Lfcs

<p align="center"> <img alt="lfcs-logo" src="https://training.linuxfoundation.org/wp-content/uploads/2018/01/logo_lfcs.png"/> </p>

This repository contains my personal notes that I take on during preparation for Linux Foundation Certified SysAdmin exam.

Table of contents

II. Filesystem layout
III. Processes
IV. Signals
V. Package managers
VII. dpkg
X. APT
XI. System monitoring
XII. Process monitoring
XIII. Memory monitoring
XIV. IO monitoring
XV. IO scheduling
XVI. Filesystems
XVII. Disk partitioning
XVIII. Filesystem features
XIX. Filesystem features
XX. ext filesystems
XXI. XFS and btrfs filesystems
XXII. Encrypting disks
XXIII. LVM
XXIV. RAID
XXV. Kernel services and configuration
XXVI. Kernel modules
XXVII. Devices and udev
XXVIII. Virtualization
XXIX. Containers
XXX. User account management
XXXI. Group management
XXXII. File permissions
XXXIII. PAM
XXXIV. Network addresses
XXXV. Network devs and configuration
XXXVI. Firewalls
XXXVII. System startup and shutdown
XXXVIII. GRUB
XXXIX. SysV, upstart and systemd

II. Filesystem layout

FHS

Initiative to standardise filesystem organization across different distributions

/bin

Essential binaries required when no other filesystems have yet been mounted. Also in single user mode or recover mode.

/sbin

System binaries for booting, recover or restore. Also capable of mounting /usr, /home etc.

/usr

A secondary hierarchy that is not needed for system booting. It contains multi-user applications. Package managers touch here. /usr/bin, /usr/lib, /usr/local, /usr/sbin, /usr/bin, /usr/share, /usr/src (kernel source)

/boot

Contains compressed kernel image, initrd, GRUB

/opt

Isolated installation directory (not scattered in multiple directories). Helpful for proprietary sw or packages downloaded without package managers

/proc

Pseudo-fs. Persists only in memory for processes to keep internal state. Each process has its place as a subdirectory

/root

Home of root user

/var

For variable data that changes frequently. Logs, spool directories (for mail and cron), transient data for cache (e.g. packages) , lock files (linked to /run/lock)

/run

Pseudo-fs. For transient data that contains runtime information as lock files

/media

Mount filesystems for removable media such as USBs

/run

A temporary place to mount filesystems such as NFS

III. Processes

orphan: A child process whose parent has terminated. Its PPID is set to 1 that is, it's adopted by init.

zombie: A child process terminates without its parent gets notified of this. A zombie releases its resources, however, it waits to notify its exit state to parent. It still has an entry in the process table.

wait is a system call that may be submitted by a process after forking a child process. Parent suspends execution and wait child process to complete and gets notified of its exit status. wait is skipped if child process is started in the background.

PID is 16 bit integer located in /proc/sys/kernel/pid_max and can be altered.

Limits

ulimit gets or sets the limits on resources to the shell and processes started by shell. That enables to restrict users to restrict system resources. On the other hand, it's also used to expand limits of some processes.

There is hard and soft limits where hard limit can only be set by root and it's the upper limit a soft limit can reach that is set by a user.max cpu time, max file locks, max open files, max threads, stack size, memory size, file size etc.

To see current limits

ulimit -a

To set stack size. This is not permanent, however, only current shell session is affected. To persist it, set it in /etc/security/limits.conf.

ulimit -s 4096

Too see max file numbers hard and soft limits

ulimit -H -s ulimit -S -s

Permissions

A process can inherit permissions from

• executor - the user who executes it
• executable - executable binary file, setuid bit set.

Execution modes

At any given time, a process is running in a certain execution mode.

• user mode us: when executing application code in user-space
• system mode sy: when executing system calls (kernel code) in kernel-space

fork and exec

$ ls

bash process forks itself and a new copy, i.e. child process is created. fork() returns child's PID to parent. bash process goes into sleep state with wait system call on its child. copy process makes exec system call and loads ls code in the child process space and executes it. when execution completed, child process terminates via exit system call and returns exit code to kernel. bash receives exit status either via polling or SIGCHLD signal handler from kernel, removes child's entry from process table (i.e. reaped) and it resumes execution.

state code | Description --- | --- D | uninterruptible sleep (usually IO) R | running or runnable (on run queue) S | interruptible sleep (waiting for an event to complete) T/t | stopped by job control signal (Ctrl+Z) / by debugger Z | defunct ("zombie") process, terminated but not reaped by its parent

Kernel processes

Kernel-created processes can run in

• kernel space for maintenance work
• user space - usually short lived

Kernel processes are created by kthreadd pid=2 and their names are in encapsulated brackets.

Process priority

nice executes a command with adjusted niceness. The lower the niceness, the higher is the process priority - between -20 and 19.

Execute ls with args and increase its default nice by +3 (priority decreased). Default niceness is 10 (priority decreased by 10)

nice -n +3 ls /proc

Only root can decrease niceness.

renice to prioritize an existing process

renice -n -5 2002

Libraries

1. static: An application compiled with a static library doesn't change thereafter even if static library is updated.

2. shared: Such libraries can be loaded into application at runtime - also called dynamic link libraries (DLL). I think it can be thought as an external dependency that is satisfied from the environment and not during application build time. Shared libraries have *.so extension.

To find shared libraries of a program depends

ldd /usr/bin/vim

IV. Signals

A way of communication with a process (basic IPC). It can originate from

• user: via kill command
• process: must be via system call through kernel
• kernel: e.g. a process makes an illegal memory reference

kill <pid> is the command to send signals to a process id.

Default kill action is to terminate given process gracefully. However, not all kill actions terminate.

kill 1234

To list signal types and values

kill -l

There are default handlers for every signal provided kernel. However, signal handlers can also be implemented in the application code to override default behavior. It's not allowed to handle SIGKILL and SIGSTOP.

Signal | Default action | Description --- | --- | --- SIGHUP | Terminate | convention: for daemons, it reloads configuration file. SIGINT | Terminate | interrupt from keyboard Ctrl-C SIGFPE | Core dump | sent from kernel to a process that attempts to divide by 0 SIGKILL | Terminate | abnormal termination (cannot be handled nor ignored) SIGTERM | Terminate | graceful termination (default in kill) SIGSTOP | Stop | Cannot be handled nor ignored SIGTSTP | Stop | Ctrl-Z SIGCONT | Continue | Resume SIGCHLD | Ignore | Child stopped/terminated SIGPIPE | Terminate | Broken pipe; socket closed

pkill and pgrep

To kill processes in batch mode by a criteria, use pkill <command>.

Kill all cat processes by user tom with a signal 15

pkill -15 -u tom cat

pgrep prints PIDs to stdout with the same options.

V. Package managers

In general, two families of package managers can be considered.

1. rpm: RedHat Package Manager
2. dpkg: Debian Package Manager

Packaging systems can be classified in two levels:

1. Low-level PMs deal with installation/removal only. They don't carry out dependency management. If a package is missing a dependency during installation, it will fail. Similarly, if a removal depends on some other package, it will also fail.

   • rpm in RedHat family
   • dpkg in Debian family

2. High-level PMs are based on the low-level ones. They handle dependency management, automatic dependency resolving and accesses external software repositories i.e. downloading/installing/removing of dependencies when needed.

   • yum (RHEL, CentOS), dnf (Fedora) and zypper (SUSE) in RedHat family
   • apt suite in Debian family

VII. dpkg

dpkg database is located at /var/lib/dpkg/. dpkg is not aware of any central repository. However, it keeps track what's been installed through apt or manual installations. Remember apt is based on dpkg.

Package namings:

Binary package name: `<name>_<version>-<revisio