autofwd
While implementing IPv6 in my company network I also started looking for a replacement for fail2ban. Fail2ban is a tool which monitors log files looking for anomalies. When someone tries to brute force your sshd, fail2ban will notice and block the offender using iptables or whatever firewall you use.
Fail2ban has served me well the last couple of years, but it doesn't support IPv6 and the last release was on 7-9-2009 which is almost 2 years ago. This didn't give me the idea the IPv6 support would ever be implemented. But then again, I can be wrong...
I gave a stab at writing my own implementation which would support IPv6 and started looking on freshmeat looking for similar scripts to see how they worked. Then I found a small Perl script called autofwd written by Arthur Corliss. I downloaded it to see how if there was any usable code in there but quickly found out that it actually was the tool I was looking for. It's portable, so you can use any kind of firewall with it. I myself use shorewall and it took me only a couple of minutes to plug that in.
If you're looking for a flexible/portable fail2ban replacement I certainly recommend looking at autofwd. It doesn't have a homepage but you can get it here. I've created a Debian package which is available here.
Debian/Ubuntu not resolving domains with the .local tld
For some time I've been wondering why none of my Debian/Ubuntu workstations would resolve something like 'proxy.mycompany.local'. Simpy resolving 'proxy' would work.
I already knew that .local is not a correct tld, but since it was recomended by Microsoft to use this when installing Active Directory we used it. I never had any problems with it because most of the time I just use ip addresses when I need to access a server.
Now I installed a proxy server and a new mail relay server so I started using them as proxy.mycompany.local and relay.mycompany.local. The I found out that none of my Debian or Ubuntu workstations would resolve those addresses. At first I blamed the Microsoft DNS server for this. That's the easiest and most logical thing to do ;-). But Windows XP/Vista clients did resolve those addresses. Strange huh?
Then I started wireshark on my client. I did a query for proxy.mycompany.local and then there was.... an MDNS request instead of a normal DNS request?!?
This quickly gave me the conclusion that it was something avahi related because this does all the zeroconf stuff with Debian/Ubuntu. Avahi seems to be configured to pick up any request ending in .local and make MDNS requests for it. This must be a problem for more people because there must be loads of Microsoft networks out there ending in .local. I won't say this is a fault from the avahi guys because it's also completely wrong to use .local as tld.
My current solution is to just simply disable Avahi on my workstations. On Ubuntu I just do 'System -> Administration -> Services' and disable 'Multicast DNS Service Discovery' there. With Debian I just disable the startup of Avahi in /etc/default/avahi-daemon by settting 'AVAHI_DAEMON_START=0'.
VLAN with Debian (Part 2)
There's another way to create vlan interfaces with Debian/Ubuntu. It's even shorter than the previous example. Just add the following to /etc/network/interfaces:
auto eth0.10 iface eth0.10 inet static addres 10.0.0.2 netmask 255.255.255.0 gateway 10.0.0.1
Just make sure you dit 'apt-get install vlan' or something like that.
VLAN with Debian
It's just that I can't remember how to make vlan's witch Debian. I always have to re-invent the wheel or look at old configs which are never where I think they are... So... Here it is so I don't have to remember it and maybe some other people will find it useful.
In /etc/network/interfaces you add the following:
# Vlan 10
iface vlan10 inet static
adress 10.0.0.2
netmask 255.255.255.0
gateway 10.0.0.1
vlan_raw_device eth0
This will add vlan10 to interface eth0. It's so easy but I just cannot remember it when I need it.
keepalived 1.1.15
I've backported keepalived from Debian Lenny to Etch (4.0). Both i386 and amd64 are available for download here. There was no need for changes from the original package, only a recompile.
I'm thinking about packaging feedbackd and use it together with keepalived to adjust the weight of realservers during runtime. I'm not sure if it's feasible, else I will write my own poor mans implementation.
Monitoring with Nagios 3
Because the release of Nagios 3.0 is comming closer, I wanted to have a look at it. I've found some nice packages on the blog of Sven Velt. Those packages are for i386 only and I needed amd64 packages. I just took the sources and recompiled them for the amd64 architecture. You can get them here. I take no credit for the packages because I merely compiled it.
Nagios 3 looks good. It has some nice new features like the multi line output for plugins. This wil likely make it possible to run more checks with less stress on the Nagios server. I'll post more when I find more nice features :-)
Perl
Finaly I took the hurdle... I ordered two Perl books. Now lets read them and drop the shell scripts :-)
Microsoft’s Ballmer Reportedly Threatens Red Hat
I just read groklaw. It seems like Microsoft is out to try to destroy FOSS again. Just read this and go figure why you shouldn't be using it. I myself have 4 M$ servers at work but this kind of stuff makes me think if I just could somehow ditch them...
Microsoft doesn't mind FOSS software as long as it runs on top of windows and doesn't compete with any of their products.
3ware_temp plugin for munin
After having my Nagios installation mostly set-up (I still want it to sms though) I figured I also wanted some performance graphs. Performance graphs are useful to predict problems, you can see the performance of your server (d0h), figure out strange problems and the most important thing: they look cool to people who don't understand them. :-)
At first I figured because I use Nagios, I should also use Nagios to provide me with the performance data. Nagios does all the checks and I could use the output of the checks to feed it to rrd and let it make the graphs.
After searching the internet and looking at NagiosExchange I decided to use n2rrd. This tool uses the performance output from the nagios plugins and makes the graphs from there.
I have to say, it really is a great tool. I would recommend looking at it. But still, after some testing, I didn't use it. The problem I had was that most of the plugins I'm using do not give the right performance output or it was pretty much unclear what the output meant. This was a bad thing because now I had to modify the plugins which is something I definitely do not want because I'm using prepackaged plugins and it takes a lot of work.
So I got munin up and running. Munin is packaged for debian and comes with a *lot* of ready to use plugins. After configuring everything I needed I looked at the hdd_temp plugin. The hdd_temp plugin takes some configuration on 3ware controllers. You have to specify all the drives you want monitored and provide some mapping between drive names and 3ware controller possitions. In my case this is totally useless. I want to monitor all drives in my server. Do configuring every single drive is just too much work.
So, I wrote my own munin plugin which uses the tw_cli utility to detect the available drives and smartctl to query the drive temperatures accordingly. The plugin is available here. And here's some example output:
(This is actually a nice example of why you should do these kind of graphs. Above you can see the difference when the doors of the 19" racks are open and when they are closed. There seems to be a bit of an airflow problem. Nothing problematic though.)