FHS rules govern the layout of Linux system directories - Part 2

Hello.
I'm Mandai, the Wild team member in charge of development.

last timeContinuing from
However, these two have quite detailed specifications, and it took some time to summarize them.

/usr

`/usr` is the location for read-only shared data.
The directory structure under `/usr` is also clearly defined, so let's take a look at that as well.

 

/usr/bin

This directory is considered the most important directory in the FHS (System Handbook), and it stores the system's executable commands.
A key point is that there is a rule against creating subdirectories within this directory.

A more detailed rule is that if the five subsystems perl, python, tclsh, wish, and expect are installed, the executable file or a symbolic link to the executable file must be placed in /usr/bin

As an aside, I just learned that perl is an acronym for "Practical Extraction and Report Language."

 

/usr/include

This directory is where general-purpose include files for the C language are placed.
BSD-compatible include files appear to be placed in a subdirectory called "bsd".

 

/usr/lib

This is a directory for placing shared libraries and object files.
Occasionally, it contains internal binary files that are not intended to be executed directly by users or scripts.

There seems to be no clear distinction between this and /lib mentioned earlier, and in fact in CentOS 7, /lib is a symbolic link to /usr/lib

Each application should have one subdirectory directly under it, and architecture-dependent data should be placed within that.
In short, don't unnecessarily pollute the /usr/lib directory.

/usr/lib/sendmail still has some outdated rules, such as requiring MTAs to provide symbolic links to sendmail-compatible executables.
Sendmail is truly great.

 

/usr/libexec

This is the directory where the internal executable binary files located in /usr/lib are placed.
My personal intuition tells me that it would be nice if they could just be clear about whether something is a library or an executable file, but it seems there are people in the world who can't be that clear.

This "internal executable binary file" seems to be a frequent topic of debate, and no conclusion seems to be in sight yet

 

/usr/lib<qual>

This is /lib<qual> Similarly, this is a directory that contains libraries that are dependent on the OS architecture

 

/usr/local

This is the installation location for software individually installed by the system administrator.
The directory structure directly under /usr/local is similar to that of /usr.
It is customary to specify this directory when compiling and installing software yourself.

Package management systems like yum and apt-get install the system to /usr, so if you accidentally install from source directly under /usr, there's a risk of overwriting existing files. This is
especially true when you want to install different versions of PHP or Ruby. Similarly, it's best to place configuration files in a subdirectory under /etc/local rather than directly under /etc.

 

/usr/sbin

This is sbin, a directory where system binaries are placed, but unlike /sbin, it is a place to place commands that are not essential but are necessary for system management

For example, useful file system construction commands such as iptables, ntpd, crond, and LVM are available.
Only executable binaries or symbolic links to binary files are allowed; subdirectories are not permitted.

 

/usr/share

This directory is where read-only, architecture-dependent data files are stored.
Font files are somewhat debatable in terms of architecture dependency; if you place font files under /usr/share/fonts, the system will recognize them.
Manual-related files are stored under /usr/share/man.

 

/usr/src

This is where you store source code and other files from a source installation.
The primary purpose is for later reference, but depending on the software, you might need the configure files from the installation process when uninstalling, so it's premature to discard them just because the installation is complete.

 

/var

The /var directory is where variable data files are stored.
Variable data includes logs, lock files, temporary files, and other
important data for monitoring and managing Linux systems.

 

/var/account

This is where logs collected by the sa command and lastcomm command are stored.
While the history command logs the commands that were executed, the sa command focuses on statistical data such as the number of executions and execution time, which are data that utilize system resources, and the lastcomm command is similar to the history command, logging command executions.

 

/var/cache

The directory where the application cache data is stored

 

/var/crash

This directory is where system crash dumps are stored.
I wondered what a system crash dump was, but5.6. /var/crash : System crash dumps (optional), it said, "System crash dumps are not supported in the current system."

Incidentally, the system crash dump tool, called kdump, appears to be installed by default in RHEL7. It
was also installed in CentOS7.

What kdump does is dump the kernel memory areas that were lost and inaccessible when the system crashed.
This mechanism is rather wild, or perhaps forceful, as it involves another command called kexec starting up another kernel (which we'll call the second kernel; therefore, the OS the user uses is referred to as the first kernel), obtaining the memory areas of the first kernel, and then kdump writing that data to a file. This process occurs when a crash occurs.

The memory required to run kexec is 160MB for the first kernel, plus 4KB of RAM for each of the 2 bits. Therefore, with 1TB of memory, 224MB is needed. That's
quite a lot of memory...

Also, since different kernels will be running at the same time, it is expected that the CPU will be used to some extent, so care must be taken here as well

Another major issue is whether examining a memory dump will actually help pinpoint the cause of the crash.
Personally, I doubt I could identify the cause by looking at it, so I might not use kdump at all...

 

/var/games

This is where game-related data is stored.
While you might not play games on Linux very often, Ubuntu, for example, comes with Shanghai and Sudoku pre-installed, so why not give them a try?

 

/var/lib

This is the area where the installed system data is stored.
For example, in the case of MySQL installed with yum, all the schema data resides under /var/lib/mysql.

 

/var/lock

This is where the lock file is located.
However, the location of the lock file varies from system to system, and in MySQL, the socket lock file is located in /var/lib/mysql. I wonder
if this is because we are in the transition period to FHS3.0, or if they have no intention of changing it; it's a bit of a mystery.

 

/var/log

This directory is a place every administrator should definitely check.
Kernel logs and logs from various applications are usually stored here.

Depending on the type of log, some may only be accessible by root or users with equivalent privileges, so adjustments in this area may be necessary depending on management needs

 

/var/mail

This is where emails delivered to each user are stored.
However, depending on the OS, mailboxes may be configured at /var/spool/mail, and this directory may be a symbolic link.

 

/var/opt

This directory is designated as the storage location for variable data of software installed in /opt.
Static files are specified to be stored in /etc, giving the impression that configuration files are scattered all over the place.
Executable files are stored in /opt, and the file storage locations for packages installed in /opt are quite strictly defined (lol), giving the impression that they are somewhat marginalized...

 

/var/run

This directory exists for compatibility reasons, reserved for systems designed according to older FHS specifications.
Its role has now been taken over by the `/run` directory, and in CentOS 7, it appears as a symbolic link to `/run`.

The original article focuses on accessing utmp, and about half of it is about utmp

 

/var/spool

/var/spool is a directory for temporary data awaiting processing. It
's a bit more specific than /var/tmp, perhaps referring to data waiting for post-processing.

/var/spool/mail contains emails addressed to local users, and under /var/spool/cron are text files containing the emails registered for each user name

 

/var/tmp

The /var/tmp directory is designated as a temporary directory that is not deleted even after a reboot.
Therefore, when working with files in this directory, you should always delete them using the application that created them.

 

/var/yp

This is the directory where NIS (Network Information Service) data will be placed

The reason it's called "yp" is because the predecessor system to NIS was called Sun Yellow Pages, a legacy of the now-defunct Sun Microsystems. Because
"Yellow Pages" could no longer be used due to trademark issues, NIS adopted the name, and that's how it remains today.

To make things more complicated, there is also a directory called /var/nis, which is not mentioned here, but it exists and is a directory used by NIS+, so it is not used by NIS

To explain in more detail, NIS is software used to share user account and network configuration information within a network. A
similar system currently in use is DNS, but DNS focuses on the network itself, so you could say that NIS has a broader scope.

At first glance, it seems incredibly convenient, but it was developed in the 1980s, a time when public networks weren't developed enough to attract malicious actors, so the concept of security didn't exist.
Furthermore, NIS can only manage a single domain and is very simple to implement.

NIS+ overcomes the weaknesses of NIS, allowing for hierarchical management of multiple domains and incorporating robust security features through encryption—a system packed with improvements.
However, it still uses DES for encryption, so there are some security vulnerabilities.

When I looked into it, all I could find were pages about Solaris, and the material was more than 15 years old, so it seems that in this day and age of the 21st century, you can operate Linux without knowing what /var/yp is

This has become quite long

That's all