fbpx

Author: Teach

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.

5 reasons for you to store your Bash scripts in Git repositories

1 Maintain a history of your script improvements – Force yourself to continuously improve

Git will help you to get a clear overview of how your scripts have evolved. Maybe you need to go back a version or two and fork a script from there. If you have added proper comments in your scripts, than you and others can follow your reasoning easily.

A funny thing happens when you start adding code in Git repositories and update them as you add or change code. You become more prone to improving your code as you know which parts needs some more work. Maybe even a #ToDo note somewhere that signifies a totally new feature – That #ToDo comment will nag you more when you have a Git repository and constantly go there to check it out. Add the reasoning in reason number 2 and you also feel the peer pressure from others to continue building on your useful scripts.

2 Others might take over your scripts for regular usage

Think of the Linux users that you will work with and that will need the same toolchest that you have. Show some team spirit and share your work, of course with proper attribution to you as a script programmer. This gives you a lot of respect

3 Understand the fallacy of “the perfect script” thinking

There are no perfect scripts. No silver bullets to any IT problem of a larger scale. In the Linux world we are also used to many ways to solve simple tasks on the commandline in many ways. This statement can then be used to argue that your solution has no need to be hidden away or not to be covered by version control. With version control you introduce the idea of newer and better versions of your Bash script. It is a nice trick to show yourself and others that yes, improvements and new ideas are welcome.

4 DevOps and Test-Driven Development ask for iteration and cross-border approaches

These two paradigms really show that more collaboration is expected between subject matter experts, whether a Linux user, a Python scripter, or a LAMP Engineer (to give only three examples). We get inspiration from each other’s solutions to tasks on the commandline. These solutions are stored in Bash scripts. By using Git you show that you are open to the idea of sharing your scripts as well as reject the notion of the “write once, all good, don’t argue” type of mentality.

5 Git is used to version control more than you think

These days you will find that Git is used by many more than programmers. From technical writers to scripters and data scientists. The idea of applying version control and having central repositories that can be forked and worked on by many people is simly very appealing. It also deals with the number one silo: The expert that sits on all the knowledge but that is so tremendously useful to others as well.

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 To – Get a grip on those network connections with pstree and lsof -i

As you know, you can string Linux commands together to achieve larger and more complicated tasks. Here we will look at locating processes that are connecting over the network. We will see how to locate established and listening endpoints.

We will also print process trees to understand how Apache2 forks processes to do load balancing of network connections.

First, let’s check all open files that are Internet addresses. All network connections will be identified by a network file (such as an Internet socket, which we are interested in here).

NailLinuxExam – Check those open network connections!