Where to Install My Products on Linux?
For some software developers and Independent Software Vendors (ISVs), there are differing ideas about where to install one's applications and software packages. Some prefer to install in /usr/bin/ or /usr/local/bin/, yet others prefer the /opt/ directory. Your preferences may vary depending on whether you have a UNIX System V, Berkeley Software Distribution (BSD), or GNU/Linux background.
The Filesystem Hierarchy Standard 1 (FHS), Version 2.1, was written to eliminate these differences by specifying detailed guidelines as to where system services, configurations and software should be located on a UNIX or UNIX-based operating system. In detail, the FHS explains the content and purpose for each of the primary directories (see Figure 1).
In a nutshell, the base operating system's, or the distribution's applications are to be installed in /sbin/, /bin/, and /usr/. The system administrator can build packages from source and install them into the /usr/local/bin/ directory. However, the binary-only packages of nonessential applications and add-on software products should be installed in /opt/<package>/ directories, where <package> is the name that describes a software suite. The binary executables should be located in their respective /opt/<package>/bin/ subdirectory. If there are any accompanying UNIX manual pages, they should be installed in the /opt/<package>/man/ sub-directories.
The System V Application Binary Interface [AT&T 1990], the Intel Binary Compatibility Standard V.2 (iBCS2), the Common Operating System Environment (COSE), the Linux Standard Base (LSB), and the UNIX community in general have already established the /opt/ directory for add-on software.
The system administrator should create a separate disk partition for the /opt/ file system, and endusers should add /opt/<package>/bin/ and /opt/bin/ to their PATH environment variable. Usually the end-user's shell will find applications in their respective /opt/<package>/bin/ directories; however, the system administrator may have created symbolic links or wrapper scripts in /opt/bin/ for each package.
Host specific configurations for /opt/ binary executables should go in /etc/opt/<package>/ directories. These are the proper locations for configuration files of the /opt/ packages, because /etc/ is where all host specific system configurations reside on a UNIX-based operating system.
Variable files in a package, or files that change during the normal course of system runtime, should be kept in the /var/opt/<package>/ directories. The contents of /var/ are host specific and the directory is usually configured in its own file system to prevent the accidental filling of the root file system.
An exception to these rules is when it is necessary, or makes sense, for a package to install or create files elsewhere. For example, if a package were to create a new device, then it would be created in the /dev/ directory.
Now that we know the rules of the Filesystem Hierarchy Standard for add-on software packages, let's try to package and install a fictional software suite called Whizbang. If we are to follow the LSB specification, we should use the RPM Package Manager2 (RPM) and try to package our software for the /opt/ directory. This is shown at lines 18-20 of the whizbang-1.2-3.spec configuration file (see Listing 1). Line 8 shows how to make it relocatable so that the system administrator can install it elsewhere if so desired. However, installing in a nonstandard directory is not advisable.
Let's build Whizbang's RPM package as shown below. Using the whizbang-1.2-3.spec as the input file, RPM can build and produce a source package file whizbang-1.2-3.src.rpm and a binary package file whizbang-1.2-3.i386.rpm.
The book Maximum RPM, by Edward Bailey, or the RPM web site, http://www.rpm.org/, are excellent resources for learning to create RPM packages. For now, don't worry about the details, but recognize that there is a guideline on where to install most everything. To create the whizbang-1.2-3.i386, do the following:
# rpm -ba /usr/src/redhat/SPECS/whizbang-1.2-3.spec Processing files: whizbang Finding provides... Finding requires... Prereqs: /bin/sh Wrote: /usr/src/redhat/SRPMS/whizbang-1.2-3.src.rpm Wrote: /usr/src/redhat/RPMS/i386/whizbang-1.2-3.i386.rpm
Using the whizbang-1.2-3.i386.rpm binary package we just created above, we can now install it onto the system as show below:
# rpm -i \/usr/src/redhat/RPMS/i386/whizbang-1.2-3.i386.rpm
Now that whizbang is installed in /opt/whiz/bin/, try to run it from the command line. Did your shell find it? Was /opt/whiz/bin/ in your PATH environment variable? What if we wanted to make it more convenient for the enduser by creating a symbolic link to /opt/whiz/bin/whizbang from /opt/bin/whizbang? This could be done during the post-install phase of the RPM installation, as shown here:
%post P=$RPM_INSTALL_PREFIX mkdir $P/bin > /dev/null 2>&1 ln -fs $P/whiz/bin/whizbang $P/bin/whizbang mkdir $P/man/man1 > /dev/null 2>&1 ln -fs $P/whiz/man/whizbang.1 $P/man/man1/whizbang.1 # EOF
This “relocatable” post-install code would be added at line 20 in Listing 1; however, the RPM %postun uninstall solution to remove the symbolic links is left as an exercise for the reader.
Sometimes it is necessary or desirable to install a software suite somewhere other than for where it was originally packaged. Now let's uninstall the whizbang-1.2-3 RPM package, and reinstall it in an alternate location.
# rpm -e whizbang-1.2-3 # rpm -i --prefix /usr/local # /usr/src/redhat/RPMS/i386/whizbang-1.2-3.i386.rpm
In summary, binary-only packages of nonessential applications and add-on software products should be installed in the /opt/<package>/bin/ directory. We've seen the basics on how to create a relocatable RPM package and how to build it, and we have demonstrated its flexibility by being able to override the default /opt/ destination and selecting an alternate location. Following the FHS standard is the first step in making your GNU/Linux application more LSB3 compliant.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Build a Skype Server for Your Home Phone System
- Why Python?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Reply to comment | Linux Journal
15 min 28 sec ago
- Reply to comment | Linux Journal
1 hour 5 min ago
- Not free anymore
5 hours 7 min ago
8 hours 54 min ago
- Reply to comment | Linux Journal
9 hours 2 min ago
- Understanding the Linux Kernel
11 hours 17 min ago
13 hours 47 min ago
- Kernel Problem
23 hours 49 min ago
- BASH script to log IPs on public web server
1 day 4 hours ago
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?