This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: --excludepath installation From: Michael Redinger <Michael.Redinger@uibk.ac.at> Date: Mon, 8 May 2000 22:00:33 +0200 (MET DST) > > 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. Yeah, completely right ... you have to be extremely careful about that. I did this with some scripts for those clients that needed it (however, most of them were "real" client - no server stuff. Eg. syslog is done to a syslog server etc. ... Building clients with absolutely no harddisk or any other place where to store permantent data is possible if the "client" is not a "server" (I did this - and as I did not recieve any message that said something different I suppose I'm right ... ;) ). Concerning "even then there's probably a better way ... " : suppose you cannot use a bootrom (there are various technical reasons for this), do not want any client to store things on your hard disk using NFS (which is a security concern - NFS is very insecure) - eg. if you have untrusted users on your network. Well, then there aren't many other possibilities if you don't want to use the local hard disk.) However - you should definitely know what you are doing ... > > > 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. (this is something similar to what St