Where do you put all your HTML stuff on a home Linux server?

[John Summerfield]

Matthew Saltzman wrote:
> On Fri, 2007-12-28 at 17:36 +0000, Chris G wrote:
>> On Fri, Dec 28, 2007 at 12:08:28PM -0500, Robert P. J. Day wrote:
>>> On Fri, 28 Dec 2007, Chris G wrote:
>>>
>>>> On Fri, Dec 28, 2007 at 11:12:14AM -0500, Robert P. J. Day wrote:
>>>>> /srv
>>>>>
>>>> .... and how does that help?  It just adds yet *another* possibility!
>>>>
>>>> It makes it easy to keep separate and to back it up I suppose but
>>>> doesn't address the ease of editing or permissions issues.
>>>>
>>>> Is it what /srv is intended for?
>>> yup.
>>>
>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>>>
>> Yes, I just found my way there too and /srv does seem to be the 'most
>> correct' place for web pages and other related things.  It does seem
>> that it's far from a well defined standard yet though which would
>> account for the many different directories used by different
>> distributions.
>>
> 
> For example, there was a long thread recently in fedora-devel-list on
> whether distributions could impose any structure at all on the contents
> of /srv.  I don't recall if any firm conclusions were reached, but for
> now, I don't think you'll see RPMs (from Fedora, anyway) making any use
> of it.
> 
> My take would be that if I'm doing a fresh install on an existing
> machine, I should be able to blow away the contents of /var without
> worrying that I'm destroying user data.  So things
> like /var/www, /var/cvs, /var/spool/mail, /var/spool/mqueue, /var/lib/<databases>, etc., should really be in /srv.  But there are definitely different views on this.

That's pretty much how SUSE has done it for years (I don't know the 
details, and I don't have a SUSE system readily to hand), and that would 
be why it's in the standard. Best, if you use it, to follow SUSE practice.

What I've settled on on RedHattish systems is 
/var/www/<accountname>/<vhostname>

/var/www/localsites/<accountname>/<vhostname> is slightly more robust, 
it's not going to conflict with anything the vendor does.

If you want to protect things in case of upgrade, make one or more 
levels a separate filesystem that's ignored (Or better, absent) during 
upgrade.



-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)