Beiträge von rws

    Für LAN steht "DHCP Name Server" auf "Auto"

    Damit übernimmt das USG die Rolle des zentralen DNS. Das war für die Umleitung auf den internen DNS (oder spätere Änderungen) die einfachste Variante, weil die Anapssung dann sofort wirkt, ohne erst die LeaseTime der DHCP-Clients abzuwarten. Also eher pragmatisch, weil ich für WAN nicht den Provider-DNS verwenden will.

    Ich meine, beim Asus-Router gab es auch nur die DNS-Option für WAN (bin mir aber nicht mehr sicher)


    Über die DHCP-Einstellungen geht das auch, aber da weiß man ja nie so genau, wei die Clients mehrere DNS verwenden (den zweiten nur als Fallback oder mit Lastverteilung). Über WAN/USG weiß ich zumindest dass der zweite DNS nur als Fallback verwendet wird, falls AdGuard mal offline ist.


    Aber deine Variante gefällt mir auch. Hat den Vorteil, dass man die Clients im Log sieht. Vielleicht kann man als zweiten DNS das USG eintragen und dann darüber den Fallback steuern mti dem externen DNS. Ich glaube, das probiere ich mal aus.

    Bei mir nicht. Mein Router (Unifi USG) teilt seine IP den Clients als DNS-Server mit und ruft dann über WAN die im Router eingetragenen DNS-Server auf.

    Der Client kennt nur das Standard-Gateway als DNS-Server:


    Windows 10 Wifi-Details:

    pasted-from-clipboard.png


    Entsprechend taucht auch der Router als "Client" im AdGuard-DNS auf:
    pasted-from-clipboard.png


    Vielleicht sind das Besonderheiten der Router, welche Infos sie per DHCP an die Clients weitergeben.

    In den DHCP-Einstellungen wird doch der Router als DNS-Resolver angegeben, nicht der lokale DNS. Der Router wiederum hat den piHole (oder AdGuard bei mir) als DNS eingetragen sowie einen zweiten Internet-DNS als Fallback.

    Damit fragen alle Clients nur beim Router an und der wiederum bei DNS.

    Ist doch so korrekt, oder habe ich dabei einen Denkfehler?


    Edit: Hier ein Beispiel:


    In den WAN-Einstellungen des Routers ist der lokale DNS und als zweites der Fallback-DNS eingetragen:

    pasted-from-clipboard.png


    Die Clients verwenden den router (also das Standard-Gateway) als DNS. Damit entscheidet nicht der Client sondern der Router über die DNS-Abfrage:


    Nachteil: Im DNS sieht man niur den Router als "Client" für alle Abfragen. Man sieht also nicht mehr, welcher Client ursprünglich die Adresse auflösen wollte.


    Diese Einstellung funktioniert gut. Man merkt das wieder beim Neustart des NAS oder Update der ContainerStation, wenn man wieder Werbung angezeigt bekommt.

    Ich habe mit den virtuellen Switches noch nicht viel gemacht. Aber nutzt der Bridge-Modus nicht standardmäßig die Default-Netzwerkschnittstelle des NAS?

    Container -> virtualSwitch -> Adapter

    Dann sollte der Container doch über den gleichen Adapter und damit über das gleiche Gateway gehen.

    Unabhängig davon, was bei dir auf dem Port läuft, würde ich beim Container besser den Bridge-Modus mit fester IP verwenden. Dann kommen sich Container umd Qnap nicht in die Quere, weil der Container mit eigener IP wie ein separates Gerät im Netzwerk erreichbar ist.

    docker wäre eine Alternativ, damit kenne ich mich aber auch nicht wirklich aus.

    Docker-Container sind einfach einzurichten.

    - du legst ein Share-Verzeichnis an (z.B. ContainerData/OpenHAB/)

    - du wählst in der ContainerStation "Erstellen" und wählst den Docker-Container, vermutlich diesen: https://hub.docker.com/r/openhab/openhab/

    - bei der Einrichtung die "Erweiterten Einstellungen" einstellen, z.B: Host/Bridge-Modus, Variablen und Freigaben. Das wichtigste ist die Zuordnung des Share-Verzeichnisses. Damit werden die Container-Daten "nach außen" gelegt.

    Bei dem Container dürfe es dieser Mount sein:

    /etc/cont-init.d => /share/ContainerData/OpenHAB/


    Zum Update einfach den Container löschen und nochmal neu anlegen (mit neuer Version). Durch die Zuordung des Shares hat der Container wieder alle Daten.


    Anleitung z.B.:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Leider funktioniert das Auslagern/Mounten nicht wie gewünscht.

    Du hast 3 Mountpunkte angegeben. Der Container hat noch weitere (zweiter Screenshot). Die werden dann auf ein Dummy-Volume gemountet.


    Relevant sind diese Mounts:

    /unifi/cert => /share/ContainerData/Unifi/cert

    /unifi/data =>/share/ContainerData/Unifi/data

    /unifi/log => /share/ContainerData/Unifi/log


    Das sind die eigentlich nicht relevanten. Die habe ich trotzdem gemountet auf Dummy-Verzeichnisse, um die Dummy-Volumes zu verhindern.

    /var/run/unifi =>/share/ContainerData/Unifi/var_run_unifi

    /unifi => /share/ContainerData/Unifi/unifi


    Ich habe diese Zuordnung mit einem Controller der Version 5.x und nun 6.0.x verwendet.


    Edit: Ich kann mich dunkel erinnern, zu den Shares etwas in der Dockerbeschreibung gelesen zu haben. Es kann sein, dass /var_run/ alt und /unifi/ neu ist. Dort könntest du nochmal nachschauen.

    Ich hatte erst vor ein paar Tagen Pi-hole als Docker auf dem NAS installiert (TS-453A, also x86). War kein Problem...

    Docker: pihole/pihole

    https://hub.docker.com/r/pihole/pihole


    Einstellungen über ContainerStation:

    - Bridge-Mode mit fester IP (zumindest bei mir, da ich parallel AdGuard Home als Docker habe und damit der Port schob verwendet wird)

    - Umgebung:

    TZ = Europe/Berlin

    WEBPASSWORD = <passwort>

    Mehr Parameter werden normalerweise nicht benötigt

    - Freigaben:

    /etc/pihole => /share/ContainerData/Pi-hole/pihole

    /etc/dnsmasq.d => /share/ContainerData/Pi-hole/dnsmasq.d


    Wichtig für Änderungszugriff bei QNAP-Shares ist das Entfernen der ACL-Option des Share-Verzeichnisses (in dem Beispiel /share/ContainerData/Pi-hole/pihole) mit dem Befehl "setfacl -b pihole".

    Das Verzeichnis muss VOR Installation des Containers angelegt und der ACL-Befehl ausgeführt werden. Damit werden die Konfig-Dateien durch Pi-hole auch ohne ACL-Flag angelegt und damit der Schreibzugriff ermöglicht,


    Damit hatte ich Pi-hole problemlos installieren können.

    Aufruf der Admin-Seite erfolgt dann über http://Container-IP/admin

    Eine zentrale Hilfe habe ich nicht gefunden. Am besten gehst du auf die Seite der jeweiligen Integration. Dort sollten auch Beispiele für die configuration.yaml zu finden sein und wie man die ausprägt. Also am besten nach dem Name der Integration in Kombination mit "Home Assistant" suchen. Damit findet man meist die passende Seite oder zumindest ein HA-Foreneintrag.

    Die Aqaras sind ZigBee. Willst du die direkt am QNAP in HA verwenden? Dann brauchst du einen ZigBee-USB-Stick, der im Container eingebunden werden muss. Da kann ich leider nicht helfen.

    Ich verwenden HA hauptsächlich als Dashboard für Homey in Kombination mit ein paar Integrationen (WLAN oder Internetdienste).

    Ich lasse das NAS über Nacht ausgehen. Was würde das für die HA bedeuten?

    Naja, HomeAssistant läuft dann nicht mehr. Kommt darauf an, was du damit machen willst.

    Nutzt du das nur aktiv zum Steuern der Geräte, dann wäre das ok.


    Ich nutze es z.B., um die Sensordaten aller möglichen Geräte (sowohl HA-Integrationen und interne Entitäten als auch externe über MQTT eingebundene Geräte/Sensoren). Von denen möchte ich die historischen Daten sehen (Temperaturverlauf usw.). Dafür muss HA dann dauerhaft laufen.

    Aber sei gewarnt: HA schreibt alle Änderungen der Daten in die interne Datenbank. Läuft deine Containerstation auf einer HDD, dann wird die dauerhaft arbeiten, falls du Entitäten hast, die dauernd Änderungen protokollieren (Wetter z.B.). Nicht wundern, wenn die HDDs mit HA nicht mehr in den Ruhemodus gehen.

    Allerdings hatte ich die "Selbstständige Portfreigaben für dieses Gerät erlauben". vom NAS aktiviert.

    Dann hast du vermutlich die NAT-Variante für die Netzwerkanbindung verwendet? Da musst du doch eigentlich eine Art Port-Forwarding einstellen, um die Zugriffsports auf HomeAssistant einzustellen? Ich habe das allerdings nie verwendet.

    Aber da du zugreifen kannst, wurde der Port 8123 vermutlich 1:1 durchgeleitet. Das ist ja aber nur relevant für den Zugriff LAN=>NAS=>Container. Hat also nichts mit WAN und Portfreigaben im Router zu tun :)


    Du kannst ansonsten "HOST" wählen. Dann ist der Container direkt über dessen Port und die NAS-IP erreichbar.

    Ich verwenden mittlerweile den "Bridge-Modus". Dabei kann man dem Container eine feste IP geben, Der Vorteil ist, dass es von deinem LAN aus wie ein separates Gerät funktioniert und dass die Container-Ports nicht in Konflikt mit den NAS-Ports kommen können. Das wäre eien Variante, wenn du dich mit Netzwerker und deinem Heimnetzwerk auskennst (DHCP, feste IPs, IP-Bereiche usw).

    Hi Ingo,

    sieht auch interessant aus. Vermutlich auch viel mächtiger als der kleine Nginx-Proxy. Danke für die Anleitung.

    Den Nginx als Container einzurichten war aber sehr einfach. Nur Docker mit Port-Parameter anlegen, dann über das Dashboard einrichten. Dann noch Portforwarding auf die Nginx-Ports aus der Container-Konfig, das wars eigentlich.

    Mal schauen, ob ich Traefik auch mal teste...

    Ronny


    Edit:

    Ich habe mir nochmal ein paar Beispiele angeschaut...

    Ist es tatsächlich so, dass man die gesamte Konfiguration des Routings in TOML-Dateien angeben muss? Oder kann man das auch über das Dashboard einstellen?

    Das schöne am NgingProxyManager ist die komplette Konfiguration über das Dashboard.

    Mit der Vorletzten Firmware-Version (ich glaibe 4.5.1.1540) setzt der QNAP-HTTPD die Apache-Einstellungen immer wieder auf Default zurück, sobald man vhosts oder ReverseProxy definiert.


    Ich bin deshalb zu einem Container gewechselt (Nginx Proxy).

    Siehe meinen Thread zum Apache-Problem: ReverseProxy https=>http funktioniert nicht mehr seit letztem Firmware-/Apache-Update

    Bzw. direkt diese Anleitung: https://forum.qnap.com/viewtopic.php?t=155970


    Damit kann man ReverseProxys für beliebige SubDomains anlegen und für jede SubDomain ein eigenes LetsEncrypt-Zertifikat installieren lassen.

    Vielleicht wäre das ja auch eine Alternative für dich.

    Dann nimm doch einfach die Version vorher.

    Das mit den Containern ist schon klar.

    Das Problem bei Dyson besteht mit allen Versionen, weil Dyson etwas geändert hat. Deshalb bleibt nur die Vorab-Korrektur im Container und warten auf einen Fix im offiziellen Release.

    Deshalb ist deine erste Antwort genau was ich dafür brauche. Danke dafür.

    Danke für die Info, Das muss ich mir mal in Ruhe anschauen. Ich hatte gehofft, dass die Containerinhalte im Containerverzeichnis liegen.


    Es ist ein eher spezieller Fehler in der Dyson-Integration bzw. den Core-Komponenten dazu. Die Authentifizierung wurde wohl seitens Dyson geändert und damit bekommt man die Integration zumindest mit vorheriger Anmeldung über die Dyson-App zum Laufen:

    https://github.com/home-assist…00#issuecomment-778508999

    Hallo an die Container-Profis,

    ich setze HomeAssistant als Container ein. Dafür gibt es einen Bugfix für eine Integration, die aktuell nur über GitHub verfügbar ist.

    Um den Fix in HA zu integrieren, muss eine Datei im HA-Core getauscht werden.

    Kommt man an die Inhalte eines Images heran? Kann man in QNAP überhaupt Dateien innerhalb des Containers ändern?


    Unter /share/container/container-station-data/lib/container sind die einzelnen Container aufgeführt. Aber wo finden sich die eigentlichen Inhalte?