Worklog

[Installations] Cyrus on Solaris

I’ve got Cyrus IMAP running on Solaris now.

First, get the right Jumpstart configuration up so that you can get the build environment (and then don’t forget to add Sun’s C compiler). And also don’t forget to add Berkeley DB to the Jumpstart config for later…

Then, the following:

• Install OpenLDAP 2.2.x: SASL and IMAP really want this, even though Solaris has it’s own LDAP libs. For some reason they won’t work right, at least at first blush.

• Install Cyrus SASL. The configure arguments are “—enable-login —with-ldap=/usr/local —with-openssl=/usr/local/ssl —with-ipctype=doors”. Don’t forget to use crle to add /usr/ucblib to the shared lib search path.

• Install Cyrus IMAP. The configure arguments are “—with-bdb=/usr/local/BerkeleyDB.3.3 —with-ldap=/usr/local —with-cyrus-user=cyrus —with-cyrus-group=cyrus —with-openssl=/usr/local/ssl —with-sasl=/usr/local”.

• Create the config directory (/var/imap) and partition directory (/home/spool/imap), owned by the cyrus user and group, and with 0750 permissions.

• In the IMAP build directory, run tools/mkimap as the cyrus user to populate the config and partition directories.

• Start saslauthd and the IMAP constellation, and things ought to work.

Next up, making Sendmail 8.13.3 compile and run on Solaris instead of the native Sendmail.

[Firefighting] Disk failure on Xserve RAID

Disk 8 (first disk on right side) failed at 5:58 this morning.

It’s currently rebuilding onto the hot spare disk 14 and should be done in an hour or so. I replaced the failed disk with the spare from the parts kit and will call Apple for a replacement spare.

I hope this infernal beep turns off when the array is finished rebuilding.

[Installations] Baleen racked and testing

After turning off MIR, I installed TAIKA in the rack for Baleen and initiated more thorough testing of Baleen.

I used the ethernet cable from MIR for the gigabit link on TAIKA as well as the power cables from MIR.

I’ve got procmail sending duplicates of everything it gets for a few people through Baleen on TAIKA and filing the results in another folder so we can see how well it works. So far we seem to be doing quite well.

I got a logo for Baleen, and I’ve been doing a little polishing off of the web interface as well as some minor behind-the-scenes work. I’m planning on letting this run in preliminary testing mode for a week or so as I work on other stuff, finish some details, and monitor the system. Then we’ll go into production testing, where I turn it on for the whole domain but in log-only mode except for volunteer users. Finally I’ll convert it to full-on mode and celebrate.

[Upgrades] MIR decomissioned

I turned off MIR this morning after having let it slowly fall out of service this spring.

Print services were turned off two weeks ago, and everything else had been off since much earlier in the semester. I’m planning to keep the box around in case wee need to get data off the hard drives for another little while, then I’ll wipe it and get it ready for recycling/selling/whatever.

[Installations] SAgate: name change and fully testing

Well, SAgate has a new and catchier name: Baleen (as in whale). I’ve also gotten the bugs worked out of the system and have it running is general test mode (accessible with a special domain address, but not yet handling all of our domain’s traffic as the default MX).

The main bug was that SQL preferences weren’t taking in SpamAssassin properly. I don’t know what the right incantation for the SA perl code ended up being, but I found a way to run spamd with full SQL access, referencing full address usernames (and not trying to setuid), so I modified the MIMEDefang code to run spamc and submit the message to spamd, and this seems to work. This means we’ve got an extra fork going on for spamc, and if I get a chance I may look into making the MD code a spamd client itself. One nice thing about using spamd is that I can make config changes to SA without having to take down MD. Nice decoupling. Now I need to delete the cruft code from the MD filter.

I also had to download the DCC clients. I was under the mistaken impression that I had some perl modules that were DCC clients already, or that it was somehow included with SA (like the URL block lists are). No such luck, but the FreeBSD port is workable and available. I may try to see if I can run some daemon mode DCC service so SA doesn’t have to fork off a DCC client itself for each message, but that’s less of a worry.

[Training] Solaris 10 Boot Camp

Went to a Solaris 10 boot camp shindig over in Indy on Wednesday.

A decent amount of intro material. I got to scratch the surface of Dtrace, Zones, and ZFS.

Impressions:

• Dtrace: way cool for debugging or performance tuning, but probably not terribly useful in day to day activities. It’s hard to tell with an hour of talk just how useful it could really be. I suspect it’s more useful than I’m quite understanding without having played with it a lot more.

• Zones: a poor excuse for a virtual machine. IBM, VMware, and Xen have it right: virtualize the hardware, not the operating system. Zones seems like the FreeBSD jail mechanism taken to the obvious but the necessarily ridiculous extreme. Instead of trying to manage operating system resources and information at two levels simultaneously, just make a clean break and allow us to run whatever OS on the virtual container. Much cleaner break, and probably much more intelligible from a management perspective.

• ZFS: now this could be exciting. I really hope they add something other than mirrors to the basic volume set (RAID 5 would be nice). The management of storage hardware could become child’s play with this, though. And if it’s as fast and as robust as they say it is, there’s not a whole lot of reason to use something like Veritas. Technically, it sounds like UFS SoftUpdates taken to obvious and highly sensible extremes (and I almost wonder if that’s not exactly what it is).

• Services management framework: yeah, whatever. We’re still going to be writing startup and shutdown scripts, regardless of where you tell us to put them or what config language it’s all in. Nobody’s solved this one (or perhaps everyone’s solved it and nobody’s way is better than anybody else’s).

• Fault management: ok, good error messages and a huge knowledge base could be useful. I don’t much care about a tree structure to the fault hierarchy, but whatever. Making the messages searchable and meaningful is good.

[Installations] More SAgate

Gee, I wonder what I’ve been working on… SAgate is close to ready.

The following things still need at least an eyeball, if not some work:

• PHP user interface review (including “logout” links and a password change feature).

• General MIMEDefang filter review, particularly in the MIME rewriting area for tagged spam.

I’ve gotten the database all set up, installed phpMyAdmin and graphdefang to decent degrees. Milter-greylist is installed and works with the ports version of libspf2, even if that’s an older version. I had to make a few code tweaks in the config file generation for that and the startup script, but it’s all happy now and doing the proper thing with the config file. Oh, nice — not only does it tell you the time for the original greylist delay in the tempfail code, but it tells you the remaining time in future attempts (of course, this can be turned off, as I recall, but it’s nice for testing, at least).

[Installations] SAgate build continues

We’re getting closer with SAgate.

MySQL, MIMEDefang, and SpamAssassin are all there and looking like they’re working properly. The SAgate MIMEDefang script is happy. I’ll need to populate the database with some defaults, make sure it’s handling SpamAssassin ok, and then take a look at the PHP interface.

[Research] LDAP routing load on Sun ONE

Since I was having problems with the OpenLDAP proxy cache, I decided to stress test Sun ONE with the kind of traffic it would get from Sendmail. Turns out that it’s barely noticeable.

I updated all our LDAP records for the proper mail routing information and then wrote a script that selects a username or list name at random, one of our LDAP-routable domains, combines them, and asks for a few attributes. About 10% of the time it generates a random nonexistent address and asks for that. Then it waits for a random amount of time between 0 and 1 seconds (or 0.5 seconds on another test) before asking for another.

It maybe adds about 0.01 to 0.05 to the average 1 minute load average. Still we’re sitting at over 50% idle most of the time and below a load average of 0.50 except when I do the NIS dumps every 15 minutes (and it goes up to 0.60 to 0.70).

I think the proxy cache is not needed.