I got my Sysadmin Magazine CD Today

When Sysadmin Magazine closed their doors, they decided to send out their complete publication on CD to all the subscribers.

Mine arrived today. It's pretty neat. The first issue was May/June 1992. I was 11. Some of these ancient articles are awesome looking. A Community-Style Overnight Job Spooler starts off with:

For a small business running a single multi-user UNIX system, processes typically fall into one of two categories: real-time, interactive programs or batch style/background jobs. Interactive programs such as the system shell, editors/word processors, spreadsheets, and data entry systems all vie concurrently for slices of the CPU pie.

Wow. I guess they didn't use screen and vim back then :) You wouldn't want to overwhelm the CPU with a s///.

When I was old enough to get my drivers license (1997), and article entitled New Storage Interfaces states:

Interesting things are occurring with storage technology including the cost per megabyte (MB) dropping, faster drives, and higher bandwidths.

Hah, cost per megabyte.

I wonder what other gems I'll find in here? I've copied it to my hard drive (thanks to the dropping cost per megabyte), so I imagine spotlight will start returning insights into the past.

I shouldn't poke too much fun. I remember when we ran our mutli million dollar website on a 400mhz server with three 36GB SCSI drives and 512MB of memory. We were awesome because it was a $4,000 PC and not a $12,000 Sun box. It was a 4U rackmount chassis that was basically a tower flipped on its side.

Using Checklists

Niclas at Aspiring Sysadmin has an article about using checklists. It's solid advice. I typically call them procedures instead of checklists, but it amounts to the same thing.

I'd just like to add that Wiki's are the perfect tool for creating procedures and checklists.

First, I find it a lot easier to search and find things on a wiki than it is on a file server or my home directory. This is important because chances are you'll be doing it more than once. I've had to migrate data centers 4 times in 8 years and I've been able to recycle my procedures and documentation a few times now.

I've blogged before about creating a page per server. I'll include a procedure common to a server right on it's page. I also like to build 'knowledge bases' (I'll have to blog on this later) right into the wiki. Often times, my server maintenance entries include links to the central procedure, along with any places I had to deviate.

Wiki's typically have formating options for blocks of code, like shell scripts. That's handy for making them readable and copy/paste-able. Word processors typically don't work well for this as they like to mangle special characters. Text documents don't manage your ordered lists and aren't as readable for large procedures. Most wikis also format well for printing -- hard copies are important when you're network is down.

Of course, you can easily update a procedure on a wiki. You can add notes and change steps while you're working through the list if you find inaccurate information. It keeps track of the changes you've made, in case you want to go back to an old one, or at least see what it was.

One of My Uses for Twiki

I think Twiki is one of the best sysadmin tools out there. I've been using it in my day to day work for a few years now.

One of my favorite uses is for a Service Journal. This is part of my light weight change management strategy. Each one of my servers gets its own page. I record vital information about the server (serial number, OS, hardware, etc), changes to the system, issues the system experiences and anything else that may possibly be useful.

I'll use a TemplateTopic to create those pages. My layout is something like:


---+ Information

---++ Table of Contents

%TOC%

---++ System Information

|*Hostname*| _server name_|
|*CPU*| Xeon 5110 |
|*Memory*| 2GB |
|*Vendor*| HP |
|*Serial Number*| 123abc |

Of course, put whatever you need in here, like drive configuration, OS, installation date, etc.

---++ Warranty Information

---++ Installation Notes

---++ Work Log


Using Edit Tables make the table easy to update.
The worklog section on the wiki page to keep track of changes and issues. I use a format like:


* 18 Sep 2007 - [[SjServerName#SepHdFailure][Server Name - hard drive failure]]

#SepHdFailure
---++ 18 Sep 2007 - hard drive failure

At 10:15AM, Nagios sent a page saying sdc had failed. I grabbed a spare drive and replaced it at about 10:30. The rebuild process finished at 11:15.

-- Main.GaryRichardson - 18 Sep 2007


I'll also create these for configuration changes.

It's a really straight forward format:

1. Using the Event Syntax for the date, you can get the events recorded in a calendar
2. Linking to an #Anchor allows for linking -- the event that shows up in the calendar will automatically jump to the right spot on the page
3. Each event gets it's own section in the wiki page. There's plenty of room to paste in (using verbatim tags) the output of commands and log files. You can add in procedures that were followed and screen shots if you like.
   

Each servers page will be named something like SjHostName. It's easy to create a dynamic list of servers using FormatedSearch. For example:



%SEARCH{ "^Sj.+" scope="topic" nosearch="on" nototal="on" regex="on" }%


You can do even more advanced stuff using the header and format lines -- I have tables that include OS, CPU, Vendor and Location for easy sorting.

My Favorite Magazine Is Now Gone!

I started flipping through my lastest copy of Sys Admin Magazine and found this in the Syslog/Note from the Editor section:

This is the last issue of Sys Admin Magazine that you will receive. The magazine is ceasing publication as of this issue.

It's really sad. I looked forward every month to flipping through and reading up. I've subscribed to a few other industry magazines, and none of them have been as good as Sys Admin for showing me the things I care about but didn't know about.

What's worse is that you can see the lack of love and care put into this last issue. The last issue should be an awesome goodbye to the 16 years the magazine has been around.

I haven't heard too much buzz about the magazine going away -- nothing on Slashdot, no other blog posts. Maybe it's because no one else was reading or cared?