Linux-Tutorial / Fehler reproduzieren und evidenzbasierte Wiederherstellung üben
Üben Sie die Wiederherstellung in einer isolierten Umgebung, indem Sie eine funktionierende Basislinie überprüfen, eine Störung einführen und den geänderten Zustand mithilfe von Beweisen wiederherstellen. Validieren Sie sowohl den Servicezustand als auch die für den Benutzer sichtbare Reaktion, bevor Sie die Wiederherstellung als abgeschlossen erklären.
Bereiten Sie VM-Snapshots und Konsolenwiederherstellung vor und vergleichen Sie die Beweise vor und nach jeder Änderung mithilfe von protokollbasierter Untersuchung.
Systemkonfigurationsübungen verwenden eine herkömmliche Ubuntu 26.04 LTS oder Rocky Linux 9 VM als Referenzumgebung. Container, WSL und andere Versionen können sich in Dienst- und Paketkonfiguration unterscheiden. Bereiten Sie die Konsolenwiederherstellung vor und zeichnen Sie Ihre Versionen mit der virtuellen Maschinen-Einrichtungslektion auf.
Definieren Sie das isolierte Labor und eine funktionierende Basislinie
Verwenden Sie ein Ubuntu- oder Rocky-Linux-Labor-VM mit einem systemd-Benutzermanager, Python 3 und curl. Diese Übung ändert weder Produktions-Nginx, SSH, Firewall noch Festplatten. Überprüfen Sie ss -lnt auf einen freien Loopback-Port 18080 und ändern Sie alle entsprechenden Laborwerte, falls dieser bereits verwendet wird.
Überprüfen Sie den tatsächlichen Python-Pfad mit command -v python3. Überschreiben Sie kein vorhandenes Unit- oder Lab-Verzeichnis mit diesen Namen. Der Python-Entwicklungs-HTTP-Server ist auf diese Loopback-Übung beschränkt und kein Produktions-Internetserver.
mkdir -p "$HOME/linux-recovery-lab/site" "$HOME/.config/systemd/user" printf "recovery baseline\n" > "$HOME/linux-recovery-lab/site/index.html" cat > "$HOME/.config/systemd/user/linux-course-recovery.service" <<'EOF' [Unit] Description=Isolated Linux recovery lab [Service] Type=simple WorkingDirectory=%h/linux-recovery-lab/site ExecStart=/usr/bin/python3 -m http.server 18080 --bind 127.0.0.1 EOF systemctl --user daemon-reload systemctl --user start linux-course-recovery.service systemctl --user is-active linux-course-recovery.service curl --fail --max-time 5 http://127.0.0.1:18080/ cp "$HOME/.config/systemd/user/linux-course-recovery.service" "$HOME/linux-recovery-lab/service.good"
Führen Sie einen Fehler nur ein, nachdem Sie die aktive und die erwartete Seite gesehen haben. Die funktionierende Einheit wurde gespeichert und der Dienst beim Start nicht aktiviert. Wenn die Basislinie fehlschlägt, beheben Sie den Python-Pfad, die Unit-Konfiguration oder Portkonflikte, bevor Sie fortfahren.
Experiment 1: Brechen Sie nur den ausführbaren Pfad
sed -i 's@ExecStart=/usr/bin/python3 @ExecStart=/nonexistent/course-python @' "$HOME/.config/systemd/user/linux-course-recovery.service" systemctl --user daemon-reload systemctl --user restart linux-course-recovery.service systemctl --user status linux-course-recovery.service --no-pager journalctl --user -u linux-course-recovery.service --since "5 minutes ago" --no-pager
Die Einheit verweist jetzt auf eine nicht existierende ausführbare Datei, sodass der Dienst nicht aktiv bleiben kann. Je nach Zeitpunkt kann der Startbefehl sofort fehlschlagen oder der nachfolgende Status einen Fehler aufzeigen. Die Protokolle sollten einen Ausführungsfehler identifizieren; systemd kann 203/EXEC melden. Zeichnen Sie die tatsächliche Meldung auf, anstatt jeden fehlgeschlagenen Dienst als Netzwerkproblem zu behandeln.
Konfiguration wiederherstellen und die Antwort überprüfen
cp "$HOME/linux-recovery-lab/service.good" "$HOME/.config/systemd/user/linux-course-recovery.service" systemctl --user daemon-reload systemctl --user reset-failed linux-course-recovery.service systemctl --user start linux-course-recovery.service systemctl --user is-active linux-course-recovery.service curl --fail --max-time 5 http://127.0.0.1:18080/
Die bekannte gute Datei wiederherstellen, den Manager neu laden und den Dienst starten. Reset-failed kann den Fehlerzustand und die Start-Limits zurücksetzen, repariert jedoch keine ungültige Konfiguration. Die Wiederherstellung ist erst dann abgeschlossen, wenn der Dienststatus und die erwartete Seite beide zurückkehren.
Experiment 2: Einen geschlossenen Port unterscheiden von einem HTTP-Fehler
curl -i --max-time 5 http://127.0.0.1:18080/missing-resource systemctl --user stop linux-course-recovery.service curl -i --connect-timeout 2 --max-time 5 http://127.0.0.1:18080/ ss -lnt systemctl --user start linux-course-recovery.service curl --fail --max-time 5 http://127.0.0.1:18080/
Die erste Anfrage erhält HTTP 404 von einem laufenden Server. Nach dem Stoppen des Dienstes schlägt die nächste Anfrage auf Verbindungsebene fehl, typischerweise mit Ablehnung, anstatt HTTP 404 zu erhalten. Vergleichen Sie das Verhalten von curl mit und ohne --fail, da eine gewöhnliche 404-Übertragung erfolgreich beendet werden kann. Dies unterscheidet Dienst-, Transport- und HTTP-Fehler, ohne eine Firewall zu ändern.
Ein Wiederherstellungsprotokoll für jeweils eine Änderung führen
| Protokoll | Beispielbeweis |
|---|---|
| Basislinie | Aktive Einheit, Listener, erwartete Seite |
| Änderung | Nur ExecStart oder Dienst stoppen |
| Beweise | Zeit, Exit-Status, Journal, HTTP, Socket |
| Wiederherstellung | Bekannte gute Konfiguration oder Dienst starten |
| Erneut testen | Gleiche URL, Port und erwarteter Inhalt |
| Prävention | Validierung vor der Bereitstellung und Zustandsprüfungen |
Füllen Sie die Systemfestplatte nicht, blockieren Sie nicht den Management-SSH-Zugang und löschen Sie keine zufälligen Dateien in dieser Übung. Störendere Tests erfordern einen separaten Klon, begrenzten Speicher, verifizierten Konsolenzugang und Backups. Das Ziel ist eine evidenzbasierte Diagnose und Wiederherstellung, nicht maximale Störung.
Stoppen Sie das Labor und entfernen Sie nur seine eigene Einheit.
systemctl --user stop linux-course-recovery.service systemctl --user reset-failed linux-course-recovery.service rm -- "$HOME/.config/systemd/user/linux-course-recovery.service" systemctl --user daemon-reload ss -lnt
Bestätigen Sie, dass der Loopback-Listener verschwunden ist. Überprüfen und entfernen Sie das Lab-Verzeichnis separat; es enthält die Basiskonfiguration und die statische Seite. In Umgebungen mit anderen Diensten sollten fehlgeschlagene Zustandsoperationen auf die relevante Einheit beschränkt werden, anstatt nicht zusammenhängende Benutzerfehler zu löschen.
