Linux Filesystem Organization

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.