Enterprise—Help for Networks
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
To stop nPULSE, use
/usr/local/npulse/etc/stopThe 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-daemoninitQuite 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 usernameIncidentally, 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 netsaintadminIt'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:
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 startIf 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!
Marcel Gagné (firstname.lastname@example.org) 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.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Senior Perl Developer
- Technical Support Rep
- Introduction to MapReduce with Hadoop on Linux
- Weechat, Irssi's Little Brother
- What the author describes
27 min 18 sec ago
- Reply to comment | Linux Journal
4 hours 37 min ago
- Reply to comment | Linux Journal
5 hours 22 min ago
- Didn't read
5 hours 33 min ago
- Reply to comment | Linux Journal
5 hours 38 min ago
- Poul-Henning Kamp: welcome to
7 hours 48 min ago
- This has already been done
7 hours 49 min ago
- Reply to comment | Linux Journal
8 hours 34 min ago
- Welcome to 1998
9 hours 23 min ago
- notifier shortcomings
9 hours 46 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?