Here, in no particular order, are some bits of verbiage I've written over the years; the only thing they have in common is the fact that they all deal with sysadmin-ish topics ...
Some sysadmin-ish biases ... disk partitioning and filesystem layout, syslog configuration, spam filtering, rebooting after a kernel panic; more to come as time permits ...
A note I wrote expressing dismay about the lack of security awareness
among many attendees at a meeting of a group of computer security professionals
found its way into a National Science Foundation report.
In September 2004, in response to the “stakkato” intrusions (if you need some context, see one or both of ...
http://www.cnn.com/2005/TECH/05/10/govt.computer.hacker
http://www.nsc.liu.se/~nixon/stakkato.pdf
for more information), the NSF hosted
a cybersecurity summit to discuss what had been learned about the attacks,
the methods used to exploit vulnerabilities in compromised systems, and
so on. A post-conference comment that I sent to the organizer was included
in the
final report to NSF: See “A Note from One Participant”,
beginning on page 39. (I didn't ask to have my comments
anonymized, but I guess the author(s)
of the report assumed that it would be my preference.)
With a bit of sadness, I've come to the conclusion that Linux is evolving on a path different from what many of us had envisioned (and hoped) way back in the early days. I've run into far too many instances of code that has all the earmarks of rank amateurism, and an approach to coding that goes against everything that Jon Bently tried to guide us toward. And amazingly, the shoddiness shows up even in code distributed by major Linux vendors. A small handful of examples are ranted about here.
I'm absolutely astounded that people still write code with fixed-length buffers, and no graceful recovery if the data that needs to go into that buffer is larger than the fixed size.
Although we escaped the “stakkato” attacks relatively unscathed (two desktop systems, both of which suffered from “benign neglect”, were compromised; but none of our large compute resources were), we decided to tighten up security in a number of ways.
One thing we did on some of our large resources was to use a verion of OpenSSH built with libwrap, and use hosts.allow to permit connections only from known IP addresses.
Unfortunately, it turns out that libwrap has a fixed-length (and not very large; 2048 bytes) buffer to hold the information from hosts.allow, and when sshd starts up, there's no indication that anything is amiss, aside from some auth.log entries.
Here are some some e-mail messages from a couple years ago, when we first bumped into this problem.
Another pet peeve is poorly-written software churned out by people who blindly forge ahead and start coding without spending some time thinking about how the code should be written.
When the DEC Alpha first hit the market, a lot of software which had been used for many years (and was probably assumed to be bug-free) crashed and burned. The reason was that it wasn't 64-bit-clean: It worked fine on all the 32-bit platforms, where integers and pointers were the same size; but that didn't mean that it was right. After all, Kernighan and Ritchie had been warning us for years never to assume that integers and pointers were the same size. But a lot of programmers didn't pay attention, and as soon as a platform appeared where integers and pointers were different sizes, a lot of users of that software suffered the consequences, until the bugs got fixed.
Here's an example from quite a few years ago; but the same careless programming techniques are still all too prevalent today, sad to say. The original story (which dates from my CITA days) and the postscript at the end are contained in an e-mail message that I sent to a colleague not long after we moved from Toronto and I'd started working at Caltech.
And looking back, I still feel that although my criticism was harsh, it wasn't unjustifiably so. Why, why don't people spend more time thinking before coding? This problem could have been avoided (and the software given a major boost up the portability ladder) if the author had simply spent ten or fifteen minutes thinking about alternative approaches, and perhaps an extra five or ten minutes coding.
[This is a partially-redacted version, with the names of the organization and the author(s) (and other people) changed, to protect the guilty.]