fbpx

Let’s setup a Git repository

The sooner you get used to storing your Bash scripts in Git, the better. Version control of your code simplifies future improvements and you can keep track of all changes in an organized fashion. It also allows your peers and colleagues to read the logic you used when you developed your scripts.

Let’s setup your first Git repo:

Enter the directory where the repository will be located.

  • Run git init
  • Copy your source code file(s) (or write a first file) into this directory.
  • Run git add *
  • Run git commit -m “Enter information about the script and any changes here."

That’s it! You just created your first Git repository. Let’s take a closer look at the directory .git that was created when you ran git init. We will look at some very important files and directories, to quickly understand the basics of Git.

description – This file contains a text summary of the project. Enter some text at will.

config – This file contains settings for the project. Here you will find Boolean variables and numeric values.

hooks – This directory contains Shell scripts that run before or after events, for instance commit or add. When you first create a Git repository you will find sample scripts here, for commit, push, rebase etc.

objects – This is where Git stores the internal data for the objects stored in the repository. This is the “useful” data, your source code.

There are several more files and directories, but the above cover the basics fairly well. Over time you will work extensively with Git hooks to customize triggers during Git events.

Well done. You have just started using Git. The first and most important step is done. Now you can start looking into the Git commands by typing git help. Hint: You want to learn how to use Git hooks to automate steps in relation to Git events.

Is MariaDB just a binary dropin replacement? Features for datawarehousing and low latency say otherwise

MariaDB is a binary dropin replacement for MySQL. So goes the old marketing message. That is all fine, but what has changed for you who work with database development and administration? There are some very crucial high level differences that come into play. Whether you are into datawarehousing or low latency solutions, MariaDB has something to offer. But you want to think twice before running a mixed environment with MariaDB and MySQL..

The Replication Matrix

MariaDB.com has a replication compatibility matrix that shows compatibility issues that you have to consider if you are planning on running both MariaDB and MySQL in the enterprise. You might find that using MariaDB as a master and MySQL as a slave in asynchronous replication setups is a challenge. Check out the matrix.

If you want to transition to MariaDB and do it the simple way, you want to design a large scale migration of all your MySQL servers. You also want to be aware of the Group Commit feature for the binary log. The purpose is to make sure that after a server crash, any transactions that were reported as committed before the crash will remain in the database after disaster recovery. Without the Group Commit feature, you can run into the situation where transactions in the binary log are missing. This will effectively break migration for slave servers in the storage engines InnoDB and XtraDB.

Storage engines and more in-depth logging

MariaDB added more than twice the number of storage engines to this list. A few of these stand out as they cater to special needs such as data warehousing and low latency data transfer speeds:

If you want an older overview of the differences between MariaDB and MySQL, Admin-Magazine.com has an interesting read.

How did systemctl/systemd change the way your Linux workstation boots up?

So you’ve been starting and stopping your daemons with /etc/init.d scripts. Stubbornly you hold on to reaching for those gems in /etc/init.d/ over and over. But you know about the service program. How sweet it is to just type service apache2 status and see the output rushing past in the terminal.

A reinvented wheel? Well..

But then something happened. There was a new Linux boot time player in town and its name was systemctl and plenty of Linux users did not use it at once. “Seriously”, some thought to themselves – Another utility to start and stop daemons?! Well yes, but also no. For us that were used to calling init.d scripts directly or use the service utility, it seemed like here was another solution to do exactly the same thing. Woe. Haven’t we seen this so many times in the world of Linux. But it turns out that systemctl does more than that. It’s part of the systemd initiative which was an init replacement daemon. Systemd which controls and manages user services is meant to replace the init daemon.

Systemctl deals with the Kernel Panic

The goal was to start processes in parallel. This was to avoid the much too familiar Kernel Panic error that occurs when the init daemon could not start for some reason.

Systemd, or the System Management Daemon, is also the parent of all other processes. The key difference here is that it uses parallel processing during boot. It doesn’t stop there though. Systemd added plenty of new features as compared with Upstart on Ubuntu. Systemd will only start processes if they are depended on by another programs at startup. Compare that with Upstart which would power up all startup events as fast as possible.

The transition solution came in Ubuntu 15.04, it was possible to switch between upstart and systemd. Both packages were installed. From then on Systemd was accepted by several major distributions. We now see CentOS (and RedHat), Debian, Slack, and Ubuntu using systemd as well. That is a pretty major shift in the way of handling system startup across Linux distributions.

Changes that stretches further than start/stop/status

The changes that came with Systemd stretches far. For instance, Systemd is not POSIX compliant but does use the Unix Domain Socket. Fedora was the first distribution to feature Systemd but many others followed suit.

Some say nay to Systemd

Yet there are critics to systemd.. Some say that systemd is way too complex and “violates the design principle of Unix-like operating systems” (see Systemd criticism section on Wikipedia for full context). So when you fire up that Apache2 daemon next time, remember that you can do more than that. There’s the possibility to see dependencies, the possibility to queue jobs according to already queued jobs, and more. You can tailor a Linux startup in great detail with Systemd. Read more about Systemd at the Fedora project.

89% of hiring managers struggle to find talent

When Dice and Linux Foundation conducted their annual jobs report, the findings showed the challenges for recruiting companies.

89% of the hiring managers struggle to find candidates with the approriate skillset. 2,000 open source professionals were asked to provide their insights for the annual report.

Drilling down into the statistics it turns out that 60% of the positions are DevOps, and 53% are system administrators. This is certainly something for you to keep in mind as you work away on the commandline in Linux!