Recently Evan Root left a comment on my entry on a bad Linux kernelmessage where he said:

I believe the reason why the Yama message is cryptic and'intriguing' is because tedious committee sanitized messages such as"AppArmor: AppArmor initialized" are at odds with the core principalbehind Ubuntu "Linux for human beings"

This is not an uncommon view in some quarters but as it happens Idisagree with it. It's my view that there are two things wrong here.

The largest is that clear technical writing

Sometimes not everything goes well with our ZFS fileservers . Today was one of those times and as aresult this is an entry where I don't have any solutions, justquestions. The short summary is that we've now had a fileserverget very unresponsive and in fact outright lock up when a ZFSpool that's experiencing active write IO runs into a pool quotalimit.

Importantly, the pool has not actually run out of actual disk space;it has only run into the quota limit, which is

Every so often I read another paen to the 'inbox zero' idea and gettempted to try to do it myself. Then I come to my senses, becausewhat I've found over time is that the 'inbox zero' idea simplydoesn't work for me because it doesn't match how I use email.

I do maintain 'inbox zero' in one sense; I basically don't allowunread email to exist. If it's in my actual MH inbox ,I've

I've said in the past that I'm a Unix pragmatistinstead of a purist (and in general I've wound up a pragmatist aboutcomputing in general). In thinking about it recently, it's struck methat it's probably very hard to be both an old Unix hand and a purist,so it's not entirely surprising that I've wound up this way. To putit simply, the history of Unix since the late 1980s is a history

Now that I've upgraded to Fedora 21 on my main machines and actuallyhave it available, I've decided to start shifting my OpenSSHusage towards considering ed25519 my primary and preferred publickey authentication system ( out of all of the ones that OpenSSHoffers ). Moving towards Ed25519 for myown keypairs was and is simple; I generated some new keypairs(one for each master machine), loaded them into ssh-agent first , and started adding them

It started with a series of tweets by C J Silverio :

@ceejbot :maybe this is the cold medicine, but was thinking thatcontainerization is a reaction to a failure of operatingsystems. Well, unix.
@ceejbot :Or maybe it's a success, because you can do that on top of Unix, but ata cost.
@ceejbot :A app or server or "thing you want to deploy & run" can't beisolated. Config & deps are splattered all over.
@ceejbot

One of the general devops mantras that I've seen go around is thepets versus cattle metaphor for servers ( eg );pets are lovingly curated servers that you care about individually,while cattle are a mass herd where you don't really care about anysingle member. My perception is that a lot of current best practicesare focused on dealing with cattle and converting pets into cattle.Unfortunately this leaves me feeling relatively detached from thesepractices because essentially all of our important machines are petsand are always going to

I've mentioned before that we have acentral console server machine where all of our serial consoles andother serial things all get centralized, automatically logged, andso on. While I don't think we're doing anything unusual in thisarea, I've realized that doing decent sized console servers isprobably no longer common and so it might be interesting to describehow ours works.

The obvious way to do a (serial) console server is just to build amachine with a bunch of serial ports

Back some time ago we really likedserial consoles here ; we configuredall of our machines with them, whether they were Linux or OpenBSDor whatever. But lately we've been moving distinctly away fromserial consoles, to the point where none of our current generationmachines are set up with them any more. We're doing this becausein the end serial consoles got in the way of our troubleshootingduring serious issues.

What we found is that often the times we deal with machines arewhen they're bad