I have been working with a team who used to install all the application and HTTP services like Apache or Tomcat to the '/srv' directory. I suspect mostly in order to keep the installed services separated from the OS as much as possible. For my own projects I kept this practice. However, over time it more and more looked like this might not be a very good idea: It prevents you from using distribution specific packages (they had a very bad reputation in that team, so mostly everything was custom installations), and I noticed that I was getting into quite some trouble when trying to use chef cookbooks, that are already available.
So lately I was tempted to switch to using the distribution specific packages instead of trying to build custom installations which fit into that directory structure. I was wondering if there is anything that I might be overlooking. Is there actually any good reason to put everything into a '/srv' directory or any good reason to not use the distribution specific packages?
What I currently need in my stack is: nginx, Tomcat (Oracle JDK) and MongoDB.
/srvmay be a good way to apply partition wide policies, such as se-linux, or noexec, whereas
/varmight need defaults flags. I've seen a use of
/srvwhich was read only, and the admin justified the use of a dedicated mointpoint rather than
/varfor that purpose.
/optbut to serve it out recreate/symlink/??? under
/srv/.... Or better yet declare it data. But then would a Java based blog be data too or would that go under /opt or .... OH MY GOOD SO MANY OPTIONS! -- Please keep in mind The current version is 2.3. It was announced on January 29, 2004. SO there isn't even
/runwhich is now widely spread (not saying everybody likes it!). The FHS is NOT a standard but very much outdated