>
>
> > > 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
I don't know enough to know what the concerns are; I presume anything's
that is exported ro to all hosts is okay>
> if you don't want to use the local hard disk.) However - you should
> definitely know what you are doing ...
I set up a floppy that booted than the got everything else via NFS.
While I've been discussing about doing it without using the local hdd, I
don't preclude it. Clearly, if you want swap, that's the place for it.
Good place for /var, esp if you don't want to export rw directories (or to
kiss).
It's also an ideal location for the kernel and lilo if you don't want to
bootrom. Floppy's okay for proof of concept and for occasional boots. CD's
a possibility too.
>
> 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 don't have a good idea of where you ware going, or the reasons driving
decisions (and, frankly, I'm not sure I want to without being on the
payroll). Nor do I know who your users are; third-year computer science
students may have a different view of things from that espoused by
lecturers in the Mathematics faculty.
If you want all machines to look alike, then shared filesystems ensures
that.
If you want some machines to have software others don't, put it in
/usr/local (or somewhere else of your own invention). Such software can be
stored on the local HDD (or on CD in the possession of the individual user
if you want it hacker-proof).
Don't upgrade software just because there's a newer version. Upgrade if
the old version's broken, or because you want some new feature. Every
upgrade brings the risk of something breaking; I read about such problems
almost daily on zoot-list or the current equivalent.
> 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.)
If you have an exported /usr (presumably share with lots of others) it's
absolutely certain that there will be times when /usr will be out of step
with stuff in /bin and /lib. Some packages split over /usr and other
locations/
Murphy says the day will arrive that this matters; a user will rely on
documentation in /usr that does not accurately reflect something in /bin,
or rpm will not correctly reflect the files under /usr because the
sysadmin has updated a package but the updates have not been applied to
the user's machine.
Murphy also says that the configuration files in /etc will not be those
required by something in /usr/sbin, or that a product upgrade will replace
a configuration file and the local user won't know enough to recognise
there's a problem.
Even if you tell everyone that now's the time to 'do x,' don't expect they
will always do what they're told (or even read the mail!). An example from
today's mail (with apologies to the miscreant).
Tony N mentions a problem with the df command from fileutils. He
illustrates nonsense output it produces from commands such as "df
/dev/hda1" and states this is from an all-scsi system.
Someone Else surmises that it's working out which filesystem it is from
the device name, showing how 'df foo' and 'df /dev/hda1' produce the same
output (he has IDE disks).
--
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
