Identifying an unknown Linux host before changing anything on it

Goal

Build an accurate picture of a Linux host — distribution, kernel, virtualization, init system, package manager, mandatory access control — before running any command that assumes one of them, all using read-only commands.

Prerequisites

A shell session on the target host; no special privileges are required for any step below except aa-status, which on many systems needs root to read the loaded profiles (sestatus works unprivileged).

Steps

1. Read the distribution identity: cat /etc/os-release. It defines machine-readable ID=, VERSION_ID= and a human-readable PRETTY_NAME=, standardized across distributions specifically so scripts do not have to guess from release-specific files.
2. Read the running kernel version: uname -r. Compare later against the newest installed kernel package to detect a pending-reboot mismatch.
3. Get a consolidated summary in one command on a systemd host: hostnamectl status (or bare hostnamectl on older versions), which prints the hostname and related system information gathered by systemd-hostnamed.
4. Detect virtualization or container execution: systemd-detect-virt prints the hypervisor or container technology name, or none; systemd-detect-virt --container and --vm narrow the check to one category and exit non-zero when that category does not apply. Cross-check with [ -f /.dockerenv ] or the contents of /proc/1/cgroup, since not every container runtime is recognized identically by every tool version.
5. Confirm the init system actually managing the host, rather than assuming systemd: readlink /proc/1/exe (or ps -p 1 -o comm=); on a systemd host this resolves to .../systemd.
6. Identify the package manager from the tools actually present, not the distribution name alone (some images strip package managers): check for dpkg, rpm, apk, or pacman with command -v.
7. Read the mandatory access control state: on an SELinux-enabled distribution, sestatus reports the SELinux status and current mode (enforcing, permissive, disabled); on an AppArmor-enabled distribution, aa-status reports whether the module is loaded and how many profiles are loaded, and in what mode.

Expected result

A short fact sheet — distribution and version, kernel version, virtualization/container status, init system, package manager, MAC framework and mode — collected without modifying the host.

Limits and test basis

Based on os-release(5), hostnamectl(1), systemd-detect-virt(1), sestatus(8) and aa-status(8). None of these steps require rollback since none write anything; a host with neither sestatus nor aa-status installed simply has no mandatory access control layer active beyond standard discretionary permissions, which is itself useful information.