> > 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ückelberg describes in the
Remote-Boot mini-HOWTO. I've implemented this, so I know what I'm
speaking about).
Ok, how do you implement this for dummies? Eg. make installtion simple
(ie. the rhat way)?.
How do you implement local rpm installations (in my "futuristic" implemention
they would be possible at least for relocateable packages while still obeying
package dependencies)? Lots of questions ....
However - the client will not be centrally administrated. No central
syslog etc. ? How do I decide if a file has been changed locally, do
I replace it with the cental file, should I copy the central file to
[file].rpmnew instead? Lots of decisions that could be done by rpm
much more easily (provided the central strategy is ok).
I did implement what you describe - and it's _really_ strange if you try to
implement this for many hosts as described above. I did implement
various versions of what you described above for the last 4 years and none
of it is suiteable if you have clients that are maintained locally but
should share some commen central characteristics.
Finally - other Unix distributions do handle this very well (although I do
think SGI Irix generally does a very bad job - this part is handled
extremely well).
There's a reason for this implementation. I've done similar things for quite
a while. So the question should not be whether this is reasonable (I've
spent a lot of time planning and defending this installation with other
professionals - I'v been planning the new system for about 2 month -
a full time jobs at least for the last month; the /usr on NFS variant did not
show up until mid April, but it seems to be ideal. It addresses nearly
everything that was not ideal in my original plannings) but whether it is
possible ...
(Maybe someone might prove me wrong, will tell me something that will work
as well or even better - I will happily provide all the necessary
information.)
I do not see any possbility with RHAT for this, and this makes me feel rather
sad ... I do not even know whom to contact (eg. the guy who did the rpm
implementation on the RHAT start disk) ...
Michael
_______________________________________
Michael Redinger
Computer Centre University of Innsbruck
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
