Linux-Grundlagen für Webserver

Für den Betrieb eines Webservers braucht es keine tiefe Linux-Kenntnis, aber eine verlässliche Routine. Die folgenden Kommandos decken den Grossteil des Alltags ab.

Die ersten zwanzig Minuten auf einem neuen Server

# 1. System aktualisieren
apt update && apt upgrade -y

# 2. Arbeitsbenutzer anlegen
adduser web
usermod -aG sudo web

# 3. SSH-Schlüssel vom eigenen Rechner übertragen
ssh-copy-id web@server.example.com

# 4. Passwort-Anmeldung und Root-Login abschalten
# /etc/ssh/sshd_config
#   PermitRootLogin no
#   PasswordAuthentication no
systemctl reload ssh

# 5. Firewall
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

# 6. Sicherheitsupdates automatisch
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Schritt 4 erst ausführen, wenn die Anmeldung per Schlüssel in einer zweiten, offenen Sitzung nachweislich funktioniert. Sonst sperrt man sich aus.

Dienste

systemctl status apache2       # Zustand und letzte Logzeilen
systemctl restart apache2      # neu starten
systemctl reload apache2       # Konfiguration neu lesen, Verbindungen halten
systemctl enable apache2       # beim Systemstart mitstarten
systemctl list-units --failed  # was ist nicht hochgekommen

reload statt restart, wo es möglich ist – bestehende Verbindungen bleiben erhalten. Und vor jedem Neustart die Syntaxprüfung:

apachectl configtest
nginx -t
postfix check

Ein restart mit fehlerhafter Konfiguration lässt den Dienst nicht wieder hochkommen. Ein reload scheitert, der alte Zustand läuft weiter.

Dateirechte

# Eigentümer: Anwendungsbenutzer, Gruppe: Webserver
chown -R web:www-data /var/www/example

# Verzeichnisse 755, Dateien 644
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;

# Nur wo der Webserver wirklich schreiben muss
chmod -R 775 /var/www/example/var/uploads

777 ist nie die Antwort. Es bedeutet, dass jeder Benutzer auf dem System die Datei ändern kann – auf einem geteilten Server sind das auch fremde Konten. Wenn ein Upload nicht funktioniert, lautet die richtige Frage: unter welchem Benutzer läuft PHP?

ps aux | grep -E 'php-fpm|apache2' | head -3

Störungsdiagnose in vier Schritten

Immer dieselbe Reihenfolge, dann findet man die Ursache schnell:

# 1. Läuft der Dienst überhaupt?
systemctl status apache2

# 2. Hört er auf dem erwarteten Port?
ss -tlnp | grep -E ':80|:443'

# 3. Kommt eine Anfrage an?
curl -sI http://127.0.0.1/ | head -3

# 4. Was steht im Log?
journalctl -u apache2 -n 50 --no-pager
tail -n 50 /var/log/apache2/error.log

Antwortet Schritt 3 lokal korrekt, aber von aussen nicht, liegt es an der Firewall oder am DNS – nicht am Webserver.

Ressourcen prüfen

df -h                          # Plattenplatz
du -sh /var/log/* | sort -rh | head    # wer belegt ihn
free -h                        # Arbeitsspeicher
uptime                         # Systemlast
top -o %CPU                    # was verbraucht gerade

Eine volle Platte ist die Ursache erstaunlich vieler Störungen, die zunächst nach etwas anderem aussehen: Die Datenbank nimmt keine Schreibvorgänge mehr an, Sessions lassen sich nicht anlegen, das Zertifikat kann nicht erneuert werden. Der häufigste Verursacher sind ungedrehte Logdateien.

# prüfen, ob logrotate greift
cat /etc/logrotate.d/apache2
logrotate -d /etc/logrotate.conf | head -40

Bei der Systemlast ist der Bezug wichtig: Ein Wert von 4,0 ist auf einem Server mit vier Kernen normal und auf einem mit einem Kern kritisch.

nproc    # Anzahl der Kerne

Was regelmässig anfällt

Der letzte Punkt braucht Vorlauf. Ein Betriebssystem ohne Sicherheitsaktualisierungen weiterzubetreiben ist keine Option, und der Wechsel auf eine neue Hauptversion will getestet sein – am besten auf einem parallel aufgesetzten Server, nicht als Aktualisierung im laufenden Betrieb.