Chapter 1 — Orientation and the safe-change workflow

Know the host before you touch it

The first commands on any unfamiliar host establish identity, privilege, and service manager — all read-only:

# [READ-ONLY]
cat /etc/os-release     # distribution and release ([os-release(5)](https://man7.org/linux/man-pages/man5/os-release.5.html))
id                      # effective identity ([GNU Coreutils: id](https://www.gnu.org/software/coreutils/manual/coreutils.html#id-invocation))
pwd                     # working directory
ps -p 1 -o comm=        # PID 1: systemd, sysvinit, openrc, runit, ...
systemctl --version     # systemd availability and version ([systemctl(1)](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html))

Current mainstream installations of Ubuntu, Debian, Fedora, RHEL/AlmaLinux, and Arch run systemd, but systemctl is not valid on a non-systemd host, in a container/chroot without a manager, and SysV init, OpenRC, runit, and other managers use entirely different service and boot-enable models (systemctl(1); ArchWiki: systemd). Detect first, then use the manager's own commands. The same rule applies everywhere else: sudo is the elevation command across these families, but the administrative group differs (sudo on Ubuntu/Debian, wheel on Fedora/RHEL-derived systems) and local sudoers policy can differ (Ubuntu Server: User management; Sudoers manual); the package manager, firewall front end, and mandatory-access-control (MAC) system likewise split by family.

None of these rows is a guarantee for a given host — images, minimal installs, and enterprise baselines deviate. Inspect the host; do not infer policy from the distribution name (Debian Wiki: NetworkConfiguration; Ubuntu: Firewall).

The seven-step safe-change workflow

This sequence is the manual's template for every mutation, from a config-file edit to a remote firewall change. It is a synthesis of the documented constraints on the tools involved — read-only inventory, filesystem-checker constraints, firewall runtime/permanent separation, and the mutation risk of repair and restore operations (lsblk(8); e2fsck(8); firewall-cmd; restic restore).

1. Establish context. Host, shell, effective identity, target path, service manager, and whether the machine is production or remote (os-release(5)).
2. Inspect before modifying. Collect status, owners/modes/ACLs, unit definitions, logs, transaction previews, mounts, and current configuration. The installed man pages, --help, local release docs, and package-manager simulation are authoritative for the target host's actual version.
3. Bound the change. Use an exact path, package, unit, or user; avoid wildcards, recursion, and blanket auto-confirm. Back up the specific config/data with ownership and permissions preserved, or use configuration management (GNU Coreutils: cp).
4. Validate before activation. Service/app config checkers, visudo -c (visudo(8)), package dry-run/simulation, systemd-analyze verify UNIT [systemd], sh -n script / bash -n script (POSIX sh; systemd-analyze(1)).
5. Apply in a recoverable manner. One layer at a time; prefer reload over restart when supported; for any remote firewall/network/auth/control-plane change, keep an independent access path and a timed rollback before applying. Never rely on the session being changed as the only recovery channel (systemctl(1)).
6. Verify from the affected vantage. Service state, recent logs, effective user/group/ACL, listening socket, network path, and application behavior — proving both that the change worked and that unrelated paths still work (journalctl(1); ss(8)).
7. Record and preserve the rollback. What changed, why, when, expected impact, evidence of success, and the rollback command/path — with passwords, tokens, private keys, and customer data redacted from notes and terminal captures (Sudoers manual).

Order safeguards from least to most disruptive

For any change: read-only queries → dry-run/transaction preview → snapshot or config backup → maintenance-window/out-of-band plan → narrowly scoped change → independent verification (findmnt(8); restic restore; firewall-cmd). This is especially important when the change affects boot, storage metadata, access control, or network reachability.

The high-risk command taxonomy

The following operations are the ones this manual marks HIGH-RISK wherever they appear, because their own documentation describes data loss, lockout, or corruption: formatting and signature wiping (mkfs, wipefs) (cryptsetup(8)); LUKS format/erase/slot-removal/header-restore (cryptsetup(8)); LVM metadata and resize operations (pvcreate … lvreduce) (LVM2); RAID create/reshape/fail/force/zero-superblock (mdadm(8)); filesystem repair on mounted filesystems (e2fsck(8)); restore with deletion or in-place overwrite (restic restore); firewall default-policy and rule-order changes (firewall-cmd); recursive ownership/mode/ACL/label changes (Ubuntu AppArmor); package transactions that remove or replace packages (DNF5 upgrade); container host mounts and privileged mode (Docker Engine security); journal vacuuming (journalctl(1)); and destructive incident-response actions (NIST SP 800-61r3). Every one of these gets its warning before its command in the chapters that follow.

Lockout principle. For any remote control-plane change (SSH, firewall, network, storage that affects boot), the mandatory preflight is: an out-of-band recovery path confirmed working, current state recorded, a fresh tested login preserved, candidate syntax validated, and a timed rollback armed. A second SSH session over the same route is a useful check but is not out-of-band access. Chapter 4 applies this in full.