TCLUG Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TCLUG:15481] Faeriedist, and directory layouts in general



ehillman@cccu.com, on 04/04/2000 10:06:13 AM
To: tclug-list@mn-linux.org @ PMDF
cc:  
Subject: RE: [TCLUG:15481] Faeriedist, and directory layouts in general

>> It bothers me that I have to look in /usr/man, /usr/local/man,
>> /usr/doc,/usr/local/doc/,/usr/share/man,/usr/local/share/man,
>> etc. just to find documentation!  How horrible is that?

>  Isn't that what "locate" or "man -k" are for?  Personally, I have rarely had
>any need to know specifically where my manpages are coming from -- and at least
>as far as "/usr" vs "/usr/local", there's a perfectly rational and obvious
>reason to use that on any system that uses install packages.  (I'll agree that
>it probably could have been kept to two 'man' directories rather than 4, but I
>may be overlooking an equally rational and obvious reason to use a 
finer-grained
>system)

If I want to have my documentation on a different partition, or even a
different machine (to save HD space, maybe have all man pages on an NFS
share), it's really nice to have them all in one place.  Besides, I've
often been in a situation where I didn't have locate and it would have
been nice to know *exactly* where to go.  Admittedly, I could use find
and find it, but even still.

>> Looking at a SuSE system, here, let's say I want to look at my
>> apache installation.  Here's what I see:
>>
>> /etc/httdp/ --> Configuration files (I like this)
>> /usr/doc/packages/apache --> Some docs
>> /usr/local/httpd --> cgi-bin, htdocs, icons, and include
>> /usr/man --> More docs
>> /usr/sbin --> Some apache executables
>> /usr/bin --> Other apache executables
>> /var/cache/httpd --> Beginning of var madness
>> /var/lock/subsys/httpd --> It keeps going
>> /var/log/httpd* --> Logs
>> /var/run --> PID #
>>
>> Now, for my customized system at home:
>> /web --> All apache

>  Well, jeez, in that case why not just dump everything in the root folder --
>then it'll be even *easier* to find!  (Or you could follow the lead of a 
certain
>popular OS and dump almost everything in c:\windows\system)

There we go.  We'll have a /windows/system32 directory on our distribution
where we'll dump everything, yeehaw!

>  Again, there's a very good reason for much of this stuff.  /etc/httpd is a
>pretty good idea, and having a folder specifically for the documents apache is
>going to serve (I prefer /home/httpd) strikes me as pretty rational -- it
>parallels nicely with my /home/samba and /home/ftp directories.  I always put
>daemons in /usr/sbin, because I want good access control, and I don't want them
>in my default path when I'm not superuser...  The "var madness" above has a
>similar rationale -- the same users/processes that can read/modify the lock 
file
>may be very distinctly *not* the ones we want reading and modifying the logs.

I'm talking about using the /opt interface for daemons that are usually
addon packages.  So you might have a /opt/ldap and an /opt/httpd, but you'd
be unlikely to have an /opt/inetd.  :)

> I think we just think differently -- I think of apache as one daemon among
>many, and I like to have it set up in a way that neatly and easily parallels
>other, similar daemons.  Your method of completely segregating it from the rest
>of the system may be fine if apache is the only thing you're running, but I'm
>not sure this approach scales well.

See above.

>> Or perhaps how it would be on Faeriedist:
>> /etc/httpd --> Apache configuration
>> /var/httpd --> Apache var stuff
>> /opt/httpd (maybe) --> Apache executables, and htdocs
>> /usr/doc --> Apache docs
>> /usr/man --> Apache man

>OK, this sounds pretty reasonable, except that there's really no way I'd ever
>put the executables in the same directory as the documents they serve up...  I
>realize that this is probably more paranoia than prudent sysadminning, but I
>sleep better when my httpd executable resides on a different *partition*, let
>alone directory, from my htdocs.

I think you misunderstood what I said.  You'd have an /opt/httpd/htdocs, and an
/opt/httpd/bin.  So you could have /opt/httpd/htdocs on a different partition, 
if
you like.

>Also, I like having all my system logs under /var/log, so I have one point of
>access to deal with security-wise.  Plus, if I'm having some unspecified 
network
>problem, or trying to figure out what some would-be intruder thought he was up
>to, I can just sit in /var/log and grep everything under it recursively for the
>offending IP.

A valid point, I'll have to take that in account.  Perhaps have a symlink
from /var/log/httpd.access_log to /var/httpd/httpd.access_log?  This would 
allow
you to do your greppy thing, while making it easier seperate logs by
directory-per-daemon.

>> I do think that having everything in /opt/httpd would be good, too.  At
>> work, we can pick up and move whole installations of software at any
>> time by moving *one* directory.  (and creating a symlink)

> There's something to be said for this, I suppose, but I can't hink of any
>situation where I've wanted to move httpd, its logs, lockfiles and cache *and*
>the htdocs all at once.  Usually it's either just the executables or just the
>htdocs.

> Also, I suppose it's worth hammering into the ground that being able to wipe
>out your whole apache setup in one command may be a little too much convenience
>for one's own good.
Well, when you're managing several Linux boxes, you'd appreciate how easy it 
could be to move an entire
installation of apache from one machine to another.  Especially if you've got 
it set up just the way you like it.

It could be as easy as:
cd /opt
rm -R httpd
scp -r linuxbox1:/opt/httpd .
httpd/bin/apachectl restart

Now, you're set up.  You've got you PHP config, your mod_perl config, your 
JServ config, etc, etc, all set
up ard ready to go.  That is, of course, if it's all in one directory.  That 
seems to be the way that Solaris
does it, and it seems to be working quite well for us here at SuperValu (we've 
got about 40 Solaris boxes).
Just copy it over.  That easy.  Whew.

Nick Reinking