There is a rule called FHS that summarizes the layout of Linux system directories - Part 2 -

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

Continuing from
last time However, these two have quite detailed specifications, so it took a while to put them together.

/usr

/usr is a read-only location for 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 positioned as the most important directory in the FHS, and stores executable commands in the system. An
important point is that there is a rule that subdirectories cannot be created in 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 contains general-purpose include files for the C language.
BSD-compatible include files are placed in a subdirectory called bsd.

 

/usr/lib

This is a directory for placing shared libraries, object files, and
occasionally 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 pushed there.
The point is, don't pollute the /usr/lib directory unnecessarily.

There is also a legacy rule that /usr/lib/sendmail must have a symbolic link to a sendmail-compatible executable file provided by the MTA.
Sendmail is great.

 

/usr/libexec

This is the directory for placing the internal executable binary files that are placed in /usr/lib mentioned earlier.
From my own personal experience, I feel like it would be better if it was clearer whether it was a library or an executable file, but it seems that there are people out there who can't make 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 destination for software installed individually by the system administrator.
The directory structure directly under /usr/local is similar to that of /usr.
If you are compiling and installing software yourself, it is customary to specify this directory.

Package management systems such as yum and apt-get install the system in /usr, so if you accidentally install the source code directly under /usr, there is a risk that it will be overwritten.
This is especially true when you want to install different versions of PHP or Ruby. It is also problematic to place configuration files directly under /etc, so it is preferable to create a subdirectory in /etc/local and place them there.

 

/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 filesystem construction commands such as iptables, ntpd, crond, LVM, etc.
Only executable binaries or symbolic links to binary files can be placed there, no subdirectories allowed.

 

/usr/share

This directory is where read-only architecture-dependent data files are placed.
Font files are not necessarily architecture-dependent; if you place font files under /usr/share/fonts, they will be recognized by the system.
Manual-related files are also stored under /usr/share/man.

 

/usr/src

This is where you store the source code etc. when you do a source installation.
The main purpose is to refer to it later, but depending on the product, you may need the configure files etc. when uninstalling, so it's a bit hasty to throw it away just because the installation is complete.

 

/var

/var is where variable data files are stored.
Variable data includes logs, lock files, temporary files, etc. This
is where important data for monitoring and managing Linux is stored.

 

/var/account

This is where the logs collected by the sa and lastcomm commands are stored.
While the history command logs executed commands, the sa command stores statistical data that focuses on system resource usage, such as the number of executions and execution time, while the lastcomm command stores command execution logs similar to the history command.

 

/var/cache

The directory where the application cache data is stored

 

/var/crash

This directory stores system crash dumps.
I wondered what a system crash dump was, but when 5.6. /var/crash: System crash dumps (optional) , I found the following statement: "The current system does not support system crash dumps."

By the way, the system crash dump is called kdump and is installed by default on RHEL7. It
is also installed on CentOS7.

What kdump does is dump the kernel's memory area that was lost when the system crashed and could not be accessed in any way.
This mechanism is quite wild, or perhaps forceful, as it uses a separate command called kexec to launch another kernel (this is called the second kernel, so the OS used by the user is called the first kernel), obtains the memory area of ​​the first kernel, and kdump writes it to a file. This is the process that occurs when a system crashes.

The memory required to run kexec is 160MB of the memory used by the first kernel + 4KB of RAM per 2 bits, so if you have 1TB of memory, you will need 224MB. That's
quite a lot...

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 big problem is how close you can get to determining the cause of the crash by looking at a memory dump.
I personally don't think you can identify the cause by looking at it, so I might not use kdump...

 

/var/games

This is the storage area for game data.
I don't think you play games on Linux very often, but for example, Ubuntu comes pre-installed with Shanghai and Sudoku, so why not give them a try?

 

/var/lib

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

 

/var/lock

This is where the lock file is placed.
However, the location of the lock file currently varies depending on the system, and in MySQL the socket lock file is placed in /var/lib/mysql.
It is unclear whether this is a transition period to FHS3.0 or whether there is no intention to change it.

 

/var/log

This directory is a place that all administrators should check.
Kernel and application logs 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 the location where emails delivered to each user are stored.
However, depending on the OS, mailboxes may be set to /var/spool/mail, and this directory may be a symbolic link.

 

/var/opt

This directory is used to store variable data for software installed in /opt.
Static files are required to be stored in /etc, which gives the impression that configuration files are scattered all over the place.
Executable files are stored in /opt, and packages installed in /opt have fairly strict file storage locations (lol), which gives the impression of being a bit of a burden...

 

/var/run

This directory exists for compatibility with systems designed according to the previous FHS specifications.
Its role has now been taken over by the /run directory, and if you check on CentOS 7, you will see that it is 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, like data waiting to be processed later.

/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

/var/tmp is a /tmp that will survive reboots,
so if you are working with this directory, you should always delete files in the application that created them.

 

/var/yp

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

The reason for the name "yp" is that 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 discovered the name, and it has remained that way ever since.

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 it in a bit more detail, NIS is software for sharing user account and network setting information within a network. A
similar system currently in use is DNS, but since DNS focuses on networks, you could say that NIS has a wider range of coverage.

Just looking at this, you might think it's incredibly useful, but it was developed in the 1980s, when public networks were not yet developed enough for malicious actors to come and do their jobs, so there was no concept of security.
Also, NIS is limited to managing a single domain, and it is easy to create.

NIS+ overcomes the weaknesses of NIS, allowing for hierarchical management of multiple domains and providing security through encryption. It is a system packed with "+" elements.
However, since it also uses DES for encryption, it has some weak points in terms of security.

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 it.