Enterprise&mdash;Help for Networks

nPULSE and NetSaint, two web-based monitors for enterpriseenvironments.

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:

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.

Figure 1. Zoom View of nPULSE at
Work

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:

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

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:

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:

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.

Figure 2. NetSaint up and Running

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.

Marcel
Gagné (mggagne@salmar.com) is president of Salmar
Consulting Inc., a systems integration and network consulting firm,
and the author of Linux System Administration: A User's Guide,
published by Addison-Wesley.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.