Home ›

Point/Counterpoint - /opt vs. /usr/local

Issue 191

From Issue #191
March 2010

May 01, 2010  By Kyle Rankin and Bill Childers
 in
Should a sysadmin put additional software in /usr/local or /opt? Bill and Kyle argue the one true location for third-party software.
______________________

Kyle Rankin is a systems architect; and the author of DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

/opt or /usr/local

Jeffrey Moncrieff's picture
Submitted by Jeffrey Moncrieff (not verified) on Fri, 10/08/2010 - 18:30.

I usually put small type of applications in /usr/local like clients types applications and servers type applications in /opt. /opt could possible be a nfs or samba mount which makes disaster recovery more easier of that mount. Now having said that you would want to make sure that share was located on a system that has a redundant backups ie RAID.

What about /srv vs. /var/lib ?

Anonymous's picture
Submitted by Anonymous (not verified) on Sat, 08/21/2010 - 05:01.

... and /home vs. /usr/home ? And /usr vs. /usr/local ?

An alternative view point just to mix it up.

Mike.Tiernan's picture
Submitted by Mike.Tiernan on Sun, 04/18/2010 - 08:50.

I agree with both Bill and Kyle in their discussion of /opt vs. /usr/local (if such a thing is allowed) but I have yet another take on it given to me by some of the brains I used to work with who had a keener grasp of the idea of multiple computers vs single standalones.

If I am running a system as a standalone machine (even if it is networked to others of it's ilk) but shares no common data/code then /opt is a symlink to /usr/local

However, if I have a set of systems that have locally unique files, they, as Kyle said, go in /usr/local but the packages/tools/files that I build in one place to make available to all the systems in my "cluster" (not cluster computing, just grouped) then all these files and things go into /opt which is a shared mount point as Bill discussed.

And, if you are really good, you'll have /opt for different flavors of systems, such as opt.x86_64, opt.i386, opt.sol9, opt.irix, etc. and they automount as needed.

A simplistic example of the difference would be something like this:
Say you have four Linux hosts, one in Buffalo, one in Boston, and two in the central office in Dallas. The weather data from each of the sites is automatically stored in a data file in /usr/local because two of the three sites don't need to know about the data for the remotes. The program which reads this data, is the same binary and is found in /opt on each machine. Each of the systems can generate the local data trending information and store it in /usr/local but none of the systems can write to /opt.

Yes, it's a contrived example but I hope it illustrates the point reasonably well.

Does the use of a "formal" packaging system such as RPM or DEB change this? No, it just makes it different.

So, in closing, in my opinion, it's a draw!

(If any sysadmin counts the six extra characters in /usr/local as an impediment to their job, they should be hanging it up right now. I question if any decent sysadmin can even measure the difference in time between typing /opt and typing /usr/local it is so small.)

Thanks for all the conversations!

Webcast
More Resources
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.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions