>
> Yes, but that's really a pain ... I even found it more convenient keeping
> /etc and /var in memory (ramdisk) ...
Warning to others: don't put /var in RAM unles syou know what you're
doing; even then there's probably a better way. Many programs store stuff
in /var that you don't want to lose next time you boot.
Nothing should be writing to /etc; anything that does can probably be
fixed with a symlink to a convenient place in /var.
> > Remember that /etc has to be kept in step with /usr - for example, if you
> > upgrade sendmail to 8.10, then everyone has to reconfigure it at the same
> > time. Even if sendmail 8.10 works with 8.9 config files (they do look
> > pretty similar) you can be sure some things will not.
> >
> > If you control it on one machine, then you can cut individuals over to the
> > updated /usr as you get their /etc fixed up. Assuming you have a
> > mistake-proof way of doing it;-)
>
>
> Well, that's why rpm is so nice ... install them on the central system
> (only /usr). Then make the clients update it too (autorpm ; excluding /usr).
> If you really install everything (the machines have the same set of rpms,
> so no dependeny problems should occur) autorpm is rather save ...
I don't see just why your approach is better than exporting the whole
shebang, with special provision for /var and /etc.
You CAN maintain an old (preupdate) tree to export and a new tree. Next
reboot gets the new tree - you've changed /etc/fstab to point to the new
one.
However, it's done, /etc needs host-by-host care. Possibly this can be doe
with a script; I don't expect there are many complex differences, it's
mostly a matter of hostname and such. You'd need to do something like
format your disk, install and setup
I've just eyeballed /etc on my RHL 6.1 system:
rpm -Va | grep \ /etc
There are 55 files that show as not being as distributed; of those most
arise from changes from installing other software (/etc/services) or from
changes likely to be site-wide (/etc/printcap). Only a few are likely to
differ between hosts. I imagine this could readily be fixed by a script
run before init (see initrd) which takes the global /etc and copies it to
local disk or ramdisk and fixes it.
syslogd should be logging to a different host; there are times when you
need a record of what someone did; mail sent, possible unauthorised use
etc.
It seems to me this is no more difficult to set up (and probably more
certain) than seting up & using autorpm.
--
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
