Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- start [2026/08/19 12:02] – created admin
+++ start [2026/09/18 15:11] (aktuell) – temp admin
@@ Zeile 1: / Zeile 1: @@
-Start
+====== plutex-status.de ======
-Hauptseite des Wiki's
+==== Statusseite-Scriptbased ====
+PLUTEX besitzt eine [[https://plutex-status.de/|Statusseite]]. Die Software dahinter ist besteht aus dem statischen Webseiten-Generator [[https://hugo.io/|HUGO]], der im Zusammenspiel mit dem Theme [[https://github.com/cstate/cstate|cState]] die Funktionalität der Status-Seite ausmacht.
+Die Domain ist bewusst ausserhalb des PLUTEX-Rechenzentrums gehostet.
+  * SSH-Zugriff: ''ssh statuspage@plutex-status.de''
+  * SSH-Zugriff von extern: ''ssh -p 2042 statuspage@plutex-status.de''
+  * HTTP-Zugriff: https://plutex-status.de/
+Das Arbeitsverzeichnis von HUGO befindet sich in ''/home/statuspage/hugo/''.
+Dort gibt es einen Ordner **Drafts**, der bereits ein paar Vorlagen im Markdown-Format (*.md) enthält, die folgenden Aufbau haben:
+<code markdown>
+---
+title: Ausfall der Zugangskontrolle im DC 5 / Bremen, Hermann-Ritter-Straße
+date: 2020-12-15 12:00:00
+resolved: false
+severity: down
+affected:
+  - Colocation-DC5
+section: issue
+---
+Durch einen technischen Defekt funktioniert unsere elektronische Zugangskontrolle im DC 5 momentan leider nicht.
+Falls Sie das Rechenzentrum betreten wollen, melden Sie sich bitte telefonisch bei uns im Büro.
+**Update (05.01.2021):**
+Durch Lieferschwierigkeiten bei den Ersatzteilen wird die Zugangskontrolle noch mindestens bis zum 08.01.2021 ausser Betrieb bleiben.
+**Update (07.01.2021):**
+Leider gibt es immer noch Lieferschwierigkeiten bei den Ersatzteilen. Die Zugangskontrolle wird noch bis zum 12.01.2021 ausser Betrieb bleiben.
+**Update (12.01.2021):**
+Die Zugangskontrolle ist wieder verfügbar.
+---
+</code>
+Eine Vorlage wird dabei stets in den Ordner ''/content/issues'' **kopiert** und der Dateiname bzgl. des Datums / Anlasses angepasst. Auf diese Weise wächst der Pool der Vorlagen mit jedem neuen Ereignis.
+<note important>''resolved:'' steht per default auf ''false''. Bei den meistens Incidents kann dies nur auf ''true'' gesetzt werden, wenn der Parameter ''resolvedWhen: yyyy-mm-dd hh:mm:ss'' auch gesetzt wird.</note>
+<note important>Die Namen der betroffenen Komponenten muss zwingend so angegeben werden, wie in HUGO's Konfiguration (''config.yml'') definiert (es mussten "eindeutige Namen" sein, z.B.: Netzwerk-DC1, Virtualisierung-DC5, Colocation-DC1, Access, Caching-DNS-Service-DC1, Hosted-Exchange-DC3 usw.).</note>
+Ist der Beitrag für die Veröffentlichung fertig, bringt man HUGO mit folgendem Befehl dazu, die Website neu zu generieren:
+  * ''./build.sh''
+Dieser Befehl legt erzeugt die statischen HTML-Dateien in einem Ordner mit dem aktuellen Zeitstempel unter ''/var/www/plutex-status.de/builds/'' und setzt anschließend den Symlink ''/var/www/plutex-status.de/public/'' auf diesen Ordner.
+Done!
+==== Statusseite-Webbased ====
+Die Statusseite hat nun auch eine Weboberfläche, die unter https://admin.plutex-status.de/ erreichbar ist. Dort kann man Incidents direkt über das Webinterface anlegen, bearbeiten und schließen. Anmelden muss man sich mit den Zugangsdaten aus dem pass.
+Neue Statusmeldungen werden als Markdown-Dateien gespeichert. Das erwartete Format enthält ein YAML-Frontmatter, z. B.:
+<code markdown>
+---
+title: Beispiel-Störung
+date: 2026-09-17 10:00:00 +0200 CEST
+informational: false
+section: issue
+resolved: False
+resolvedWhen: 2026-09-17 10:45:00 +0200 CEST
+severity: disrupted
+affected:
+  - Netzwerk-DC1
+  - Routing
+---
+Beschreibung der Störung.
+</code>
+Die Felder werden vom Formular in dieses Frontmatter umgewandelt und anschließend in die Datei im Ordner `content/issues/` geschrieben.
+Nutzung
+Bestehende Einträge bearbeiten
+. Ein vorhandener Eintrag im Auswahlmenü wählen.
+. Das Formular wird automatisch mit den gespeicherten Daten befüllt.
+. Änderungen vornehmen und absenden.
+Neue Statusmeldung anlegen
+. Formular ausfüllen
+. Titel, Beschreibung, Start-/Enddatum, Schweregrad und betroffene Komponenten eingeben
+. Absenden
+. Die Datei wird automatisch im Ordner `content/issues/` gespeichert
+. Der Build wird ausgeführt und die Seite aktualisiert
+Sowohl die bearbeitete als auch die neue Statusmeldung werden automatisch in den Ordner ''/content/issues'' geschrieben. Danach werden die Änderungen automatisch in die statische Website übernommen.
+==== Informationen ohne Incident posten ====
+Um nur eine **Information** ohne akuten Incident zu posten, setzen wir den Tag ''informational:'' auf ''true''. Dies bewirkt, dass sich der Status der betroffenen Komponenten nicht auf ''down'', ''disrupted'' oder ''notice'' ändert, wohl aber die Mitteilung selbst am Seitenanfang dargestellt wird. Der Monitoring-Check zeigt diese Issues mittlerweile nicht mehr als unresolved an.
+==== plutex-status_publish.sh ====
+Alternativ gibt es ein Skrip, das die nötigen Parameter (Titel, Datum, usw.) abfragt, diese in eine Markdown-File gießt, und die Webseite generiert. Beim Login als Benutzer ''statuspage'' wird danach gefragt, ob man mit diesem Script ein Incident anlegen möchte. Alternativ manuell ausführen:
+''~/hugo/plutex-status_publish.sh''
+==== SSL ====
+Benutzt ein Let's Encrypt-Zertifikat. Wird von einem Cronjob in ''/etc/cron.daily/dehydrated'' passend erneuert.
+==== CheckMK CState Status ====
+==== DNS ====
+Die DNS-Zone für plutex-status.de liegt auf dem p00.isp.plutex.de. Die 3 für die Domain eingetragenen Nameserver sind:
+ns3.plutex.de\\
+ns2.afraid.org\\
+ns1.he.net\\
+Die beiden externen Nameserver ziehen sich die Zone vom ns3.
+===== Probleme =====
+==== Statusmeldung wird nur unten in der Liste, aber nicht oben angezeigt ====
+Das ist der Fall, wenn die Option "resolved" gar nicht gesetzt ist. Wenn die Störung noch andauert sollte diese auf "false" stehen, an sonsten auf "true" (dann muss aber "resolvedWhen:" gesetzt sein).