When I look at the focus of this month's issue, François, my first thought is certainly the same as yours, mon ami. For me, the word enterprise summons the image of a certain starship searching space for new and exciting aliens, not to mention their local wines, non? But in the business world where many of our guests work, enterprise means très grand, as in big business.

Quoi? Moi aussi, François. When I think of a large office, or worse, many large offices, I think of the poor system administrators who must take care of all those computers, hubs, switches and PCs. My heart goes out to them.

Ah, François, what are you doing standing there? Our guests have arrived. Away to the cellar and bring up the 1996 Stellenbosch immédiatement. Vite! Vite! Mes amis, please sit down. Your table is waiting and François is fetching the wine. I envy you, mes amis, a bold South African red with a wonderfully long finish. I may even join you.

When you arrived, we were discussing the special pressures that working in a large enterprise puts on a system administrator. Imagine having to keep track of numerous systems spread across a distributed network, mon ami. People do not want to hear that the mail server is off-line; they want the administrators to know before them and have the problem already solved. It seems impossible. Add to that paper shortages in the supply cabinet and our friends have their hands full, non? That is why I have dedicated tonight's menu to helping them with this impossible job. Relief, mes amis, is on the way with a couple of wonderful recipes from great open-source kitchens.

The first item on tonight's menu is a little something designed to take the pulse of your network. What better name for such a tool than nPULSE.

In order to use nPULSE, you are going to need a couple of Perl modules (in fact, nPULSE is written in Perl) and my favorite port scanner, nmap. You can pick up nmap from www.insecure.org/nmap/index.html. You may also find it on your distribution CD, so look there first. While nmap is but one ingredient in the creation of nPULSE, I invite you to try it on its own. The latest version even comes with a nice GUI front end called nmapfe.

We also need a couple of Perl modules, mes amis, CGI.pm and Mail::Mailer (which is part of the MailTools package). There are two ways to install these modules. One is to go directly to the CPAN site and download both. You'll find the two modules at ftp.cpan.org, specifically in the following directories: /pub/mirrors/ftp.cpan.org/pub/CPAN/modules/by-module/CGI and /pub/mirrors/ftp.cpan.org/pub/CPAN/modules/by-module/Mail.

Installing the Perl modules is simple. The format is always the same, so let me show you with the MailTools package:

tar -xzvf MailTools-1.16.tar.gz
cd MailTools-1.16
perl Makefile.PL
make
make install

Now, do the same with the CGI.pm package, and you are ready to install the rest of nPULSE. Mais oui, I did say that there was another way to install Perl modules, so we shall look at that briefly. You can have the whole process happen magically by using the following commands:

perl -MCPAN -e 'install Mail::Mailer'
perl -MCPAN -e 'install CGI'

If you have never installed a Perl module in this way, be warned—the process can take awhile the first time around. You will have to go through a question-and-answer session asking where various files are located and what mirrors you wish to use for your downloads. The process also may install a fair number of packages so that you can do seamless Perl module installs in the future.

There you have it, non? Our modules are installed, we have nmap and are ready to continue with our nPULSE installation:

tar -xzvf npulse-0.54.tar.gz
cd npluse-0.54
./setup.sh

You'll be asked where you want nPULSE installed (the default is /usr/local/npulse) and a handful of other questions, including one about your personal architecture. Because nPULSE is multiplatform, you need to specify what you are running it on. I chose Red Hat 7 when I did this, but you'll see support there for every major Linux distribution, as well as for SCO, Solaris, SGI and number of others. The final set of questions asks you to choose an administrator login and password for security authentication. Once that is done, nPULSE's web server is started on port 19000 (although you can change that as well). Point your favorite browser to http://your_server:19000/ to connect to the server.

The first thing you will want to do is configure the hosts being monitored. You do this with the Setup button on the page. When the new page appears, type an IP address or a range of addresses into the Discover box on the top right-hand side. Then click Go. nPULSE will scan that machine for available services, and these will appear in the large window below. Click Save and then switch to the Status screen where you can do a ping or port sweep. It is possible to switch from one view to another by choosing the various options in that little drop-down box beside the on/off switch at the top, right-hand side.

nPULSE is quite configurable with a number of possible responses to a particular host being on- or off-line. You can set it to send e-mails, page you or simply refresh the screen automatically for a bird's eye view of various networked systems. For a look at nPULSE in action, see Figure 1, where we zoom in on a PC client on the network. You'll notice that it is running a primitive operating system.

The installation procedure automatically starts the server. To restart nPULSE, use

/usr/local/npulse/etc/restart

To stop nPULSE, use

/usr/local/npulse/etc/stop

The next item on tonight's menu is a saintly program called, quite appropriately, NetSaint. NetSaint is also a web-based network monitor that uses Apache to serve its web pages. Luckily, most Linux distributions come with the Apache server on the disk. You may already have it installed.

With NetSaint, you can keep track of your various networked machines, keeping an eye on all your important protocols, like SMTP, POP3, HTTP and so on. The program has built-in event notification similar to nPULSE and will send you an e-mail or a page in the event of a system going down. You even can define program responses to common problems so that things more or less take care of themselves. NetSaint also provides detailed logging of network status and events. Best of all, NetSaint is freely distributed under the GPL.

To get your copy of NetSaint, start by visiting the project site, www.netsaint.org. Then, extract and build the package as follows. Be warned, mes amis, there are a few interesting differences in the standard build when it comes to NetSaint. It pays to pay attention. The beginning is a familiar one:

tar -xzvf netsaint-0.0.6.tar.gz
cd netsaint-0.0.6
./configure
make all

While the programs are compiling, you should take a moment to add a NetSaint login, the user ID NetSaint will run as, if you have not already done so. Then, when the compile is done, you may finish the install. Here are the remaining steps:

adduser netstaint
make install
make install-config
make install-daemoninit

Quite a mouthful, non? I think we need a little something to wash that down with. François, refill our guests' glasses. Merci, mon ami.

Before you can use the package through the web interface, you will need to add a couple of lines to your httpd.conf file and restart Apache. The first of those lines is as follows. Yes, I know there are two, but the one you need to add is the first. I'll explain in a moment:

ScriptAlias /cgi-bin/netsaint/ "/usr/local/netsaint/sbin/"
ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"

I showed you these two lines to illustrate an important point: make sure the NetSaint ScriptAlias appears before the standard cgi-bin ScriptAlias. This is very important. After these, you will now add an Alias definition for the main NetSaint HTML files:

Alias /netsaint/ /usr/local/netsaint/share/

Look in /usr/local/netsaint/etc to find a few scripts that will need modification for your site. Specifically, you will want to look at the hosts.cfg and the nscgi.cfg files, which were created when you did your make install-config earlier. Conceivably, you could have created them by hand, but that may have required more wine than we have in the cellar, non?

In order to access NetSaint functions with your browser, you must first authenticate with a user name and password. Do this by creating a .htaccess file in NetSaint's program directory, /usr/local/netsaint/sbin. I'll show you the file in a moment, but before we can use .htaccess, we need to add this section to the httpd.conf file, after the ScriptAlias information listed above:

<Directory /usr/local/netsaint/sbin>
    AllowOverride AuthConfig order allow,deny allow from all
    Options ExecCGI
</Directory>

Now, save the file and create the .htaccess file. This is what it should look like:

AuthName        "NetSaint :  Restricted access"
AuthType        Basic
AuthUserFile    /usr/local/restricted/.netsaint
<Limit GET POST>
   require valid-user
</Limit>

The AuthUserFile parameter points to the location of the actual password file. Notice that I have mine sitting outside of my web server's document root. In that way, the file cannot be downloaded with a simple HTTP request. Passwords are added to this file with the htpasswd command, like this:

htpasswd -c passwordfile username

Incidentally, if you built your Apache server from source, the program will likely be in the /usr/local/apache/bin directory. A note of caution here—the -c flag creates a new password file if none existed before. You do not want to use this unless you want to flush the whole file and start over. Another flag you may want to use (and probably should) is the -m flag, which forces MD5 encryption on the passwords:

htpasswd -m /usr/local/restricted/.netsaint netsaintadmin

It's time to restart Apache. If your Apache installation is a source install, you likely will execute apachectl stop followed by apachectl start. That command is usually in the /usr/local/apache/bin directory. On something like a Red Hat system, you usually stop and start the httpd dæmon with a call to /etc/rc.d/init.d/httpd, specifying stop or start on the command line.

Now comes the fun part. Go back into the /usr/local/netsaint/etc/hosts.cfg file and start defining the hosts you want monitored. As I mentioned earlier, this is definitely one file where it makes sense to take what is there and slowly, host by host, modify it to suit your needs. Finally, you will want to grant yourself some permissions. By default, NetSaint is somewhat restrictive in what you can and cannot do. You grant yourself (possibly others) permissions by uncommenting the appropriate lines in the nscgi.cfg file. These lines all start with “authorized_for” and then specify a list of user names and what they can and can't do. That way, you can create multiple users and share the administration load. Here's one of these lines:

authorized_for_configuration_information=netsaintadmin

Mon Dieu! All this work, it makes for a big appetite, non? Oui, mes amis. It is time to start the NetSaint dæmon:

/etc/rc.d/init.d/netsaint start

If all has gone smoothly, we should be able to connect to NetSaint through our browsers. No special port numbers here. Assuming a system called my_system, you would use the URL http://my_system/netsaint/. For a peek at our NetSaint in action, I invite you to sample Figure 2.

The NetSaint interface is rich and provides plenty of opportunity for exploration. You can customize things from here as well, and there is full, on-line documentation should you run into problems. Exploring every aspect of the program would take far more time than we have, but with your own NetSaint watching over your network, you should have plenty of time to explore later.

Ah, mes amis. The clock, she is telling us once again that we must finish our wine and head home. Since there is but a little left in the bottles, I shall have my faithful waiter refill your glasses a final time before you go. Until next time; au revoir, mes amis. Your table will be waiting.

A votre santé! Bon appétit!

Resources