Mailinglist Archive: opensuse-security (231 mails)
| < Previous | Next > |
Re: [suse-security] Apache Source Tree under 6.1
- From: "Michael T. Reiff" <mr@xxxxxxxxxxxxxxxx>
- Date: Wed, 25 Aug 1999 19:40:32 +0200
- Message-id: <37C42A90.AFB47D68@xxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxx)
PGP Fingerprint: C8BE A34B 5CD3 660E 01C4 BA1F E42E 1E67
PGP Key ID: 0x7714DA0B 2048 Bit RSA / IDEA
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@xxxxxxxxxxxxxxxx)
PGP Fingerprint: C8BE A34B 5CD3 660E 01C4 BA1F E42E 1E67
PGP Key ID: 0x7714DA0B 2048 Bit RSA / IDEA
| < Previous | Next > |