Re: [suse-security] Apache Source Tree under 6.1
HI Ralf Steenbock wrote:
Well, if you look at the "Filesystem Hierarchy Standard -- Version 2.0": 4.6
Does it have to be right, or the best solution, or reflect requirements in a real environment just because the FHS tells us so ???
/usr/local : Local hierarchy The /usr/local hierarchy is for use by the system administrator when installing software locally.
Exactly. So please tell me which *user* needs to run Apache locally ??? In other words : /usr local is for packages that no one else would need. So why then share it over the network ??? Personally, I found that /usr/local is often mounted to a small local disk (often < 4 GB), while /usr and /opt reside on large NFS volumes with oodles of GB's. Partly due to the fact that quite some people found it to make sense to put DB2 and/or its data there (along with other large stuff).
It needs to be safe from being overwritten when the system software is updated.
The "system software" is typically updated on the boot server (at least I hope so).
It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
In fact that's what the FHS says ... and I think the people who drafted that fine document should think this part over once more. Of course you could argue that /usr/local could be an exported server volume just as well, however /usr/local can (partly) be written by (some) users, and I just don't like the idea that Joe User would be able to spread his stuff across my network and pour it into my server. He's free to mess up his, and only his /usr/local dir mounted to his local disk. Btw, the KDE developers seem to share my view too. Would you really like to maintain a package like KDE in /usr/local on a couple dozen or hundreds of machines, with its hundreds of components in steady change ??? The way it is now, it's easy to test drive new releases while the production system can remain unchanged. Simply clone the disk behind /opt/kde and use the duplicate for toying around, and mount the original disk again next morning.
/var? You're kidding... "Linux System Administrators' Guide 0.6": The /var contains data that is changed when the system is running normally. It is specific for each system, i.e., not shared over the network with other computers.
Like I said, /var is not the best place, and if an exported mount exists for /opt, such stuff should go there. However, /opt is not necessarily existant on every unix machine (because it deosn't need to since it's available via NFS ... ) Btw I somehow got the impression that you assume I'd put the entire /var sub-tree on the same physical disk ... I may not be the ultimate unix guru, but I'm not *that* stupid neither ;-) -- C U ... Mike :-) (mr@java-factory.com) PGP Fingerprint: C8BE A34B 5CD3 660E 01C4 BA1F E42E 1E67 PGP Key ID: 0x7714DA0B 2048 Bit RSA / IDEA
On 25-Aug-99 Michael T. Reiff wrote:
... Ralf Steenbock wrote:
... /usr/local : Local hierarchy The /usr/local hierarchy is for use by the system administrator when installing software locally.
Exactly. So please tell me which *user* needs to run Apache locally ??? In other words : /usr local is for packages that no one else would need. So why then share it over the network ??? ...
"/usr" has NO connection to "user" and the local system administrator is not the "user". "/usr" is the place where things are installed, which are not needed at boot time. Users install into their home-directory.
... Btw, the KDE developers seem to share my view too. Would you really like to maintain a package like KDE in /usr/local on a couple dozen or hundreds of machines, with its hundreds of components in steady change ??? ...
The KDE developers do not install software - they develop it. If -- lets say -- SuSE or the "master of a hundred machines" vote for KDE, they have to install it into /usr. They may NOT use /usr/local, as this is the playground of the local system administrator. If the local system administrator decides to install something, he or she may not use /usr but should use /usr/local or even /local (if it is needed to boot). Wilhelm
Wilhelm Spickermann wrote:
"/usr" has NO connection to "user" and the local system administrator is not the "user".
In an ideal world, you'd be right. Unfortunately, in a production environment things are often a bit more obfuscated, and the "local system administrator" may turn out to be the ordinary user. Joe User may not use the local root account for his daily work, yet know the password. I absolutely agree that /usr is not related to "user" ; however, /usr/local is (in the way I mentioned in my recent posting).
"/usr" is the place where things are installed, which are not needed at boot time. Users install into their home-directory.
Typically, user homes are that part of the file system where quota are most strictly enforced. The ideal place to install huge binary packages into, right ??? User homes are the place where user specific config files and user *DATA* should go into, not binaries.
If -- lets say -- SuSE or the "master of a hundred machines" vote for KDE, they have to install it into /usr.
I'm happy it's not like that. /opt is the perfect place for the KDE binaries.
They may NOT use /usr/local, as this is the playground of the local system administrator.
See above.
but should use ... /local (if it is needed to boot).
I guess our points of view are totally divergent ... keeping files needed for booting on the local machine is something that may work for a couple of machines where each one keeps the OS on a local disk, but once your networks has grown to a larger size you may wish to get rid of all that local OS stuff too.
From the network admin point of view, maintaining /boot and /local in a centralised location and exporting via NFS simplifies things significantly. From a security point of view, remote boot is a good idea anyway.
-- C U ... Mike :-) (mr@java-factory.com) PGP Fingerprint: C8BE A34B 5CD3 660E 01C4 BA1F E42E 1E67 PGP Key ID: 0x7714DA0B 2048 Bit RSA / IDEA
participants (2)
-
Michael T. Reiff -
Wilhelm.Spickermann＠t-online.de