While the setup we described in these article worked out great, there were a few things that we didn’t really like about the setup:

We connected with SSH from the Cacti server to the server we wanted to monitor (security issue).

We were using regular SSH tunnels. While these are great, they do have a tendency to die (reliability issue).

Due to security and portability, we wanted to isolate Cacti to a separate server (or VM).

1. Turning the tunneling around

The reason why we didn’t like to have the Cacti server connecting to the servers was simply that we needed one more user account on the remote servers. If these are production servers, it’s desirable to keep the publicly accessible user accounts to a minimum.

As it turned out, replacing the ‘-L’ with a ‘-R’ in the tunneling command turns the tunnel around. Instead of opening a port on the local machine, it opens a forwarded port on the remote server. By doing this, we can connect from the remote server to the Cacti server and still fulfilling the same purpose (but without creating an additional user on the remote server).

2. Creating more reliable tunnels

One of the major problems we were having with the setup was that the tunnels died for one reason or another. We initially solved this by writing a bash-loop that automatically reloaded the tunnel if that occurred. However, we were still experiencing some problems with dead tunnels.

The solution to the problem was autossh, a simple front-end to SSH that keeps the tunnel alive.

With autossh, we could simply launch the tunnels at boot-time on the remote server (in rc.local) without having to worrying about them dying. As we were implementing this on a number of servers, we wrote a small bash-script that launches autossh with the server-specific settings. The script looks like this:

This script creates a tunnel on port 2001 ($REMOTEPORT) on the Cacti host (cacti.server.tld) that goes to port 161 on the local machine (in this case, the server we want to monitor).

Isolate Cacti

In order to make our monitoring both more secure and portable, we felt that we wanted to isolate the monitoring to a separate Virtual Machine. This was easily done by creating a new VM under VMware Server. If you’re lazy, there are ready-to-use VMware images to download on the Cacti forum.

Bonus: Monitor several hosts with one tunnel

While reading the Cacti forum the other day, I ran across this article that talks about SNMP Proxies. By adding an extra entry in the SNMP config file, it’s possible for a single host to relay SNMP information about the other hosts on the network. This is very useful if you’re trying to monitor more than one host on the same network, as you don’t need one tunnel per server (beware that this creates a single-point-of-failure though).

Conclusion

After implementing these changes, we feel much more comfortable with our Cacti setup. Not only is it more reliable with more robust tunnels, but it’s also more secure.

The next Cacti-related task we will be looking at is to design custom plug-ins to monitor our own apps.

A few days ago I received a question from a friend of mine at UC San Diego if it was possible to use YippieMove to save the content of his UCSD account when it expires. The answer is yes, and below are the instructions to get you started.

I fooled around with the script for a while. Seeing that it was trying to generate its class path using creative uses of dirname on the first script argument, I figured that maybe it’d help to run the program with the full path specified like so:

Stryker:iReport-2.0.3 2 siker$ "`pwd`/iReport.sh"

That didn’t do it though. After looking at the script some more I realized they were pretty lax with quoting. That was it. Moving the software to a location without spaces in the path solved the problem and made iReport start up just fine.

Hope that helps someone running into the same problem. I would post a bug report but I saw someone was two steps ahead already and had created a clickable Mac application and submitted a build file. That’s clearly the preferable solution.

Tom over at the eclipse-dev blog posted this useful snippet for putting native looking checkboxes in SWT JFace TableViewer tables. Unfortunately the checkboxes ended up with a gray background in OS X, as seen in the picture below.

It’s based on Florian Potschka’s version of makeShot as found in the comments to the original post. Replacing your makeShot method with the one above makes the background of the checkbox transparent. It’s not perfect: we use a random near white background color as our ‘green screen’ color in order to get the right antialias color in the edges. But this will also make any pixels with exactly this color inside of the widget shine through. Hopefully there won’t be many. Given enough time somebody will add checkbox support to arbitrary table cells in SWT and this hack will be made obsolete.

Just in case anyone runs into trouble with this, I just want to describe the steps for installing the symfony framework on an OS X 10.5 (Leopard) machine.

The good news is that Leopard comes with PHP 5 built in. The bad news is that PEAR is not included, which is needed to install symfony in the most convenient way.

My first attempt to remedy the situation was to run the darwin ports package manager to install pear:

# port install pear-base

Unfortunately there were two problems. First of all, the version of pear that comes with darwin ports does not use the OS X version of PHP by default, but rather looks for the PHP darwin port. This was easily remedied by adding export PHP_PEAR_PHP_BIN=`which php` to /etc/profile but unfortunately that’s not enough. The second problem is that a few files seems to be missing in the darwin port of PEAR and you’ll get the following error when you try to install symfony:

PEAR_Downloader::require_once(Structures/Graph.php): failed to open stream: No such file or directory in Downloader.php on line 1230