[svlug] RHL 5.2

[Walter Reed]

At 07:29 PM 11/14/98 , Javilk wrote:
>The Infamous Rick Moen wrote:
>> Nothing in the Filesystem Hierarchy Standard even remotely suggests 
>> putting the system HTML tree under /home (or even mentions that tree,
>> for that matter.)  The notion that it's the httpd "user's" home directory 
>> is pretty ridiculous.  (Does that "user" get a public_html subtree and
>> mail spool, too?)
>
>     As a professional webmaster, I would say that /home is a good place
>for it, as it is something you want to preserve between installations, and
>maintain frequent backups of; while /usr, if not complete with /usr/local
>on a separate drive, is wiped clean during installs. (Though not
>upgrades.)  Given that, one might argue that /home/httpd/conf is a good
>place for the configuration files, though.  Yet these are more subject to
>attack than /etc, since /etc might more likely be on a write protected
>drive.   Since my /home directory is a different drive from the /etc
>directory, I back up the /etc/httpd/conf directory to the /home/httd/conf
>directory.

As someone who also hosts quite a few sites, I would Never use /home for 
web docs. I always setup a dedicated partition for Apache outside the
standard directory tree. 

/home is for real login users only on my system, and Apache is NOT a 
login user, it's a "system" user. You wouldn't have /home directories 
for the "mail", "lp", "news" users would you? Since Apache's log files 
can grow Very large, Very fast, I tend to keep them away from the 
standard places too.

Also, since RedHat puts crap in /home the argument of leaving /home alone
during install / upgrades fails.

Until most / all the major packages support FHS, the problem of OS vendors
doing strange things won't go away. The FHS people probably need to 
petition the major package managers to include support maybe by adding
a (default?) configuration option (--install-layout=FHS). Getting support for 
all the standard GNU stuff, sendmail, qmail, bind, apache, etc. is what FHS
needs to be useful.

Until that happens, people (like me) who like to keep current are going to 
have a hell of a time with package management. That's the real issue here.

So on one side, Red Hat is doing (mostly) the "right thing" by supporting
FHS, and on the other, I can't update and easily maintain that structure
because the package doesn't nativly support FHS.




--
Walter Reed
Engineering Director
InterTrade Systems Corp.


--
echo "unsubscribe svlug" | mail majordomo at svlug.org
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to unsubscribe
see http://www.svlug.org/mdstuff/lists.shtml for posting guidelines.