The Life of a Sysadmin

Just a heads-up for anyone in Canada: the Standards Council of Canada is taking comments on adopting Microsoft's Office Open XML as "an international open standard". Take a moment and add your voice to the 215 comments, nearly all of which are against this proposal.

When trying to install OpenBSD to a Sun Ultra 1 workstation over the network, I got the Fast Data Access MMU Miss error when running boot net bsd.rd. Turned out I'd copied the wrong boot loader to the TFTP directory; copying ofwboot.net over it fixed the problem.

New emacs, woo! I've downloaded it and compiled it already, 'cos I am that l33+, thank you. But one thing: the tarball is signed by Chong Yidong, pgp/gpg key #BC40251C. I could not find any indication anywhere that this is the right key, or what the right key might be. A quick search turned up lots of posts on the Emacs mailing lists, bugzilla entries and such from him, so I presume it's okay…but it would be nice to make this explicit. (Even a search for the key number turned up nothing.)

This article about updating pkg-src makes me even happier I went with Debian. That is all.

Yesterday I got a new switch in at work. Good god, the 10/100 Procurves are getting cheap — $600 w/academic discount for a 2626. I was just going to rack it, but as always I couldn't stop once I got going; that server room needs a lot of cleaning up. Three hours later I emerged, bloody but triumphant: the network cables were cleaned up considerably, I'd identified the last of the mystery boxes (step-down transformer, not a UPS like I thought), and I'd figured out that the big UPS was only one-third loaded — plenty o' room. Once I get all the cleaning done, I'll post before-and-after pix, 'cos that will be one chunk of work I'll be damned proud of.

All morning I've been hearing voices. I was beginning to think it was late-onset schizophrenia, but instead it was just my Ogg player; I'd put it in my pocket without locking it off, and it was stuck on repeat, playing a podcast. That was a bit of a scare.

A coworker misheard me today and stared at me. "Next beer in Jerusalem?"

I think that's gonna be my motto from now on.

This morning I noticed these entries in the logs of my monitoring machine at work:

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xef
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xef

After a lot of Googling, I managed to find a few things that explained it:

• This bugzilla comment from Dave Jones explains "51/04 is the drive saying I don't know what that command means after being told to do something. It's not an error." The failed opcode — in this case, 0xef — is the operation that's being tried and confusing the HD.
• This page says "yep, that'll happen, all right" (no, not a direct quote) with SLES 9 and Seagate drives, and says you can ignore it. No explanation why.
• Finally, this post to the LKML says that opcode 0xef is telling the hard drive to keep its settings over a reset, and can be produced using hdparm -K 1 /dev/hda. Sure enough, running this produced the error in the logs, and this one on the screen:

setting drive keep features to 1 (on)
HDIO_DRIVE_CMD(keepsettings) failed: Input/output error

This is a completely benign error, of course…I really don't care if we have to run hdparm with every boot. I had also tested the drive by booting into Knoppix and md5summing every file on the drive — no errors produced at all.

Don't know what's worse — wasting two hours on this, or not noticing it before now. At any rate, this failed opcode appears to be completely harmless.

It astounds me that, until a couple of days ago, I did not know about Bash's help or declare functions.

...is this picture of Arlo and me:

My god, the kid's cute:

There is always time to script something. (Well, nearly always.)

For a while now I've been irritated with the behaviour of OpenRCS and Emacs on my OpenBSD machines: every time I try to check out a file kept in RCS, using C-x v v (vc-next-action), I still have to toggle read-only status on the file. Then, when I try to check it in, it asks if I want to steal the lock from myself, and never actually checks it in.

Finally had some time to track this down, and this bug appears to be the cause. I may have to play around with Emacs a bit to get it to ignore the permissions, or I may just use the OpenBSD package for GNU rcs instead.

My wife was using her iBook tonight when alla sudden Apple Mail said the Inbox was read-only. Wha'? Couldn't remove or create files from the Terminal, and /var/log/system.log showed this message:

kernel: disk0s3: I/O error
kernel: jnl: do_jnl_io: strategy err 0x5

A lot of scary messages turned up in the search results about replacing hard drives, memory and mainboards, but I decided to try a fsck for the fun of it. Splat-s sent the Apple into single-user mode, and then fsck -f -y said the volume had been repaired successfully. Reboot and things look good: I can create and remove files, and Apple Mail is fine. Interestingly, the disk said it had an extra GB free compared to before the reboot.

The drive is old, and may still need replacing. Thankfully, I've set up a cron job on this thing to rsync the home directory daily to another machine.

This entry, detailing the love that comes from XTerm's meta-sends-escape functionality, saved me from tearing my hair out today over why the Alt refused to send Meta to Emacs in a terminal. And hurray for this line in .Xresources:

XTerm*metaSendsEscape: true

Exciting times, I tell you.

Yesterday I finally moved the monitoring machine at work from SuSE 9.1 to Debian Etch. It still amazes me how easy Debian makes it to install things like Nagios, Apache 2 and RT (!). I hadn't paid attention before to the way Debian handles loading websites and modules in Apache, and that's just elegant…the same mess o' symlinks that you use for /etc/rc?.d. Nice.

Of course, that didn't prevent some silly problems with Nagios from cropping up, but it was stricly PEBKAC. By the end of the day Nagios was watching everything again, RT was moved from my desktop machine (with tickets intact), and all was well.

A nice overview of system administration, and a thoughtful reply from Ben Rockwood. As always, I've got lots to learn.