Automate everything: Another lesson from the Linux philosophy

How to do fast, repeatable Linux installations

Two different business organization charts
Image by :

Subscribe now

Get the highlights in your inbox every week.

Some of my recent articles have been about the Linux philosophy and its impact on the daily activities of system administrators like myself. One of the basic tenets of the Linux philosophy is to use software leverage, and one of the important corollaries of that tenet is to automate everything.

Lots of installs

I have always had several computers (as many as 14 or 15 at one time) and, with the advent of VMware and VirtualBox, a similar number of virtual machines that I use for testing. I also install Linux on customer systems. As a result, I do frequent installations of Linux, sometimes several a day. This leads to the need to do fast, repeatable installations.

For example, I have a favorite set of configurations that I do for things like Midnight Commander. I also have a number of fonts that I like to install that are not part of most default installations. I could install each font manually using YUM and make the configuration changes to Midnight Commander manually each time I do an install, but that takes a lot of time and gets to be tedious and boring.

When I was doing all of this manually, I forgot things. I started keeping lists of things to do, but that was still time consuming. So over the years I have developed a process that ensures installations are done quickly, reliably, and without me forgetting to install or configure anything.

I first do a pretty basic installation. I configure the disk partitioning and logical volumes the way I want and I (maybe) install the KDE desktop. I do not go through the entire list of available packages or groups and try to remember which ones I want to install to get the right tools I want on my computers.

Scripting repetitive tasks

Over the years, I developed what was at first a fairly simple Bash script that I ran to do the configurations and installation of the other RPM packages that I wanted.

As time went on, that simple script evolved to allow me to tailor the standard installation based on whether they would be desktops, servers, or classroom systems. I added options that enabled me to select one or more of the several available desktop environments for installation. I created various configuration files that needed to be installed and determined that the best way to do that was to create an RPM package that included those files, some of which were more scripts that I have created over the years to perform various other repetitive tasks as well as my post-installation script.

I also expanded my script to enable the same functionality with CentOS as I had for Fedora. The RPM package is in itself a form of automation because it relieved me of the need to remember which files to install and where. The RPM package now installs about two dozen files, and the post installation script I have been improving for about 10 years is up to more that 1,300 lines of code and more than 800 comment lines.

Even using the RPM and the post-installation script, completing all of the work required to get each one of many computers I install up to my standards could take more than an hour. I certainly don't miss the days of typing all of those instructions by hand and waiting for each to complete before typing in the next one.

From desirable to necessity

Everything was going along nicely. And although I could have done all of that work manually, it has been much easier to use my automation. Fedora 21 appeared on the scene a few months ago, and the automation I have created over the years has now become a necessity.

For those of you who are not familiar with Fedora 21, the installations have changed dramatically with this release. There are now three separate installation ISO images: Desktop, Server, and Cloud. I have used both Desktop and Server ISOs for installation and I dislike them both intensely. I think the new installations are terribly limiting for the vast majority of Fedora users.

There is no simple install image. The Desktop ISO is a live image. There are no options for installing any packages during the installation except those that are in the live image ISO. None. If I want to install the KDE—or any other—desktop instead of GNOME (which I do), I have to download the KDE spin or install it after the initial installation. I cannot do it from the primary installation medium, the Live image.

I cannot even choose to install LibreOffice. There is no way to do that during installation. I have to install that and many other things after the initial installation. In my opinion this is a huge stumbling block to many would-be Linux users, especially newcomers.

Fortunately, my post-installation RPM and script allow me to do just that with very little fuss. And yes, I have had to make a few adjustments to my script—as I have with every new release—to accommodate some of the changes between releases.

My penchant for following the Linux philosophy has paid off exceedingly well for me. Because I take the time to automate everything, I have personally experienced little disruption due to a major change in the way Fedora Linux handles installations.

So here is what I have gained by automating my installations:

  • I save time on every installation.
  • Installations are consistent.
  • There is zero to minimal disruption when major changes to distribution installation are introduced.

Of course, there are other ways to do the automation of a Linux installation and configuration, and many tools that can be applied to that task, such as Kickstart, Puppet, Satellite Server, and others. I have used Kickstart extensively, but my script just works very well for me in my current environment and meets my needs—and that is the name of the game in Linux.


Warning: The Bash program described in this article is always a work in progress and may contain errors. Some of the changes this script will make to your system, such as disabling SELinux may leave your system more vulnerable to intrusion. It may not work as intended or described and you should use it only as a learning tool in the context of these articles and not in a production environment until you have thoroughly tested it and modified it as necessary for your own needs and environment.

About the author

David Both - David Both is an Open Source Software and GNU/Linux advocate, trainer, writer, and speaker who lives in Raleigh North Carolina. He is a strong proponent of and evangelist for the "Linux Philosophy." David has been in the IT industry for nearly 50 years. He has taught RHCE classes for Red Hat and has worked at MCI Worldcom, Cisco, and the State of North Carolina. He has been working with Linux and Open Source Software for over 20 years. David prefers to purchase the components and build his...