Andrew Kohlsmith wrote:
> > Well, how does it grip you if we say "This is a local issue" :-)
> > Then we expected the machines in the cluster to mount /usr/local
> > from "the fileserver", because "we don't have the time to install that on
> > all machines separately". Consequence - users (departments) cannot buy
> > an application and install it on a single machine in the cluster, as it
> > installs on /usr/local, which we preempted for network-wide stuff, and
> > not on the network file server, because there was no space left.
> I'm not sure what side you're arguing for here -- Does the FHS not state that
> /usr/local is for locally-installed applications, which are (can be) separate
> from /usr, which is used to mount common filesystems? Are you arguing that
> the app is wrong, because it is expecting you to follow FHS guidelines, or
> are you wrong for mounting /usr/local to a number of workstations?
Actually, both. We should *never* have made /usr/local a network mountpoint
going to a single cluster-wide server. It really only makes sense if you have
a totally homogeneous (client-) machine set, and leave them that way until
you junk them 10 years or so later (I am still installing IPX machines sometimes).
And the app is also broken if it is compiled with hard-coded paths
looking at /usr/local - if they want to use hardcoded paths, they should be
> > Not fixing the directory where raid systems are accessed means the support
> > routines have to ask the user (end-system administrator) where they are,
> > and thus need to use variables. That is a Good Thing (TM). It introduces
> > diversity, which in turn makes the life of malware writers more difficult.
> > Malware needs to run without support by the user or administrator. Malware
> > writers love constants. You, as an admin, should not.
> I, as an admin, have systems set up how I like them. I, as a manager, am
> trying to find a set of guidelines to follow so that I may stop having to
> remember details about specific machines and may instead harmonize with a set
> of guidelines, such as FHS. This reduces my headaches and allows me to hire
> people and have some expectation that they will be able to navigate around
> any of my machines.
Yes, but we, as a service department set up to "help people to help themselves"
do not have that liberty. We cannot prescribe how users (research groups) should
install their machines (unless we buy and install them for them), and we should
not claim that we are too stupid and inflexible to cope with whatever the
end system admins throw at us - this is in effect what we did, lacking the money
to go the former path.
> I, as a programmer, would not declare "thus spake the standard, and so verily
> I will hardcode paths into mine application." I, as a manager of
> programmers, would strike any such programmers with my Clue Stick. I realize
> that the rest of the world takes these shortcuts, but I have yet to see an
> application hardcode paths because of FHS or any "standard" for paths. It's
> usually out of sheer ignorance that these things happen. I don't think
> people consciously hardcode paths.
There seems to be a lot of programming done in a state of total stupor ...
Yes, autoconf has helped. But I have come across a high cost package
(ca $3000 per seat per annum) that shall be nameless:
o used interbase as a database manager (at a time when it was non-free)
o used setuid binaries to modify the database and set the interlocks
o had said setuid binaries in a .../bin directory hung off a publicly
writeable directory - mounted over NFS
It took me about a day to unpick the installation and replace that lot with
a link farm so that not everybody with a PC and a network card could take over
> And that brings me back to my original question: /usr is declared for
> nonessentials and may be group-mounted. /opt in similar fashion. /mnt is
> _specifically_ declared as a temporary mountpoint. I was just trying to get
> an idea of where people would mount things like raid arrays, semi-permanent
> removable media and data stores.
This is a local issue. At the application level (where FHS has its use),
there are filesystems containing useable space. The management of that
space is a system administration issue, and no knowledge of that is needed
for application installability across systems and sites.
How big, how reliable, fast, or admin-intensive it is is of no concern to the
application provider or system integrator. If you map /usr to the console for
the user to memorise the information and type back in when needed, the system
may become a little slow, but it will work correctly as long as the user types
the stuff back in correctly or the reader task makes sure it comes back properly.
That is of no concern to the FHS ...
* Why not use metric units and get it right first time, every time ?
* email: cmaae47 @ imperial.ac.uk
* voice: +4420-7594-6912 (day)
* fax: +4420-7594-6958
* snail: Thomas Sippel - Dau
* Linux Services Manager
* Unix Support Group
* Information and Communication Technologies
* Imperial College of Science, Technology and Medicine
* Exhibition Road
* London SW7 2BX
* Great Britain