Einsatz der QNAP hinter einem Proxy

    Einige Benutzer wollen die QNAP sicher auch etwas ausgiebiger hinter einem Proxy nutzen. Das ist vor allem im
    betrieblichen Umfeld der Fall. Probleme gibt es hier eigentlich nur, wen man z.B. mit Optware arbeiten will, bzw.
    die Anforderung hat, mit der QNAP auf WAN-Resourcen zuzugreifen. Da das Standard-Environment und die Admin-
    Oberfläche hier standardmäßig keine Proxy-Konfiguration vorsieht, geht das mit den normalen Bordmitteln leider
    nicht.


    Deshalb habe ich mal diese kleine Anleitung geschrieben, wie man das trotzdem zum Rennen bringt. Getestet habe
    ich das auf der TS119 und der TS109. Das muß aber eigentlich mit nahezu jedem Modell tun, da die zugrundeliegenden Standards eigentlich immer zum Einsatz kommen.


    Schritt 1:
    Die quasi schon obligatorische Installation des Optware-QPKG. Hier haben wir schon den Salat. Die KlickiBunti-Installation mittels WEB-Oberfläche wird hier nicht funktionieren. Das liegt daran, dass das Environment der WEB-Admin-Umgebung keine Proxies berücksichtigt und damit keine Verbindung in´s Internet zustande kommen kann. Im Hintergrund kommen sowohl von den Packages direkt, als auch z.B. über Begleitprozesse z.B. wget-Algorythmen zum EInsatz, welche versuchen, über http, oder ftp in´s Internet zu connecten. Wenn man jetzt Glück hat, wird man zumindestens in den Logs mit einer
    mehr oder weniger informativen Meldung darauf hingewiesen, dass irgendwas schiefgelaufen ist. Hätte man jetzt Optware am Laufen, könnte man natürlich auf der Konsole z.B. mittels ipkg zum Ziel kommen. Geht aber nicht, also hat man hier
    jetzt ein klassisches "Ei-Huhn"-Problem, welches nicht so ohne weiteres lösbar scheint.
    Der große Vorteil bei QNAP-Geräten ist aber, dass sich unter der Oberfläche ein leistungsfähiges Linux-System befindet
    und die eingesetzten Programme (z.B. wget) natürlich durchaus in der Lage sind, mit Proxy-Umgebungen klarzukommen.


    Folgende Vorgehensweise hat bei mir zum Erfolg geführt.


    Als erstes sollten wir mal für ein einigermaßen brauchbares shell-Environment sorgen, welches die Proxy-Konfiguration berücksichtigt. Hierzu sorgen wir mit der allseit bekannten autorun.sh für einen dauerhaft verfügbare Konfiguration.


    Code
    mount /dev/mtdblock5 /tmp/configcd /tmp/configvi autorun.shchmod +x autorun.sh


    In der autorun.sh sind folgende Einträge zu tätigen:



    WICHTIG! Wie oben erkenntlich, finden sich in meinem Beispiel-Proxy-String auch Benutzername und Passwort.
    Das muss natürlich nur mitgegeben werden, wenn man es wie in meinem Fall mit "nicht transparenten" Proxy-Relays
    und Authentifikation zu tun hat.


    Hier noch mal ein Beispielstring mit einem Proxy-Benutzer "fritz", Passwort "Test", IP 192.168.0.1, Port 8000:
    http://fritz:Test@192.168.0.1:8000
    Und hier nochmal ein einfacherer Standard-String bei Proxies ohne Authentisierung:
    http://192.168.0.1:8000


    Des öfteren findet man auch Beschreibungen, bei welchen man den Benutzer mittels Parameter "proxy_username" und
    das Benutzer-Passwort mit dem Parameter "proxy_password" übergeben kann. Das hat bei mir bei verschiedenen Firewall-Konstrukten immer wieder zu Problemen geführt, weshalb ich das auch nicht weiter ausführen will.



    Wie oben erkenntlich, wird im Profil des admin(root) users dafür gesorgt, dass egal in welchem shell-Kontext ein brauch-
    bares Environment verfügbar ist. Zudem wird noch eine wgetrc generiert, welche zentral verfügbar ist. Alles natürlich erst, wenn man die neue Umgebung mittels eines reboots verifiziert.


    Da dieses Environment aber in der Standard-Konfigurationsoberfläche nicht zum Tragen kommt, kann man z.B. das
    Optware-QPKG immer noch nicht mittels WEB-Oberfläche installieren. Aber auch hier gibt es natürlich eine Lösung.
    Bei den QPKG-Paketen handelt es sich um ausführbare POSIX-shellscripte. Deshalb kopiert man das Optware-QPKG nun
    auf ein QNAP-Share, gibt diesem qpkg-Package Ausführrechte und führt es einfach aus (bitte mit obigem Environment).
    Und siehe da, wenn alles korrekt vorbereitet wurde, läuft die Installation des QPKG auch hinter einem Proxy problemlos
    durch. Auch in der Weboberfläche wird korrekterweise ein installiertes Optware angezeigt.


    Schritt 2:
    Da man jetzt über ein installiertes Optware verfügt und man nun auch ein tolles neues Proxy-Environment hat, funktioniert jetzt auch der ipkg relativ problemlos, der verwendet nämlich ebenfalls wget.


    Wie gesagt, in meinem Fall hat die obige Vorgehensweise funktioniert und wir konnten problemlos unsere für unsere Einsatzzwecke notwendigen ipkg´s installieren und zur Anwendung bringen. Aus meiner Sicht könnte man auf die etwas holprige Vorgehensweise der jedesmal neu generierten Environment-Dateien verzichten, wenn man das der WEB-GUI-Umgebung schon beim Start beibringt.
    Auch im Optware-Umfeld kann man sich noch andere elegantere Vorgehensweisen vorstellen. Aber wir kommen mit dieser erstaunlicherweise relativ sauber funktionierenden Lösung sehr gut klar und wenn ich das richtig erkannt habe, ist eines
    der wichtigsten zukünftigen Projektwünsche an QNAP eine standardmäßige Proxy-Unterstützung, so dass da eh in Zukunft
    mit einer integrierten Lösung zu rechnen ist. Das dürfte auch nicht sonderlich schwierig umzusetzen sein. Im Prinzip muß man ja aufgrund der unter der bunten Oberfläche arbeitenden Standard-Programme nur dafür sorgen, dass der Webserver
    ein entsprechendes Environment bekommt, daß er dann ja auch bereitwillig durchreicht.