Web Server Administration Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A listener, a site, and a certificate you own

A web server answers on an address and a port, for a name, from a directory or by proxying to an application. Nginx, Apache, Caddy, IIS, OpenLiteSpeed, Lighttpd, and Traefik each have a pillar because the file format is not portable. This page is the decision those files have to satisfy. The converters in the migration guide move a config after the decision is already true on the old server.

The lab listener is 127.0.0.1. A public address is a later change, after the site works locally and the firewall allows only the ports you named. An admin console, a status page, or a WebAdmin port is not part of the public listener. If the product has one, it stays on loopback or on the management prefix.

TLS uses a certificate for a name you control. A lab does not need a public certificate. Use plain HTTP on loopback, or the product's local certificate, until DNS for that name points at this host and you intend to renew the certificate. Automatic public certificates are a production decision, not a side effect of installing the package.

Logs and the document root have owners and modes from the permissions guide. The worker user can read the site and cannot write it, except for an uploads directory you named. A reverse proxy and the application are two hosts or two ports in the ticket, so you know which log is which.

One name on loopback before any public address

Pick the server the organisation already runs, unless this ticket is the choice of a new one. Install it on the lab host. Add one site for a name you will only use locally, rooted at a directory of a single test page. Bind it to 127.0.0.1 and a port you choose, such as 8080. Fetch the page from the host itself. That fetch is the proof. A fetch from your laptop is a different proof you do not need yet.

Read the config test command for that server before you reload. Nginx has nginx -t. Apache has apachectl configtest. The others have their own, and the vendor pillars name them. A reload of a file that failed the test is how you take the lab down. If the test fails, you do not reload.

Add TLS only when you have a name and a reason. Until then the lab stays on loopback without a certificate. When you do add TLS, the certificate file and the key file have modes that keep the key unreadable to the world, and the key is not in the ticket.

The config generators for each server draft a site. Compare the draft's listen address to 127.0.0.1. If the draft listens on every address, change it for the lab. The generator does not open your firewall.

A change you can finish

The public change is a second window: the listen address, the firewall port, the DNS name, and a fetch from outside the host. Rollback is the previous listen address and the firewall close, which you write down while the lab still works.

A reverse proxy window names the upstream address and checks it is not the public internet. You proxy to an application you run.

Choose the server and say why it is this one and not the neighbour.
Bind the lab site to 127.0.0.1.
Pass the config test, then reload.
Fetch the test page from the host.
Confirm the admin port is not reachable except from loopback or the management prefix.
Set document-root modes so the worker can read and not write.
Leave public DNS and public certificates for the window that names them.

Mistakes that outlive the command

web server administration fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Listening on every address because the sample config did.
Publishing the admin port next to the site.
A public certificate attempt for a name that does not point here, or for a name you do not own.
Reloading a config that failed its test.
Pasting an Nginx server block into Apache, or the reverse, because both have the word server in them.
A document root the worker can write.
Proxying to an upstream you did not mean to publish.
Treating a converter's output as already reviewed.

Decisions to write down before the window

One decision for web server administration: The server software is named, and the matching pillar is the file format. The lab bind address is 127.0.0.1. Every-address listen is a later ticket. The config test passes before reload. The proof is a local fetch of the test page. Admin listeners stay off the public address. The key file, when TLS exists, is not world-readable and is not in the ticket. The worker user matches the permissions guide. A generator draft was edited until the bind address matched the ticket. Public DNS is unchanged in the lab window. Rollback is the previous config file, which you kept, and the reload command. And a second person read the listen directive.

Web server checks before a public listener exists

Confirm this before you call the change done: The process is the server you chose. The lab site binds to 127.0.0.1. The config test passed. A local fetch returned the test page. The admin port is not on a public address. The document root is not writable by the worker. No certificate request was sent for a name you do not control. The draft from the generator matches the file you reloaded. The previous config is saved. The firewall does not allow the lab port from the outside. Logs for this site do not contain a secret. A second person saw the listen address. The vendor pillar's reload command is the one you used. The hostname in the prompt matches the hostname in the ticket for web server administration. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for web server administration happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.