In Linux, the “/opt” directory is a standard directory in the file system hierarchy. It is typically used for installing optional or add-on software packages that are not part of the core operating system.
As you might have guessed by now, “opt” stands for “optional.”
The /opt directory provides a location where you can install software that is not managed by the package manager of your Linux distribution.
It is often used for third-party applications or software packages that are self-contained and have their own directory structure.
What is /Opt Used For?
The main purpose of using “/opt” is to keep the software installations separate from the core system files and directories.
This helps in maintaining a clean and organized file system structure and makes it easier to manage and uninstall optional software packages.
When you install software in the “/opt” directory, it typically creates its own subdirectory within “/opt” to keep all its files and directories.
For example, if you install a package called “example” in “/opt,” it might create a directory structure like “/opt/example/bin” for executable files, “/opt/example/lib” for libraries, and so on.
It’s important to note that the use of “/opt” is a convention and not enforced by the operating system. It is up to the software developers or package maintainers to decide whether to use “/opt” for their installations.
Additionally, some Linux distributions may have specific guidelines or recommendations on how to use the “/opt” directory.
How to Use /Opt
Let’s take an internal application developed in a company, CompanyApp, as an example.
Typically, if an app is not packaged using standard tools like dpkg or rpm, it is best practice to place all the files associated with CompanyApp in a single directory.
This means that binaries, libraries, and configurations would coexist in one location, deviating from the traditional UNIX system structure.
Suppose the company decides to deploy this application on a server. In that case, we can simply copy the app’s directory into the “/opt/CompanyApp” directory.
Consequently, we can execute it directly from there as and when necessary. By utilizing “/opt,” installing our application is as straightforward as copying and extracting a TAR file.
By the same token, removing the application is a breeze—simply delete the corresponding directory under “/opt.”
However, there is an alternate approach to managing the location of the app. You can employ the “/opt/Company/CompanyApp” directory structure. This is more convenient if the company has several apps.
But bear in mind that you must use a LANANA registered company/provider name if you’re taking this approach.
It’s worth noting that deploying software by copying a directory is not the norm for a traditional UNIX system. Typically, a UNIX application has separate directories for libraries, binaries, and other files, such as “/usr/local/bin” and “/usr/local/lib.”
In any case, it’s worth exploring the differences between the UNIX way of deploying software and /opt.
Using /usr/local Vs. /opt
According to the Filesystem Hierarchy Standard (FHS), “/usr/local” must be used by the sysadmin when installing tools locally.
Though this description is similar to that of “/opt”, there is a notable difference.
The hierarchy under “/usr/local” should mirror the structure under “/usr.” Consequently, application binaries should be placed in “/usr/local/bin,” and libraries in “/usr/local/lib,” following the conventional UNIX style of organizing application files into separate directories.
This means that deploying into “/usr/local” does not involve having a single directory for each application. Instead, applications are organized according to the traditional UNIX method, dividing files into separate directories.
This traditional approach is driven by two reasons:
- Placing all binaries in “/usr/local/bin” allows us to add this single directory to the system’s $PATH, enabling the execution of installed binaries without additional configuration.
- Storing all installed libraries in “/usr/local/lib” allows multiple binaries to share the same library, preventing any duplicate copies on the system.
In contrast, “/opt” does not impose these directory structure restrictions. As long as applications within “/opt” reside in separate directories, they can have custom directory structures inside.
This means they can have duplicate copies of system-installed libraries and may require additional $PATH configuration for terminal execution.
Use Cases of /usr/local and /opt
Let’s explore some potential scenarios for utilizing “/opt” and “/usr/local”:
- If our application comprises a single binary, we can copy or link it to “/usr/local.”
- When opting for an alternative system program built from source using make, we would install it under “/usr/local.”
- In the case of an application where all files reside in a single directory by design, we would deploy it by copying that directory into “/opt/myapp.”
By understanding the distinctions and use cases of “/opt” and “/usr/local,” we can effectively manage software deployments in Linux.
