Whole document tree
4. Linux Directory Hierarchy: Oriented to the Software Parts
By now, all discussion are OS independent. On Linux, the Four Software Parts theory is expressed in his directory structure, which is classified and documented in the Filesystem Hierarchy Standard. The FHS is part of the LSB (Linux Standard Base), which makes him a good thing because all the industry is moving thowards it, and is a constant preocupacao to all distributions. FHS defines in which directories each peace of Apache, Samba, Mozilla, KDE and your Software must go, and you don't have any other motivo to not use it while thinking in developing your Software, but I'll give you some more:
FHS is a standard, and we can't live without standards
This is the most basic OS organization, that are related to access levels and security, where users intuitively find each type of file, etc
Makes user's life easyer
This last reason already justifies FHS adoption, so allways use the FHS !!!
More about FHS importance and sharing the same directory structure can be found in Red Hat website.
4.1. FHS Summary
So let's summarize what the FHS has to say about Linux directories:
Linux system directories
- /usr/bin
Directory for the executables that are accessed by all users (everybody have this directory in their $PATH). The main files of your Software will probably be here. You should never create a subdirectory under this folder.
- /bin
Like /usr/bin, but here you'll find only boot process vital executables, that are simple and small. Your Software (beeing high-level) probably doesn't have nothing to install here.
- /usr/sbin
Like /usr/bin, but contains only the executables that must be accessed by the administrator (root user). Regular users should never have this directory in their $PATH. If your Software is a daemon, This is the directory for some of executables.
- /sbin
Like /usr/sbin, but only for the boot process vital executables, and that will be accessed by sysadmin for some system maintaining. Commands like fsck (filesystem check), init (father of all processes), ifconfig (network configuration), mount, etc can be found here. It is the system's most vital directory.
- /usr/lib
Contains dynamic libraries and support static files for the executables at /usr/bin and /usr/sbin. You can create a subdirectory like /usr/lib/myproduct to contain your helper files, or dynamic libraries that will be accessed only by your Software, without user intervention. A subdirectory here can be used as a container for plugins and extensions.
- /lib
Like /usr/lib but contains dynamic libraries and support static files needed in the boot process. You'll never find an executable at /bin or /sbin that needs a library that is outside this directory. Kernel modules (device drivers) are under /lib.
- /etc
Contains configuration files. If your Software uses several files, put them under a subfolder like /etc/myproduct/
- /var
The name comes from "variable", because everything that is under this directory changes a frequently. Usually /var is mounted over a separate high-performance partition. In /var/log logfiles grow up. For web content we use /var/www, and so on.
- /home
Contains the user's (real human beings) home directories. Your Software package should never install files here (in installation time). If your business logic requires a special UNIX user (not a human being) to be created, you should assign him a home directory under /var or other place outside /home. Please, never forget that.
- /usr/share/doc, /usr/share/man
The "share" word is used because what is under /usr/share is platform independent, and can be shared among several machines thru a network filesystem. Portanto this is the place for manuals, documentations, examples etc.
- /usr/local, /opt
These are obsolet folders. When UNIX didn't have a package system (like RPM), sysadmins needed to separar an optional (or local) Software from the main OS. These were the directories used for that.
You may think is a bad idea to break your Software (as a whole) in many pieces, instead of keeping it all under a self-contained directory. But a package system (RPM) has a database that manages it all for you in a very professional way, taking care of configuration files, directories etc. And if you spread your Software using the FHS, beyond the user friendlyness, you'll bring an intuitive way to the sysadmin configure it, and work better with performance and security.
4.2. Examples Using the FHS
Now that we know where each part of our software must be installed, lets review the Universal Parts Table applied to the FHS.
Table 2. Same Software, applying FHS
| Software on its Own | Configurations | Content | Logs, Dumps etc | |
|---|---|---|---|---|
| Data Base Server | /usr/bin/, /usr/lib/, /usr/share/doc/mydb/, /usr/share/doc/mydb/examples/ | /etc/mydb/ | /var/db/instance1/, /var/db/instance2/, etc | /var/db/instance1/transactions/, /var/log/db/access-instance1.log, /var/log/db/access-instance2.log |
| Text Editor | /usr/bin/, /usr/lib/, /usr/lib/myeditor/plugins/, /usr/share/myeditor/templates/, /usr/share/doc/myeditor/ | $HOME/.myeditor.conf | $HOME/Docs/ | $HOME/.myeditor-tmp/ |
| MP3 Generator | /usr/bin/, /usr/lib/, /usr/lib/mymp3/plugins/, /usr/share/doc/mymp3/ | $HOME/.mymp3.conf | $HOME/Music/ | $HOME/.mymp3-tmp/ |
| Web Server | /usr/sbin/, /usr/bin/, /usr/lib/httpd-modules/, /usr/share/doc/httpd/, /usr/share/doc/httpd/examples/ | /etc/httpd/, /etc/httpd/instance1/, /etc/httpd/instance2/ | /var/www/, /var/www/instance1/, /var/www/instance2/ | /var/logs/httpd/, /var/logs/httpd/instance1/, /var/logs/httpd/instance2/ |
| E-Mail Server | /usr/sbin/, /usr/bin/, /usr/lib/, /usr/share/doc/mymail/ | /etc/mail/, /etc/mailserver.cf | /var/mail/ | /var/spool/mailqueue/, /var/logs/mail.log |
4.3. Friend Advice: Never use /opt or /usr/local
This is a very polemic subject, and that is whay this is the most important section in this document. After almost ten years of UNIX experience I can beat any /usr/local-prone argument. I'll try to organize some ideas here.
It is very important to Linux evolution and popularization (sobretudo in the desktop batlefield), that developers stop using this hell directories, and start using the FHS. After reading this section, if you still think this folders are good business, please drop me an e-mail.
Products that are entirely installed under one directory, uses the self-contained approach, that has several problems:
Forces the user to change environment variables like $PATH and $LD_LIBRARY_PATH to use your product easilly.
Puts files in non-standard places, dificulting system integration, and future installation of extensions to your product.
The sysadmin probably didn't prepared disk space in these partitions, generating problems in installation time.
It is an accepted approach only for pure graphical application, without the command line concept. This is why it were well accepted in Windows. But...
...even using this approach, you can't avoid installing or changing files in standard locations to, for instance, make your icons appear in the user desktop.
This directories exists for historical reasons, and for compatibility with other UNICES, from the epoch we didn't have a package management system, and the sysadmin needed to segregate the products, to keep the control. And the last item shows us that even if you want, you'll not be able to segragate your product. You'll make it distant and non-practicall to the user.
You don't have to be affraid of spreding your files according to FHS because RPM will keep an eye on them.
Many developers believe that the "self-contained" approach let them work with several versions of the same product, for testing purposes, or whatever. Yes, agree, with this or any good reason in the planet. But remember that a High Quality Software (or Commercial Grade Software) objective is to be practical for the final user, and not to be easy to their developers and testers. Invite yourself to visit an unexperienced (but potential customer) user and watch him installing your product.
If you have a business requirement to let the user work with several versions of your Product simultaneously (or any other reason), make a relocatable package, which is described in the Maximum RPM book. Be also aware about the implications of using this feature, described in the same book.
Não é a toa that distribuições like Red Hat and derivatives allways use FHS, instead of /opt or /usr/local. Read what Red Hat says about this subject, and thik about it.
 | The Makefiles of an OpenSource Software that is portable to other UNICES must have the standard installation in /usr/local for compatibility reasons. But must also give the option, and induct the packager, to create the package using FHS specifications. |