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

As a recovering, long-time Windows user, I've been trying to clarify my understanding of the "proper" place to put things in Linux (or UNIX too I guess but I rarely work in a non-OS X UNIX and Mac OS X is hardly "proper"). I'd prefer to keep the question fairly distribution-independent but if the correct answer depends upon a particular flavor then that is fine. My goal is to be able to have others work within a system that I've setup and be able to logically follow the organization.

1. When it comes to the roll of a sysadmin (as opposed to a user role), where do people generally agree is best for installing server binaries like web servers, database, etc.? From what I've gleaned over time it appears that both of these are correct:

  • /opt/<package>
  • /usr/local/bin/<package>

The Filesystem Hierarchy Standard doesn't seem to clearly differentiate. Are there advantages disadvantages of one over the other, or is this just preference?

2. Also I've commonly seen this type of thing:

  • /usr/local/bin/foo-bar-3.2.1-baz
  • /usr/local/bar -> /usr/local/bin/foo-bar-3.2.1-baz

Where the version-specific package is the actual location and then a symbolic link is added to make typing / upgrading easier. Is this pretty universal?

3. And then the next logical question is where do the data for their binaries go? This seems to be common:

  • /var/lib/<package>

Is there a better location?

share|improve this question

3 Answers 3

up vote 4 down vote accepted

In this day and age, I don't believe there's a hard and fast definitive answer about "where does file X go?". There are conventions, sure, and a lot of these are documented by TLDP. However, many distributions will have their own conventions about where things go.

In general, I go with this:

/opt: Big lumpy apps which live in their own directories, binaries, libraries, config and all. I see a lot of java apps living there, but that's probably the environment I work in

/usr/local: Any script/program I've written and not packaged up in a deb/rpm. Should be read-only to the user, so that the user can't (easily) go and overwrite it

/var: as the name hints, variable data goes here. Persistent data stores. A lot of apps use /var/lib for application data, and things like /var/run for PID files and sockets. This will vary depending on distribution though.

share|improve this answer
    
Nice heuristics. Thanks! –  McKAMEY Dec 15 '11 at 20:32
    
Large software packages must not use a direct subdirectory under the /usr hierarchy. /opt is better. It is funny though why Java distros tend to install there. –  djangofan Dec 16 '11 at 0:50
    
Thanks for the TLDP link as well. –  McKAMEY Dec 17 '11 at 16:35

I also found this confusing when I first moved to Linux and over time, this is what I've learned.

Rule #1: When possible, always install using the distro's package manager (yum for most RPM based distros and apt-get for most Debian based distros. Slackware and Gentoo have their own). When you use the package manager, your packages will be installed where they belong and where other applications expect to find them. Moving binaries from their package manager destination will cause problems later so leave them where they are.

Rules #2: If you cannot find a package you need in your package manager, then you may have to compile and install from source code. This is the situation where things can get confusing. The application that your are compiling will usually come with a make file that tells make where to install the files when make install is called. In general, this is when you will find files installed in /opt or /usr/local. Those are common locations for applications installed from source. More specifically, it seems to me that I typically find closed-sourced binaries end up in /opt and open source binaries end up in /usr/local

Regarding the symlinking you're seeing; you are correct. In most cases when you see a symlink situation like you've stated, that was done by the installation process in order to facilitate upgrades/backwards compatibility/or some other known issue.

Regarding the data - if you're talking about conf files, you will generally find them in the /etc directory. The various lib directories provide libraries that are used by other applications on the system.

The LSB (Linux Standards Base) project has been trying to standardize stuff like this and init script locations for years. It has made some headway, but not as much as they would like mostly because the older distributions are entrenched in how they do business and don't see the value in changing to some other method.

Hope that helps.

share|improve this answer
    
Good additions to the above description with the comments about package managers and config locations. Thanks! –  McKAMEY Dec 15 '11 at 20:32
    
Interesting, the package manager didn't have the version of a particular package I wanted but I thought I'd let it install it anyway and see where it put things. It splayed it's bits all over /usr/share/*... –  McKAMEY Dec 15 '11 at 20:54

You may want to look at the Filesystem Hierarchy Standard (v2.3) at http://www.pathname.com/fhs/.

This is referred to by the Linux Standards Core Base Specification (v3.1) in Chapt. 16.

share|improve this answer
    
I also referenced it in the question... –  McKAMEY Dec 15 '11 at 21:02
    
Whoops, RTQ (Read The Question). Mea Culpa –  TonyG Dec 15 '11 at 21:19

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.