Einführung
DAYMARK besitzt in dieser neuen Umgebung bereits ein sicheres Veröffentlichungsskript. Das Team benötigt nun einen echten Zeitplan unter einem eigenen Berichtskonto. Ein manueller Erfolg im Terminal beweist nicht, dass ein geplanter Job seine Eingabe finden oder lesen kann.
Du konfigurierst einen zusammengehörigen systemd-Service und Timer, beobachtest wiederholte echte Auslösungen und behebst Verzeichnis- und Eingabefehler, ohne den letzten Bericht zu verlieren. Daymark ist die Geschäftswebsite; Workstation startet in /srv/daymark-sales. Grundlegende Terminalkenntnisse reichen aus. Die Shell-Skript-Konzepte des vorherigen geführten Labs werden wiederverwendet. Rechner und Skript sind vorbereitet und brauchen keine Installation.
Den Export mit einem echten Timer ausführen
In diesem Schritt ermittelst du das korrekte Geschäftsergebnis und lässt systemd den Export zweimal ausführen. Beginne in Daymark. Öffne Records: Die anfängliche Quelle enthält 11 Artikel im Wert von 3450 Cent. Reports bietet noch den vorherigen Abschluss mit TOTAL,1,100. Der Job muss diese Datei durch den tatsächlichen Abschluss ersetzen.
Wechsle zu Workstation. Diese Umgebung ist unabhängig: Das richtige Skript ist vorbereitet, aber es ist kein Berichts-Timer installiert. cat zeigt Dateien und pwd dein aktuelles Verzeichnis an:
pwd
cat publish.sh
Das Skript schreibt neben das Ziel und benennt erst nach erfolgreicher Berechnung um. Es nimmt Eingabe- und Ausgabeargumente an. id zeigt die Kontoidentität, ls -ld den Eigentümer und die Zugriffsbits des Verzeichnisses. Ein Verzeichnis braucht Suchberechtigung zum Durchqueren und Schreibberechtigung zum Erstellen von Dateien.
id daymark-report
ls -ld reports
Das vorbereitete Systemkonto besitzt reports/. Leserechte an der Eingabe und Suchrechte an übergeordneten Verzeichnissen erlauben ihm, orders.csv zu lesen. Der Besitz des Berichtsverzeichnisses erlaubt die Veröffentlichung. Verwende weder root noch Schreibrechte für alle als Abkürzung.
systemd ist der Dienstmanager dieser Instanz. Eine .service-Datei beschreibt eine Ausführung; der gleichnamige .timer beschreibt, wann sie angefordert wird. Type=oneshot wartet auf das Ende dieses endlichen Jobs. User bestimmt das tatsächliche Ausführungskonto. WorkingDirectory wählt, wo das relative orders.csv aufgelöst wird. ExecStart verwendet absolute Pfade für Programm, Skript und Ausgabe. Das aktuelle Terminalverzeichnis und interaktive Shell-Einstellungen werden nicht an einen Systemdienst weitergegeben. Lass RemainAfterExit ungesetzt: Ein abgeschlossener Job muss inaktiv werden, damit das nächste Timer-Ereignis ihn erneut ausführen kann.
sudo tee FILE schreibt eine geschützte Datei und zeigt sie zugleich an. <<'UNIT' ist ein Here-Dokument in Anführungszeichen. Füge alles bis zum passenden Abschlusswort ein. Erstelle nur die benannten D10-Units:
sudo tee /etc/systemd/system/d10-sales.service <<'UNIT'
[Unit]
Description=Daymark sales export
[Service]
Type=oneshot
User=daymark-report
WorkingDirectory=/srv/daymark-sales
ExecStart=/bin/bash /srv/daymark-sales/publish.sh orders.csv /srv/daymark-sales/reports/sales.csv
UNIT
Dieser Übungs-Timer startet fünf Sekunden nach seiner Aktivierung und fordert zwanzig Sekunden nach der vorherigen Aktivierung einen weiteren Lauf an. AccuracySec=1s erlaubt ein kleines Zeitfenster; die Maschine kann weitere Verzögerung verursachen. Dies ist eine kurze Übung, kein täglicher Produktionszeitplan. Ein täglicher Uhrzeitplan könnte diese beiden relativen Direktiven durch OnCalendar=*-*-* 23:00:00 ersetzen, wobei die Serverzeitzone bewusst gewählt werden muss. Hier bleibt das kurze Intervall, damit echte Läufe beobachtbar sind.
sudo tee /etc/systemd/system/d10-sales.timer <<'UNIT'
[Unit]
Description=Daymark short training schedule
[Timer]
OnActiveSec=5s
OnUnitActiveSec=20s
AccuracySec=1s
[Install]
WantedBy=timers.target
UNIT
daemon-reload liest Unit-Definitionen neu ein. enable --now verbindet den Timer für künftige Systemstarts mit timers.target und startet ihn jetzt. Es startet den Timer und keinen manuellen Export:
sudo systemctl daemon-reload
sudo systemctl enable --now d10-sales.timer
sleep 50 wartet, ohne den Job auszuführen. Starte den Service nicht manuell und ersetze den Timer nicht durch eine Shell-Schleife.
sleep 50
list-timers zeigt tatsächliche LAST- und NEXT-Auslösungen. --no-pager gibt direkt aus, statt einen scrollbaren Betrachter zu öffnen:
systemctl list-timers d10-sales.timer --no-pager
Das Journal ist systemds echtes Ereignisprotokoll. -u wählt diese Unit, -n 20 begrenzt die Ausgabe. Sie sollte mindestens zwei vollständige Ausführungen mit uid=... cwd=/srv/daymark-sales, einem Berichtshash und erfolgreichem Abschluss enthalten:
sudo journalctl -u d10-sales.service -n 20 --no-pager
Vergleiche die numerische uid mit id daymark-report. Nach einem erfolgreichen oneshot ist inactive (dead) normal; ein aktiver Timer fordert künftige Ausführungen an. show -p wählt bestimmte Zustandseigenschaften:
systemctl show d10-sales.service -p User -p WorkingDirectory -p Result -p ExecMainStatus --no-pager
Erwartet werden User=daymark-report, das richtige Verzeichnis, Result=success und ExecMainStatus=0. Fehlt eine Auslösung, lies systemctl status d10-sales.timer --no-pager, korrigiere nur diese Unit-Dateien, führe erneut daemon-reload aus und starte nur d10-sales.timer neu. restart stoppt und startet diesen Timer, um Timer-Änderungen anzuwenden. Warte erneut und prüfe das Journal. Bei CHDIR prüfst du WorkingDirectory; bei Permission denied den Besitz von Eingabe und Berichtsverzeichnis, statt Rechte auszuweiten.
Kehre zu Daymark zurück, lade Reports neu und lade die neue CSV herunter. Ihre Summe lautet TOTAL,11,3450. Öffne Records erneut und kehre zur Startseite zurück; die normalen Geschäftsseiten bleiben verfügbar.
Beim nächsten geplanten Lauf wiederherstellen
In diesem Schritt beobachtest du echte geplante Fehler, behältst den vorherigen Bericht und veröffentlichst nach der Wiederherstellung einen neuen Abschluss. Beginne in Workstation. Bearbeite nur D10-Units und die Eingabe dieser Übung. Stoppe niemals unbeteiligte Dienste.
Erzeuge zuerst einen Fehler im Arbeitsverzeichnis. sed -i bearbeitet die benannte Datei direkt; s|old|new| ersetzt passenden Text. Dies ist ein absichtlicher Fehler:
sudo sed -i 's|WorkingDirectory=/srv/daymark-sales|WorkingDirectory=/tmp|' /etc/systemd/system/d10-sales.service
sudo systemctl daemon-reload
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
Der Prozess läuft weiter unter dem Berichtskonto, aber orders.csv wird in /tmp aufgelöst und scheitert mit Export failed: ... No such file .... Ein fehlendes Arbeitsverzeichnis selbst würde stattdessen vor dem Skriptstart CHDIR verursachen. daemon-reload aktualisiert Definitionen und führt den Job nicht aus. Der Timer verursachte diesen fehlgeschlagenen Versuch.
cat reports/sales.csv
Der Bericht muss weiterhin mit TOTAL,11,3450 enden. Lade in Daymark Reports neu und lade die Datei herunter, um die Nutzbarkeit derselben Bytes zu bestätigen. Kehre zu Workstation zurück und korrigiere das Verzeichnis:
sudo sed -i 's|WorkingDirectory=/tmp|WorkingDirectory=/srv/daymark-sales|' /etc/systemd/system/d10-sales.service
sudo systemctl daemon-reload
Erprobe nun einen Eingabefehler. cp kopiert einen vorbereiteten fehlerhaften Datensatz ausschließlich über orders.csv. Der Rechner muss einen Fehlerstatus zurückgeben und das Skript den letzten Bericht unverändert lassen:
cp fixtures/broken.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
Erwartet wird der absichtliche Fehler wegen einer ungültigen Zahl. show zeigt den tatsächlichen letzten Exit-Status unabhängig davon, ob der Journal-Anzeigebefehl erfolgreich war:
systemctl show d10-sales.service -p Result -p ExecMainStatus --no-pager
Erwartet werden Result=exit-code und ExecMainStatus=1. Bestätige, dass der vorherige Bericht erhalten bleibt:
cat reports/sales.csv
Stelle einen gültigen neuen Abschluss mit zwei zusätzlichen Tea wieder her. Beim nächsten Ereignis muss die Summe auf 13 Artikel und 3950 Cent aktualisiert werden:
cp fixtures/next.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
cat reports/sales.csv
Erwartet werden Tea,5,1250 und TOTAL,13,3950 sowie eine spätere echte Veröffentlichung im Journal. Bleibt der Bericht alt, lies den neuesten Fehler, korrigiere Verzeichnis, Eingabeschreibweise oder Skript und warte auf ein weiteres Timer-Ereignis. Ersetze die CSV nicht von Hand und starte den Service nicht manuell. Der fehlgeschlagene oneshot kann von diesem Timer erneut ausgeführt werden.
Lade in Daymark Records und Reports neu. Lade die Datei nochmals herunter und vergleiche die geänderte Quelle mit TOTAL,13,3950. Lass den Timer für die Bewertung aktiv. Diese Übung testet weder Neustartwiederherstellung noch Zeitzonenrichtlinien, Nebenläufigkeit zwischen Maschinen oder die Abrechnung ausgelassener Tage.
Zusammenfassung
Du hast die vollständige Veröffentlichung von CSV-Dateien, aussagekräftige Fehlerstatus und Wiederherstellung geübt. Ein geplanter Bericht ist nur nützlich, wenn tatsächliche Ausführungsidentität, Auslösung und Geschäftssummen zusammenpassen. Diese Übung auf einer Instanz verwendet erfundene Daten und einen kurzen Übungszeitplan; sie ist keine vollständige Berichtsplattform für den Produktivbetrieb.
