Wednesday, June 29, 2011

The palest ink is better than the best memory

To document or not to document, that's the question.

When in doubt, write it out

Documentation saves hours of research and frustration and that translates into money. Yet so many IT managers tolerate systems without documentation while others go crazy after formalizations that end up in unmaintained material.

I still have to see documentation that is kept current. I am doing my best with my current team trying to enforce that practice. My opinion is documenting what you do is just about showing respect to your partners.

I am usually asked for the best anti-spyware or anti-virus for Windows and I always say: Rebuild your system every six months. Just have it documented: Basically keep a backup of your applications and related metadata and clear instructions as to how to recreate your system from scratch. Some years ago when I was using Windows as my main OS I found myself rebuilding my Windows box so often that I developed a procedure (part of it scripted I have to admit) that allowed me in just 2 hours to recreate my whole environment. That included: Apache, PHP, Java, Tomcat, JBoss, Eclipse, MS Office just to name few of them.

Nowadays I use VirtualBox and recovering Windows is just a matter of going to a safe Snapshot so the only reason for me to rebuild from scratch would be a company change (because of licensing)

The same happens in the world of OS virtualization. If you find that your P2V is difficult, go for a rebuild. With good documentation this could take anytime from 2 to 8 hours. Way less of what you will spend troubleshooting incompatibilities with your tools, different source and destination hardware etc. And if you do not have documentation you better start it.

This is exactly what happened to me when I tried to convert my Ubuntu 10 Server box into a VMware Server VM.

VMware converter will not work for Ubuntu 10. It is simply not supported http://www.vmware.com/support/converter/doc/releasenotes_conv40.html#platf

I tried anyway to install it (you know we always try just in case :-) but as you see below it is totally incompatible:

[several lines like below]
...
The script you are attempting to invoke has been converted to an Upstart
job, but lsb-header is not supported for Upstart jobs.
insserv: warning: script 'atd' missing LSB tags and overrides
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `atd'
insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for script `atd'
The script you are attempting to invoke has been converted to an Upstart
job, but lsb-header is not supported for Upstart jobs.
insserv: warning: script 'udevmonitor' missing LSB tags and overrides
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `udevmonitor'
insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for script `udevmonitor'
...
[more lines like above]

While I could have spent more time trying some other converters I decided to spend 8 hours building the box from scratch. But of course I had good old school documentation for building that box. WIKI is your fiend, don't forget that team member!

As the Chinese proverb says "The palest ink is better than the best memory"

3 comments:

Unknown said...

What about toolchains installed over a period of time which has version dependencies and scattered across multiple subdirs? Some might have got to installed under /var/opt, /usr/, /etc, /share etc!

Unknown said...

I mean how to back it up and re-establish after a new re-install ?

Nestor Urquiza said...

Again if you keep your documentation current you should not have problems. I am of course assuming you are backing up which is a different story.

Installation and backup recipes should help with this.

Followers