oreilly.comSafari Books Online.Conferences.


Automating Network Administration, Part Two

by Luke A. Kanies

We've already discussed the merits of automation and how you should always plan your automation. Now we're going to discuss where it all starts: server install time.

Start At the Beginning

Remember how planning and automation both feed on themselves so that the more of them you do, they easier they become? The opposite is also true: the longer you neglect them, the harder they become. That in itself is a problem, but when you don't plan or automate the installation of your servers themselves, you put yourself in a catch-22 where out of the gate you have a lack of consistency, understanding, documentation, and everything else that planning and automation provide you. The minute you first deploy your servers you're already behind in automating them, because they were built without a plan, which almost by definition guarantees that they were not built in the best manner, and they were also built with all the same potential for human error and lack of consistency that the lack of automation provides in an existing network.

The biggest problem with not planning and automating your system installs, though, is that you usually have absolutely no excuse not to do so. For most systems, you get adequate warning; so you can spend some time planning the install, and Unix is scriptable enough that you should be able to automate a significant amount of any server installation. You don't have all of the standard barriers of not wanting to work on production systems or being short on time -- system administration is usually full of lulls and crunch times, and if you automate during the lulls, then you will be able to significantly reduce the crunch times.

Planning and automating your server installs rewards you in ways that they usually don't with other aspects of your network, though. I can't count the number of times I've seen companies do a vanilla install of everything that comes with their OS, because when they tried a minimal install the compiler didn't work, and they didn't want to take the time to figure out what little OS package to add to fix the problem. This full install takes up more hard-drive space, results in more software to be patched, and often ends up with a less-secure system. Not having an automated server install also makes you less likely to install appropriate tools onto the server, because of the added effort. Basically, a lack of automation in the install process means that you are likely to spend the same amount of time on each server but end up with a machine that doesn't fit your needs, whereas automation requires significant time up front but results in a shorter turnaround time for each individual build and a resulting server which exactly meets your needs by having everything you want and nothing you don't.

Getting To the Point

Previously in this series:

Automating Network Administration, Part One -- Any task that is carried out by a system administrator more than once is a candidate for being automated. Luke A. Kanies explains how important automation and planning are to a sysadmin.

Now that I've convinced you that automation and planning are the key to maintaining your network, I'll get to the real point of this article. If you research and plan your server and then build an automated system to execute that plan, you will end up with a more secure, more stable server which you will understand more thoroughly and on which it is much easier to automate ongoing maintenance. And remember that our whole goal now is to automate our network, so the ability to automate should be a defining characteristic of our network.

What is there to plan about building a server? Plenty. In addition to deciding exactly what OS software to install (you really don't want to install the entire OS on a server), you also need to plan all of the configuration details (what is your patching scheme? naming scheme? IP addressing scheme?), your filesystem layout, and then you need to plan exactly what non-OS software you want to install. Do you need ssh? (Yes, you do.) Tripwire? TCP-wrappers? What management tools will you need to do your job? What about security auditing, performance monitoring, scripting, and reporting? Are you going to install a compiler, or are you going to have a central compiling and packaging server?

Related Reading

Running LinuxRunning Linux
By Matt Welsh, Matthias Kalle Dalheimer & Lar Kaufman
Table of Contents
Sample Chapters
Full Description
Read Online -- Safari

These are all questions you should ask yourself anyway; I'm merely saying that you should ask these questions before you build any servers, so that all of the servers you deploy will conform to your plan. Of course, most of us started work at companies which already had servers, and we won't get the opportunity to rebuild them any time soon. This plan is still important, though, because it gives us an ideal to shoot for, and we can slowly massage existing servers towards that ideal. Hopefully, the methods we use to do this massaging will the be the same methods we use to install the servers when we finally get the opportunity. Planning what you want your servers to look like is never a bad idea, even if you can't do it right now. And once you have an installation plan and the tools to implement it quickly, you will be much more likely to be given permission to rebuild a server to fit into your planned network.

Pages: 1, 2

Next Pagearrow

Sponsored by: