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, the specifications for these two items were quite detailed, and 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 I would like to take a look at that as well.

 

/usr/bin

This directory is considered the most important directory in the FHS and stores executable commands within the system.
An important point is that there is a rule that prohibits creating subdirectories in this directory.

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

As a side note, 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 seem to be placed in a subdirectory called bsd.

 

/usr/lib

This is the directory for placing shared libraries and object files.
In rare cases, there are internal binary files that are not intended to be executed directly by users or scripts.

There doesn't seem to be a clear line as to what is different from /lib that appeared earlier, and in fact, in CentOS7, /lib is a symbolic link to /usr/lib.

Each application should have one subdirectory directly under it, and architecture-dependent data should be pushed into it.
The point is, don't unnecessarily contaminate the area directly under /usr/lib.

/usr/lib/sendmail also has a legacy rule that requires the MTA to provide a symbolic link to a sendmail-compatible executable.
sendmail is great.

 

/usr/libexec

This is the directory where the internal executable binary files located in /usr/lib are placed.
I don't care, but I feel like I need to clarify whether it's a library or an executable file, but it seems like there are people out there who can't make that distinction.

This "internal executable binary file" is often the subject of debate, and no conclusion seems to be in sight yet.

 

/usr/lib<qual>

This is /lib<qual> Similarly, this is a directory that stores OS architecture-dependent libraries.

 

/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 /usr.
If you compile and install it yourself, it is customary to specify this directory.

Package management systems such as yum and apt-get install the system to /usr, so if you inadvertently install the source directly under /usr, it may be overwritten.
This is the case when you want to install different versions of PHP or Ruby, and it would be a problem to put the configuration file directly under /etc, so it is recommended to create a subdirectory in /etc/local and place it.

 

/usr/sbin

This is sbin, so it is the directory where system binaries are placed, but unlike /sbin, this is where commands that are not required but are necessary for system management are placed.

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

 

/usr/share

This directory is where read-only, architecture-dependent data files are placed.
The font file seems to be architecture-dependent. If you place the font file under /usr/share/fonts, the system will recognize it.
/usr/share/man files related to manuals are also stored under /usr/share/man.

 

/usr/src

This is where you can supplement the source code etc. when installing the source.
Basically, the purpose is to refer to it later, but depending on the item, you may need the configure file from the installation when uninstalling it, so it is premature to throw it away just because the installation is finished. .

 

/var

/var is the location for variable data files.
Variable data includes logs, lock files, and temporary files.
Important data is stored in monitoring and managing Linux.

 

/var/account

This is where logs collected using the sa command and lastcomm command are stored.
While the history command is a log of executed commands, the sa command provides statistical data that emphasizes data using system resources, such as the number of executions and execution time, and the lastcomm command is a log of command execution similar to the history command. Masu.

 

/var/cache

This is the directory that stores the application's cache data.

 

/var/crash

This directory stores system crash dumps.
What is a system crash dump? I thought so, but 5.6. /var/crash: System crash dumps (optional) , I noticed that there was a text attached that said, "System crash dumps are not supported on the current system." Ta.

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

What kdump does is dump the kernel memory area that was blown up when the system crashed and could not be accessed.
This mechanism is rather wild or brute-forced, so we launch another kernel from another command called kexec (this is called the second kernel), so the OS used by the user is When a crash occurs, kdump acquires the memory area of ​​the first kernel (referred to as the first kernel) and writes it to a file.

The memory area required to run kexec is 4KB of RAM per 160MB + 2 bits of memory used by the first kernel, so with 1TB of memory, 224MB is required.
I eat quite a lot...

Also, since kernels from different systems are running at the same time, they will probably use quite a bit of CPU, so you need to be careful here as well.

Another big issue is how close you can get to the cause of the crash by looking at the memory dump.
Personally, I don't think I can identify the cause by looking at this, so I may not use kdump...

 

/var/games

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

 

/var/lib

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

 

/var/lock

This is the location for the lock file.
However, the location of the lock file currently varies depending on the system; MySQL stores the socket lock file in /var/lib/mysql.
I think it's unclear whether it's a transition period to FHS3.0 or if they have no intention of changing.

 

/var/log

This directory is a must-see location for administrators.
Most kernel and various application logs are stored here.

Depending on the type of log, there are some logs that can only be authorized by root or a user with similar privileges, so you may need to make adjustments depending on your management needs.

 

/var/mail

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

 

/var/opt

This directory is intended to store variable data for software installed in /opt.
Static files are stipulated to be saved 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 rather strict regulations (lol) about where they can be saved, giving the impression that they are being limited...

 

/var/run

This directory is a leftover compatibility directory for systems designed to previous FHS specifications.
Currently, that role has been moved to a directory called /run, and when you check it on CentOS7, it is a symbolic link to /run.

The original text focuses on accessing utmp, and about half of the text is about utmp.

 

/var/spool

/var/spool is a directory that stores temporary data that is waiting to be processed.
Is it a bit more clear than /var/tmp, like data waiting for post-processing?

/var/spool/mail contains mail addressed to local users, and under /var/spool/cron there are text files registered with each user name.

 

/var/tmp

/var/tmp is positioned as /tmp, which will not be deleted even after rebooting.
Therefore, when working with this directory, you should always delete the files in the application that created them.

 

/var/yp

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

The name yp is said to be because the name of the predecessor system of NIS was Sun Yellow Pages, a legacy of the now defunct Sun Microsystems.
Because "Yellow Pages" could no longer be used due to trademark issues, NIS resolved the issue, which continues to this day.

To complicate things, the directory /var/nis also exists, although it is not shown this time, and this directory is used by NIS+, so it is never used by NIS.

To explain in more detail, NIS is software for sharing configuration information regarding user accounts and networks within a network.
A similar system currently in use is DNS, but it focuses on networks, so it can be said that NIS has a broader scope.

You'd think it would be super convenient just by looking at it, but it was developed in the 1980s, and public networks weren't developed enough to have people trying to do bad things, so there was no concept of security.
Additionally, NIS can only manage a single domain and is easy to create.

Therefore, NIS+ overcomes the weaknesses of NIS, and is a truly rich system that can manage multiple domains hierarchically and has security using encryption.
However, this also uses DES for encryption, so it is a bit lenient in terms of security.

I searched, but only the Solaris page came up, and the material is from over 15 years ago, so in the 21st century, it seems like you can operate Linux without knowing what /var/yp is.

It's been too long.

That's it.