Beiträge von springfeld

    Warum das jetzt scheitern soll, dein NAS via SNMP an ne USV anzubinden, weil dein GUI nen USV SNMP Menüpunkt hat, versteh ich jetzt auch nicht

    Weil du schriebst,

    Mod: Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    CAT2 NAS sollten eine SNMP Funktion in den USV Optionen haben..

    und ich daraufhin - in Unkenntnis, was CAT1 und CAT2 überhaupt bedeutet und wie man sie unterscheiden kann, s.o. - nachgeschaut habe, ob dem so ist.


    Die Sache ist die: Eaton verweist hinsichtlich der Kompatibilität auf QNAP, QNAP auf Eaton.

    Mir sagt also keiner, ob das Szenario, so wie erdacht, Sinn macht.

    Ich soll für 300 Euro Hardware anschaffen, eine etwas komplexere Netzwerkkarte wohlgemerkt, ohne Zusicherung der Funktion.

    dolbyman CAT2 sagte mir - in dem Kontext natürlich - erstmal nichts. Unter Zuhilfenahme eines anderen Threads habe ich ermittelt, wie man beides unterscheiden kann. Kurzum: Die TS-531X hat nur ein CACHEDEV1_DATA (auf das alle anderen Links verweisen) und ist daher wohl nicht CAT2. Hier die Ausgabe:


    Code
    ls -al /share
    drwxrwxrwt    4 admin    administ       260 Feb 26 11:20 ./
    drwxr-xr-x   23 admin    administ       860 Mar 25 15:12 ../
    drwxrwxrwx   42 admin    administ      4096 Apr 17 09:23 CACHEDEV1_DATA/
    (...)


    Heißt das im Umkehrschluss, dass die QNAP mittels Netzwerkkarte herunterzufahren scheitern wird?


    In der Systemsteuerung werden folgenden Optionen unter Externe Geräte angeboten:

    1. USB-Verbindung
    2. SNMP-Verbindung
    3. Netzwerk-USV-Slave

    Das legt ja erstmal die Vermutung nah: Doch. Allerdings ist es schwierig dazu eine eindeutige Auskunft zu bekommen.

    Moin,


    ich würde gerne zwei Hyper-V Hosts und zwei QNAP NAS von einer Eaton IPP aus abschalten. Den Zahn, das ginge nur per USB, wurde schon gezogen. Diese Vorstellung deckt kein Szenario des Herstellers - der aber eine SNMP-Netzwerkkarte (Eaton Network M2) als Option anbietet.


    Frage nun: Sind QNAP NAS, insb. TS-531X und TS-932PX, auf Basis von QTS 5.0 mit den Eaton 5P im Allgemeinen und deren Network M2-Option im Speziellen kompatibel insofern als das man sie via "Externes Gerät" im gleichnamigen Systemsteuerung-Zweig als USV bzw. "Netzwerk-Slave" konfigurieren und also im Stromausfall-Fall ausschalten kann? Anschlussfrage: Wie?


    Grüße


    Udo

    Hätte ich drauf kommen können.


    Es erscheint, wenn ich das App Center aufrufe, und dann Alle Apps aufschlage:

    Code
    Updates sind vorübergehend nicht verfügbar.


    Nachdem ich nun überzählige Netzwerkverbindungen gekappt habe, die nicht aktiv verwendet wurden, bleibt nur noch eine Ursache für das Problem in Frage: In dnsmasq sind noch vier Einträge vorhanden.


    Code
    [admin@xfnas06 etc]# cat resolv.dnsmasq
    nameserver 192.168.0.15@eth3
    nameserver 192.168.178.1@eth3
    nameserver 192.168.0.15@eth0
    nameserver 192.168.0.15@eth0

    Ausgeführt wird dnsmasq mit dem Flag -o, und zumindest UNIX sagt dazu: Frag alle!


    Heißt (Arbeitsthese): Die QNAP versucht nicht nur über das Interface, auf dem der Gateway jetzt, deinem Ratschlag folgend, festgelegt ist, sondern auch über eth0 auf die selbe IP-Adresse. Aber auf dem Pfad ist keine Antwort zu erwarten: eth0 ist ein 10GbE Interface, das als iSCSI Target eingebunden ist. Versuche morgen in aller Früh das Default Gateway wegzunehmen, das darauf liegt. Vorher kann ich das nicht riskieren, da ich davon ausgehen muss, dass das Interface kurz abgeschaltet wird.


    Dann bin ich aber mit dem Latein am Ende, eigentlich müssten die beiden anderen Server nämlich Antworten liefern.


    Tatsächlich sind mehr Apps installiert, als ich erwarten würde. Ich kann mir auch schon vorstellen, dass hier die nächsthöhere Hierarchieebene ausgetobt hat und mindestens eine davon auch Spuren in der Netzwerkkonfiguration hinterlassen hat: Unter /etc/hosts findet sich nämlich (Pseudonymisierung durch mich)


    Code
    [admin@xfnas06 etc]# cat /etc/hosts
    127.0.0.1  localhost
    127.0.1.1  localhost
    192.168.0.6 qnap.example.org qnap #eth3
    10.0.5.1 qnap.example.org qnap  #docker0
    10.0.3.1  qnap.example.org qnap  #lxcbr0
    192.168.10.6  qnap.example.org qnap  #eth0

    Da die in der Reihenfolge abgearbeitet werden, trifft das so auch zu (192.168.0.6 qnap.example.org qnap #eth3), aber Einträge wie


    Code
    10.0.5.1 qnap.example.org qnap  #docker0
    10.0.3.1 qnap.example.org qnap  #lxcbr0

    sind totaler Bullshit, da die Netzwerke hier gar nicht existieren - weder auf der QNAP, noch darüber hinaus.


    Frage hierzu: Gibt es eine Liste der unabdingbaren Apps, die installiert sein müssen, um die Funktion als reiner Datenspeicher nicht zu gefährden?


    Grüße


    Springfeld

    Eingangs habe ich behauptet, die Prüfung auf Updates sei erfolgreich, weil die Systemsteuerung das suggeriert. Inzwischen bin ich mir da nicht mehr so ganz sicher:


    TS-531X - Download-Center | QNAP

    • listet 2 neuere (5.0.0.1853, 5.0.0.1858)
    • listet die installierte Firmware (5.0.0.1828)

    Insofern gehe ich davon aus, dass die QNAP nur behauptet, dass die Update-Prüfung funktioniert.

    Hi,


    ich habe nicht so viel Erfahrung mit QNAP: Zuhause verwende ich unter Fujitsu vermarktete und geschäftlich eine TS-531X. Will vorausschicken: Mein Produkt-spezifisches Know-How hält sich in Grenzen.


    In besagter TS-531X erscheint nach einer gewissen Wartezeit die Meldung (Anhang: QNAP DNS-Server oder Standard-Gateway stimmen nicht.png)QNAP DNS-Server oder Standard-Gateway stimmen nicht.png, dass das System erkennt habe, dass der DNS-Server Hosts nicht auflösen könne. Als Handlungsanweisung wird empfohlen, den DNS-Server und Standard-Gateway zu prüfen.


    Beide sind im ganzen Netzwerk aber dieselben, und die NAS hängt mit beiden im selben Netzwerk.


    Und das System hat Internetzugriff, denn: Es gelingt auch eine Update-Prüfung durchzuführen.Update-Prüfung.png


    In der TS-531X sind zwei zusätzliche Transceiver verbaut. Das auf dem einen Transceiver konfigurierte Netzwerk ist allerdings nicht öffentlich und absolut unabhängig vom Netzwerk (192.168.10.0/24). Der andere ist derzeit deaktiviert.


    Der erste eingebaute NIC, über den auch die Administration stattfindet, hat eine Adresse in 192.168.0.0/24, die statisch konfiguriert ist. In dem liegen auch die DNS-Server und Default-Gateway.


    In der resolv.dnsmasq fanden sich trotzdem merkwürdigerweise mehrere Einträge, die nicht die aktuelle Konfiguration widerspiegelten:


    Code
    nameserver 192.168.0.15
    nameserver 192.168.0.15
    nameserver 192.168.0.15@eth0
    nameserver 192.168.0.15@eth0
    nameserver 192.168.0.15@eth1
    nameserver 192.168.0.15@eth1

    Richtig wäre gewesen:


    Code
    nameserver 192.168.0.15@eth3
    nameserver 192.168.178.1@eth3

    Wobei das 192.168.178.1 der Router ist, der auch DNS anbietet.


    Die NAS ist Domänenmitglied.

    Die beiden Nameserver sind erreichbar. Die Nameserver antworten tendenziell eher zu auskünftsfreudig,

    DNSMASQ läuft.


    Code
    [admin@xfnas06 etc]# ps -ef | grep dnsmasq
    
    
    12237 admin      2208 S   /sbin/dnsmasq -S /<Domain>/192.168.0.15 -S /<Domain>/192.168.0.15 -o


    Hat jemand einen Rat, hier sitzen drei ohne weiteren.


    Gruß


    Udo Springfeld