Foreword

When I graduated from MIT in 1990, I joined the MIT Network Operations Group . It was there that, among other things, I started working on the Linux kernel as recreational programming. During my time with the Network Operations Group, I learned what it was like to have operational responsibilities. This is a valuable perspective that all developers should be exposed to, if only briefly .

During my first year or two with the Network Group, we evaluated a commercial network management system. Out of charity, I will not reveal the name of the product nor its vendor, but suffice it to say, it was a very complicated beast , which required huge amounts of disk space and computing power. It would display a picture of the campus, which when you clicked on a building, would zoom in and allow you to select a floor and display a floor plan, at which point you could click on a room, and finally, select a piece of network equipment. When selected, a picture of the device would appear, complete with flashing LEDs, which were emulated via SNMP monitoring. If there was a problem with a router, it would cause an alarm to ring and, on the campus map view, the building containing the bad network device would flash. If the building map was displayed, the floor with the problem would flash, and so on, until the faulty router was identified.

Unfortunately for the vendor of this very complicated, proprietary, network-management system, an experienced network engineer could localize the problem faster using simple tools like ping, traceroute, and an ASCII terminal. This was advantageous to us because we could also use them when we dialed in from home at 3 a.m.

Even implementers of this product realized how outrageous the entire interface was; rumor had it that by setting a certain magic configuration variable, the interface would display a picture of the Milky Way, and you could zoom into our local group of galaxies, pick our home galaxy, the star system on the edge of that galaxy, and so on, before finally zooming into the campus map level. No doubt it was the implementers' private protest against the set of requirements handed to them by some fuzzy-cheeked product manager who, obviously, had never configured a router or repaired a malfunctioning network in the middle of the night.

Not surprisingly, we decided to skip purchasing this very expensive, very unnecessary network management system. Instead, we stuck to our own collection of tools; some of which were freely downloaded from the Internet, and some of which we developed ourselves .

My personal contribution to this set of tools was the "ninit" program, a very simple tool. It watched over the named program, and restarted it if the need arose. It also collected periodic statistics, and tested the named program every 15 seconds to make sure it was still functioning correctly and responding to queries. If not, ninit would kill of the named process and restart it.

The ninit program was made famous in the Unix Haters Handbook (IDG Books, 1994), where it was lampooned as a demonstration of how unreliable Unix software is ”or perhaps all software from BSD; or perhaps just Named ”because it needed a watcher process. The Unix Haters may have had a point, but the ninit program was short, and it was sweet, and it restarted the name service on our servers at 3 a.m. so I didn't have to be awakened by a pager after our mail queues had exploded due to a lack of name service.

Many other people have advanced other explanations for the superiority of Open Source software, such as Linus Torvalds' observation that "with enough eyeballs, all bugs are shallow ." While this is true, I think it is the last point which is the most important for explaining why Open Source network management tools work as well as they do: When the person to be aroused from bed to fix an operational problem is the person writing the tools, the very tight accountability loop means that they might not be architecturally beautiful (although often they are), nor have fancy graphical interfaces (very often not necessary), but they will certainly solve the problem at hand.

This book is a wonderful survey of a wide range of Open Source network management tools. Some of these tools may be well known to you already; others may be entirely new to you. All of them are extremely useful to a network operations team. I hope you enjoy going through these tools, and I encourage you to try them out in your own work. If you haven't tried some of these tools yet, you will be in for a very pleasant surprise.

Theodore  Ts'o
Linux  Kernel  Developer
August  25,  2003