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

Linux Overlay

Discover the Linux control planes

“Linux” is a kernel family, not one operating model. Before a mutation, discover the distribution/release, init system, package manager, configuration owner, firewall implementation, and whether a higher-level system such as a configuration manager owns the setting.

Useful indicators include /etc/os-release, ps -p 1, command -v systemctl, and package-manager discovery. Treat these as observations, not a permission to overwrite files managed by another system.

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.

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.

Package-manager families and configuration collisions

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.

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.