Linux: The Practical Administration That Actually Matters

Nearly everything runs on Linux — your web servers, your containers, your cloud instances, most of your suppliers' infrastructure. You do not need to be a kernel specialist. You do need to be able to log into a server that is misbehaving and work out why.

This guide covers that: the model that makes Linux make sense, and the handful of skills that resolve most real problems.

The model#

Everything is a file. Configuration, devices, running process information, even hardware. Learning this stops the filesystem feeling arbitrary.

Small tools, composed. Each command does one thing; you pipe them together. grep, sort, awk and wc are far more useful combined than individually.

Text configuration. Settings live in readable files under /etc. This is why Linux servers are easy to version-control, diff and automate — and why a change with no record is a problem.

Permissions on everything. Every file has an owner, a group and a permission set. Most access problems are permission problems.

Where things live#

If you know /etc and /var/log, you can solve most problems.

Permissions, properly#

Three groups of three: owner, group, everyone — each with read, write, execute.

-rw-r--r--   file: owner can read/write, everyone else reads
drwxr-x---   directory: owner full, group can enter and read, others nothing

The numeric form appears constantly: 644 for a normal file, 755 for a directory or program, 600 for anything secret.

Two rules that prevent most problems:

• chmod 777 is almost never the right answer. It usually means the owner or group is wrong. Fix that instead.
• Directories need execute (x) to be entered. A directory with 644 cannot be opened even though it looks readable — a common and confusing failure.

Services#

Modern Linux manages long-running programs with systemd.

systemctl status nginx      # is it running, and what did it last say?
systemctl restart nginx     # restart
systemctl enable nginx      # start automatically at boot
journalctl -u nginx -n 50   # its last 50 log lines
journalctl -u nginx -f      # follow live

systemctl status is the single most useful diagnostic command on a modern Linux server: it shows whether the service is running, when it last started, and its most recent output.

enable and start are different. A service that is started but not enabled disappears after a reboot — a classic three-months-later surprise.

Diagnosing the three common failures#

"The server is slow."

uptime          # load average - if it exceeds your CPU count, work is queueing
top             # what is consuming CPU and memory right now
free -h         # is memory exhausted? is it swapping?
df -h           # is a disk full?
iostat -x 2     # is the disk the bottleneck?

Check disk space first. A full disk produces symptoms that look like everything else, and it is the most common cause of a server behaving strangely.

"The disk is full."

df -h                              # which filesystem
du -sh /var/* 2>/dev/null | sort -h  # what is large
journalctl --disk-usage            # logs are a frequent culprit

Two traps: deleted files still held open by a running process do not free space until the process restarts (lsof | grep deleted finds them), and inode exhaustion produces "no space left" while df -h shows free space — check df -i.

"It cannot connect."

ss -tlnp                    # what is listening, on which port
curl -v http://localhost:80 # does it respond locally?
ping -c3 8.8.8.8            # network up?
dig example.com             # DNS resolving?

Work outward: is the service running, is it listening on the expected interface, does it respond locally, is the firewall allowing it, does DNS resolve.

Security defaults worth setting on day one#

• SSH keys only — disable password authentication
• Do not log in as root — use a normal account with sudo, so actions are attributable
• Change the SSH port if you like; it reduces log noise, not real risk
• A firewall allowing only what you need
• Automatic security updates, at minimum for security patches
• Fail2ban or equivalent to slow brute-force attempts
• Know what is listening: ss -tlnp regularly, and turn off what you do not need

Most compromised Linux servers were running an unnecessary exposed service, or allowed password authentication on SSH.

Scheduled jobs#

cron runs things on a schedule, and it has two failure modes that cost people days:

A different environment. Cron runs with a minimal PATH and none of your shell setup. A script that works when you run it can fail under cron. Use absolute paths.

Silent failure. Output goes to local mail nobody reads. Redirect it:

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Without 2>&1 you lose exactly the errors you need. And a job that writes an empty output file and exits zero looks identical to one that succeeded — check the content, not just that the file exists.

Logs#

/var/log for services that write files; journalctl for systemd services.

journalctl -u nginx --since "1 hour ago"
journalctl -p err -b            # errors since last boot
tail -f /var/log/nginx/error.log
grep -i "error\|fail" /var/log/syslog | tail -50

Set up rotation. Logs that grow unbounded are the second most common cause of a full disk.

FAQ#

Which distribution should we use?#

For servers, Ubuntu LTS or a Red Hat–family distribution. Both have long support windows and excellent documentation. Consistency across your estate matters far more than the choice itself.

Do I need to learn the command line?#

For running servers, yes. Graphical tools exist but every guide, every log and every incident response assumes a terminal. A dozen commands cover most day-to-day work.

What is the difference between sudo and root?#

Root is the all-powerful account. sudo lets a normal user run specific commands as root, with each use logged and attributable. Use sudo; do not log in as root.

How often should we patch?#

Security updates promptly — the window between disclosure and mass exploitation is now days. Enable unattended security upgrades, and schedule fuller updates on a regular cadence with a reboot plan.

Why does my script work manually but fail in cron?#

Almost always the environment: cron has a minimal PATH, no shell profile, and a different working directory. Use absolute paths for both commands and files, and log the output.

How do I find what is using disk space?#

df -h for filesystems, then du -sh /var/* | sort -h to drill down. Check journalctl --disk-usage and old log files first. If df shows space free but writes still fail, check inodes with df -i.

Is Linux more secure than Windows?#

Neither is inherently secure. Linux servers are typically more minimal, which reduces attack surface, and are usually configured by people who understand what they are running. Configuration determines the outcome far more than the operating system does.

What else is coming for Linux