Title: Building a Tool from Other Tools

If there is one thing that characterises system and network administrators it is probably a tendency to collect and create tools. All too often there either is no existing tool for a task, or it does not fit in a particular situation well. Now that I am administering an NT network full-time, I choose shell scripts, AWK, or PERL to bind (or bend) existing tools to my will. However, there are times when compiled C is a better choice. I use C when a project meets one or more of the following criteria:

A recent task I had which required C was to put a convenient NT/Windows 9x face on the Unix vacation program. The vacation program is used to set 'away from mail' messages and mail storage and forwarding instructions. Normally this is done from a Unix command prompt. However, we have a number of users who have absolutely no need to connect to Unix except for this purpose. Since they do not get many vacations each year, they are never very confident. An additional complication is that the basic account configuration on the Unix system does not define an editor, and relies on the system default of Vi. This is about as far from the Windows editing environment as it is possible to get. Since the Unix administrators took the 'let them eat cake' approach to my suggestion that neophyte users deserved a gentler environment, I decided to build a basic tool to do the job from the NT/Win9x side^[1]. This is perceived as being easier to learn by most of my users than running a telnet session to a Unix machine and remembering or looking up unfamiliar command syntax.

Our environment does not support either Samba (NT filesystem under Unix), or Services for Unix (Unix filesystem under NT). This prevents direct access to the '.vacation' and '.forward' files in the user account that control mail handling. However, 32-bit Windows operating systems do provide a scriptable command-line File Transfer Program (FTP). Using this existing program avoided the need to obtain or create and test an FTP library. It did raise a security issue in that the username and password have to be embedded in the FTP script^[2].

The basic program was implemented as a console application using a simple program loop to display a screen of status messages and a menu of options. The user selects and configures the settings from the menu, which builds a list of FTP commands in memory. When the user decides that the configuration is complete, the final option writes the script to a file, spawns the FTP program to run the script, and then erases the script. Any user edits of the vacation message content are handled by spawning the standard Notepad editor with the P_WAIT flag to ensure that the modifications are saved before the controlling program continues. Without this precaution, it would be possible to attempt a transfer of a file opened for edit (which would probably fail due to an access error).

Once the user has provided a username and password for their Unix account, the program can use FTP to obtain several pieces of information. By issuing a PWD instruction and parsing the return, the program can determine the user's home directory at login. The location of the mail directory can be verified by a similar method. Any existing '.forward' and '.vacation' files can be downloaded, or deleted to cancel an existing vacation setting.

The program was compiled using the Cygwin port of the GNU C compiler using the -mno-cygwin switch. This forces the program to use the MinGW static libraries instead of the Cygwin Dynamic Link Library, and makes for a stand-alone executable. Since I had not used any Win32 calls in the program, I did not need the added complexity of installing a DLL on various workstations.

The resulting program is somewhat crude by modern standards (though I suppose a nice Windows dialog version could be made), but it is probably only run 30-40 times a year in total. By using existing tools, (I hesitate to use the term 'components' here) the project took a day and a half to design, code and test. User and program documentation took another half-day to write. The program resides on an NT server to make updates easy and universal, and a desktop link is installed for any user who requires it from the administration console. Initial user response has been favourable, although some have found the configure and then commit sequence foreign. I am attributing this to people having more familiarity with the event loop approach of the Windows environment than the 'configure and run' method.

Wrapping existing tools and utilities is not always the optimum path, even for system tools. It often complicates error handling, and can force design choices in order to fit the interface. A lot of scripting and control seems to involve massaging the output of one program to suit another. Nevertheless, it does offer a means of obtaining complex functions quickly. Efficiency is rarely an issue in practice. User input and network bandwidth are the bigger limiting factors than the overhead of starting another process.

Ultimately I have to balance two needs. I need to keep the network operating effectively, and I need to keep my users happy. This little utility certainly does the latter.