USER MANAGEMENT accounts, groups, passwords, quotas SOFTWARE installation, patching, dependency management FILE SYSTEM mounting, quotas, monitoring free space and INODES BACKUP & RECOVERY scheduling, verification, retention, restore drills SECURITY permissions, firewalls, auditing, vulnerability patching MONITORING CPU, memory, disk, network, logs, alerts PERFORMANCE TUNING identify the bottleneck, then fix THAT BOOT & SERVICES what starts at boot and in what order DOCUMENTATION the part everyone skips and later needs THE PRINCIPLE OF LEAST PRIVILEGE runs through all of it: every user, process and service should have exactly the permissions it needs and no more. Concretely: · do not run services as root — give each its own account · use `sudo` for specific commands rather than a root shell · use CAPABILITIES rather than setuid where possible (`ping` needs CAP_NET_RAW, not full root) · grant group membership rather than individual permissions, so access can be revoked in one place

USER IDENTITY: UID numeric user id; UID 0 is root, and root is defined BY the number, not the name — any account with UID 0 is root GID primary group id /etc/passwd username, uid, gid, home, shell (world readable) /etc/shadow the password HASH (root-readable only) /etc/group group memberships WHY THE SPLIT: /etc/passwd must be readable so that `ls -l` can map UIDs to names, but password hashes must not be, or they could be attacked offline. Hence shadow files. MEASURED ON THIS MACHINE: the earlier `ps` output showed PID 1 PPID 0 /sbin/launchd running as UID 0. Everything else descends from it, inheriting or dropping privilege. COMMON OPERATIONS: useradd / adduser create an account usermod -aG group user add to a supplementary group passwd user set a password chown user:group file change ownership chmod 640 file change permissions umask 022 default permission mask for new files THE UMASK IS SUBTRACTIVE and this is examined: new file default 666 (rw-rw-rw-) umask 022 result 644 (rw-r--r--) new directory 777 umask 022 result 755 (rwxr-xr-x) Files never get execute permission by default — only directories do, because x on a directory means traverse. DISK QUOTAS limit per-user consumption, in two dimensions: BLOCK quota how much space INODE quota how many FILES — needed because a user can exhaust the inode table without using space Each has a SOFT limit (warn, with a grace period) and a HARD limit (refuse).

BACKUP TYPES: FULL everything, every time ✔ simplest restore — one archive ✗ slowest, largest INCREMENTAL only what changed since the LAST backup of any kind ✔ fastest, smallest ✗ restore needs the full PLUS EVERY incremental in order — and one missing link breaks the chain DIFFERENTIAL only what changed since the last FULL backup ✔ restore needs only the full plus ONE differential ✗ grows steadily until the next full WORKED COMPARISON — full on Sunday, daily thereafter, 100 GB of data changing 5 GB per day: day INCREMENTAL DIFFERENTIAL Sun 100 GB (full) 100 GB (full) Mon 5 GB 5 GB Tue 5 GB 10 GB Wed 5 GB 15 GB Thu 5 GB 20 GB Fri 5 GB 25 GB Sat 5 GB 30 GB total 135 GB 205 GB restore on Saturday: incremental → 1 full + 6 increments = 7 archives, all required, in order differential → 1 full + 1 differential = 2 archives The trade is storage and backup time against restore complexity and risk. Incremental is cheaper to take and more fragile to restore. THE 3-2-1 RULE — the industry standard: 3 copies of the data 2 different media types 1 copy OFF-SITE The off-site copy is what survives fire, theft and ransomware. A backup on the same machine is not a backup; a backup on a network share the ransomware can also encrypt is not a backup either — hence the modern addition of an IMMUTABLE or air-gapped copy. THE TWO NUMBERS THAT DEFINE A BACKUP STRATEGY: RPO Recovery Point Objective — how much data you can afford to LOSE. Determined by backup FREQUENCY. RTO Recovery Time Objective — how long you can be DOWN. Determined by restore SPEED. Both are business decisions, not technical ones, and both must be set BEFORE the incident. A nightly backup means an RPO of up to 24 hours; if the business cannot accept that, the answer is continuous archiving (the WAL archiving of ACtE0704), not a faster nightly job. VERIFICATION — the step that is always skipped: · RESTORE from the backup, on a regular schedule, to a separate machine · verify checksums · confirm the restored system actually WORKS, not merely that files exist A backup job that reports success proves only that the job ran. RAID IS NOT A BACKUP. RAID protects against DISK FAILURE. It does not protect against deletion, corruption, ransomware or fire — all of which are faithfully mirrored to every disk instantly. This is the most common misconception in the topic.

THE ESSENTIAL COMMANDS, and what each tells you: CPU top, htop, uptime (load average), vmstat, mpstat MEMORY free, vm_stat, vmstat, /proc/meminfo DISK SPACE df -h (blocks) df -i (INODES — the failure `df -h` cannot show) du -sh (per-directory usage) DISK I/O iostat, iotop PROCESSES ps, pgrep, lsof NETWORK netstat, ss, tcpdump, ip LOGS journalctl (systemd), /var/log, dmesg (kernel) LOAD AVERAGE, which is routinely misread: the 1, 5 and 15-minute averages of runnable + uninterruptible processes. · on a 10-CORE machine (as measured here), a load of 10 means fully busy, not overloaded · load 4 on 1 core is a crisis; load 4 on 16 cores is idle · ALWAYS divide by the core count before interpreting · a high load with low CPU usage means processes blocked in uninterruptible I/O — a disk problem, not a CPU problem THE TUNING DISCIPLINE — measure, do not guess: 1. identify the BOTTLENECK (CPU? memory? disk? network?) 2. measure it, with a number 3. change ONE thing 4. measure again 5. keep it only if the number improved Changing several settings at once means you cannot attribute the result — which is how systems accumulate configuration nobody can justify. BOOT SEQUENCE: 1. FIRMWARE (BIOS/UEFI) — POST, find a boot device 2. BOOTLOADER (GRUB, systemd-boot) — load the kernel 3. KERNEL — initialise hardware, mount the root filesystem 4. INIT (PID 1) — start services SysV init sequential scripts, runlevels systemd parallel, dependency-based (Linux) launchd macOS — MEASURED: PID 1 on this machine 5. LOGIN systemd essentials: systemctl status/start/stop/enable <service> journalctl -u <service> -f systemd-analyze blame ← what is slowing the boot SECURITY HYGIENE, briefly: · patch promptly; most breaches exploit known, fixed bugs · SSH keys, not passwords; disable root SSH login · a firewall that DENIES by default · audit logs, kept somewhere the attacker cannot edit · least privilege, everywhere