Over the past year, my place of employment has had the opportunity to change a lot of our alert handling procedures, not least when it comes to hardware, and that has been the cause of a lot of very nice changes for those of us in the trenches. In short, we have moved from reactive to proactive where it matters, which means we get to sleep at night even when on call.
As the timeline of my posts clearly shows, the last few years have featured absolutely no new posts here. Much of that has to do with tools. The right tools makes a huge difference to productivity and to what time is spent on, and sadly, these last few years it has occasionally felt like I've spent more time fighting my tools than being productive.
Changes are afoot at my little abode on the interwebs, first of all I've decided to ditch Wordpress for Drupal and to change my primary domain for this little collection of random ramblings. I'm also half-stride in a server move and many other changes, great and small.
During my time as a consultant I've seen many interesting takes on security. Today has been no exception. When visiting a client, we found that a new security policy has been enforced. In order to ensure that only authorized personnel and invited guests are in the building, they now require that guests are wearing guest access cards.
Every few years I come across one of the little boxen, and every time I face the same issue. I can clearly remember that the RAID is slow for a reason, just not which reason. This posting is intended to save me from spending time on google in a few years...
The Dell PowerEdge SC440 is a nice little Xeon-based tower server featuring a SAS 5/iR RAID controller. The sluggish writes are due to the default disabling of write cache on the controller, which is just fine for making sure data are not lost if the power fails, but which also drags performance down to ridiculous levels.
I recently had the opportunity to fiddle a bit with getting iChat video chat to work properly with PF and NAT. As we all know, NAT is evil - getting ugly protocols past it no less so.
First step in finding out exactly what went wrong was doing a bit of tcpdump on the internal firewall interface while trying to connect to a video chat session:
From the capable minds and hands of Solido Systems I got a license key for the spamfilter they make, and just had to try it on my OpenBSD 4.4 server. The filter is a java app with a spamasssassin plugin, and with java 1.7.0 included in the package list for 4.4, the time was right for testing - I'd previously had (and lost) quite a few fights with java from ports on 4.2 and 4.3.
Recently, the company brought in a clownsultant (supposedly he'd not only taken a VCP but also been a VCP course instructor) to upgrade our VMWare ESX cluster to ESX 3.5 and VC 2.5. This lead to a number of interesting issues, that I'll list here - with solutions for your enjoyment:
1. Upgrade failed with the server stuck at GRUB after reboot
Solution: disconnect the fibers from the HBA before upgrading, they seem to confuse grub-install even if you select the right boot device (internal RAID) during install/upgrade.
With release 3.2.1, using mini_sendmail on a chrooted Apache on OpenBSD was suddenly broken. With the following error message in the log being the only result of trying to send mail:
usage: /bin/mini_sendmail [-f] [-t] [-s<server>] [-p<port>] [-T<timeout>] [-v] [address ...]
This caused me a bit of a headache at first, but the answer was out there - if not entirely easy to find.
One of the latest crazes in the open source world is planets, not your regular space-bourne lump of rock surrounded by an odd assortment of gasses, but the blog-related kind of planet. Latest might be a wrong word to use now, but it was correct when I started thinking about writing this entry. Work just happened to get in the way of any actual writing for quite a few months. Among the more interesting planets, you'll find the linux distribution-related ones, such as planet.debian.org and planet.gentoo.org.