The Random Ramblings of a Sysadmin

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:

1235401525.872542 192.168.142.30.16402 > snatmap.mac.com.5678: udp 16 1235401526.060152 snatmap.mac.com.5678 > 192.168.142.30.16402: udp 16

So far so good, the connection to the SNATMAP service at Apple worked nicely.

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.

May 1st means new OpenBSD release, this year being no exception. One of the things that really amazes me in regards to the OpenBSD project is how precise the release schedule is. Though I should have gotten used to it over the years, it still strikes me as an example of how much a proper plan means for development and releasing on time. Regular, fixed release dates combined with the policy of small evolutionary steps means more than ten years, yet only two remote holes in the default install - it also means easy planning for those of us that have multiple hosts to upgrade. Getting down to business, my use of RAIDFrame means the usual "make new kernel first" procedure. This time I'll try to add a few more details, though all the information needed for this procedure are in the OpenBSD FAQ and the excellent RAIDFrame How-To on Eclectica.ca. The procedure leading up to the point where the upgrade FAQ can be followed is quite simple, and only step 3 is different from the process for building new kernels listed in the upgrade FAQ:

1. Update the source tree
2. Build the kernel
3. Copy the kernel to the boot slices
4. Reboot

Or maybe not, but at least the end of contact forms with CC-options and no captcha or login has finally arrived. Over the last few weeks I've seen a remarkable increase in the bot-driven abuse of contact-forms to send spam, and have spent inordinate amounts of time tracking down perpetrators and helping clients fix their sites. We've managed to plug most, if not all, holes in client sites, but it serves to illustrate the ever increasing ingenuity of the spamming community.