Back Up GitHub and GitLab Repositories Using Golang

github logo

Want to learn Golang and build something useful? Learn how to write a
tool to back up your GitHub and GitLab repositories.

GitHub and GitLab are two
popular Git repository hosting services that are used to host and manage
open-source projects. They also have become an easy way for content
creators to be able to invite others to share and collaborate without
needing to have their own infrastructure setup.

Using hosted services that you don’t manage yourself, however, comes with a
downside. Systems fail, services go down and disks crash. Content
hosted on remote services can simply vanish. Wouldn’t it be nice if you
could have an easy way to back up your git repositories periodically into
a place you control?

If you follow along with this article, you will write a Golang program to back up git
repositories from GitHub and GitLab (including custom GitLab
installations). Being familiar with Golang basics will be helpful, but
not required. Let’s get started!

Hello Golang

The latest stable release of Golang at the time of this writing is 1.8. The package name is
usually golang, but if your Linux distro doesn’t have this release,
you can download the Golang compiler and
other tools for Linux. Once downloaded, extract it to
/usr/local:


$ sudo tar -C /usr/local -xzf 
$ export PATH=$PATH:/usr/local/go/bin

Opening a new terminal and typing $ go version should show the
following:


$ go version
go version go1.8 linux/amd64

Let’s write your first program. Listing 1 shows a program that expects
a -name flag (or argument) when run and prints a greeting using the
specified name. Compile and run the program as follows:


$ go build listing1.go
$ ./listing1 -name "Amit"
Hello Amit

$ ./listing1
./listing1
2017/02/18 22:48:25 Please specify your name using -name
$ echo $?
1

If you don’t specify the -name argument, it exits printing a message
with a non-zero exit code. You can combine both compiling and running
the program using go run:


$ go run listing1.go -name Amit
2017/03/04 23:08:11 Hello Amit


Listing 1. Example Program listing1.go

Read More

RHSA-2018:1784-1: Important: rh-java-common-xmlrpc security update

Red Hat Enterprise Linux: An update for rh-java-common-xmlrpc is now available for Red Hat Software
Collections.

Red Hat Product Security has rated this update as having a security impact of
Important. A Common Vulnerability Scoring System (CVSS) base score, which gives
a detailed severity rating, is available for each vulnerability from the CVE
link(s) in the References section.
CVE-2016-5003

Read More

Linux Mint 19 "Tara" Cinnamon Beta Released, GNU Linux-libre 4.17-gnu Kernel Now Available, NVIDIA Isaac Launches and More

News briefs for June 4, 2018.

Linux Mint 19 “Tara” Cinnamon BETA released today. Version 19 is a long-term
release with support until 2023. New
features
include Timeshift, a new
welcome screen and a revamped software manager. See the Release Notes for
more info about the release and important links. And remember, this is a BETA
release, so use it only for testing and be sure to report bugs to the Linux
Mint team.

GNU Linux-libre 4.17-gnu kernel, which removes all non-free components from
Linux, is now available. See the announcement
for all the details.

NVIDIA today announced the availability of NVIDIA
Isaac
. Isaac is “a new platform to power the next generation of autonomous
machines, bringing artificial intelligence capabilities to robots for
manufacturing, logistics, agriculture, construction and many other
industries.” At the heart of Isaac is NVIDIA Jetson
Xavier
, “an AI computer for autonomous machines, delivering the
performance of a GPU workstation in an embedded module under 30W.”

Helm became its own standalone project last week, TechCrunch reports. Previously, it was a
subproject of Kubernetes, but it’s now a separate program as it doesn’t always
follow the same release schedule as Kubernetes. Helm allows you to package up a set of requirements
into “charts”, so you can repeat the installation process in a consistent
way, this helps developers “benefit from the community, who
could build Charts for common installation scenarios”.

FreeBSD 11.2-RC1 is now
available
. This is the first RC build of the 11.2 release cycle, it
includes a “fix to flush caches before initiating a microcode update on
Intel CPUs”, “Wake On LAN features for Ice Lake and Cannon Lake devices has
been
activated” and more.

Read More

Loading Arbitrary Executables as Kernel Modules

Alexei Starovoitov posted some patches to allow the kernel to load regular
ELF binaries (aka plain executables) as kernel modules. These modules
would be able to run user-mode helper routines instead of being absolutely
confined to kernel space.

Alexei listed a variety of benefits for this. For one thing, as a user
process, an ELF-based module could crash without bringing down the rest of
the kernel. And although the ELF modules would run with root privileges, he
said that a security breach would not lead directly into accessing the kernel’s
inner workings, but at least initially would be confined to userspace. The
ELF module also could be terminated by the out-of-memory (OOM) killer, in
case of need, or ended directly by a human administrator. It additionally would be
feasible to subject ELF-based modules to regular userspace debugging and
profiling, using the vast array of tools available for that.

Initially there were various technical questions and criticisms, but no one
spoke out immediately against it. Linus Torvalds said he liked the feature,
but he wanted one change: to make the type of module visible in the system
logs. He said:

When we load a regular module, at least it shows in lsmod
afterwards, although I have a few times wanted to really see module load as
an event in the logs too. When we load a module that just executes a user
program, and there is no sign of it in the module list, I think we *really*
need to make that event show to the admin some way.

And he said specifically, “I do *not* want this to be a magical way to hide
things.”

Andy Lutomirski raised a pertinent question: why not just retool the
modprobe program to handle ELF binaries as desired, rather than doing
anything with kernel code at all? In other words, why couldn’t this feature
be implemented entirely outside the kernel?

But Linus replied:

The less we have to mess with user-mode tooling, the better.

We’ve been *so* much better off moving most of the module loading logic to
the kernel, we should not go back in the old broken direction.

I do *not* want the kmod project that is then taken over by systemd, and
breaks it the same way they broke firmware loading.

Keep modprobe doing one thing, and one thing only: track dependencies and
mindlessly just load the modules. Do *not* ask for it to do anything else.

Right now kmod is a nice simple project. Lots of testsuite stuff, and a
very clear goal. Let’s keep kmod doing one thing, and not even have to care
about internal kernel decisions like “oh, this module might not be a
module, but an executable”.

Read More