Tools Programming

The Tools Team is a critical component of any Software Development organization. Version control, build tools, defect tracking, document management, source browsers, debuggers, compilers. The list seems endless. Whether it's developing tools for in house use, or integrating and configuring 3rd party tools, a successful Tools person makes the developers more productive.


I started my career as a software developer. While I have branched out quite a bit over the years, I have always managed to do at least a few development projects a year. This is one of the things that sets me apart from others in the Configuration Management and System Administrator arenas: I'm a programmer. That's a rare combination. Many administrators can write the occaisional 20-line shell script to "automate" a process. But that's the limit. I can look at a project through a developer's eyes, determine what is needed and what is possible, and then implement the solution.

Sample Project Descriptions

My client had a Unix environment with approximately 30 servers and 500 clients, primarily SUN systems, with a sprinkling of HP clients. They were against using the NFS automounter, for reasons that are beyond the scope of this page. Managing the *fstab files on the clients was a major problem. After some research, I wrote a tool to manage the *fstab file on an individual system. The tool was invoked from cron each night, and read a master map of NFS server mount points. It then made sure that all mount points were mounted on the client, that no unexpected mounts were present, and that the proper network interface was being used on a server-by-server basis. Over time, this tool grew to be a general client management tool, collecting data and updating clients as needed on an ongoing basis. If I were to do this project now, I would probably just use cfengine, but this project pre-dates cfengine.

Start-up Needs an Installation Program

My client was a start-up. They contacted me 4 weeks before the first revision of their product was scheduled to ship, because they had no installation procedure. This was a Unix (Sun) based product that integrated with a pre-existing Oracle database. Different people within the company had certain knowledge about parts of the installation, but there was no single source who had a handle on all of the requirements. I met with everyone who had any knowledge on the subject, then wrote a requirements document/functional spec for the installation program. Once this was agreed upon, I wrote the installation program, using Perl for the pre-op and post-op scripts from the pkgadd family. Included in the installation was the complete Oracle database table creation and initial data upload. The installation program was available and tested one week before the product ship date.