Use of /opt and /usr/local directories in the context of a PC


Next:36. httpd Up:rute Previous:34. uucp and uux




This chapter reproduces the Filesystem Hierarchy Standard, translated into LATEX with some minor formatting changes and the addition of this book's chapter number to all the section headers. An original can be obtained from the FHS home page .

If you have ever asked the questions ``Where in my file system does file xxx go?'' or ``What is directory yyy for?'', then consult this document. It can be considered to provide the final word on such matters. Although this is mostly a reference for people creating new LINUX distributions, all administrators can benefit from an understanding of the rulings and explanations provided here.

Filesystem Hierarchy Standard -- Version 2.2 final

Filesystem Hierarchy Standard Group

edited by Rusty Russell and Daniel Quinlan

ABSTRACT This standard consists of a set of requirements and...
0 0

Ubuntu (like all UNIX-like systems) organizes files in a hierarchical tree, where relationships are thought of in teams of children and parent. Directories can contain other directories as well as regular files, which are the "leaves" of the tree. Any element of the tree can be referenced by a path name; an absolute path name starts with the character / (identifying the root directory, which contains all other directories and files), then every child directory that must be traversed to reach the element is listed, each separated by a / sign.

A relative path name is one that doesn't start with /; in that case, the directory tree is traversed starting from a given point, which changes depending on context, called the current directory. In every directory, there are two special directories called . and .., which refer respectively to the directory itself, and to its parent directory.

The fact that all files and directories have a common root means that, even if several...

0 0

Designing a file system layout to improve system performance and safety

Roderick W. Smith
Published on February 17, 2009

The UNIX® operating system enables you to split up your disk data into multiple volumes. Knowing how to do this is only half the battle, though; to make effective use of this ability, you must understand how the files on a UNIX system are organized as well as why they're organized in this way. This article addresses the issue of why you should use multiple volumes.

Terminology notes

Before proceeding further, a couple of terminology issues must be addressed. First, file system can mean either the low-level disk structures used to organize data on the disk or the higher-level structure of files and directories on the computer. The operating system you run supports one or more low-level file systems and therefore determines your available choices. High-level file system structure, by contrast,...

0 0

The usage & meanings have changed with the times.

Presumable, back in whatever day, '/bin' & '/sbin' were the directories needed to boot the OS, then a remotely-located read-only /usr file system would be mounted into place, to complete the OS. /usr/local was mounted overtop that, as a local storage for whatever the server needed.

Nowadays, especially in an environment where precompiled packages are the norm, it has little use for most users. '/opt' is often default location for pre-packaged applications which once might have been compiled and resided within /usr/local. Also, disk storage is cheap, so every host keeps its own '/usr' file system, and most Linux/UNIX no longer support the idea of having a separate /usr file system, using it to boot the OS.

Even so, '/usr/local' is still the default self-contained location to install applications you've manually compiled yourself - a location outside control of the package manager (pkg,rpm,yum,etc) that you can...

0 0

This is a list of the primary Red Hat Enterprise Linux system directories. Each directory is described briefly. For additional directory information, refer to the and the .

/bin/ — Used to store user commands. The directory /usr/bin/ also stores user commands.

/sbin/ — Location of many system commands, such as shutdown. The directory /usr/sbin/ also contains many system commands.

/root/ — The home directory of root, the superuser.

/misc/ — This directory is used for automatically mounting directories on removeable devices (such as Zip drives) and remote directories (such as NFS shares) using autofs. Refer to the autofs manual page (type man autofs at a shell prompt) for more information.

/mnt/ — This directory typically contains the mount points for file systems mounted after the system is booted.

/media/ — This directory contains the mount points for removable media, such as diskettes, CD-ROMs, and USB flash...

0 0

Have you wondered why certain programs are located under /bin, or /sbin, or /usr/bin, or /usr/sbin?

For example, less command is located under /usr/bin directory. Why not /bin, or /sbin, or /usr/sbin? What is the different between all these directories?

In this article, let us review the Linux filesystem structures and understand the meaning of individual high-level directories.

1. / – Root

Every single file and directory starts from the root directory. Only root user has write privilege under this directory. Please note that /root is root user’s home directory, which is not same as /.

2. /bin – User Binaries

Contains binary executables. Common linux commands you need to use in single-user modes are located under this directory. Commands used by all the users of the system are located here. For example: ps, ls, ping, grep, cp.

3. /sbin – System Binaries

Just like /bin, /sbin also contains binary executables. But, the linux...
0 0

I hope this will help others to workaround until there is an solution, thanks to @cgwalters and @copumpkin

Rebuild puppet-agent rpm with new path

Regular Expression to change /opt/ -to-> /var/opt:


Copy Conent from /opt/ to the new location: /var/opt/

cp -rfa /opt/puppetlabs /var/opt/puppetlabs rpmrebuild -e puppet-agent opens vi/vim, run the regular expression... and write close the change ( !wq ). ls -lha /root/rpmbuild/RPMS/x86_64/puppet-agent-1.4.1-1.el7.x86_64.rpm yum install createrepo createrepo --database /root/customrpms

File: sig-atomic-buildscripts/puppetlabs-pc1.repo

[puppetlabs-pc1] name=Puppet Labs PC1 Repository el 7 - $basearch #baseurl=$basearch baseurl= gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-puppetlabs-PC1

Start Custom Yum repository:

http-server: ( npm install -g http-server ) cd /root/customrpms/ http-server -p 6060


0 0

Red Hat Enterprise Linux uses the Filesystem Hierarchy Standard (FHS) file system structure, which defines the names, locations, and permissions for many file types and directories.

The FHS document is the authoritative reference to any FHS-compliant file system, but the standard leaves many areas undefined or extensible. This section is an overview of the standard and a description of the parts of the file system not covered by the standard.

Compliance with the standard means many things, but the two most important are compatibility with other compliant systems and the ability to mount a /usr/ partition as read-only. This second point is important because the directory contains common executables and should not be changed by users. Also, since the /usr/ directory is mounted as read-only, it can be mounted from the CD-ROM or from another machine via a read-only NFS mount.

3.2.1. FHS Organization


0 0

Last revised 2018-02-23 by Tibbs.

The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee.

It is the package reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) Please remember that any package that you submit must also conform to the Review Guidelines .

The original author of these documents is Tom 'spot' Callaway, though they were originally based on many other documents. They have been significantly modified over the years by many members of...

0 0

I think the complexity is brought about by using MacPorts or Fink. If you simply compile the libraries yourself instead of letting MacPorts do it and install the libraries in /usr/local my guess your experience may be better.

Not sure which libraries you are using from MacPorts but do those libraries have any specific environment variables that you can set that would help tell CMake where to look? Like Boost has BOOST_ROOT and Qt has QTDir. I had to write a couple of modules that over-ride the standard modules included with CMake in order to look for environment variables FIRST and set the search paths accordingly.
Mike Jackson Principal Software Engineer
BlueQuartz Software Dayton, Ohio
[hidden email]

> Thank you for your detailed reply, Rolf. The code you've included

> looks to me like the similar complexity of the code I've...

0 0

As you try to install software from source or a locally built package, where do you install it? Is /usr/local the right path or does /opt make sense?

Purpose of /opt

From the FHS,

/opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name.

Purpose of /usr/local

From the FHS,

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

Confused Yet?


0 0


This section details the organization for manual pages throughout the system, including /usr/share/man. Also refer to the section on /var/cache/man.

The primary of the system is /usr/share/man. /usr/share/man contains manual information for commands and data under the / and /usr filesystems.

Manual pages are stored in //man/. An explanation of , , , and is given below.

A description of each section follows:

man1: User programs Manual pages that describe publicly accessible commands are contained in this chapter. Most program documentation that a user will need to use is located here.

man2: System calls This section describes all of the system calls (requests for the kernel to perform operations).

man3: Library functions and subroutines Section 3 describes program library routines that are not direct calls to kernel services. This and chapter 2 are only really of interest to programmers.

man4: Special files Section 4...

0 0
0 0
If you are using the SPL FileInfo object and then try to create the path with mkdir, don't forget that mkdir expects a string as the first argument and NOT an object...

I have forgotten that very important rules and get only a permission deny to mkdir to create new directories but in fact, the issue was the fact that i wasn't passing a string to mkdir

$my_file = new SplFileInfo('path/to/file.txt') ;

// get path from file
$parent = $my_file->getPathInfo() ;

// check if path is directory or not
// create / open file.txt file
} else {
// if path/to does not exists, create the directory recursively
mkdir($parent, 0755, true) ; // THIS WON'T WORK because $parent is a SplFileInfo object.

// instead, get the path as a string
$path = $parent->getPathname() ;
mkdir($path, 0755, true) ; // THIS WILL WORK

0 0

This guide will provide a brief introduction to the Linux Filesystem Hierarchy (LFSH; ie, the filesystem layout) for those familiar with Windows. The first section will clarify any terminology used, the second section will address frequently asked questions (FAQs) about the LFSH, and the third section will provide a brief rundown of the LFSH. The goal is to help new Linux users figure out where things are located.

note: Linux has directories; Windows has folders. They're basically the same thing.

"Where is Program Files?"

Linux has no single location for most of its executable (think \*.exe) files. Instead, these files may be located in one of multiple, mostly pre-determined, locations. Most notably:

/bin contains non-administrator executable files necessary for system booting. /sbin contains administrator executable files necessary for system booting. /usr/bin contains non-administrator executable files not necessary for system booting. /usr/sbin...
0 0