Qnap & Syno – USV im Master-Slave-Mode - NAS Hilfe und Support Forum

Ich habe mir vor kurzem ein NAS von Synology zugelegt, weil ich einfach mal sehen wollte wie deren NASen so sind. Da ich eine USV habe, wollte ich natürlich auch, dass sowohl mein Syno-NAS, als auch das von Qnap sauber von der USV heruntergefahren werden, sollte der Strom mal für längere Zeit ausfallen.

Jeder, der sich schon mal mit dem Thema beschäftigt hat, wird wissen, dass dies nicht so einfach ist, da die NASen bzgl. USV so „out oft he box“ nicht miteinander reden. Dabei sollte das gar kein so großes Problem sein, denn unter dem Blech setzten beide die gleiche SW ein – wenn auch in unterschiedlichen Versionen.

Um das Ergebnis vorweg zu nehmen: Ich habe es geschafft! Die beiden NASen reden so miteinander, wie ich mir das gewünscht habe. Hier nun der Weg dorthin.

Ach ja, eines noch:

Wer Respekt vor der Shell auf dem NAS hat, wird evtl. hiermit an seine Grenzen kommen.

Ausgangsbasis:

Qnap TS-853A mit FW 4.4.1.1439

Syno DS-1618+ mit FW 7.2 Upd 3

Der offensichtlichste Grund, warum die NASen nicht miteinander reden ist erst mal der, dass Namen für die USV (das Gerät) und Credentials für den Zugriff vergeben werden müssen. Die lauten auf den beiden Geräten jeweils unterschiedlich.

	Qnap	Syno
Name der USV	qnapups	ups
Name für den Login	admin	monuser
Passwort	123456	secret

Theoretisch müsste es reichen in den Config-Files die Daten passend für das jeweils andere Gerät einzutragen, so dass beide NASen dieselben Namen für die USV und die Credentials verwenden und alles wäre gut. Praktisch haben wir bei Syno das Problem, dass diese Änderungen einen Reboot nicht überleben und bei Qnap, dass Name und Credentials nicht nur in den Konfig-Files stehen, sondern auch noch an mehreren Stellen (Scripte und Binaries) hart codiert sind.

Da ich es in der mir zur Verfügung stehenden Zeit nicht geschafft habe, auf der Syno einen Weg zu finden, die Änderungen an den Config-Files so einzubauen, dass sie zuverlässig einen Reboot überleben, war relativ schnell klar, dass ich nach Möglichkeit alle Änderungen an der Konfiguration auf Seiten des Qnap-NAS machen werde, und zwar so, dass die Konfiguration von Qnap (Name und Credentials) unverändert bleibt und lediglich Name und Credentials der Syno zusätzlich akzeptiert werden. Das hat noch einen weiteren Vorteil: Da der Gerätename der USV „qnapups“ auf dem Qnap nicht nur in den Config-Files hinterlegt sondern auch in mehreren Scripten und sogar in einigen Binaries hart codiert ist, brauche ich auf diese Weise nicht versuchen die Namensgebung von Qnap zu verändern.

Generell ist es keine gute Idee einem der beiden NASen beibringen zu wollen, dass „seine“ USV (also die, welche via USB direkt mit dem Gerät verbunden ist) nun anders heißt. Erfolgversprechender ist es, dem jeweils anderen NAS, den Zugriff für den „fremden“ Namen zuzulassen. Tatsächlich habe ich dies bei meinen Versuchen in beide Richtungen zumindest kurzzeitig hinbekommen. Die Änderungen auf der Syno haben nur nie den Reboot überlebt.

Folgende Lösung funktioniert für mich:

Die USV hängt an dem Qnap. In der Web-GUI sind 2 Geräte für den Zugriff über Netzwerk eingetragen: Das Syno-NAS und auch das Qnap-NAS. Letzteres ist nötig, weil wir eine Art Proxy einrichten werden, was dazu führt, dass das Qnap NAS mit sich selbst redet.

pasted-from-clipboard.png

Die Config-Files für die USV befinden sich bei Qnap unter /etc/config/ups. Folgende Files werden wir anpassen:

ups.conf
upsd.users

In die ups.conf tragen wir folgende Zeilen am Ende ein:

Code

[ups]
driver = dummy-ups
port = qnapups@localhost
desc = "UPS for Syno"

Erklärung:

Der USV-Treiber „dummy-ups“ reicht Zugriffe auf das Gerät „ups“ einfach an das Gerät weiter, das in der Zeile Port steht. Durch diese Einträge habe wir also einen Alias-Namen für unsere USV erstellt, den die Syno versteht.

In die upsd.users tragen wir folgende Zeilen ein:

Code

[monuser]
password  = secret
allowfrom = 192.168.2.3
upsmon slave

Erklärung:

Dies sind die Credentials, welche die Syno verwendet. Das Qnap akzeptiert daraufhin den Zugriff von der Syno. Die IP-Adresse muss natürlich die der Syno sein.

Theoretisch wären wir jetzt bereits fertig. Aber leider ist das nur die Theorie. In der Praxis zeigt sich, dass Qnap nicht das vollständige SW-Package aufgespielt hat. Unter /usr/local/ups/bin liegen die USV-Treiber, und dort fehlt dummerweise just der Treiber dummy-ups. Ich habe versucht ihn über opkg nachzuinstallieren. Das führt aber auch zu keinem funktionierenden Ergebnis, da für Komponenten, die via opkg nachinstalliert werden, alle Pfade unterhalb von /opt liegen (müssen) und auch diese hart codiert in den Binaries sind. Sprich der Treiber erwartet seine Config-Files unterhalb von /opt (das könnte man ihm noch abgewöhnen). Er will aber auch seine Sockets für die Kommunikation dort anlegen. Und damit können die Komponenten nicht miteinander reden, was zu einem nicht funktionierenden Ergebnis führt.

Ich habe dann ein NUT-Package einer Slackware-Distro ausfindig gemacht. Das hatte sogar dieselbe Versionsnummer wie das NUT, das auf meinem Qnap vorinstalliert war. (Link: https://ftp.sotirov-bg.net/pub…nut-2.7.4-x86_64-2gds.txz; Das extrahierte file "dummy-ups" habe ich an diese Anleitung angehängt.)

Diesem Package habe ich den dummy-Treiber entnommen und auf dem Qnap in das Verzeichnis /usr/local/ups/bin kopiert. Mit dem Kommando

Code

upsdrvctl -u admin start ups

kann man den Treiber starten und sehen, ob er irgendwelche Fehler wirft. In meinem Fall konnte er zwei Libraries nicht finden (libssl.so.1 und libcrypto.so.1). Das war aber kein größeres Problem, da die Libs grundsätzlich auf meinem Qnap vorhanden waren. Nur eben mit ihrer vollen Versionsnummer. Ich musste daher lediglich für jede Library einen weiteren Symlink anlegen.

In /lib einen Symlink von libssl.so.1 -> libssl.so.1.0.0 und in /usr/lib einen Symlink von libcrypto.so.1 -> libcrypto.so.1.0.0.

Damit lässt sich der Treiber starten.

Leider sind diese letzten Änderungen in den Verzeichnissen /lib, /usr/lib und /usr/local/ups nicht boot-fest. Wir müssen daher also das Binary an einer Stelle ablegen, wo es nicht gelöscht wird. Ich habe für solche Zwecke bei mir eine spezielle Freigabe, die von außen nicht sichtbar ist und auf die keiner Zugriffsrechte hat, namens „NAS_Config“. Dort lege ich das Binary ab. Zusätzlich habe ich ein Script, dass bei jedem Start ausgeführt wird. Dort kommen folgende Zeilen rein:

Code

cd /lib
ln -s libssl.so.1.0.0 libssl.so.1
cd /usr/lib
ln -s libcrypto.so.1.0.0 libcrypto.so.1
ln -s /share/NAS_Config/Data-NAS/usr/local/ups/bin/dummy-ups /usr/local/ups/bin/dummy-ups

Wenn wir nun in demselben Script mit der Zeile /usr/local/ups/bin/dummy-ups -a ups -u admin auch den Treiber starten, werden wir feststellen, dass dies nicht funktioniert. Das liegt daran, dass das Timing hier wichtig ist. Zuerst müssen wir warten, bis das Qnap die USV-Dienste gestartet hat. Das sehen wir an der Datei /var/run/upsisrunning. Allerding muss man auch dann noch kurz warten, da die Dienste ein paar Sekunden brauchen, bis sie vollständig in den Speicher geladen sind und die Sockets für die Kommunikation eingerichtet haben. Es sind also zwei Warteschleifen in dem Startscript nötig. Beide habe ich mit einem Timeout als „Notausgang“ versehen, damit das Script nicht versehentlich in einer Endlosschleife landet.

Mein fertiges Script sah dann so aus:

Bash

#!/bin/sh

# This scripts loads an additional UPS driver
# for Synology NAS to be able to communicate with this Qnap NAS


LOG_TOOL="/sbin/log_tool -t 0 -u SYSTEM -m ${HOSTNAME}"
LOGFILE=/tmp/dummy-ups.out

OWN_INITD_PATH=$(getcfg Own-Initd Install_Path -f /etc/config/qpkg.conf)
QPKG_PATH=${OWN_INITD_PATH%/Own-Initd}


export NUT_CONFPATH=/etc/config/ups
echo $NUT_CONFPATH > $LOGFILE
RUNFILE=/var/run/upsisrunning

# files needed by dummy-ups driver.
# (to enable Syno NAS to use local UPS)
cd /lib
ln -s libssl.so.1.0.0 libssl.so.1

cd /usr/lib
ln -s libcrypto.so.1.0.0 libcrypto.so.1

ln -s /share/NAS_Config/Data-NAS/usr/local/ups/bin/dummy-ups /usr/local/ups/bin/dummy-ups

# waiting for UPS to be started by Qnap routines
# this may need about one minute...
(( i=0 ))
until [ -f $RUNFILE ]; do.
    sleep 10;.

    # check for Timeout
        (( i++ ))
        if (( i>= 10 )); then
        # !! TIMEOUT !! stop here !!
        echo "Timeout reached. File $RUNFILE did not apear." | tee -a $LOGFILE
        ${LOG_TOOL} -a "$0: Timeout reached. File $RUNFILE did not apear."
        exit 1
    fi
done
echo "Waited $(( i*10 )) seconds for $RUNFILE." | tee -a $LOG_FILE


# even though the systems claims, it is up an running
# we need to wait some more time until all of the UPS is finally loaded into memory
# and has established all its sockets etc.
# That means, we probably need a few attempts to get the dummy driver running

echo "starting driver dummy-ups" | tee -a $LOGFILE

DUMMY_UPS_PID=`/sbin/pidof dummy-ups`
echo "DUMMY-UPS_PID = ${DUMMY_UPS_PID}" | tee -a $LOGFILE
(( i=0 ))
while [ "x${DUMMY_UPS_PID}" = "x" ]; do
    echo "Trying to start dummy-ups..." | tee -a $LOGFILE
    /usr/local/ups/bin/dummy-ups -a ups -u admin 2>> /tmp/dummy-ups.err | tee -a $LOGFILE
    sleep 2
    DUMMY_UPS_PID=`/sbin/pidof dummy-ups`

    # check for Timeout
    (( i++ ))
    if (( i>= 10 )); then
        # !! TIMEOUT !! stop here !!
        echo "Timeout reached. Unable to load driver dummy-ups." | tee -a $LOGFILE
        ${LOG_TOOL} -a "$0: Timeout reached. Unable to load driver dummy-ups."
        exit 1
    fi
done
echo "Waited $(( i*2 )) seconds until dummy-ups got loaded." | tee -a $LOG_FILE

echo "UPS driver dummy-ups running with PID: ${DUMMY_UPS_PID}"  | tee -a $LOGFILE


${LOG_TOOL} -a "$0: UPS dummy driver (needed for Synology) loaded. PID:${DUMMY_UPS_PID}."

Alles anzeigen

Nun sicherheitshalber das Qnap neu booten und direkt danach die Dateien und Symlinks prüfen. Wenn die Einträge immer noch vorhanden sind, haben wir gewonnen.

Wer will kann sich auf der Shell von der ordnungsgemäßen Funktion überzeugen:

Auf dem Qnap: upsc ups ups.status. Antwort „OL“ (Online).

Auf der Syno: upsc ups@192.168.2.2 ups.status. Antwort „OL“ (Online).

(Die IP muss natürlich die von dem Qnap-NAS sein)

Nun in die Web-GUI der Syno gehen und dort unter Systemsteuerung / Hardware & Energie / USV die USV-Unterstützung aktivieren. Als Typ wählen wir „Synology USV-Server“. Bei „Netzwerk-USV-Server IP:“ geben wir die IP-Adresse des Qnap ein. Nach Klick auf den Button „Übernehmen“ sehen wir in den „Geräteinformationen“ die Daten der USV.

pasted-from-clipboard.png

Das war's. Das ist die Lösung, die bei mir läuft.

======================================================

Wem das mit dem Runterladen des (systemfremden) Slackware-Binaries zu heikel ist, für den gibt es eine andere Lösung. Die funktioniert zwar, ist aber nicht ganz so schön, da in der Web-GUI nicht ersichtlich ist ob / dass die Verbindung zwischen den beiden NASen besteht.

In diesem Fall muss man die USV an die Syno anschließen und in der Web-GUI, den Zugriff für das Qnap freigeben.

Auf dem Qnap fügen wir in der Datei /etc/config/upsmon.conf folgende Zeile hinzu:

Code

MONITOR ups@192.168.2.3 1 monuser secret slave

(Die IP muss natürlich die von der Syno sein)

Mit upsc ups@192.168.2.3 ups.status sehen wir nun schon, dass die Kommunikation funktioniert. Das Qnap fährt bei einem Stromausfall aber noch nicht runter. Dafür müssen wir in der Datei /etc/config/upsmon.conf zusätzlich noch die Zeile

Code