Nate Campi’s Blog

There was an email interview with the nice people at searchenterpriselinux.com that resulted in an article. Here it is.

I’m one of those people that gets a kick out of signs with stick figure people getting themselves into all kinds of trouble, such as this picture:

I also like silly warning signs, though this one is a little extreme, I admit:

Every good system administrator likes to get work done, real project work. It’s not enough to just work hard for 8 (or more) hours, they need to feel like they made real progress on projects or that they were making a change for the better that day.

Just the other day, my entire work day was made up of in-house code releases, configuration file updates (distributed via cfengine, of course) and helping other SA staff while they learned to use Subversion. Most SA’s would consider the day wasted. It was all busy work, no project work.

A typical SA manager probably figures that they day isn’t wasted, they may say, “You’re getting paid, what do you care? On days where urgent non-project work is required, just do the work and let manager worry about making up project progress.” Pay is all well and good (very good, actually), but a good SA wants constant progress, constant improvement.

As a (hopefully atypical) SA manager, I’m glad to see SA staff unhappy with tedious busy work, and that they want to make things better. Every once in a while though, I do sorta wish that a day of tedium here or there didn’t bother them that much - such days are occasionally unavoidable. Doing everything we can to avoid them with automation, though, sounds like a good idea to me.

Today I had this Craigslist listing forwarded to me, it’s for a “manly bike”, and it’s hilarious.

http://www.craigslist.org/about/best/sfo/765370039.html

It seems like I decide every year that I’m finally going to make some of those long-planned improvements to my UNIX infrastructure at work. I always predict that this year is going to be different, and that we’ll beef up the hardware and reinstall infrastructure hosts (DNS, LDAP, cfengine servers, etc) and enhance our system management procedures.

Well now I’ve been doing that enough that I realize the folly of all that “someday” planning, and I’m moving forward now. We’re doing some painful and important upgrades now at work, over the holiday period, because there’s no time like the present.

Wish me luck.

During the enhancement of the example UNIX/Linux infrastructure in my book, everything contained on the cfengine master as well as the configuration files for the three imaging systems (Kickstart, Jumpstart, FAI) were all checked into Subversion.

Since everything done for the book was done in real life, I have a working SVN repo with all the source code, including the various binaries built for the book. If people think it would be useful to have the full repo available for anonymous checkout, I’d be happy to do the work to make it available.

I’d just have to comb through and make sure that the passwd/shadow files and the like are safe to share. I won’t bother doing the work unless people want me to, so let me know via email or comments on this blog entry if you’d like to see it.

My book is coming out today, and of course I’m nervous.

The most important thing to me (and Kirk, I’m sure), is that the readers of the book feel free to come directly to me with questions or feedback. Feel free to use the email address given in the introduction, or append comments to this blog entry. If something is unclear, I’ll clear it up. If you suggest improvements, I’ll keep track of your suggestion for future editions.

Just don’t be bashful, I want to help.

If you’re interested in cfengine or automated UNIX/Linux system administration, you can view a sample chapter from my new book here at cfengine.org.

Check this out - at first I couldn’t tell if it was for real. Damn funny.

Again and again, you hear a system administrator criticize the work of their predecessors as stupid or naive. Previous sysadmins put together an infrastructure or automations or simple services they best they can, and later sysadmins usually find it to be totally unusable and needing to be re-done.

I have to admit that I’ve fallen victim to this quite a bit over my career as a sysadmin. I’d look at some method used to lay out applications in the filesystem, or the way that DNS replication was set up, etc, and pronounce the setup as “retarded” and proceed to grumble about it and eventually replace it.

Here’s the rub: I’ve now been doing this job long enough to have some of the apps, systems, infrastructures that I’ve set up live long enough to be criticized by others after I’m gone. I don’t remember offhand if any criticisms have made it back to me - but I guarantee that my work has been badmouthed quite a bit. Now if I were there, it would be easy to answer questions. If they said “why do the DNS servers all replicate every last zone controlled by our company, even if that DNS server doesn’t have it delegated there?” A casual glance would make it seem like a lot of extra work on the part of the DNS servers to slave a lot of uneeded zones. That’s too quick a look, of course. It saves human time to never have to worry about how to set up a new DNS server and getting the right zones there if every DNS server simply loads up all the zones.

Other questions wouldn’t have such complex answers - sometimes the answer is as simple as “we knew it was a dirty hack of a solution, but we were under pressure to get it done and it was the least evil choice at the time.” The funny thing about SAs is that if there’s no one around that built the system, they tend to chalk up the choices to stupidity.

I’m now old^H^H^Hexperienced enough that I usually assume the choices made were the best available at the time, and don’t assume the staff were morons. Heck, whatever company and infrastructure I’m working on at the time got the business to the current point, which if I’m being paid, is a functional environment.

I dunno, maybe people are just jerks, SAs included.