Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

According to a guide on the Linux directory structure, /usr/ is for application files, and /var/ is for files that change (I assume this means "files that belong to the applications"). Is this correct?

If this is the case then I'm a little torn between using either. A website is an application (if it's dynamic, so to speak), but in other cases it is just a collection of files used by Apache.

The default www dir lives in /var/www/, so should we follow suit by using /var/websites/ (or something similar), or choose /usr/websites/ since they could be applications?

This is a very trivial question, but it's bugging me nonetheless. For our case, I'm leaning toward /usr/web or something like that, since our websites are all applications.

Update:

This is for our company websites; it's not a shared hosting server, so we don't need to worry about separating them in /home/ or anything like that.

share|improve this question
3  
I don't think the question is that trivial; it's a rather good one, actually. Interesting. –  Aron Rotteveel Jan 14 '10 at 12:38

6 Answers 6

up vote 30 down vote accepted

According to the FHS, /usr is for shareable, read-only data - not where you want to put the website. This is where you should put your code (for example Fedora does this for Wordpress). See also the web assets packaging guide for Fedora.

/var is "variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files." -- better, but still not quite right -- but a lot of systems will use /var/www, so even if you're wrong to put it there you're in good company.

/srv is for "site-specific data which is served by this system." -- which seems like a good match, but is much less common than /var/www.

The other common place to put the site files is under /home -- but creating a special user called website or such, then placing the files inside that user's homedir.

share|improve this answer
    
@womble: Thanks for the cleanup –  James Polley Jan 15 '10 at 12:36
2  
Ah, my work uses /srv -- as I'd never seen this before, I thought it was created by them. Is it a Redhat/CentOS thing? –  nbolton Jan 17 '10 at 18:45
3  
The default is only set to /var/www because distributions are not allowed to touch /srv; that is for the system administrator to configure. So, that's why it's "much less common" and also correct. –  Michael Hampton Apr 21 at 15:27

Websites should live in users' home directories. They're user data, should be isolated by one-user-per-site, and dynamic content should run as a separate user again, with files that the dynamic content needs to read and modify given the appropriate permissions to do so.

Update:

Just because it's not a shared hosting server doesn't mean that you shouldn't engage in good security practices and separate independent roles into their own security zones.

share|improve this answer
    
Thanks for the answer, please see my update. –  nbolton Jan 14 '10 at 8:10

According to me you should NEVER and NEVER put any Internet Services on the common system zone.

Your Internet Services (Apache / Tomcat / SSH etc) are a front door, then if you put those services into your System zone you'll be potentially vulnerable to some attacks.

More than if you have put your differents services into a safe sandbox zone like another detach partition.

Here is an exemple of structure you could use:

/ --> Root System --> On SDA1 --> Root and System security operator access only
 |
 | -->/usr /etc /var etc.

/SRV --> Web Root --> On SDB1 --> Web users access with minimal rights access.
 |
 |-->/srv/bin & /srv/dta
      |
      |-->/srv/bin/apache (or any other APPLICATION Binaries)
      |-->/srv/dta/SQL (or any other APPLICATION Datas like a 
                        database or web PHP files etc.)
share|improve this answer
    
Could you expand on "common system zone"? It's not a term I've heard before and I'm not sure what you mean. /srv/bin seems to violate the FHS, which states that /srv is for data, not binaries –  James Polley Jan 14 '10 at 9:20
    
Well Common system zone means, the part of the OS where is store all System component like, account, password, Administrator binaries and Library. I know that My installation doesn't respect completely the FHS but I can completly split the OS in two part. 1°/- The system which is quite fix (except for update and administration tools installation) 2°/- The applications, datas and USers Homeland. With this way, if you got some troubles with your system or datas you will not lost all the datas. –  Dr I Jan 14 '10 at 10:52
    
I see. This makes sense - it's why most desktops for instance put /home on a seperate partition - you can blow away everything on the non-/home partition and not worry about losing user data. +1 for segregating data. –  James Polley Jan 15 '10 at 12:39

Where they live on disk has little matter. It's where you want them.

I have a symlink from /www on all my machines to where they really live, so I never have to wonder from machine to machine. Some older machines have /u0 and /u1 for user disks, and I place the web things there. Some have /home mounted directly, so they go there, but /www always points to the right place.

I also do not put any configuration in /usr nor in /var. It goes in /local (which, you guessed it, is a symlink somewhere on /u0 or /u1 typically). This makes backing up things easy. I just back up the user disks.

Of course, I have a master distribution site for my OS of choice, NetBSD. I make the system like I want it on this main machine (really a xen instance) and rsync /usr around. Makes my life easy.

share|improve this answer
3  
This is fine if you're a one-person operation, or a perhaps even a small team who work closely together and are familiar with each other's foibles - learning the 'right' way to do it is probably going to take longer than just doing it. If you have a large operation and are frequently bringing new people on-board, having to get them up to speed with a layout like this is going to take a lot of time - sticking with (or at least, close to) the FHS is going to save time with every new person you bring into the team. –  James Polley Jan 14 '10 at 9:24
3  
When you use 8 different OSs, in-house standards are far easier to learn than each-os-does-it-its-own-way. –  Michael Graff Jan 14 '10 at 9:32
1  
@James Polley How much time does it take to tell a new hire "we put stuff in /path/we/chose"? –  ceejayoz Jan 14 '10 at 14:57

Take a look at the Filesystem Hierarchy Standard (Wikipedia). I myself use /srv/www/$domain/{htdocs,logs,cgi-bin,...}.

share|improve this answer
    
I do it like this too, but instead of "www" I always use the service name "httpd". So I have /srv/httpd/$domain... or /srv/smbd/sharename... Like this it is easier to see which service is serving the files. E.g on some systems we have /srv/nginx/$domain –  Raffael Luthiger Apr 21 at 15:59

The definitive guide is the Filesystem Hierarchy Standard which says that /srv is the proper place.

share|improve this answer
2  
I don't read it that way - or at least, I read it as being ambiguous on this point. Most websites are not served simply by this system, they're served by a whole cluster of systems; and the two sentences starting at This setup will differ from host to host. suggest that this isn't the place for files shared across many servers. It is a fairly likely place though - certainly more appropriate than /usr, and arguably better than /var –  James Polley Jan 14 '10 at 9:19
1  
I don't think the FHS is at all definitive. Re: (From Wikipedia): Most Linux distributions follow the FHS and declare it their own policy to maintain FHS compliance. However, the vast majority (as of 2009) of distributions, including those developed by members of the Free Standards Group, do not follow the proposed standard completely. –  Michael Graff Jan 14 '10 at 9:37
5  
That's the nice thing about standards - there's so many to choose from! :) –  James Polley Jan 15 '10 at 12:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.