Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

Since we started writing here at Playing With Wire, we’ve managed to write two articles about Cacti. In January 2007 we introduced Cacti in the article “What’s Your Utilization, Kenneth?“. Six months later we wrote another article about how to monitor remote hosts with Cacti.

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:

  1. We connected with SSH from the Cacti server to the server we wanted to monitor (security issue).
  2. We were using regular SSH tunnels. While these are great, they do have a tendency to die (reliability issue).
  3. 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:

#!/bin/sh
REMOTEPORT=2001
MONITORPORT=29001
/usr/bin/autossh -M $MONITORPORT -q -f -N -R
127.0.0.1:$REMOTEPORT:127.0.0.1:161 [email protected]ver.tld

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.

Author: Tags: , , ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

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.

Go to YippieMove. Fill in your UCSD username and your password in Step 1 and select “Other…” as provider. As Host enter your ACS Server as listed below:

  • sdcc3.ucsd.edu
  • iacs5.ucsd.edu
  • ieng6.ucsd.edu
  • ieng9.ucsd.edu
  • sdcc12.ucsd.edu
  • sdcc13.ucsd.edu
  • sdcc15.ucsd.edu
  • sdcc17.ucsd.edu
  • sdcc21.ucsd.edu
  • popmail.ucsd.edu
  • ucsd-exchange.ad.ucsd.edu
  • mail.ucsd.edu
  • icogsci1.ucsd.edu
  • sgva-serv1.ucsd.edu
  • man104-1.ucsd.edu
  • imusic1.ucsd.edu
  • phcomp.ucsd.edu
  • bioinf.ucsd.edu

Check the check SSL and click next

UCSD

Here jsmith is using YippieMove transfer his account that resides on ieng9.ucsd.edu.

That’s it, Step 2 and Step 3 will be as normal.

Author: Tags: , ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.
Jan
11.
Comments Off
Comments
Category: Uncategorized

Today I tried to start iReport for the first time on the Mac. There was a shell script distributed with the program, so I gave it a shot in the Terminal. Unfortunately I got an exception immediately.

Stryker:iReport-2.0.3 2 siker$ chmod a+x iReport.sh
Stryker:iReport-2.0.3 2 siker$ ./iReport.sh
Exception in thread "main" java.lang.NoClassDefFoundError: 2

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.

Stryker:iReport-2.0.3 2 siker$ cd ..
Stryker:Downloads siker$ mv iReport-2.0.3 2 ~/iReport
Stryker:Downloads siker$ cd ~/iReport/
Stryker:iReport siker$ ./iReport.sh

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.

Author: Tags: , ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.
Dec
19.
Comments Off
Comments
Category: Uncategorized

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.

Gray Checkbox Background
An unsightly gray checkbox background.

I came up with this hack to hack the hack to work.

private Image makeShot(Control control, boolean type)
{
	// Hopefully no platform uses exactly this color
	// because we'll make it transparent in the image.
	Color greenScreen = new Color(control.getDisplay(), 
		222, 223, 224);

	Shell shell = new Shell(control.getShell(), 
		SWT.NO_TRIM);

	// otherwise we have a default gray color
	shell.setBackground(greenScreen);

	Button button = new Button(shell, SWT.CHECK);
	button.setBackground(greenScreen);
	button.setSelection(type);

	// otherwise an image is located in a corner
	button.setLocation(1, 1);
	Point bsize = button.computeSize(SWT.DEFAULT, 
		SWT.DEFAULT);

	// otherwise an image is stretched by width
	bsize.x = Math.max(bsize.x - 1, bsize.y - 1);
	bsize.y = Math.max(bsize.x - 1, bsize.y - 1);
	button.setSize(bsize);
	shell.setSize(bsize);

	shell.open();
	GC gc = new GC(shell);
	Image image = new Image(control.getDisplay(), 
		bsize.x, bsize.y);
	gc.copyArea(image, 0, 0);
	gc.dispose();
	shell.close();

	ImageData imageData = image.getImageData();
	imageData.transparentPixel = imageData
		.palette.getPixel(greenScreen.getRGB());

	return new Image(control.getDisplay(), imageData);
}

The result now looks like the picture below.

Normal Checkbox
It’s not pixel perfect but closer.

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.

Here’s the complete snippet (untested):

package de.fhmracing.glasseye.canexplorer.gui.transmit;

import org.eclipse.jface.resource.JFaceResources;
import org.eclipse.jface.viewers.ColumnLabelProvider;
import org.eclipse.jface.viewers.ColumnViewer;
import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.GC;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.graphics.Point;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Control;
import org.eclipse.swt.widgets.Shell;

public abstract class EmulatedNativeCheckBoxLabelProvider extends
    ColumnLabelProvider {
  private static final String CHECKED_KEY = "CHECKED";
  private static final String UNCHECK_KEY = "UNCHECKED";

  public EmulatedNativeCheckBoxLabelProvider(ColumnViewer viewer) {
    if (JFaceResources.getImageRegistry().getDescriptor(CHECKED_KEY) == null) {
      JFaceResources.getImageRegistry().put(UNCHECK_KEY,
          makeShot(viewer.getControl(), false));
      JFaceResources.getImageRegistry().put(CHECKED_KEY,
          makeShot(viewer.getControl(), true));
    }
  }

  private Image makeShot(Control control, boolean type)
  {
    // Hopefully no platform uses exactly this color because we'll make
    // it transparent in the image.
    Color greenScreen = new Color(control.getDisplay(), 222, 223, 224);

    Shell shell = new Shell(control.getShell(), SWT.NO_TRIM);

    // otherwise we have a default gray color
    shell.setBackground(greenScreen);

    Button button = new Button(shell, SWT.CHECK);
    button.setBackground(greenScreen);
    button.setSelection(type);

    // otherwise an image is located in a corner
    button.setLocation(1, 1);
    Point bsize = button.computeSize(SWT.DEFAULT, SWT.DEFAULT);

    // otherwise an image is stretched by width
    bsize.x = Math.max(bsize.x - 1, bsize.y - 1);
    bsize.y = Math.max(bsize.x - 1, bsize.y - 1);
    button.setSize(bsize);
    shell.setSize(bsize);

    shell.open();
    GC gc = new GC(shell);
    Image image = new Image(control.getDisplay(), bsize.x, bsize.y);
    gc.copyArea(image, 0, 0);
    gc.dispose();
    shell.close();

    ImageData imageData = image.getImageData();
    imageData.transparentPixel = imageData.palette.getPixel(greenScreen
        .getRGB());

    return new Image(control.getDisplay(), imageData);
  }

  public Image getImage(Object element) {
    if (isChecked(element)) {
      return JFaceResources.getImageRegistry().get(CHECKED_KEY);
    } else {
      return JFaceResources.getImageRegistry().get(UNCHECK_KEY);
    }
  }

  protected abstract boolean isChecked(Object element);
}

Hope it’ll help somebody.

Author: Tags: , , ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.
Oct
31.

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

Indeed, even running pear install Structures_Graph results in this error message.

The Solution

This blog suggested go-pear.php as an alternative way to install PEAR on the Mac and it does work. So with no further ado, this is how to install symfony on Leopard:

sudo su -
curl http://pear.php.net/go-pear > go-pear.php
php -q go-pear.php

pear channel-discover pear.symfony-project.com
pear install symfony/symfony

Good luck with your Leopard powered symfony hacking.

Author: Tags: , ,

© 2006-2009 WireLoad, LLC.
Logo photo by William Picard. Theme based on BlueMod © 2005 - 2009 FrederikM.de, based on blueblog_DE by Oliver Wunder.
Sitemap