Ubuntu 26.04 / Einen Server aufbauen und die Betriebsübergabe vorbereiten

Ein Serveraufbau ist abgeschlossen, wenn ein anderer Administrator darauf zugreifen, Änderungen vornehmen und ihn wiederherstellen kann. Dieses Abschlussprojekt verwendet eine dedizierte Ubuntu 26.04 LTS VM, installiert nur die erforderlichen Dienste und dokumentiert die gemessenen Zugriffs-, Neustart- und Wiederherstellungsergebnisse in einem Übergabedokument.

Umfang und Akzeptanzkriterien definieren

Das Basisprojekt stellt SSH-Administration und einen Nginx-Webdienst innerhalb eines LAN bereit. Bereiten Sie eine dedizierte VM, Konsole, Adressplan, zugelassene Verwaltungsklienten und einen unabhängigen Sicherungsort vor. Fügen Sie öffentliches HTTPS nur mit einer kontrollierten Domain und Validierungsroute hinzu; wählen Sie Samba oder Container, wenn erforderlich. Die Installation jedes einzelnen Dienstes ist nicht das Ziel.

In Abhängigkeitsreihenfolge mit kleinen Änderungen bauen

1. Ubuntu-Version, Geräte, Uhrzeit und Adressierung aus der Konsole aufzeichnen; Updates und erforderlichen Neustart durchführen.
2. Den tatsächlichen Netplan/NetworkManager-Bereich identifizieren und eine Konsole, Backup und Validierung für Adressänderungen verwenden.
3. Die Schlüsselauthentifizierung in einer neuen SSH-Sitzung überprüfen, bevor die Richtlinie verschärft wird; aktuelle Listener und Service-/Socket-Konfiguration prüfen.
4. Nur erforderliche Dienste installieren; sichern, validieren und Konfiguration anwenden. Tatsächliche Clients und Ports in UFW und externen Firewalls einschränken.
5. Bereiten Sie unabhängige Sicherungs-/Wiederherstellungsmaßnahmen und Fehlermeldungen vor; behalten Sie eine Basislinie vor dem Neustarttest bei.

Wenn eine Phase fehlschlägt, untersuchen Sie deren Differenzen und Protokolle, bevor Sie eine weitere Änderung hinzufügen. Gleichzeitige Änderungen an Port, Authentifizierung und Firewall verschleiern die Ursache des verlorenen Zugriffs und den korrekten Rollback. Überprüfen Sie, ob der Konsolen-Wiederherstellungsweg tatsächlich geöffnet werden kann.

Trennen Sie lokale Überprüfungen von den LAN-Diensten

Überprüfen Sie die 127.0.0.1:8080-Seite der Nginx-Lektion direkt auf dem Server. Das Abbilden von alpha.example.test auf 192.168.56.20 setzt seinen Loopback-Listener nicht frei. Verwenden Sie zuerst --resolve auf dem Server, um den Hostnamen und das Loopback-Ziel auszuwählen, und überprüfen Sie die alpha-Site. Das Container-Labor verwendet 8081; diese LAN-Übung verwendet 8082.

curl --fail --show-error --resolve alpha.example.test:8080:127.0.0.1 http://alpha.example.test:8080/

Für LAN-Überprüfungen bereiten Sie das Host-Only-Netzwerk der Lektionen 5/15 mit Server .20 und Linux-Client .10 vor. Fügen Sie die neue Seite unten auf der dedizierten VM hinzu, die das Document Root der Lektion 23 enthält. Passen Sie die verifizierten Adressen/Pfade konsequent an und prüfen Sie zuerst Portkonflikte. Vorhandene Dateien stoppen den Vorgang.

(
set -eu
site=/etc/nginx/sites-available/ubuntu-course-lan
enabled=/etc/nginx/sites-enabled/ubuntu-course-lan
sudo test -f /srv/ubuntu-course-alpha/index.html
if ! ip -4 -o address show | grep -Fq ' 192.168.56.20/24 '; then
    printf 'Configure the verified server lab address first.\n' >&2; exit 1
fi
for path in "$site" "$enabled"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Existing lab site: inspect before changing.\n' >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-lan.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<'EOF'
server {
    listen 192.168.56.20:8082;
    server_name course-lab.example.test;
    root /srv/ubuntu-course-alpha;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp
printf 'LAN site backup: %s\n' "$backup_dir"
)

Fügen Sie die folgende Regel mit der Standard-Eingang-Verweigerungspolitik der UFW-Lektion und dem erhaltenen SSH-Zugriff hinzu. Eine bereits bestehende umfassende Erlaubnis für 8082 wird den Ausschlusstest zunichtemachen, überprüfen Sie daher die tatsächlichen Regeln. Leiten Sie diesen nur für das Host-only-Netzwerk vorgesehenen Port nicht ins Internet weiter.

sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 8082 proto tcp
sudo ufw status numbered

Führen Sie curl unten von einem erlaubten Linux-Client .10 aus und überprüfen Sie die alpha-Seite. Eine neue Verbindung von einem ausgeschlossenen Client, wie Host .1, sollte durch die Richtlinie blockiert werden. Falls unbekannte Hostnamen abgelehnt werden müssen, entwerfen Sie einen separaten Standard-Virtual-Host für die Ablehnung; server_name ersetzt nicht die Filterung oder Authentifizierung.

curl --fail --show-error --connect-timeout 5 --max-time 10 --resolve course-lab.example.test:8082:192.168.56.20 http://course-lab.example.test:8082/

Zur Bereinigung identifizieren und entfernen Sie nur diese Site und ihre UFW-Regel, dann validieren und laden Sie Nginx neu. Behalten Sie die Loopback-Site und andere Dienste bei. Nach dem Neustart messen Sie die Adressen, tatsächlichen Listener und erlaubten/ausgeschlossenen Verbindungen erneut.

Erstellen Sie eine kleine HTTP-Zustandsprüfung

Speichern Sie das vollständige Skript unten als ~/check-web-lab.sh. Es benötigt Bash/curl und nimmt die tatsächliche URL und den erwarteten Text entgegen. Für die lokale Überprüfung in Lektion 23, ordnen Sie alpha.example.test auf 127.0.0.1 in der /etc/hosts des Servers selbst zu, und führen Sie dann bash ~/check-web-lab.sh http://alpha.example.test:8080/ alpha-site aus. Das frühere --resolve betrifft nur einen curl-Aufruf, nicht die Namensauflösung dieses Skripts.

set -eu
if [ "$#" -ne 2 ]; then
    printf "Usage: bash check-web-lab.sh URL EXPECTED_TEXT\n" >&2
    exit 2
fi
url=$1
expected=$2
case "$url" in
    http://*|https://*) ;;
    *) printf "Use an HTTP or HTTPS URL.\n" >&2; exit 2 ;;
esac
if [ -z "$expected" ]; then
    printf "Expected text must not be empty.\n" >&2
    exit 2
fi
body_file=$(mktemp)
trap 'rm -f -- "$body_file"' EXIT
if ! curl --fail --silent --show-error --connect-timeout 5 --max-time 10 "$url" -o "$body_file"; then
    printf "FAIL: request or TLS verification failed\n" >&2
    exit 1
fi
if ! grep -Fq -- "$expected" "$body_file"; then
    printf "FAIL: expected text missing\n" >&2
    exit 1
fi
printf "PASS: %s %s\n" "$(date -u +%FT%TZ)" "$url"

Erfolg gibt den Exit-Code 0 und PASS zurück; bei Anforderungs-, TLS- oder Inhaltsfehlern wird 1 zurückgegeben, und ungültige Argumente führen zu 2. Testen Sie absichtlich eine fehlende erwartete Zeichenkette, um die Fehlererkennung zu überprüfen. Eine HTTP-Prüfung ersetzt keine Datenbank-Schreib-, Login- oder Sicherungsprüfungen. Halten Sie Anmeldeinformationen außer der URL und organisieren Sie getrennt die Erfassung von Ausführungszeiten und Exit-Status.

Für den LAN-Zustandsprüfung, ordnen Sie course-lab.example.test auf 192.168.56.20 in der /etc/hosts von Client .10 oder im kontrollierten DNS, zu und führen Sie dann bash ~/check-web-lab.sh http://course-lab.example.test:8082/ alpha-site aus. Sichern Sie die hosts-Datei vor der Bearbeitung und vermeiden Sie doppelte Namenseinträge. Unterscheiden Sie lokale, LAN- und öffentliche HTTPS-URLs sowie erwartete Ablehnungen von Dienstfehlern.

Erlaubte und abgelehnte Verbindungen, Neustart und Wiederherstellung protokollieren

Testen Sie von tatsächlich erlaubten und ausgeschlossenen Clients sowie vom Server selbst. Behalten Sie die bestehende SSH-Verbindung bei, während eine neue geöffnet wird, planen Sie dann einen Neustart und überprüfen Sie ihn. Stellen Sie Backups in einem separaten leeren Verzeichnis wieder her und prüfen Sie Inhalt, Berechtigungen und anwendungsspezifisches Verhalten. Lassen Sie nicht durchgeführte Prüfungen ausstehend.

Verwenden Sie Ubuntus Firewall-Leitfaden zusammen mit Aufzeichnungen der tatsächlichen Regeln und Verbindungstests.

Füllen Sie die Übergabe mit gemessenen Werten aus

Verwenden Sie diese Vorlage als Ausgangspunkt für ein Betriebsprotokoll. Ersetzen Sie die Klammern durch beobachtete Werte und verweisen Sie auf einen genehmigten geheimen Speicher anstelle des Kopierens von Geheimnissen. Weisen Sie Eigentum und Wiederherstellungsverantwortung zu; geben Sie keine Beispieladressen oder angenommene Erfolge als Messwerte an.

System: [Hostname, Zweck, verantwortliche Person]
Plattform: [Ubuntu-Version, Kernel, VM-Host, Konsolenzugang]
Netzwerk: [Schnittstelle, Renderer, Adresse, Gateway, DNS]
Zugang: [erlaubte Clients, tatsächlicher SSH-Listener, Aufbewahrungsort der Schlüssel]
Dienste: [Versionen, Konfigurationspfade, Befehle für Prüfung und Neuladen]
Erreichbarkeit: [Listener, UFW-Regeln, externe Firewall, Container-Bindungen]
TLS: [Hostnamen, Erneuerungsmechanismus, Ablauf- und Fehlerüberwachung]
Backup: [Umfang, Identität des unabhängigen Ziels, Aufbewahrung, Schlüsselverwaltung]
Wiederherstellungstest: [Zeit, Ziel, Ergebnisse für Inhalt, Berechtigungen und Anwendung]
Abnahme: [Test, Client, erwartetes/tatsächliches Ergebnis, Ablage der Nachweise]
Rollback: [Änderungsumfang, gesicherter Ausgangszustand, Wiederherstellungsverfahren]
Ausstehend: [nicht durchgeführte Prüfungen, offene Risiken, Verantwortliche, Zieldatum]

Bewahren Sie Überprüfungsnachweise zusammen mit dem Änderungsverlauf auf und fragen Sie, ob ein anderer Administrator Zugriff, Inspektion und Wiederherstellung allein anhand des Datensatzes vorbereiten kann. Benannte Benachrichtigungsempfänger, Überprüfungsintervalle für Updates/Zertifikate/Sicherungen und Verantwortliche für ausstehende Arbeiten machen den fortgesetzten Betrieb unabhängig vom Gedächtnis des ursprünglichen Erstellers.