NetSaint – a network monitor
NetSaint is a network monitor. You can use it to keep close tabs on your routers, printers, computers, and services. NetSaint can watch/monitor various services (SMTP, POP3, HTTP) to make sure they keep running. It can ping boxes to make sure they are still up. If a problem occurs, NetSaint can send out email, page people, and escalate problems if they persist. When the problem is fixed, NetSaint can also send out a recovery notification. And my personal favourite, you can view the current status through a webpage.Regular readers will know that in early 2000, I wrote about another network monitor, Big Brother.
NetSaint uses a feature called plugins to perform the actual service checks. This is a very flexible approach
which allows new plugins to be created for specific situations as and when necessary. If also allows you to create
your own plugins if you so wish. In fact, there is a port for the plugins
net/netsaint-plugins). This port is a dependency of NetSaint and will be installed
when you install NetSaint.
Installing NetSaintIt seems like everything I install is already available in the ports collection. That makes life simple. Here’s what you do:
Don’t forget to do acd /usr/ports/net/netsaint make install
make cleanafterwards. Otherwise all the files created by the build will sit around clutting up your disk. The NetSaint port has a fair number of dependencies (including gd, bzip2, etc, about a dozen in total) so it may take some time to install everything. But that’s the beauty of the ports system. It’s just start and forget.
But don’t forget it for too long. You will eventually be given a list of things to choose from:
You can see the selections I choose. Only you can figure out what makes sense to you. If none of the above options make any sense, don’t select them. If you’re not running mysql or postgresql, then don’t worry about those options.NetSaint plugins configuration options Please select desired options: [ ] QStat Game server query support [X] FPing Support for non-flooding fast ping [X] NetSNMP SNMP support [ ] Radiusclient Radius support [X] MySQL MySQL support [X] PostgreSQL PostgreSQL support [ ] OpenLDAP OpenLDAP support [ OK ] Cancel
I answered y to both of the following questions:
NetSaint will run as a specific user, which is a good thing from a security point of view. The use of a specific group is also a good security concept. Combining the use of a specific user and a specific group for NetSaint is a basic and commonly used security precaution. Everything, including your NetSaint configuration files should be treated on a ‘need to know’ basis.You need a group "netsaint". Would you like me to create it [y]? Done. You need a user "netsaint". Would you like me to create it [y]?
The web interface
This section may seem out of place, but I think it’s a good idea to get the web interface set up and at least partially functional before we go very far down the track. It also has the added benefit of giving you online access to the documentation….You need to add the following to your apache configuration file (normally, this is /usr/local/etc/apache/httpd.conf). You should place these directives in the vhost section for the website you wish to use for NetSaint.
For a complete working example, see samples/netsaint.vhosts.txt.
Alias /netsaint /usr/local/share/netsaint
ScriptAlias /cgi-bin/netsaint/ /usr/local/share/netsaint/sbin/
Take note that the Alias does not contain a trailing /. On this point, I disagree with the NetSaint documentation where it specifies a trailing slash. I originally followed the documentation but encountered a “The page cannot be found” message when I did not specify a trailing slash in my browser. Removing the trailing slash from the Apache configuration file solved that problem.
To further restrict access to NetSaint, I also added the following to my Apache configuration file for the vhost in question:
<Directory "/usr/local/share/netsaint/sbin"> AllowOverride None AuthConfig Options FollowSymLinks ExecCGI Order allow,deny Allow from 192.168.0.99 </Directory>
The AuthConfig will be used later to authenticate people using NetSaint. The ‘Allow from’ directive will restrict access to the CGI directory to the specified IP address. You can specify multiple IP addresses or hostnames on that line, separated by commas.
If you are even more worried about access, try adding this entry:
<Directory "/usr/local/share/netsaint"> Order deny,allow Deny from all Allow from 192.168.0.99 </Directory>
This will prevent anyone from even getting to /netsaint/ unless they are at that IP.
You should then test your Apache changes:
# /usr/local/sbin/apachectl configtest
You should then HUP Apache to invoke your changes:
# /usr/local/sbin/apachectl graceful
You should then be able to browse to your NetSaint directory using http://www.example.org/netsaint/ (subsitute your own domain). But if you click on any of the CGI links, you may see an error something like this:
Error: Could not read host and service status information!
That’s because NetSaint isn’t running yet with host/service information. But we will deal with that problem after we complete the configuration.
Seen this error? (added on 27 January 2003)If you encounter this error:
If so, then you haven’t done what the next section tells you to do!
Error: Could not open CGI configuration file '/usr/local/etc/netsaint/nscgi.cfg' for reading!
NetSaint configuration files are located at /usr/local/etc/netsaint. The main configuration files are:
- The main configuration file for NetSaint. Basically, I didn’t do anything to this file.
- The hosts file is where you define what you want NetSaint to monitor. It allows you to specify the computers, collect them into groups for ease of use, and specify who should be notified for a given problem. It was this file which took up most of my configuration time. The hosts.cfg can be split up into almost as many sub config files as you want which is especially useful to keep track of monitoring a large network.
- The commands are what NetSaint uses to perform various tasks. I modified this file slightly, but nothing major.
- NetSaint provides a web interface and makes heavy use of CGI programs. Access to these CGI programs is controlled by this file.
cp commands.cfg.dist commands.cfg cp netsaint.cfg.dist netsaint.cfg cp nscgi.cfg.dist nscgi.cfg cp resource.cfg.dist resource.cfg chown netsaint * chmod o-r *
WARNING: I just removed world-readability using the above step. I run Apache as www. So I used this to allow Apache to read the above (note: this tip may apply to other items as well, which I may have neglected to include; you’ll soon find out….):
chgrp www *
I purposely have not taken the distributed hosts file (hosts.cfg.dist) as I’m going to provide a simple example later in the next section.
That chown ensures the files are owned by netsaint rather than root. And the chmod makes sure nobody but netsaint can read the files. Both of these steps may be considered overkill, but I think it’s a good security measure. Keep things tidy.
The distributed hosts.cfg contains a very rich example. I suggest that you closely examine that file and use that as the basis for your actual configuration. But first, as a practical example, I suggest you use the following example and comment out the existing sections. This will get you going and allow you to see a small example with a minimum of fuss. Start small. Walk first. Then run. The sample hosts file is provided via this link. I don’t want to display it in this article because some of the lines are very long. You will need to make modifications to this sample file. Be sure to get the IP address right. Fill in the name, probably your own name. That name will be used in the next section for authentication.
nscgi.cfgnscgi.cfg controls access to the CGI programs. It’s pretty obvious that you don’t want just anyone to see the system monitor information. The official information for this step is contained in your online documentation (available via the /netsaint/docs/cgiauth.html link) or at NetSaint. The short version of the story is we use .htaccess and a database in order to authenticate users via CGI. For more information about .htaccess files, try reading Protected Apache directories. In the meantime, I’ll just press ahead with a simple setup. The directory you want to protect is /usr/local/share/netsaint/sbin. You can protect it by placing a .htaccess file in that directory. In that file you would place the following:
You then create a password entry using the steps shown in Protected Apache directories. Be sure to use the same name as you used in the hosts.cfg file. You add this entry to /usr/local/etc/netsaint/htpasswd.users:AuthName "NetSaint Access" AuthType Basic AuthUserFile /usr/local/etc/netsaint/htpasswd.users require valid-user
After doing those changes, Apache will prompt you for a user name and password when you broswe to one of the CGI directories (e.g. Status Overview).dan:esaBHd2tW29g2
The next step is to specify what commands are avialble to you. This is done via the nscgi.cfg. To get you started, just add the following. WARNING: This may be more than you want to allow. Read the documentation.
authorized_for_all_hosts=dan authorized_for_all_host_commands=dan authorized_for_all_services=dan authorized_for_system_information=dan authorized_for_system_commands=dan authorized_for_configuration_information=dan
Now it’s time to start NetSaint and see what happens….
Starting NetSaint is easy:
# /usr/local/etc/rc.d/netsaint.sh start
Starting network monitor: netsaint
PID TT STAT TIME COMMAND
88260 ?? Ss 0:00.03 /usr/local/bin/netsaint -d /usr/local/etc/netsaint/netsaint.cfg
Similarly, you can use the stop and restart options.
NetSaint process may not be running!If you happen to see the message ‘NetSaint process may not be running!’ when you broswe to /netsaint, don’t worry. First, verify that NetSaint is indeed running. You should see something like this:
$ ps auwx | grep netsaint
netsaint 89648 0.0 2.1 1876 1288 ?? Ss 7:54PM 0:00.11 /usr/local/bin/netsaint -d /usr/local/etc/netsaint/netsaint.cfg
If you see something like that, then you know that NetSatint is actually running. If you click on the link ‘Click here for more info.’ (right below ‘NetSaint process may not be running!’), you’ll find that you need to modify nscgi.cfg and supply a value for netsaint_check_command. That’s pretty easy. All you need to do is uncomment the line on which that keyword is found and restart NetSaint.
OK, you should be running nowYou should have NetSaint running now. There’s no reason why it shouldn’t be running. If you are having trouble, and it’s because of something not covered in this article, please add your solution/problem to the article comments. In any case, please consider this. Thanks.
Optional configurationThe steps in this section are optional. They may not be applicable to you. I strongly urge you to get everything else working, then consider these steps. In this section, I’m going to restrict things. I’m not going to let just anyone read my NetSaint configuration files. I’m only going to let the netsaint user read them. Let’s just say a little bit of paranoia is a good thing when it comes to security.
The first step is to chmod o-r the configuration files.
cd /usr/local/etc/netsaint chmod o-r *
But if you do just that, you’ll find that Apache can’t read htpasswd.users. This will manifest itself as authentation failures in your Apache logs:
[error] [client 188.8.131.52] user dan not found: /cgi-bin/netsaint/status.cgi
The solution is to make htpasswd.users readable by Apache:
chgrp www htpasswd.users
But then you’ll have trouble with the other configuration files as well. So I found it easiest to just do this:
That will go some way to restricting access to your configuration files but still allow the web interface to function.chgrp www *
FreeBSD graphics for NetSaintNOTE: The graphics rerferred to by in this section are now included in the FreeBSD port. The steps below are no longer necessary. If you have a look at the web pages for NetSaint, you’ll notice it’s rather Linux-centric. Fair enough. It is designed for Linux (it says so right on their homepage. But RevDigger decided that some better graphics were in order. In the spirit of sharing, he’s allowed me to distribute these graphics. The graphics are available at:
<img src="/images/sblogo.gif" width="130" height="125" border="0">
<img src="/images/bsd_sblogo.gif" width="110" height="95" border="0">
<IMG SRC="/images/logofullsize.gif" BORDER="0" ALT="NetSaint" width="238" height="227">
<IMG SRC="/images/bsd_logofullsize.gif" BORDER="0" ALT="NetSaint" width="268" height="221">
Possible problemsI think NetSaint has the ability to change configuration items from the webpage interface. If so, you may need to make the configuration files chmod +w with respect to your http process. In my case, I’m running Apache as www. So I made the NetSaint configuration files (/usr/local/etc/netsaint) a member of the www group and chmod g+r.
If you happen to see the following message:
It appears as though you do not have permission to view information for any of the hosts you requested…
Then I suspect your .htaccess user name and your NetSaint user names are not matching up. Or you didn’t specify any permission for your user name in nscgi.cfg.
If you keep seeing messages like this on your screen:
/home/dan/.mail_aliases: Permission denied
/home/dan/.mail_aliases: Permission denied
Or these in
Then I know of a change which will fix the problem (if it hasn’t already made it into NetSaint>. Modify /usr/local/etc/rc.d/netsaint.sh to add a single line (
forward /usr/local/var/netsaint/.forward.dev+: Group writable directory
unset -v HOME) as shown below:
rm -f $NetsaintCmd unset -v HOME $NetsaintBin -d $NetsaintCfg
That should stop the messages.
ThanksI wish to thank the following people for reviewing this article.
- Shane Allen
- Atle Veka