Posts by Category


Pure New Zealand

This site is driven by Blosxom

his site was written in vi

SDF is driven by NetBSD

Subscribe to this sites RSS/XML feed

This site has a Tableless Stylesheet

Email me

Oct 10, 2006

Solaris Patch Management + More

Useful for Solaris admins - PCA - Solaris Patch Management Tool. Its a perl script that will patch Solaris 8/9/10 - SPARC & x86.

Retro gaming goodness via this web-java app - Virtual Nintendo.

Jason Kottke points to some Interesting Google Code Search hits.

Wikipedia article on last weeks South Park in World of Warcraft piss-take. The episode is a work of genius and I'm not entirely sure of the Wikipedia article writers realise the irony of spending time and effort documenting it ?

In light of the trailer for 'The 300' heres a slightly less fanboyish look back at The Battle of Thermopylae. Its a shame the movie is based on Frank Millers comic rather than Steven Pressfields 'Gates of Fire'. The comic is good but is limited by the medium; the book is brilliant.

Wonderful scanned magazine article from the 1950's of miracles you'll see in 50 years.

New York Times article - Long Zoom: Will Wrights new game Spore. Will Wright is the genius behind 'SimCity' and 'The Sims'.

Why marketing should create documentation - Creating Passionate Users.

Amusing - Iggy Pop's concert rider funniest in rock history?.

The Gustbuster Umbrella. They'd make a killing in Wellington - the rubbish bins in town are filled with destroyed brollies after a rainy southerly blows through town.

[/links/2006] | [permalink] | [2006.10.10-22:55.00]

Run Book

A new job brings new challanges. One of the things that helps a new comer get a handle on what does what is a run book (and an up to date LAN / WAN diagram). A Run Book should contain -

  • Hostname + Aliases
  • Function
  • Hardware details (make, model, serial number/tag)
  • Hardware config (disks, ram)
  • Installed OS + patch level
  • Installed applications (if its an application server)
  • Special startup/shutdown procedures (if any)
  • Location (server room, rack and geography if you have multiple sites)
  • Basic change log - eg when important changes were made to the system - you may want to add a simple service history too
  • System Owner / Business Owner (eg the responsible systems admin and the person in the business who looks after the application on the box)

A runbook lends itself to a simple database (we used to use a simple Lotus Domino database which worked well) - absolute worst case use a book in the server room or a text file at the root of the system drive on each server to track basic config and change information. Another advantage of a database is that you can age the information and chase updates (eg every 6 months mail the Helpdesk to ensure someone checks the system configuration and updates the run-book details).

The key is to try and keep it as simple as possible while ensuring the vital information is available to admins when they need it. No one likes entering data into an overly complicated tracking system - it ends up actively discouraging use rather than encouraging it. In fact if the run-book can draw upon information already in an asset management system that would save on duplication - or if the asset tracking system can flag systems as 'special' so you can extract the equivalent of a run-book from within the asset database that would be even better.

[/tech/ultimate] | [permalink] | [2006.10.10-22:54.00]