Monthly Archives: September 2016

How to Effectively and Efficiently Edit Configuration Files in Linux


Every Linux administrator has to eventually (and manually) edit a configuration file. Whether you are setting up a web server, configuring a service to connect to a database, tweaking a bash script, or troubleshooting a network connection, you cannot avoid a dive deep into the heart of one or more configuration files. To some, the prospect of manually editing configuration files is akin to a nightmare. Wading through what seems like countless lines of options and comments can put you on the fast track for hair and sanity loss.

Which, of course, isn’t true. In fact, most Linux administrators enjoy a good debugging or configuration challenge. Sifting through the minutiae of how a server or software functions is a great way to pass time. But this process doesn’t have to be an exercise in ineffective inefficiency. In fact, tools are available to you that go a very long way to make the editing of config files much, much easier. I’m going to introduce you to a few such tools, to ease some of the burden of your Linux admin duties. I’ll first discuss the command-line tools that are invaluable to the task of making configuration more efficient.

Let’s begin.

diff

If you’ve never used the diff command, you don’t know what you’re missing. The gist of diff is simple: It compares one file against another and displays the differences. Let me explain.
Say you have two files. File1 has the contents:

<Directory “/var/www”>

     AllowOverride None

     Require all granted

</Directory>

File2 has the contents:

<Directory “/var/www/html”>

     AllowOverride None

    Require all granted

</Directory>

If that’s all those two files contained, it would really simple to open them up and see the diff. But what if those lines of code were buried within thousands of other lines and interspersed with comments and other options? All of a sudden, that task becomes a bit more daunting.

Thanks to diff, we can find these differences easily. If we open up a terminal and issue the command diff File1 File2, we’ll see the output clearly displaying the differences (Figure 1).

What you want to look for are the letters a, c, and d, where:

  • a means something was added

  • c means something was changed

  • d means something was deleted

In this example, you see 1c1, which means line 1 was changed in the second file.

The diff output is a bit cumbersome because it was actually intended to be read by the system, not humans. The intention of diff is to show what would need to be done to the files to put them in sync with one another. What is important in the output, however, is that it will only output the lines which are different. In our example, everything in the file is identical except for the first lines, where you have “/var/www” in one and “/var/www/html” in the other. Using diff makes it incredibly easy to find out the differences between two configuration files. Of course, diff is much more complex than that, but understanding this very fundamental usage of the tool will help you tremendously when comparing two files.

If we change File2 to reflect:

<Directory “/var/www/html”>
    AllowOverride all
</Directory>

The output of diff would then a bit more complex. For that, we might want to run diff -c File1 File2. The c option prints the output in context format, which makes it much easier to read (Figure 2).

Here we see diff reporting that lines 1 and 4 in File1 and lines 1 and 3 in File2 do not match. You can now make those changes.

grep

The grep command should be one of the first tools you learn as a Linux administrator. Without it, you will find yourself searching for the proverbial needle in a haystack, especially when digging around more extensive configuration files. Say, for instance, you want to disable the EnableSendfile in your CentOS Apache configuration. You could open up the /etc/httpd/httpd.conf and then scroll through until you see the entry, or you could issue the command grep -n EnableSendfile /etc/httpd/conf/httpd.conf.

What grep does is print lines matching a pattern. It’s that simple. However, if you add the -n option, grep will also print the line number for which the pattern can be found. In our example, grep outputs that EnableSendfile is found on lines 340, 346, and 349 (Figure 3).

 

If you happen to use a text editor, such as nano, you can open up the /etc/httpd/conf/httpd.conf file, scroll down a bit and hit Ctrl-c to report what line number the cursor is on. Keep scrolling until you find the line you need to edit. You can also open up the file with nano, using the -c option, to display the current line number (without having to hit the key combination — Figure 4).

The grep command is incredibly powerful. Make sure to view the man page (man grep) to learn everything you can about this helpful tool.

Find a good GUI

Some people would rather spend their time with a GUI tool than the command line. Although I highly recommend you fully understand how to work with the command line, there are instances where a GUI can go a long way to make this process easier. Take, for instance, the Gedit text editor. With this GNOME-friendly editor, you can set syntax highlighting on the fly to easily suit the configuration file you’re working with.

Suppose you open up /etc/httpd/conf/httpd.conf in Gedit. Because this particular file is just a basic text file, Gedit will open it set on Plain Text (in other words, no syntax highlighting). You can switch that from the drop-down in the bottom toolbar and select the type of syntax highlighting you want. If you switch it to PHP, anything that could be viewed as a PHP element will be highlighted (Figure 5).

There are plenty of solid editors out there that will aid you in making cumbersome configurations a bit easier. Start with the tool included with your desktop and see if it will do the trick. If not, open up your package manager and see if you can find one that might fit your needs (such as Sublime Text, Geany, or Leafpad).

Don’t let it overwhelm you

With just a few simple tools, you can make the process of editing Linux configuration files quite easy. Start out with these three tools and build from there. Eventually you’ll have a toolkit so powerful, you’ll be editing config files like a pro. And don’t forget to RTFM!

Want to learn more about managing your configuration files? Check out the Essentials of System Administration course from The Linux Foundation.

 

6 Things That Ubuntu Does Better Than Windows


By downloading this free guide, you agree to receive regular updates on the latest cool apps, product reviews, and giveaways from MakeUseOf.

We all love Windows, right? It’s a great operating system, there’s no doubt about that. However, what if I told you that Ubuntu was better? You may laugh and think that nothing could possibly be better than your beloved Windows, but in this article we’re going to look at 6 reasons why Ubuntu is better than Windows.

Some of you may think that Ubuntu is just for nerds, and that the average user wouldn’t be able to use it. So how on earth could it be better than Windows? Well the truth is that Ubuntu is not that difficult to use, in fact, it’s actually just as easy as Windows to use, if not easier in some respects. So then, let’s take a look at some of the reasons why Ubuntu is better than Windows.

Related posts

Dig into DNS: Part 4


Previously in this series (see links below), I’ve described the dig utility and its many uses in performing DNS lookups, along with several examples to help solve specific problems. In this final installment, I’ll look briefly at some security options and wrap up with additional examples.

All Secure Here

Many of you will have come across DNSSec in the past. It’s not an area that I have explored in great detail, I admit, but as you would expect the excellent dig utility takes the securing of DNS in its stride with the following option:

# dig @8.8.8.8 chrisbinnie.tld A +dnssec +multiline

where I request an “A” record and any associated DNSSec records with it.

We can see the inclusion of DNSSec records in Figure 1. For clarity, we are purposefully interrogating a non-existent domain name so you can see the response from the a root server (a.root-servers.net) again.

Custom Fitted

To facilitate those readers with a compulsive, painstaking need to make certain configuration changes with the dig utility, there’s a config file option which reads from within a user’s home directory, named as follows:

# cat ~/.digrc

+nocomments +recurse +multiline +nostats +time=1 +retry=5

As you can see, my “.digrc” file is simple and to the point, but it keeps the output straightforward. Note that the standard “A Record” is the default lookup unless another type of record is specified such as “MX” etc. That might affect how much information you usually want from your output, and thus how you set up your “.digrc” file, should you be looking up less popular record types more frequently.

Negatory

It would be remiss not to mention at this stage that I have intentionally — to keep things simple for newcomers to the dreaded DNS realm — so far not mentioned the fact that each and every one (barring a couple exceptions where it simply wouldn’t make sense) of the powerful dig utility’s command-line options can be negated with a prepended “no”.

A simple example, which I will leave you to apply to your heart’s content, might be as follows:

# dig chrisbinnie.tld +notrace

I’m sure you get the gist and that any further explanation would be futile. You can try any of the other options with a “no” in front if you’re unsure.

Eggs, Beans, Spam

With the viral outbreak of spam during the latter years of the Internet, clearly it’s critical that the largely successful attempt by the community to suppress it within DNS be integrated into the dig utility.

Step forward TXT record checking. You can either point at a “@server” to query directly or use something like this in the same format as before:

# dig chrisbinnie.tld txt

If you look closely at the ANSWER section, the IP addresses that SPF (Sender Policy Framework) pays attention to should be fairly obvious. In brief, this shows which IP addresses are authorized to send email on behalf of a domain name amongst other settings. Another important parameter is how strictly to enforce such settings before bouncing or blackholing an email as spam.

Suit Yourself

In keeping with the truly accommodating perspective with which the dig utility was written, there are also a couple of useful options that have caught my eye in the past.

First, the try-hard dig utility offers the ability to look past any malformed or corrupted responses received from name servers with the following option:

# dig @8.8.8.8 chrisbinnie.tld A +besteffort

In other words, this says to display some corruption if it exists, even if the output is a little nonsensical, in the hope that some useful information might be gleaned. You might see why this could be very useful if I mention that the dig utility even pays attention to non-ASCII based domain names.

Referred to as IDN Support, (which the manual reports is Internationalized Domain Name Support), the mighty dig tool can covertly change its character set before receiving an answer or sending a question to an international name server. On today’s Internet, this is of significant value and will likely only become more useful in the future as international languages meld further.

Actually, It’s A Feature

One concluding note, which I enjoyed reading from the June 30th, 2000 version of dig’s man pages, was at the foot of the information under the “BUGS” section. This line might be read differently on a number of levels but expresses simple sentiments if read literally.

The BUGS section of the manual is usually a way of briefing declaring known issues. In dig’s case, however, the line “There are probably too many query options.” is all that exists.

I’m afraid that on the surface I would have to agree, but I suspect that, at one stage or another, each one of those DNS options has been very useful to someone, somewhere. I mention this because it’s not always obvious how far to delve into DNS, even when faced with relatively complex scenarios such as using name servers for failing-over between web servers. Be assured, however, that whatever you need from a DNS query, the ever-faithful dig utility will almost certainly provide it, in varying levels of detail, to suit your preference.

Summary

I have barely scratched the surface of the dig utility’s feature list and how DNS actually works. If you are new to working as a sysadmin, there will likely be many opportunities for you to learn DNS and evolve your knowledge over time.

My hope in writing these articles was to give you the confidence required to turn to the dig utility if you ever need to query DNS in detail. And, having written this series, I have come to realize that “dig www.domainname.tld” is actually shorter than using the “host” command alternative. You never know, maybe my daily DNS habits have been changed forever as a result, and I will turn to the dutiful dig over the “host” command from now on.

Read previous articles in the series: Part 1, Part 2, and Part 3.

Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.

Learn more about network and system management in the Essentials of System Administration training course from The Linux Foundation. 

Linux Foundation Certified System Administrator: Muneeb Kalathil


The Linux Foundation offers many resources for developers, users, and administrators of Linux systems. One of the most important offerings is its Linux Certification Program, which is designed to give you a way to differentiate yourself in a job market that’s hungry for your skills.

How well does the certification prepare you for the real world? To illustrate that, the Linux Foundation will be spotlighting some of those who have recently passed the certification examinations. These testimonials should serve to help you decide if either the Linux Foundation Certified System Administrator or the Linux Foundation Certified Engineer certification is right for you. In this installment, we talk with Muneeb Kalathil.

How did you become interested in Linux and open source?

I started using Linux when I was in school. But at that point, I was limited to Installation and running a few commands. I really started learning and growing my interest in Linux while I was working on my degree in Computer Applications. My first distribution was Red Hat CentOS. I spent many hours learning Linux and enjoyed it.

What Linux Foundation course did you achieve certification in? Why did you select that particular course?

I attended Introduction to Linux on edX and Essentials of System Administration, which comes with the LFCS Exam Registration. Thanks Linux Foundation for the course.

The Introduction to Linux course is perfect for anyone who is just starting out with Linux. Essentials of System Administration is an Intermediate course, which helps with the LFCS Exam and most system administration tasks. My work experience also helped me in achieving LFCS.

What are your career goals? How do you see Linux Foundation certification helping you achieve those goals and benefiting your career?

I love IT. I really love to learn and work with various technologies: servers, networks, DevOps, virtualization, clouds, etc. I think LFCS is my first step. This is my first Linux certification. It is from The Linux Foundation — a name that says everything. I am sure it will help me a lot in my future career.

What other hobbies or projects are you involved in? Do you participate in any open source projects at this time?

I love to learn new things as well as implement the experience I’ve gained. I do some personal projects, mainly scripting for automation. I would love to participate in some open source projects (I’m just not sure how great my programming skills are. 😀 )

Do you plan to take future Linux Foundation courses? If so, which ones?

I am planning to take the LFCE exam. I would also love to take courses on OpenStack, KVM, and SDN. Cost is the major setback for me at present.  🙁

In what ways do you think the certification will help you as a systems administrator in today’s market?

I always love certification. It is some sort of proof, that we know something. LFCS is provided by The Linux Foundation and it offers such great value. Since LFCS is a practical exam, it allows us to do the tasks, not just select answers. This adds more value to the certification.

What Linux distribution do you prefer and why?

In our company, we use Ubuntu/Fedora/OpenSUSE for various services. For desktop, I always prefer Ubuntu. Servers for small to medium organizations, also Ubuntu. Why? Ubuntu is easy to install and configure. For larger organizations, I prefer Red Hat/CentOS/OpenSUSE. Why? server hardware support.

Are you currently working as a Linux systems administrator? If so, what role does Linux play?

I am working as a Network Engineer. I manage Linux servers, firewalls, network monitoring,  system, and other services (where we only uses open source solutions).

Where do you see the Linux job market growing the most in the coming years?

Linux and open source are the future. There is no doubt about it. Linux has already got a larger share in servers. Cloud, DevOps, IoT skills are going to be the real job market in the future.

What advice would you give those considering certification for their preparation?

The first thing is time management. You need to complete the tasks within two hours. Some of my personal suggestions are:

  • Finish first the tasks you know well

  • Don’t try to configure interface using tmux or screen

  • Check man pages (but don’t check for every command)

  • Time … Time…

  • Learn every small thing

  • Everything is important in the exam and more than that, it will help in your work

  • Go through all the exam objectives

Learn well and practice… practice… Best of Luck 🙂

Read more:

Linux Foundation Certified System Administrator: Theary Sorn

Linux Foundation Certified Engineer: Ronni Jensen

Linux Foundation Certified System Administrator: Elyasin Shaladi

Linux Foundation Certified System Administrator: Lorenzo Paglia

Linux Foundation Certified System Administrator: William Brawner

Linux Foundation Certified Engineer: Ansil Hameed

Linux Foundation Certified System Administrator: Adedayo Samuel

Linux Foundation Certified System Administrator: Dashamir Hoxha

Linux Foundation Certified System Administrator: Chris van Horn

Linux Foundation Certified System Administrator: Joshua Tang

Linux Foundation Certified System Administrator: George Doumas

Linux Foundation Certified System Administrator: Jorge Tudela Gonzalez de Riancho

Linux Foundation Certified Engineer: Francisco Tsao

How to Easily Roll Back Changes with Snapper


One thing a Linux sysadmin must know how to do is recover from a change gone bad. It happens. You install, upgrade, or configure a system or service and things immediately go wrong. What do you do? If you’ve made a copy of the configuration file, you’re okay. If the software didn’t install too many dependencies (which could have, in turn, caused a systemic issue), then you can simply uninstall. But, there are times when you will want to be able to easily roll back those changes.

If you happen to be employing the Btrfs filesystem, this isn’t a problem. With Btrfs, you have access to an amazingly handy tool called Snapper that allows the taking of snapshots and rolling back to those snapshots (in the event of an issue). Snapper is a command-line program designed for filesystem snapshot management that allows you to create, delete, and compare snapshots as well as undo changes made between snapshots.

In this tutorial, I will walk you through the process of rolling back changes with Snapper, and I’ll be using the latest release of openSUSE Leap. It should also be noted that openSUSE and SUSE both offer a YaST plugin for Snapper that makes this process even easier. Before you venture into the land of the GUI, it’s always best to understand the underlying command first.

First steps

My test bed was a fresh install of openSUSE Leap. Because this was a fresh install, no Snapper configurations were available. You could open the YaST tool, go to Miscellaneous > Snapper and YaST would error out. To fix this, all you have to do is run a system upgrade with zypper. So, the command zypper upgrade would not only upgrade the system, it would create a Snapper configuration for /. You could also do this manually with the command:

snapper -c root create-config /

The above command creates a new configuration file, named “root” for the root directory (/). Configurations are crucial to Snapper; so much so that, without them, you’ll get nowhere. Fortunately, having a root config is all you need for basic usage of Snapper.

If you issue the command snapper list-configs, you’ll now see there is at least one configuration listed (Figure 1).

If you issue the command snapper-list, snapper will reply by listing all of the currently saved snapshots. If this is a fresh install, chances are there aren’t many… or any. Let’s create one.

Creating a snapshot

Suppose you’re about to install Apache and you want to first take a snapshot of the system before you install the web server. Everything on the server is running great and you’ve yet to install Apache. Let’s take a snapshot. Here’s the command you’d use:

snapper create --type pre --print-number --description "Before LAMP install"

Let’s break that command down.

  • snapper: That’s the command. Simple.

  • create: This tells Snapper you are going to create a new snapshot.

  • –type pre: This tells Snapper you’re creating a snapshot prior to changes being made.

  • –print-number: This instructs Snapper to print out the number associated with this snapshot (you will need this when creating the related post snapshot). This number is important.

  • –description: This is the human-readable description of the snapshot (very important in helping you discern which snapshots are associated with specific changes or periods).

Now that you have the pre snapshot created, do whatever it is you need to do to the server (for our example, installing Apache). Once that task is complete, you have to then create an associated post snapshot. You see, for every important change on your server, you’ll want to create a pre and post snapshot (pre before you make a change, post after you make the change). That is how you can then roll back the changes.

To create the post snapshot, you’d issue the following command:

snapper create --type post --pre-number X --description "After the Apache install" 

Where X is the number printed out when the pre type snapshot was created.

Remember, in creating the pre snapshot, Snapper will print out the ID number associated with the first snapshot… that is what you’ll use for –pre-number variable. Issue the command snapper list and you will see the pre and post snapshts listed (Figure 2).

Checking changes

This is where things start to get really handy. You can instruct Snapper to list out all changes made to the system between snapshots. So we have a pre ID of 2 and a post ID of 5. What alterations have been made? Issue the command snapper status 2..5 and the output will list every change (Figure 3).

In the far left of each line, you’ll notice a + symbol which means whatever follows was added. A c would indicate change and a – would indicate a deletion.

You can also run a diff on a specific file. Suppose you notice a c for the line /etc/sysconfig/apache2 and you want to know how that file was changed. You can issue the command:

snapper diff 2..5 /etc/sysconfig/apache2 

The diff command will then run on the /etc/sysconfig/apache2 file, comparing it between pre and post Apache install. You can also run snapper diff 2..5 without a file name to get a diff of every change made.

Undoing changes

With the help of diff, you’ve managed to figure out where the problem lies and need to undo that change. This is actually really simple. Let’s say, for the sake of example, the problem lies in the /etc/sysconfig/apache2 file. To roll back to the pre state, you would issue the command:

snapper -v undochange 2..5 /etc/sysconfig/apache2

The above command would revert the /etc/sysconfig/apache2 file from the post snapshot state to the pre snapshot state (in this case, before Apache was installed).

It’s really that simple. Even without making use of the YaST Snapper plugin, you’ve rolled back changes using nothing but the command line.

Pure power

With Snapper, you have pure power at your fingertips. With just a few quick commands you can take snapshots, compare snapshots, and rollback changes from one snapshot to another. Once you’ve mastered the Snapper command, make sure to take a look at the YaST Snapper plugin; you’ll find it offers the same power, in an easier to use GUI form.

To learn more about Snapper, issue the command man snapper and behold the sum total power that tool has to offer.