Sophos UTM – Postgres Rebuild

Manchmal passiert es einfach, nichts geht mehr.
So ist es mir mit einem Sophos UTM-Cluster ergangen auf dem sich die Postgres-Datenbank verabschiedet hat.
Merken tut man dies meist an zwei Phänomenen :
1. UTM startet plötzlich neu -> bei HA nicht ganz so schlimm
2. Anwender können keine Mails mehr verschicken\empfangen -> Der SMTP-Proxy funktioniert nicht mehr (Der Mail-Manager ist komplett leer)

Sollte euch so etwas widerfahren, halb so schlimm 🙂

Ich habe zuerst im Kernellog der UTMs geschaut ob evtl. ein defekt der HDD/SSD vorliegt und habe keinen Eintrag gefunden.

Dann weiter im „System Messages“ Log wurde ich fündig. Die folgenden Einträge sind ein Indiz für eine defekte Datenbank:
ulogd[9722]: pg1: connect: could not connect to server: No such file or directory
I/O error occurred while writing; fd=’94‘, error=’Broken pipe

Nun steht als fest: Datenbank defekt.
Cool finde ich das dies aber nicht für die gesamte Firewall zu gelten scheint, da andere Dienste einfach weiterlaufen. Bei mir war es ausschließlich der Mail-Dienst aka SMTP-Proxy der seinen Dienst verweigerte.

Also los und Datenbank erneuern…

Was vorher erwähnenswert ist, wäre das die Statistiken oder auch Konfiguration vom Wireless (sofern das noch jemand hat) weg sein sollen….bei mir fehlt nur ein Teil *grübel*

Um den Rebuild durchzuführen, besonders in einem HA Cluster hab ich dies mal zusammen geschrieben. Solltet ihr kein HA Cluster haben, dann die Befehle nur auf der einen Node ausführen.

1. Per SSH mit loginuser Master und Slave anmelden, für Slave SSH auf Master und dann „ha_utils ssh. WICHTIG: Vorher im WebAdmin den „ShellAccess“ aktiveren und ein Kennwort vergeben!

Auf beiden UTMs als loginuser anmelden und dann Dienste stoppen:

su –
/etc/init.d/ulogd stop
/etc/init.d/syslogng stop
kill repctl
killall repctl

Rebuild auf beiden Nodes ausführen (treten Fehlern auf (rote Schrift)ggf. ein zweites mal ausführen. Der Rebuild dauert nicht lange, ca. 30 Sekunden:

/etc/init.d/postgresql92 rebuild

Dann Dienste starten:

repctl
/etc/init.d/syslogng start
/etc/init.d/ulogd start

HA-Log prüfen oder via WebAdmin

cd /var/log
tail high-availability.log

Und schon läuft die UTM wieder wie geschmiert. Wie gesagt, da die Datenbank erneuert wird verliert man wohl Statistiken, konnte ich jetzt so nicht bestätigen, höchstens vom Tag des Rebuilds.