Gears of Linux automation

Automating Linux installs

Are you still running down to the datacentre to install your Linux machines with a CD? Is it still taking you hours to install a new machine? You can’t be a hyperscaler if you don’t automate your server installs.

Linux install scenario

You’ve just purchased 300 shiny new HP DL380s or Dell PowerEdge r720s. They are racked and powered on. You‘re all ready to set up your hyperscale cloud environment but you need to get them installed. Clearly it doesn’t make sense to install each one with a live DVD. The time has come to automate your provisioning.

Plan of action

All major Linux distributions are able to perform unattended installs, ie you do not need to be there whilst it is installing. If you are installing your server in a completely automated fashion, there are four distinct parts:

  • Find your server
  • Install OS onto server
  • Configure server
  • Set server live

Find server

Your friendly DCOE (datacentre engineer) phones to say your servers are racked and powered on. Your excitement is clear, but first you need to actually find your new server on the network. Or do you? By default, your servers should be set to PXE boot by default. So if you have your boot environment set up correctly, as per below, your server should come to you.

Of course you might have a server that is DOA (dead on arrival) that will not work at all. So you need to put some checks in place, so that if you have racked 100 servers you also get 100 servers built in the end.

Install server

Now that your server is trying to PXE boot from the network we can start provisioning it. Firstly, an OS needs to be installed on the box. This can be done with a scripted install. Most modern flavours of Linux come with some mechanism for doing this. Kickstart, Fully Automatic Installation (FAI) and Cobbler are popular examples. When manually installing an operating system there are a number of decisions and questions that get asked along the install. For example, how to provision the disk, what packages to install, even what users you need. With a scripted install you can provide these choices upfront in a file. Then each installation can happen the same, over and over again, with no intervention. All you need to do is update the install script as needed.

Installation with the above method is one of a few ways to provision your machines. The operating system gets built and installed just as you would with any install media but with the config decided upfront. There are other options such as creating a Golden Image. This is where you create a fully functioning server as required and then copy the disk image around from machine to machine.

Configure server

Great, once you have reached this point you should have a generic machine fully up and running. Now you can start to think about what role the server is going to take. A web server will need different packages and configurations to a database server. This is where configuration management comes in. Not an exhaustive list by any means, but popular options are Puppet, Ansible, Chef, CFengine and Salt. Whilst you could run round all the machines with an SSH loop and configure things, you will not get the consistency that configuration management gives you. Once you have your config managed, you lose the undocumented edge cases or tribal knowledge. Someone can join your organisation tomorrow and build a box the same as anyone else.

This does require discipline when in place though, so that no further manual changes are made to boxes.

Set server live

This might sound trivial but it’s important to get this right. A new box that is not configured correctly is going to cause errors for a user somewhere. Make sure that all your automated magic has actually completed without errors. Make sure you turn monitoring on for that machine and that it passes all the tests. Only then set it live.


There are many ways to automate your installs, but the point is to do it. Many people argue that creating the install environment is too time-consuming and that a USB stick works well enough. They point out that they only have a few machines, so it is not worth it.

Never underestimate how much admin time is wasted debugging nuances in your server farm that should not even be there. Being able to quickly and easily roll forward and back your changes can really save you time and money. For more information, contact Hyperscale IT on +44 (0)207 514 5683 or

We’re interested in your thoughts. What route have you taken, for good or bad?

Leave a Reply

Your email address will not be published.
You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>