• viewvc + Pygments (browser interface for cvs and svn)
• xspacewarp (Time-Trek like game for X-Windows)
• inadyn (Dynamic DNS updater)
• nagios + nagios-plugins (IT monitoring system)
• ntop + GeoIP + graphviz (Network usage monitor)
• zabbix-server / -agentd / -proxy (Distributed monitoring solution)
• hercules (Mainframe emulator)
• lbench (Multi-thread benchmarking tool)
• nbench (Console benchmarking tool)

This finishes the series of packages I planned to test / run on my ARMedslack system.
I might build other packages in the future, but there are no specific plans at the moment.

The build environment

I build all my packages for Slackware in Virtual Machines, using QEMU. I use the snapshot feature to guarantee that I always use the same, stable version without leftovers from previous builds. So for my ARMedslack packages I set up a new VM in Qemu, using the emulation of the ARM Versatile board. ARMedslack runs fine on this, but it is quite slow compared to a “real” system with an ARM processor, like the SheevaPlug I have.
I set up a distributed compiler “farm”, using spare processor time of some other desktops / servers I have in my network, so that compile-time gets a lot friendlier.
Whenever I find some time I’ll write a post about distcc and how to set it up to compile for the ARM architecture on x86 boxes.

What to build for ARMedslack

Not all packages I maintain are useful on ARMedslack.
Most ARMedslack systems (SheevaPlug, GuruPlug, etc.) don’t use any graphical interface, or are slow if using them, so it does not make sense to prepare any heavy graphics-dependent packages like FreeCAD or BRLCAD. I also don’t think anyone will use ARMedslack to construct Lego models, so these were out as well.
On the other hand, the plug computers are ideal for monitoring your network, so the Nagios, rrdtool, ntop and Zabbix are all on the list.
Hercules has been one of my favorites on the SheevaPlug, to show off my “portable mainframe”. I also put a few benchmark programs in the mix and fbreader and QComicBook to test simple graphics applications.
After all, I still hope to have a ARM-based net/note-book one day.

What is ready *now*

Building and testing these packages takes some time if done with care, but I started with the following packages that can already be downloaded from my site:

• QComicBook – A Comic Book reader
• liblinebreak – a library needed by fbreader
• fbreader – An e-book reader
• rrdtool – a library to store and display time-series data, used by many monitoring programs

Next…

Other packages will follow and I’ll announce them here as soon as they become available (after some basic testing).

As a happy and satisfied user of Nagios, I updated my SlackBuild script immediately and after a few days of testing, I submitted the new version to SlackBuilds.org today.

Pre-built packages are already available for Slackware (32- & 64-bits) on my site.

First of all, there is new version of cacti, with several patches from upstream. It corrects a few bugs that appeared after the release of version 0.8.7g. Since there have been five patches, I called this version 0.8.7g_p5.

The second update is for Zabbix. I created new versions for zabbix_server and zabbix_agentd and added a new module, zabbix_proxy. All use the new 1.8.3 version that was released a few days ago.
I also implemented some suggestions I received by e-mail, mainly corrections in the documentation.

The third update is for ntop, which released a completely revamped version 4. I actually waited for version 4.0.1, as I had some stability problems with the 3.x series. This new version seems to be quite stable and adds some nice features.

The new SlackBuilds have been uploaded to SlackBuilds.org and packages for Slackware (32 & 64 bits) are available on my site.

I successfully updated my server, which was a very simple process.
After installing the new package, the web-page automatically redirected to the upgrade-page and with a single click Cacti was up-and-running again.

The new SlackBuild is in the pending queue of SlackBuilds.org and the pre-built package is available on my site.

The SlackBuild was also improved to solve some problems with the lua, tcl and ruby bindings, that are all installed in the correct paths now.

The new SlackBuild has been submitted and new packages can be downloaded from my site.

While we’re waiting for the new version to be re-released, I built a package for the current release (0.8.7e) with all the patches that upstream made available on their site.
This way we can have a stable and secure Cacti installation while we wait for the new version.

The package can be downloaded from my site.

I updated the SlackBuild script and submitted it to SlackBuilds.org. Pre-built packages for Slackware 32+64 bits and ARMedslack can be downloaded from the usual page.

I submitted the new SlackBuilds for the server and agent parts to SlackBuilds.org. Pre-built packages for the agent daemon for Slackware can be downloaded from my site, including a new package for ARMedslack.

The last few days I was struggling with the following situation:

• I wanted to examine some packets passing through my firewall
• my firewall is a “headless” (this means without a monitor, accessible only via ssh) Slackware server
• it has no X installed (and therefor no window manager etc.) so it won’t run wireshark

Now wireshark can read packets captured by tcpdump and written to a file, so that’s what I did at first:

• capture with tcpdump
• write the packets to a file on a network share
• open the file with wireshark

The problem is that I wanted to examine the packets “on-line”, as they pass through the firewall.
Linux has a solution (inherited from Unix) for this, called “pipes”. These are a special kind of files, where one program writes, while another reads from it, getting the contents in the right order.
In other words: the packet that went into the pipe first, will come out first at the other site of the pipe. Imagine it as a “vitrual tube”.

It was a bit of a struggle to get all the parameters right, but in the end, I got it working like this (note: all commands are entered in a terminal session on the desktop):

1. Create the pipe

niels@desktop:~$ mkfifo /tmp/pipes/cap_fw
“/tmp/pipes/” is where I create my pipes, feel free to use whatever directory you prefer.
“cap_fw” is the name of the pipe I selected.

2. Start tcpdump remotely with ssh from the desktop where you have wireshark installed:

niels@desktop:~$ ssh root@<firewall> "tcpdump -s 0 -U -n -w - -i eth1 not port 22" > /tmp/pipes/cap_fw
Replace <firewall> with the name or ip address of your remote server.

The options I used are:
-s 0 : use the required length to catch whole packets
-U : packet-buffering – write packet to pipe as soon as it is captured (as opposed to waiting for the buffer to fill)
-n : no address-to-name conversion (you can let wireshark do this if you want)
-w - : write output to standard output
-i eth1 : capture from interface eth1 – change to match your setup
not port 22 : leave out any packets from / to port 22. This is needed as we use ssh to connect to out firewall, so that we don’t capture the captured packets again… If you need to examine port 22 on your server, use ssh over an alternative port.
> /tmp/pipes/cap_fw : redirect the output to our pipe.

3. While tcpdump is capturing packets and sending them to the pipe, open another terminal, start wireshark and use the pipe as the input

niels@desktop:~$ wireshark -k -i /tmp/pipes/cap_fw
Here the options mean:
-k : start immediately
-i /tmp/pipes/cap_fw : use our pipe as the “interface”

And you’re up and running!
You can use all the normal functions of wireshark, like filtering, etc., as if you were capturing from a local interface.

By special request from BP{k}, here is a diagram of the setup showing how ssh gets the data from the server, captured by tcpdump and sends it through the pipe to wireshark (with a little help from LeoCAD, l3p and POV-Ray):

(click on the image to enlarge it)

I might write a nice bash script to make things simpler now that I figured it all out.
If it is good enough in the end, I’ll publish it here on my blog.