Re: [SAGE] Pros/Cons of complete rejumstart v.s. just patching OS images

["Mark R. Lindsey" <markrlindsey@yahoo.com>]

> Just wondering what people feelings are pertaining to patching the OS
> image or patching jump-start and than rejumpstarting the box.

In theory (i.e., ideally) you should be able to get the same results 
by patching an existing system as you would by re-installing.

None of the systems that I've maintained support re-installation as
a mechanism for maintaining the system; these are Red Hat Linux,
Solaris, and FreeBSD. The major OS releases are always ammended with
bug fixes which include updates critical to security.

The Debian Linux philosophy holds that one should almost-never re-install
a system; i.e., it's maintained by updating the component packages.

However, at any point, a system can be compromised and therefore cannot
be trusted. This is an example of the sort of case where no amount of
patching can be known to fix the system; afaik, the only deterministic 
way to restore the system is to re-install from a trusted source medium
(e.g., cdrom).

> 2. Dose anyone have a way of minimizing the reconfigure (after
> rejumpstart) time of a server, i.e. Dbase machines, print servers, mail
> hubs? 

I've done a bit of research on this at Commerce Engine; incidentally, I think
it has some commonalities with service relocation as studied for mobile 
devices.

I think that the `system' is composed of three disjoint software elements:
	-> the operating system -- which is copied from source medium
		and from vendor-supplied patches
	-> the system configuration (lots of stuff under /etc, plus
		filesystem symlinks, etc.)
	-> `operating data' (such as mail spools, database files, etc).

I'd like to see us (system administrators) develop some consistent, uniform
ways to encapsulate each of these.

Most Unices seem to have some sort of automated OS installation (e.g.,
jumpstart; kickstart). So any number of `virgin' systems with 
suitably-compatable hardware configurations can be installed with 
functionally-identical OS installations. This will let us cleanly 
recover the system to its original-medium installed state.

Then we have to find some way to apply patches consistently. Not every
unix makes this so easy, but it's necessary in order to restore a system
to its properly-updated, installed state.

Fortunately, if you can decouple the OS from the configuration,
the OS needn't be `backed up' in the conventional sense -- you can 
always re-install it.

Next, the system configuration needs to be applied. cfengine provides
a good framework for this task; with it, you can conveniently write 
scripts that encode your configuration. Then on a newly-installed/restored 
OS installation, you can run cfengine with the scripts you've written
to bring to restore the configuration.

The configuration must be backed-up, or, to be precise, the programs
which generate the configuration. Fortunately, though, configuration
programs tend to be tiny.

Last, you need to restore the `operating data'. For a mail server, this
will be a bunch of mail files. For a web server, this might be a 
combination of cgi programs and files. Obviously, this data will need
to be backed-up.

If you're able to decouple each service's configuration and operating
data, then you should be able to move services between servers. E.g.,
maybe your mail server includes a few configuration scripts and a 
bunch of mail spool files. If you can programmatically identify the
components, then you can modify the configuration/re-installation
script to move mail service from machine `foo' to machine `bar' 
in a straightforward way.

Maybe, someday, we'll be able to make this entirely automated. But
there's a lot of work to be done.

There are some complexities that perturb the Configuration Theory
that I'm describing; e.g., the Oracle database server software doesn't
easily fit into any of the data catagories -- OS, configuration, or
operating data. In theory, it needs to be installed and patched just
like the OS.

And sometimes the OS and the configuration cannot be made disjoint;
some configuration tasks force you to modify OS-supplied scripts.
For example, to setup a wireless network card in Red Hat 7.1,
one must edit /etc/pcmcia/wireless.opts -- an OS-supplied script.
Fortunately for practice, though, most of RH's configuration is 
encapsulated in definition files under /etc/sysconfig which are
(by my definitions) not strictly part of the OS.



__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/