[colug-432] Documenting System Installation, Configuration, and Changes

[Rick Troth]

> How do you document the installation, configuration,
> and changes to a computer? What are the best practices for such?

So many standards.  So little time!

Larger organizations are turning to CMDB of one form or another.  Free
form text is also vital:  Need to make verbal notes whatever you do,
so be sure your CMDB has a "notes" field.  Lately, I start with a
"setup.txt" which may be in the root or may be in /etc.

More recently, I have started a collection of "make it so" scripts in
a /setup directory.  After running the same sequence of 'yum' (or
'zypper' or 'apt-get') a number of times ... you get the idea.  So I
have a script for Fedora, another for SuSE, one for Ubuntu or Debian.
But getting these into the new system is a manual step.  What Neal
said about network installation ... ahhh...

CLI beats GUI for repetitive tasks.  (And networked automation beats both.)

> This would be for a development computer where experimental
> futzing about is often needed.

When futzing, I hate getting the RPM database dirty.  So this takes me
back to the "execute in place" way of building some packages.  I mean
... suppose you need a specific release of GCC.  Rather than blast
your supported GCC, build the one you want and set it to install out
of the way.  Then point to it when you need it.

There is a whole process around this.  I did not invent it, used to
hate it, and now live by it.

> I mostly use plain text files with prose in chronological order,
> with occasional screen shots.

Of course!
You cannot capture the rationale without prose.

> I have been STFWing, but just finding stuff for how to install
> various vendors' add-ons.

Vendor stuff is tough to handle.  Time was, you simply got a tar ball.
 That had the advantage of (usually) being able to reside anywhere.
(Back to the "out of the way" point from before.)  More recently,
vendors have gotten wise to the installation tools on the various
platforms.  (We're talking more than just Linux.  ANY Unix.)  But when
vendors play nice with RPM, they might not (yet) know how to also
allow redirection.

Source is good, where available, because you can usually find a single
throat to choke w/r/t where the package lives.

I hope this helps.

-- R;   <><
'::1, sweet ::1'