OPNsense: apcupsd und NUT parallel betreiben

und Linux, Synology, QNAP und Windows-Geräte kontrolliert herunterfahren

Nicht nur aus technischen Gründen kann es sinnvoll sein, auf der Firewall OPNsense parallel die beiden Dienste apcupsd und NUT (Network UPS Tools) zu betreiben.

Beispielsweise funktionieren die NAS-Systeme von QNAP und Synology ausschließlich mit NUT, für die GUI von OPNsense jedoch gibt es nur für apcupsd eine ordentliche Dashboard-Visualisierung:

Das Plugin von apcupsd für das OPNsense-Dashboard

Auch lässt sich apcupsd über die GUI einfacher konfigurieren und es gibt mehr feingranulare Einstellungen als bei NUT. Es ist also kein Schaden, wenn man mit wenig Aufwand beides bereitstellen kann.

Bei der Einrichtung gibt es allerdings ein paar Dinge zu beachten, worauf ich im Folgenden genauer eingehe.

* * *

Inhaltsverzeichnis

Voraussetzungen
Konfiguration von apcupsd
Konfiguration von NUT
  Dienstkonfiguration
  Das leidige Thema USV-Name und Zugangsdaten
    Synology
    QNAP
    USV-Name bei QNAP von qnapups auf ups ändern
  Details zum Timeout des NUT-Daemons bei OPNsense
Wenn alles geklappt hat...
NUT-Server emulieren

Ich möchte apcupsd und NUT parallel betreiben, habe dabei aber Schwierigkeiten
Quellen und weiterführende Links

* * *

Voraussetzungen

Ich gehe davon aus, dass du bereits beide Plugins in OPNsense über die Erweiterungen nachinstalliert hast. Die Pakete dafür heißen os-apcupsd und os-nut. Auch sollte die USV bereits per USB angeschlossen oder im Netzwerk eingebunden sein.

* * *

Konfiguration von apcupsd

Wir beginnen mit apcupsd, welcher als Master direkt mit der USV kommuniziert. NUT hängt sich dann als "netclient" an den apcupsd-Daemon dran und stellt wiederum einen eigenen Server bereit. Beide agieren also theoretisch unabhängig, da sie jeweils einen eigenen Server bereitstellen. Beim Beenden von apcupsd wird allerdings auch NUT nicht mehr funktionieren.

In meinem Fall ist die USV per USB an die Firewall angeschlossen. Es geht aber auch über alle anderen verfügbaren Wege wie bspw. übers Netzwerk oder über SNMP. Wichtig ist nur, dass apcupsd zuerst konfiguriert wird.

Hier findest du ein Schaubild der gesamten Konfiguration:

Meine OPNsense-Konfiguration für apcupsd sieht wie folgt aus:

Der Einstellungs-Dialog von apcupsd bei OPNsense

Anschließend sollte die Statusausgabe reale Werte zurückgeben, andernfalls prüfe bitte deine Konfiguration:

Die Status-Ausgabe von apcupsd bei OPNsense
* * *

Konfiguration von NUT

Nun folgt die Konfiguration von NUT.

WICHTIG!
Den Haken bei "Aktiviere Nut" erst setzen, wenn du alle Einstellungen gemacht hast. Solltest du in der Zwischenzeit auf "Diagnose" klicken und der Daemon in ein Timeout laufen, wird deine Weboberfläche von OPNsense für ca. 20 Minuten hängen bleiben. Das ist ein bekannter Bug, der nicht gefixt wird bzw. werden kann.

Sollte das Problem bei dir auftreten, hast du zwei Möglichkeiten:

  1. Die Firewall per CLI neustarten
  2. Abwarten. In der Regel funktioniert der Zugriff auf die OPNsense-WebGUI nach ca. 20 Minuten wieder.

Während dieser Zeit funktioniert nur die Weboberfläche nicht, die restlichen Firewall-Dienste sind davon nicht betroffen.

Weitere Informationen dazu findest du unter "Details zum Timeout des NUT-Daemons bei OPNsense".

Dienstkonfiguration

In der NUT-Konfiguration setzen wir den den Dienstmodus auf "Eigenständig", da wir ja einen eigenständigen NUT-Server erstellen wollen. Wenn du hier "Netclient" auswählst, werden bspw. in der Datei /usr/local/etc/nut/upsd.users keine Zugangsdaten hinterlegt und es kann sich niemand mit dem Server verbinden.

Beim Namen kommt es nun darauf an, ob du QNAP oder Synology-Systeme einsetzt. Denn beide Systeme setzen unterschiedliche Standardwerte ein, die allesamt hardcoded sind 🤦‍♂️ und sich auch per SSH nur mühsam ändern lassen. Siehe dazu "Das leidige Thema USV-Name und Zugangsdaten".

Wichtig ist außerdem, dass du die IP-Adresse deiner Firewall UND die Adresse 127.0.0.1 (für localhost) setzt. Andernfalls wirst du beim Aufruf des Punktes "Diagnose" in ein Timeout laufen und die Weboberfläche wird sich für ca. 20 Minuten aufhängen (siehe Kasten "Wichtig" oben).

Die finale Konfiguration sieht dann (z.B. für QNAP) wie folgt aus:

Dialog der NUT-Konfiguration

Öffne nun die Konteneinstellungen und passe die Werte darin entsprechend an:
(siehe Das leidige Thema USV-Name und Zugangsdaten)

Die Konfiguration der Zugangsdaten bei NUT

Wähle nun beim Treiber "APCUPSD-Driver", welcher apcupsd-ups entspricht:

Die Treiberauswahl bei NUT

Konfiguriere diesen so, dass er direkt auf die IP zeigt, die du für apcupsd festgelegt hast und aktiviere ihn:

Die Konfiguration des USV-Typs bei NUT

Jetzt ist es an der Zeit, in der Dienstkonfiguration den Haken bei "Aktiviere Nut" zu setzen. Klicke auf "Diagnose", nachdem du auf "Anwenden" geklickt hast. Wenn alles geklappt hat, bekommst du nun auch hier reale Daten angezeigt, hat sich hingegen die Oberfläche aufgehängt, ist vmtl. der oben beschrieben Timeout aufgetreten:

Die Statusausgabe von NUT

Geschafft🥳

Jetzt kannst du deine Linux-, Windows- und NAS-Clients entsprechend konfigurieren, dass sie auf einen der beiden Server zugreifen und bei einem Stromausfall kontrolliert herunterfahren. Denk daran, ggf. noch Firewall-Regeln für die beiden Dienste zu hinterlegen, damit sich die Clients auch verbinden dürfen.

Unter "Wenn alles geklappt hat..." findest du noch ein paar Screenshots der unterschiedlichen Systeme und ihrer Konfiguration.

* * *

Das leidige Thema USV-Name und Zugangsdaten

Synology

Für Synology lautet der hardcoded USV-Name ups, wie er auch standardmäßig bei NUT im Plugin hinterlegt ist.

Alle Standardwerte sind:
upsname: ups
username: monuser
password: secret

Zu finden sind diese Werte auch per SSH unter /etc/ups/upsmon.conf:

MONITOR ups@192.168.0.1 1 monuser secret slave

Noch ein paar nützliche USV-Befehle für die Synology-Kommandozeile:

USV-Dienst steuern:

/usr/syno/lib/systemd/scripts/ups-net.sh restart
upsmon -c reload

Bash-Tool von Synology, welches die Daten für die Weboberfläche aufbereitet:

/usr/syno/bin/synoups

Dieses Status-Tool ist eine Eigenentwicklung von Synology, welches ebenfalls den hardcoded USV-Namen ups enthält.

QNAP

Für QNAP lautet der hardcoded USV-Name qnapups

Alle Standardwerte sind:
upsname: qnapups
username: admin
password: 123456

Zu finden sind diese Werte auch per SSH unter /etc/config/ups/upsmon.conf:

MONITOR ups@192.168.0.1:3493 1 admin 123456 slave

Noch ein paar nützliche USV-Befehle für die QNAP-Kommandozeile:

USV-Dienst steuern:

/etc/init.d/usb_ups.sh {start|stop|restart}
/etc/init.d/ups.sh restart
/usr/local/sbin/upsutil
/usr/local/ups/sbin/upsc
upsmon -c reload

Alle Werte können jeweils per SSH geändert werden (QNAP: /etc/config/ups/*, Synology: /etc/ups/* mit anschließendem Dienste-Neustart), werden dann aber durch ein Update ggf. wieder überschrieben oder erst übernommen, wenn die hersteller-eigenen Konfigurationstools ebenfalls angepasst wurden.

Falls du beide NAS-Systeme parallel einsetzt, kommst du nicht drum herum, die Werte auf einem der beiden Systeme anzupassen. Ich empfehle es auf dem zu tun, welches seltener Updates bekommt 😉

* * *

USV-Name bei QNAP von qnapups auf ups ändern

Und weil es mir so viel Spaß gemacht hat, beim Schreiben des Artikels diese dämlichen Scripte mit ihren hardcoded Werten zu überlisten, habe ich eine sehr einfache Methode gefunden, bei einem QNAP-System den USV-Namen anzupassen.

QNAP nutzt das closed-source Binary unter

/usr/local/sbin/upsutil

um die Details der USV abzufragen – unter anderem auch für die Weboberfläche. Darin sind auch die folgenden zwei Zeilen mit dem hardcoded qnapups enthalten:

/sbin/upsc qnapups@%s "%s" 2>/dev/null^@^@r^@^@^@/sbin/upsc qnapups@localhost "%s" 2>/dev/null

Weil sich dieses Binary nicht "einfach so" per Texteditor ändern lässt, musste eine einfachere Lösung her.

Da das Script im Hintergrund einfach nur das normale NUT-Binary unter

/usr/local/ups/sbin/upsc

aufruft, habe ich es kurzerhand durch folgendes Wrapper-Script mit dem Namen upsc.sh ersetzt:

#!/bin/bash
SUBSTITUTE=${1//qnapups/ups}
/usr/local/ups/sbin/upsc.org $SUBSTITUTE $2

Das Script unter /usr/local/ups/sbin/upsc.sh speichern, ausführbar machen, anschließend das bestehende Script einmal backuppen, das Original entfernen und einen Symlink auf das Wrapper-Script setzen:

cd /usr/local/ups/sbin
vi upsc.sh
chmod +x upsc.sh
cp upsc upsc.org
ln -s upsc.sh upsc

Voila – direkt daraufhin meldet sich die USV in der Weboberfläche als ONLINE.

Hinterlasse gerne einen kurzen Kommentar, wenn dir diese simple Lösung geholfen hat. Ggf. muss der Speicherort des Scripts noch angepasst werden, da diese Einstellung nach einem Neustart vmtl. NICHT bestehen bleibt.

* * *

Details zum Timeout des NUT-Daemons bei OPNsense

Wie oben bereits beschrieben tritt bei einer Fehlkonfiguration des NUT-Plugins auf OPNsense ein Timeout auf, welches die gesamte Weboberfläche unbedienbar macht.

Während des Timeouts tauchen im Log regelmäßig folgende Fehlermeldungen auf:

Log: Allgemein:

Error   upsmon  UPS [ups]: connect failed: Connection failure: Operation timed out
Notice  upsmon  UPS ups is unavailable
Error   upsmon  UPS [ups]: connect failed: Connection failure: Operation timed out
Error   upsmon  UPS [ups]: connect failed: Connection failure: Operation timed out
Notice  upsmon  UPS ups is unavailable
Error   upsmon  UPS [ups]: connect failed: Connection failure: Operation timed out
Error   upsmon  UPS [ups]: connect failed: Connection failure: Operation timed out
Notice  upsmon  UPS ups is unavailable
Error   upsmon  UPS [ups]: connect failed: Connection failure: Operation timed out

Log: Weboberfläche:

Notice  configd.py  [e7b6d463-5565-4588-b994-d565f8d5af04] retrieve ups status
Error   configd.py  [d61b8f73-eff4-4446-a891-6372981f6bee] Script action failed with Command '/usr/local/bin/upsc 'ups@127.0.0.1'' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 482, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/usr/local/bin/upsc 'ups@127.0.0.1'' returned non-zero exit status 1.

Per SSH:

Broadcast Message from root@OPNsense.local.domain.de                        
        (no tty) at 17:05 CEST...                                              

UPS ups is unavailable

Ursache ist nach meinen Experimenten, dass der NUT-Server falsch konfiguriert ist und NICHT auf 127.0.0.1 hört. Dadurch tritt bei der Nutzung des Menüpunktes "Diagnose" der genannte Timeout auf.

Befehl der im Hintergrund aufgerufen wird:

/usr/local/bin/upsc 'ups@127.0.0.1'

Alternativ kannst du auch den Menüpunkt "Diagnose" nicht verwenden, dann hängt sich ebenfalls nichts auf, falls du den Daemon nicht auf localhost hören lassen kannst / möchtest.

* * *

Wenn alles geklappt hat...

...sieht es bei Synology so aus:

...sieht es bei QNAP so aus:

...sieht es unter Windows mit WinNUT so aus:

... sieht es unter Linux mit apcupsd so aus:

$ apcaccess -h 192.168.0.1:3551
APC      : 001,038,1008
DATE     : 2023-03-27 23:21:45 +0200
HOSTNAME : OPNsense.local.domain.de
VERSION  : 3.14.14 (31 May 2016) freebsd
UPSNAME  : Back-UPS RS 900G
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2023-03-11 00:52:44 +0100
MODEL    : Back-UPS RS 900G
STATUS   : ONLINE
LINEV    : 221.0 Volts
LOADPCT  : 27.0 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 40.9 Minutes
MBATTCHG : 10 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 300 Seconds
SENSE    : Medium
LOTRANS  : 176.0 Volts
HITRANS  : 294.0 Volts
ALARMDEL : 30 Seconds
BATTV    : 27.1 Volts
LASTXFER : Automatic or explicit self test
NUMXFERS : 2
XONBATT  : 2023-03-27 09:16:16 +0200
TONBATT  : 0 Seconds
CUMONBATT: 21 Seconds
XOFFBATT : 2023-03-27 09:16:27 +0200
LASTSTEST: 2023-03-27 09:16:16 +0200
SELFTEST : NO
STATFLAG : 0x05000008
SERIALNO : XXX
BATTDATE : 2022-01-29
NOMINV   : 230 Volts
NOMBATTV : 24.0 Volts
NOMPOWER : 540 Watts
FIRMWARE : 879.L4 .I USB FW:L4
END APC  : 2023-03-27 23:22:07 +0200
* * *

NUT-Server emulieren

Ende März 2024 habe ich von Martin per Telegram den Tipp erhalten, dass er ein kleines Script geschrieben hat, was einen NUT-Server emuliert und die Daten dafür von einem apcupsd-Daemon abgreift.

Vielleicht ist das Script auch für dich nützlich, hier der Link dazu:
Apcupsd NUT Wrapper Script (Apcupsd and NUT on the same machine)

* * *

Ich möchte apcupsd und NUT parallel betreiben, habe dabei aber Schwierigkeiten

Ich unterstütze dich gerne bei allen Konfigurationen rund um apcupsd und NUT, nicht nur auf der OPNsense-Firewall.
Schreib mir hierzu einfach über Kontakt, per Telegram oder unten in die Kommentare eine Nachricht.

* * *

Synology

QNAP

* * *

Änderungshistorie

04.04.2024 – Passage NUT-Server emulieren hinzugefügt
07.03.2023 – Artikel erstellt

* * *
Christian Süßenguth Christian Süßenguth @sweetgood

Hi, ich bin Christian und Inhaber der Firma SWEETGOOD. Mit dem andersGOOD Blog möchte ich auch dich für datensichere IT-Lösungen begeistern. So bringst du dein Unternehmen voran, ohne großen Konzernen deine wertvollen Daten zu liefern. Probiers mal anders!


Kommentarbereich

Die Kommentare sind für dich noch deaktiviert, da du dem Setzen von Cookies bisher nicht zugestimmt hast.
Klicke oben rechts auf "Ja, klar!" und lade die Seite neu, um die Kommentare anzuzeigen.

Seite neu laden

👾 Magst du Kekse?

Ich würde gerne Cookies setzen

Ist das OK für dich?