You inherit a Linux machine with no documentation or handover because the previous administrator is gone. Before changing anything, what commands would you run to identify the operating system, hardware, running services, network exposure, scheduled jobs, storage situation, containers, and clues from the previous administrator? My starting point is usually `ss -tulpn` and `systemctl list-units --type=service --state=running`, but the investigation quickly becomes less structured.
4 Answers
Do not start by shutting the machine down, wiping it, installing random tools, or booting from external media. First establish whether it is business-critical and take notes or a snapshot if the environment supports that. Keep the initial survey read-only, verify backups and access paths, then investigate services, storage, scheduled tasks, and application configuration in a controlled way.
For processes and network exposure, I’d use `ps -ef`, `systemctl --type=service --state=running`, `systemctl list-timers`, `ss -tulpn`, and `lsof -i -n -P`. `lsof` is useful because it can reveal outbound connections as well as listening ports. Also check `docker ps`, since important applications may be running in containers rather than under systemd.
Start with non-destructive inventory: `hostnamectl`, `cat /etc/*release`, `uname -a`, `uptime`, `who`, `lsblk`, and `df -hT`. That quickly tells you what the machine is, who may be using it, what disks are present, and whether a full filesystem is already causing problems.
The shell history is often the closest thing to documentation. Preserve it before doing anything else, then inspect root’s history and the history files for regular users. Check `crontab -l`, `/etc/crontab`, `/etc/cron.d`, and the per-user crontabs too; important maintenance jobs are frequently hidden in one of those places. Package-manager history, such as `dnf history` or the equivalent for the distribution, can also show what was recently installed or changed.
I’d copy the relevant history and configuration data somewhere safe first. It may contain useful clues, but it can also include credentials, so handle it as sensitive information.
Container workloads are easy to miss on older servers—especially when someone started them manually years ago—so I’d also check the container runtime’s configured restart policies and compose files.