The Random Ramblings of a Sysadmin

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.

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.

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

Never! Today I had the pleasurable experience of doing a remote upgrade on my server. Usually, remote upgrades on boxes with no LOM is a nail-biting edge-of-the-seat experience, not so when they're running OpenBSD - for me, at least. I started by fetching the source and building a new kernel, a step made necessary by my use of RAIDFrame with autoroot. Most people wouldn't need to build a new kernel. Then I installed the kernel and rebooted, untarred the 4.0 tarballs and followed the rest of the instructions from the OpenBSD FAQ.