What else a server administrator needs to know

The skill map

A site on a VPS works after lesson 5, and then stops being a project and starts being a machine you look after. The knowledge it asks for is not endless, but it has parts, and each part has a purpose. The table below is the whole map; the sections after it take the parts in the order a beginner meets them.

The command line

Everything on a server is a file or a process, and the shell is how you see both. You need perhaps thirty commands and three habits. The habits matter more: read the manual before the internet, print a path before you delete it, and change one thing at a time.

man 5 nginx.conf

The number in man 5 means the section: 1 is a command, 5 is a file format, 8 is system administration. A man page is faster and more exact than a random blog post, and it was written by the people who made the program. When you do not know the name of a command:

apropos "dns lookup"

dig (1) - DNS lookup utility host (1) - DNS lookup utility getent (1) - get entries from Name Service Switch libraries

Practice with real files, not toys. Find the three largest files in a folder, find a line in a log, count how often an error repeats:

du -h /var/log/* | sort -h | tail -n 3

grep -c " 500 " /var/log/nginx/access.log

Bash is the language of these commands. You do not need to write programs at first; a pipeline of two commands already solves most daily questions.

Users, permissions and sudo

Every process runs as a user, and every file says who may read, write and execute it. The three numbers in chmod are permissions for the owner, the group and everyone else, in that order: 4 is read, 2 is write, 1 is execute.

Learn id to see who you are, and ls -l to see who owns what. Never solve a permission problem with chmod 777: it gives write access to every user on the machine, including the one an attacker created. Give the group the access instead, and make the group right. sudo is configured in /etc/sudoers, which you edit only with visudo so that a syntax error cannot lock you out.

Services and systemd

On Ubuntu every long-running program is a systemd service with a unit file, usually in /lib/systemd/system/. Four systemctl commands answer almost every question:

systemctl status nginx

sudo systemctl restart nginx

sudo systemctl enable nginx

journalctl -u nginx --since "1 hour ago" --no-pager

status shows whether the service runs and the last lines it printed. restart stops and starts it; reload asks it to reread its configuration without dropping connections, and is what you want for Nginx and PHP-FPM. enable makes it start at boot; a service can run now and still be forgotten after a reboot without it. When you write your own unit file, copy an existing one and read every line; the two lines people forget are After=network.target and Restart=on-failure.

Packages

Install software from the distribution, not from a random archive. Ubuntu packages are signed, tested together and updated by the security team. The four commands to know:

apt search nginx

apt show nginx

sudo apt install nginx

dpkg -l | grep nginx

apt show prints the version, the size, the dependencies and the maintainer before you install. A program you compile yourself from source will not receive security updates, and in two years nobody will remember how it was built. When a site needs a newer version than the distribution ships, prefer the official repository of the project, and write down where it came from.

Updates are a habit, not an event: see Updates: patch day, not someday, and switch on automatic security updates as lesson 8 shows.

Networking

Four ideas explain almost every network problem: an address, a port, a route and a name. An address says which machine, a port says which service on that machine, a route says how packets get there, and a name is a convenience that is resolved into an address before anything happens.

ip -brief address

lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 203.0.113.10/24 2001:db8::10/64

ip route

default via 203.0.113.1 dev eth0 proto static 203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.10

The default route is the way out to the internet. Without it the server can talk to its own subnet and nowhere else, which looks exactly like a broken DNS. Then test the layers in order: the address answers, the port answers, the name resolves, the service answers.

ping -c 2 1.1.1.1

dig +short example.com

curl -I https://example.com

A firewall sits between the port and the network. On Ubuntu it is ufw in front of nftables; a closed port looks like a service that is down when you test it from outside and fine when you test it from the server. That difference is the clue: if localhost works and the internet does not, suspect the firewall or the provider network before the program.

Web servers and TLS

You already wrote a server block in lesson 5. The skill to build is reading one: every request follows listen, server_name, root, location and the handler. When a page returns the wrong thing, read those five in that order. nginx.conf: configuration and sites is the reference for the details.

TLS is a certificate, a private key and a chain of trust. Certbot makes all three for you, and the parts you must understand are the names it covers, the date it expires and the check that renewal still works. To look at what a server really sends:

openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -noout -subject -dates

subject=CN = example.com notBefore=Nov 6 09:00:00 2026 GMT notAfter=Feb 4 09:00:00 2027 GMT

The -servername option sends SNI, so you see the certificate of that name and not of the default site. If the two differ, the name is missing from the configuration.

Databases

A webmaster does not need to be a database administrator, but needs four things: create a database and a user, grant only what the site needs, take a consistent dump, and restore it into a test database. MariaDB is the reference for the commands; the habits are these:

• The database listens on localhost only, and the site connects over the local socket.
• Every site has its own database and its own user, never the root account.
• The dump is taken with mysqldump --single-transaction for InnoDB tables, so that a busy site does not produce a broken copy.
• A restore is tested into a separate database, not over the live one.

mysqldump --single-transaction -u example_user -p example_db > site-$(date +%F).sql

Backups and monitoring

Two questions decide whether you survive a bad day: how old is the newest copy, and did anyone ever restore it? The 3-2-1 rule answers the first: three copies, on two kinds of storage, one of them off the server. The restore test answers the second, and it is the part everybody skips. Backups that actually restore has the method; rsync, restic and borg are the tools.

Monitoring is the same idea for the present: a check that runs every minute from outside, and a few numbers from inside. Uptime, free disk, memory, the age of the newest backup, the days left on the certificate. An alert that reaches your phone is worth more than a beautiful dashboard nobody opens.

df -h /

Filesystem Size Used Avail Use% Mounted on /dev/vda1 39G 12G 25G 33% /

How to learn

The order matters less than the loop: read a little, do it on a machine, break it, fix it, write down what you learned. A server you are afraid to touch teaches nothing, so build one you are allowed to destroy.

• A virtual machine at home. VirtualBox or KVM on your computer, a cloud image of Ubuntu, a snapshot before every experiment. Cost: nothing. This is the best place to learn the first month.
• A cheap VPS. Once the commands work locally, rent the smallest server for a month. A real IP, a real firewall and a real certificate teach what a local machine cannot, including the moment you lock yourself out.
• Break and fix on purpose. Stop the web server, close a port, corrupt a configuration file, then repair it with the console. You will meet these failures at 2 a.m. anyway; meet them first on a machine with no visitors.
• The manual and the official documentation. man pages, the Nginx documentation, the Ubuntu Server Guide, the MariaDB knowledge base. Read the page for the exact version you run, not the newest one.
• Write it down. A file with the commands that worked, the ports you opened and the addresses you used. In a year it is your best reference, and it is the draft of your own runbook.
• Thirty minutes a day. Regular short sessions beat a weekend every two months, because the machine state stays in your head.

A learning order

1. Files, permissions, grep, find, less: two weeks of daily use.
2. Users, sudo, SSH keys: one week, and then never log in as root again.
3. systemd, packages, logs: one week, enough to install and diagnose a service.
4. Networking: addresses, routes, ports, DNS, the firewall. Two weeks, because this is where most confusion lives.
5. Nginx and PHP-FPM: one week, with your own site as the exercise.
6. TLS and certificates: two days, mostly learning to read what the server sends.
7. Databases: one week of create, grant, dump and restore.
8. Backups and monitoring: a weekend, with a real restore.
9. Bash scripts and cron: one week, automating the backup and the update check.
10. Git for configuration files: a weekend, and then every change has a history.

Ten weeks at half an hour a day is a realistic plan for a motivated beginner. The lessons in this course follow the same order, so the course itself is the first pass through the list.

Certifications

A certificate does not make you an administrator, but a good one gives a study plan with a deadline and a ticket past some hiring filters. Four are worth knowing:

LPIC-1 and Linux+ are vendor-neutral. LPIC-1 is multiple-choice and fill-in-the-blank questions; Linux+ mixes multiple-choice questions with performance-based tasks. RHCSA is tied to Red Hat and is respected because the whole exam is performed on a real system. Security+ is not a Linux certificate and will not teach you Nginx, but it is the usual first step into security work. None of them replaces a working site and a backup you have restored.

Where to go next

• Docker and containers. Package the site with its dependencies, and run the same image on a laptop and a server. The next logical step after a hand-built server.
• Ansible. Write the server setup as a playbook, so a new machine is configured the same way in ten minutes and the configuration is reviewed like code.
• CI/CD. Test, build and deploy from a pipeline instead of copying files by hand. The site changes only after the tests pass.
• Infrastructure as code. Terraform or OpenTofu describe the servers themselves, not only what runs on them. Create and destroy a whole environment with one command.
• Monitoring and SRE. Metrics, logs in one place, alerts that mean something, error budgets. The discipline of keeping a service reliable on purpose.
• Security. Application security, dependency scanning, penetration testing, incident response. Lesson 7 is the map of what can go wrong; this is the road to fixing it professionally.
• Cloud platforms. AWS, Google Cloud or a local equivalent: managed databases, object storage, load balancers, autoscaling. The same ideas at a larger scale and a different price model.

Quiz

Article author: Arthur Isaev