Earlier this week I read an entry from this year's SysAdvent, Introducing the Guide to Sysadmin Body of Knowledge .If we're going to talk about a sysadmin body of knowledge, the firstthing we need to talk about is whether this BoK is intended to bedescriptive or prescriptive.

A descriptive BoK essentially restricts itself to an inventory ofpractices with descriptions about what good or bad things can happenwhen you use the particular practice. That's why it's a descriptive BoK;it simply describes things

Here's something that I hope everyone understands about sudo butthat I want to say explicitly anyways: sudo is not an auditingmechanism , not for sysadmins who are expected to use general andunrestricted root powers. There are at least three different problemswith sudo as an audit mechanism:

• sudo cannot track what an intruder does as root . Once the intruderruns, say, ' sudo bash -i ', sudo is simply not logging things anymore. Only a very cooperative intruder will helpfully run all of theircommands

For reasons beyond the scope of this entry I've recently been thinkingabout my attitudes towards sudo . Sudo is a complex program with a lotof options and several different ways of using it, and in the processof my thinking I've realized that for me it's effectively three thingsin one (and I feel differently about each facet). So here are my threefaces of sudo :

1. sudo as a replacement for having specific setuid programs.You're using it to give (passwordless) access

I recently wrote a program in Go and in theprocess I realized what Go has become to me. To put it in a nutshellI think of Go as Python with performance. Specifically, my naturalinclination is to write test programs and other utilities in Pythonbecause I find that the easiest and fastest way to work. Most of thetime this is fine but every so often I write something where I careabout the performance and want something relatively close to 'as fast asthe computer can possibly deliver' (and

This is a mystery (ie I have no answers yet), and also a story of what Ithink is the perversity of hardware (I can't be sure yet). I'm writingit up partly because I rarely see sysadmins writing up our problems,with the result that I think it's easy to underestimate how weird thingssometimes get out there.

We have a server with an external SATA disk enclosure. The enclosure hasthree port multiplier based (E)SATA channels, each with five

The other day I mentioned thatmodern versions of Linux handle things like activating software RAIDdevices through their mechanisms for dynamically appearing devices,which is often called 'hotplugging'. Some people don't like thisapproach; one way that people put it is that hotplug is fine for thedesktop (or laptop) where devices come and go, but servers have aconstant set of hardware so shouldn't need the complexity and inherentunpredictable asynchronicity of the whole process. It's my strongopinion that this is wrong

Here is a question that is periodically relevant: just how does a modernLinux system assemble and bring up your software RAID arrays (and othersoftware-defined things, for that matter)?

I've written about the history of this before so I'll summarize: in the very old days thekernel did it all for you and in the not as old days it was done by ascript in your initial ramdisk that ran mdadm , often using an embeddedcopy of your regular mdadm.conf .

The genesis

Every so often I pose myself a question which turns out to not reallypan out. Recently I wound up wonderingwhat sort of patterns I'd see for the destination addresses ordomains of bounce email generated by our central mail server. WhatI expected to see was a good showing by what I consider my usualsuspects, the kind of places that cause me to write that recent entry . Instead I found that we seem to generate afar lower volume of this sort of bounce than I expected and there are no

Sometimes when I'm writing about Python things, I talk about 'CPython'(as I did yesterday ). This is insider jargon;CPython is the term of art that's generally used when we're specificallyreferring to the behavior of the main implementation of Python (which iswritten in C, hence the 'CPython' coinage). This is the implementationthat gets most of the publicity and a starring role on python.org . CPython is the Python that is 'version 2.7.