magnus919_agent-skills/remote-systems-administration/references/linux.md

# Linux Classification and Routing

“Linux” is a kernel family, not an operating model. Before a mutation, discover the distribution/release, init system, package manager, configuration owner, firewall implementation, and management layer. `/etc/os-release`, `ps -p 1`, and executable presence are observations, not authority to overwrite managed state.

## Classify before selecting a control plane

| Observed evidence | Route | Do not infer |
|---|---|---|
| `ID=debian` or `ubuntu`, or a Debian-derived system with `ID_LIKE=debian`; APT/dpkg | `linux-debian-ubuntu.md` | Ubuntu network ownership or release-upgrade procedure from APT/dpkg alone |
| `ID=rhel`, `fedora`, or compatible `ID_LIKE`; Yum/DNF/RPM | `linux-rhel-fedora.md` | Vendor support, DNF module semantics on a yum-only target, or a RHEL major-upgrade path for every derivative |
| `ID=sles`, `opensuse*`, or `ID_LIKE=suse`; zypper/RPM | `linux-suse.md` | That the root is transactional or read-only |
| `ID=arch` or Arch-derived; pacman | `linux-arch.md` | Repository/support policy or a safe partial upgrade |
| `ID=alpine`; apk/OpenRC | `linux-alpine.md` | That package/configuration changes persist across boot |
| Missing, contradictory, minimal, or unsupported derivative | retain this reference and vendor docs | Family, lifecycle, firewall owner, or mutation path |

Record `ID`, `ID_LIKE`, `VERSION_ID`, init PID, package manager, enabled repositories, firewall process/configuration, and file owner or configuration manager. Package transaction semantics, firewall ownership, release lifecycle, and reboot/rollback procedure follow that classification.

**Unsupported-derivative stop rule:** If `ID`/`ID_LIKE` does not identify a documented family, or the vendor changes its package, init, transactional-root, or network model, stop after read-only discovery. Obtain the vendor procedure and explicit authorization before a mutation.

**Derivative lifecycle stop rule:** `ID_LIKE` is a routing clue, not proof that every derivative follows Debian or Ubuntu release or lifecycle procedures. For a Debian-derived target, use the documented vendor procedure only after confirming it applies to the observed distribution and releases.

## Read-only family command routing

`ID` and `ID_LIKE` route this inspection only; they do not authorize a derivative's release procedure. Run the matching overlay preflight next.

| Observed family | Next overlay | Family-native read-only evidence |
|---|---|---|
| Debian/Ubuntu | `linux-debian-ubuntu.md` | `apt-cache policy <package>`; `apt-mark showhold`; `dpkg-query -W -f='${Status} ${Version}\n' <package>` |
| RHEL/Fedora | `linux-rhel-fedora.md` | DNF target: `dnf repolist`; `dnf history list`; `dnf module list --enabled`. Yum-only target: `yum repolist`; `yum history`; `yum info <package>` |
| SUSE/openSUSE | `linux-suse.md` | `zypper repos`; `zypper locks`; `zypper --no-refresh patches` |
| Arch | `linux-arch.md` | `pacman -Q <package>`; `pacman -Qu`; `pacman -Qdt` |
| Alpine | `linux-alpine.md` | `apk policy <package>`; `apk info -vv`; `cat /etc/apk/world` |

## Services and logs

Most contemporary distributions use systemd, but do not assume it. When systemd is active, use `systemctl` for unit state and `journalctl` for bounded journal evidence. A unit becoming `active` is only component-level evidence; verify the listener, dependent service, and external boundary separately.

Other Linux systems may use OpenRC, SysV-style scripts, runit, s6, or a distribution-specific control interface. Discover the active manager and load its authoritative documentation before lifecycle or boot-persistence changes.

| Question | systemd-oriented evidence |
|---|---|
| What is running? | `systemctl status <unit>` and a bounded `journalctl -u <unit>` range |
| Will it start at boot? | `systemctl is-enabled <unit>` |
| Did configuration parse? | service-specific validation before `reload` or `restart` |
| Did it serve traffic? | endpoint/socket check plus relevant client/dependent check |

Do not blindly restart a service because configuration changed. Validate the configuration first where the service provides a check, then use reload only when documented as safe; otherwise plan the restart, effect, and rollback. If a systemd unit file or drop-in changed, run `systemctl daemon-reload` before the lifecycle action so the manager rereads unit metadata.

## Packages and updates

Discover the native package manager. Common families include APT/dpkg, DNF/RPM, zypper/RPM, pacman, and apk. Package-manager commands, repository configuration, update semantics, and reboot requirements are distribution-specific.

Before upgrades:

1. classify the change: one package, security updates, all packages, kernel, distribution release, or third-party repository change;
2. inspect candidates/transaction plan and held/excluded packages;
3. identify service restart and reboot implications;
4. preserve rollback or recovery strategy appropriate to the package system, filesystem, and workload; and
5. stage or canary before a fleet rollout.

Do not claim that a package update is rollback-safe merely because the manager supports downgrade. Availability, dependency graphs, database migrations, and configuration changes determine actual reversibility.

## Cross-family failure signatures

| Signature | Likely boundary | Safe response |
|---|---|---|
| Package database lock or concurrent transaction | timer/automation or another operator | identify holder; do not delete a lock or start a competing transaction |
| Package manager succeeds but config does not take effect | conffile, generated configuration, or manager ownership | inspect conflict/generated files and active configuration |
| Firewall command exists but policy reverts | firewalld, nftables, cloud-init, or configuration management owns it | discover owner; do not layer a second control plane |
| Host returns after reboot but service is unavailable | kernel/base update, unit enablement, or dependency | verify boot, logs, listener, and external boundary |
| Update appears successful but reverts after boot | transactional or diskless root | classify persistence/snapshot mode before retrying |

Package manager discovery is not enough to choose a safe transaction. It must be paired with the distribution release, enabled repositories, package origin, held/excluded policy, and configuration-file behavior. A package transaction can leave a generated or conflict copy of an edited configuration rather than silently replacing it. Inspect and resolve that state deliberately before declaring a configuration change active.

- APT/dpkg, DNF/RPM, zypper/RPM, pacman, and apk have separate repository, solver, cache, and configuration semantics.
- Pacman tracks local package metadata and uses a separate sync operation for repository packages. Its removal and database bypass controls can have broad effects; do not turn off dependency/conflict checks to make a transaction proceed.
- Alpine `apk` can preserve proposed configuration as `.apk-new`; diskless/data-disk installations also require an explicit persistence step. Detect that deployment mode before treating a successful package command as durable across boot.
- A package manager's package name is not portable. `ansible.builtin.package` does not translate it between distributions.

## System configuration

Configuration files may be vendor-managed, package-conffiles, generated by cloud-init, NetworkManager, systemd-networkd, a configuration-management tool, or an application. Discover ownership before editing. Back up or version the existing state, make a minimal change, validate syntax, reload/restart only as required, and verify the active configuration rather than the file alone.

Changes to network configuration, DNS, SSH, sudo, PAM, routing, firewall state, mounts, kernel parameters, users, or storage are high-risk. Load `safety-and-verification.md` first and preserve access.

## Firewall routing

Linux firewall control planes include nftables and systems layered above it, such as firewalld or distribution tooling. Discover which system owns rules before changing anything. Do not mix direct nftables edits with a higher-level manager unless its documentation permits it, and never mechanically translate PF, iptables, or cloud firewall rules.

| Evidence | Decision |
|---|---|
| A firewall binary exists or `firewalld` is active | Ownership is still unknown. Inspect the managed configuration and sanctioned control path; do not select a tool from presence or service state alone, and do not use a trial rule or any other mutation to decide ownership. |
| firewalld is the confirmed policy owner | Use its documented interface; do not add direct nftables rules beside it. |
| Native nftables configuration is the confirmed policy owner | Use nftables only through that configuration's documented management path. |

For nftables, inspect the existing ruleset and ownership before edits. Policy changes can sever the live SSH session. Validate rule syntax where available, retain a recovery path, apply a bounded change, and verify both expected traffic and retained administrative access.

## Reboot and lifecycle

A reboot is a state transition with dependencies. Identify the reason, pending work, required services, users, maintenance window, recovery access, and post-boot validation before issuing it. Verify boot completion, expected units, networking, time synchronization where relevant, and the affected application boundary. A reachable SSH daemon alone is not complete recovery.