It's implicitly in the apt-get manpage, but I didn't see it until now - downgrading Ubuntu/Debian packages (for example to remove packages from an Ubuntu-PPA or a manually installed .deb with a newer version): Just add /distribution-name to the package when reinstalling.

For example (Ubuntu):

apt-get install --reinstall libgnutls26/oneiric libgcrypt11/oneiric

So I have this rather old Celeron-300 laptop that I install a new version of Ubuntu on from time to time to see if it still works.

It's had the problem that DPI gets set to a wrong value (20) and consequently I get a really tiny font for quite some time, and after the old way of forcing --dpi on the X comand line doesn't seem to work anymore, it was finally time to find out why.

Turns out the newly created /etc/X11/xorg.conf contains garbage in the form of a wrong DisplaySize and PanelSize:

Both contain the resolution of the display in pixels in the autogenerated xorg.conf, but are supposed to have the size of the panel in millimetres instead.

After setting DisplaySize to the correct values (and just commenting out PanelSize in the Device section), the resulting DPI looks much more sane...

DisplaySize 245 185

...creates the following DPI value:

(II) SMI(0): Output LVDS using initial mode 800x600
(**) SMI(0): Display dimensions: (245, 185) mm
(**) SMI(0): DPI set to (82, 82)

1. intro

In december, I stumbled over a short presentation (in german) on netdot and RANCID by Jens Link (cache). I've been a fan of RANCID for a long time, but never had heard of netdot, the Network Documentation Tool (cache).

Turns out netdot does a lot of useful things via SNMP::Info (cache), from pulling inventory data to reading out VLAN, IP, ARP and forwarding tables, and then puts all that in a neat web interface for further classification. It's possible to document just about everything around network systems in netdot, down to the cabling setup.
On the logical side, netdot can be used for IP address and VLAN management, and to create configurations files for RANCID, ISC bind and dhcpd, and Nagios.

All in all it seems like a pretty nifty tool, and I've only scratched the surface of it's functionality until now - just having the MAC database (and by that the information where each end system is attached) makes setting up netdot worthwhile.

2. basic setup

My installation is based on netdot 0.9.10 on a Debian Squeeze LAMP system.
Setup is quite straightforward, just follwing the available documentation: Dowload, unpack, run make installdeps-apt-get to install all missing packages, run make installdeps to fetch anything that might still be missing from CPAN.
Then copy etc/Default.conf to etc/Site.conf and adapt all settings for your installation, especially those for the database connection. A make installdb will take care of setting up the DB. (I'm not very fond of the way that's done, as the routine needs database admin credentials and fails if you create a database in advance with a user that just has admin rights on that.)
After that, make install copies everything to /usr/local/netdot. I've used checkinstall to create a basic debian package:

As a last step, netdot needs to be added to the apache configuration, by copying a template: cp /usr/local/netdot/etc/netdot_apache2_local.conf /etc/apache2/conf.d/

3. installation woes

At this point, everything works in principle, including logging in to the web interface. Unfortunately, that's also where the problems start...

3.1. Can't add any system to the database

Looking at network traffic with tcpdump, no snmp queries go out at all... After tinkering with SNMP::Info internals for two hours, found the unexpected solution in the netdot bugtracker, bug #1622 (cache):
Two debian packages are missing in the installdeps phase: apt-get install snmp-mibs-downloader smistrip

3.2. Alcatel MIBs missing

netdot contains a collection of MIB files that's probably derived from the netdisco-mibs package. When trying to add Alcatel OmniSwitch systems on our network, SNMP::Info barfs - it has an AlcatelLucent.pm to handle those systems, but that doesn't work without the MIBs. In the end I found a relatively complete set of OmniSwitch MIBs in the Observium SVN (cache) (because, you know, those files are so secret that you can't download them from the Alcatel-Lucent web site - I'll be so happy when we're rid of the last of these things).
To make things somewhat more fun, Alcatel provides a customized AaIETF_HUBMIB_POWER_ETHERNET_DRAFT.mib that uses the same module name as the official POWER-ETHERNET-MIB. SNMP::Info::Layer3::AlcatelLucent documentation advises to change it's module name to ALU-POWER-ETHERNET-MIB by editing the file. Which is fine, except that the corresponding error also comes up when there's another problem (like a dependant mib still missing).

3.3. Juniper EX non-obviously not supported

Adding our Juniper EX 4200 and EX 4500 switches to the database seemed to work fine at first, until it turned out that just the data for the system that was added last is in the database.
I did not have a look at netdot's data model, but obviously the problem was caused by IP addresses used on internal interfaces that are identical on all EX systems (128.0.0.x). Fortunately, Site.conf provides a configuration directive to weed out these pseudo interfaces:

Next I noticed that the VLAN information gathered from Juniper switches was broken: Instead of the VLAN ID, the database just contained sequence numbers.
Obviously EX switches use a different method to provide VLAN information via SNMP than Juniper routers. Someone has already provided an JuniperEX.pm extension to SNMP::Info, but it's not integrated into the distribution yet.
I ended up reinstalling a current version of SNMP::Info directly from CPAN, and then just copy the JuniperEX.pm file into /usr/local/share/perl/5.10.1/SNMP/Info/Layer3/ (path on my system) and patch SNMP/Info.pm:

...except the netdot MIB package doesn't contain JUNIPER-VLAN-MIB and it's dependencies, but that can be solved easily by downloading a complete collection of Juniper MIBs (cache) from juniper.net.

4. unsolved problem

After all that, my netdot installation happily crunches data from about 90 switches in our central location, and I'll most probably add our external sites in the coming weeks.
One last problem remains - SNMP::Info doesn't read inventory information from Juniper EX switches, so I'll have a look at exending the existing JuniperEX.pm. More news when that actually works.

At last, a thanks to the developers - got a detailed description on where to look when I posted my various problems to the netdot-users mailing list.

So it's that time of the year again...

Feels somewhat different from last time over (25C3, has it really been three years?):

• Less crowded. Maybe just because it's day one, but most things run smoothly (exception: trying to get a r0ket, I think 50% of the attendands were in that queue). No probelm to find place with a free power socket.
• Less laptops in the lectures. The desks in Saal1 have been removed, and I have the impression that the same happened to lots of wall sockets. Ok, people switched to tablets and smartphones, but even that seems at a reduced level.

I'm not going to write summaries of speeches, but I noticed that the topic of (OSI) layer boundary violations came up twice - once in the session on PHY attacks on wireless devices, and when Dan Kaminsky mentioned something in the line of "applications built on top of TCP assume reliability" (and that assumption can be broken). It seems there's some surprises still waiting in that direction.

Cory Doctorow was good for a host of quotes, but I was hit by his description of networked activism, and why it seems so disparate without being desolate, which went something like this: Earlier on, the main work was actually organizing the activist movement, and so people agreed on common goals first and then went on organizing around that ("2% figuring out what to do, 98% stuffing envelopes"). Nowadays, organization comes mostly for free, and it's easy to form up around a topic, start discussing things, and maybe move off in different directions without losing touch. Which is exactly what confuses people about the pirate party in germany, for example (or Anonymous, or Occupy). Now that maybe oversimplified, but it rings true in principle.

His talk is here on youtube: http://youtu.be/OyNmUmmQ0kI

Nebenbei scheinen in Sachsen manche Dinge anders zu funktionieren als anderswo: http://youtu.be/Cz22Vx1MRzM

I've now seen several installations of an Checkpoint R70 management GUI where the details pane in SmartView Monitor doesn't work because of Javascript errors like "'statSection' is undefined" or similar. The URL usually is "file:///C:/Program%20Files/CheckPoint/SmartConsole/R70.40/PROGRAM/data/htdocs/overview.html?", as in the following screenshot (german version):



I've found several references to this problem on the Checkpoint support forums and elsewhere, but none with a conclusive solution.

Obviously, this error occurs because SmartView Monitor can't find several files in PROGRAM/data/htdocs.

I have a somewhat convoluted workaround for this:

1. There are two .tar files in PROGRAM/data which contain the required files, namely SmartViewMonitor.tar and SmartViewTracker.tar.
2. For some reason it's impossible to untar those two files directly in the data folder, even as Administrator - I have the impression that a htdocs directory already exists, but is invisible or has very strange access restrictions (have found no way to make it visible).
3. So copy the two files to somewhere else, and untar them using either an archiver like 7-Zip, or with the gtar.exe that's included in PROGRAM/util with any SmartDashboard installation.
4. Move the resulting htdocs folder back to PROGRAM/data within the Checkpoint GUI directory. You'll need administrative privileges, and force overwriting any existing files.
5. Never see script errors again.

Dieses Wochenende habe ich versucht, einen eigenen Diaspora (cache) pod entsprechend der Anleitung im Diaspora-Wiki zusammenzubasteln. (Läuft auch, zumindest wenn die Kiste gerade an ist: https://diaspora.infra.de/people/2)

Nachdem mein Reverse-Proxy - Setup mit Apache zuerst nicht ganz so richtig funktioniert hat, habe ich einen entsprechenden Post von Bernd Eckenfels dazu gefunden.

Das hat geholfen, allerdings sieht es bei mir trotz der Alias-Definitionen nicht so aus, als ob die statischen Dokumente direkt vom Apache ausgeliefert werden.

Ich habe das dann nochmal ein bischen umgebastelt und stattdessen mod_rewrite verwendet. Der Vhost hat bei mir direkt das Diaspora public - Verzeichnis als Root, so dass die Dateien direkt von dort ausgeliefert werden können.

Die Konfiguration sieht jetzt so aus:



Das Rewriting kann man bestimmt noch intelligenter machen - ich bin da etwas außer Übung. Funktionieren tut es aber.

So I've learned some new things since yesterday... Instead of awkward terminal hacks, I'm now using Zenity to collect the command line, and gksu to elevate privileges. It's all still not polished, but looks slightly better.

Also I've quickly packaged the curses version of MTR (My Traceroute) in a similar way. GTK-detection fails with a crosscompiler setup, and I couldn't yet convince the configure script to work around that...

tcpdump: http://web.gxis.de/pnd/tcpdump.pnd
mtr-curses: http://web.gxis.de/pnd/mtr.pnd

The OpenPandora (cache) uses a special application package format, called PND. It allows running programs from an SD card, without cluttering the system's (limited) NAND flash space that holds Pandora's firmware (a Linux distribution based on Angström (cache)).

The firmware doesn't have a whole lot of networking tools, so I started trying to build some things I might need. First off, tcpdump.

I'm using sebt3's Yet an other Cross-compiling Toolchain (cache) in a Debian VM, which currently seems the easiest way to a working cross-compiler setup with all required libraries.

Building libpcap and tcpdump was quite easy, besides the small problem that "ac_cv_linux_vers=2" needs to be set manually for the configure script to work when cross-building for a Linux system.

There's not currently a standard way to integrate command-line tools with the PND system. My current workaround is to start an XFCE Terminal and ask for the commandline, and then run tcpdump in that same window. That's badly hacked up though and prone to errors, so it definitively needs improvement.

In the meantime, a copy of tcpdump for the Pandora can be found here: http://web.gxis.de/pnd/tcpdump.pnd.

I've been following the various reports on spam volume in January (especially about the massive drop between the years), and I have tried to compare them with my own data.

Now my view is very limited in comparison to the global services - all I'm running here is an MX for two .de domains (though one of them has been on the net since 1995, and should be on about every spam list out there). Also, my main metric differs from what I've seen elsewhere: I'm counting the number of hosts in my greylisting database (using the spamdb munin plugin I hacked up last year). So I don't see the volume of spam, but how many hosts have tried connecting to my system to deliver mail.

Let's start with two graphs - the first is my greylist summary, the second a spam volume count taken from the Symantec MessageLabs Intelligence Report for January 2011. I've resized the Symantec graph to roughly line up with mine.




That doesn't seem very useful: Apart from the marked drop after christmas, there's little to no similarity. At least the dark blue line for greylist entries could show some some correlation - it's the total count of sender / recipient address combinations that's been fed to my system by spammers.

In addition, I can't see a positive effect from events like the shutdown of Spamit (as reported by Brian Krebs) or the decline of Rustock traffic starting from October 2010: To the contrary, the number of distinct hosts connecting to my system (light blue line) almost doubles in that time frame.

The other observation that doesn't fit into anything is the bump in whitelisted hosts (green line): Obviously this means that a group of spammers has successfully defeated greylisting as a counter measure, a fact that can be verified by looking at the volume of mail that has gone through to sendmail on the same system:



Have I been hit with something that has gone under the radar elsewhere? When comparing with M86's "spambot activity over time" graph in Krebs' "taking stock of rustock" article, linked above, there seems to be an activity spike from one of the bots around that date. I just can't make out which one it is from the legend, even using a colour picker.

Now I'm left wondering why that effective spam weapon has gone out of use at the end of October... Maybe it just wasn't worth the hassle after all, as most of the hosts that managed to pass greylisting turned out to be blacklisted. Unfortunately I've been blinded by my disinterest in spamfighting over the past year: I don't have any logs that reach back into October to find out more.

Maybe anyone else has some useful information in this regard?

Ever since I bought an Evoluent VerticalMouse, having the middle mouse button on the scroll wheel felt kind of awkward. Since it already has three buttons on the right hand side, I'm now using the actual middle button, and the one on the bottom as right button. Remapping is done vie a custom script in /etc/X11/Xsession.d (only works if the mouse is connected when X is starting up, but that's good enough for me).



(Under Windows, I'm using X-Mouse button control (cache) for the same task.)