Beiträge von tuxflo

    können zwei docker auf die gleichen pfade verweisen sodass man so ggf. ein fallback initiieren kann?

    Ja das können sie, es darf aber logischerweise immer nur ein Container gestartet sein, beide mit den gleichen Mountpoints gleichzeitig zu starten ist keine gute Idee. Aber ja, falls mit dem "neuen" Container was nicht läuft kannst du diesen einfach wieder stoppen und den alten anwerfen. Zumindest spricht aus Sicht von Linux und den Containern nichts dagegen, wenn sich natürlich in der Anwendung was grundlegendes wie ein Datenbankschema oder ähnliches ändert, ist das "Rollback" nicht so ohne weiteres möglich. Aber falls du diesen Fall auch noch abdecken willst, kopierst du dir einfach die Ordner die du in den Container reinreichst an eine andere Stelle.

    Kann ich das neue Image einfach reinladen und mit dem gestoppten Container geknüpfen

    Nein kannst du nicht, so funktionieren Container nicht. Was du stattdessen machen musst ist: den alten Container löschen, ein neues Image herunterladen (docker pull) und mit dem frischen Image einen neuen Container starten. Wenn alle entsprechenden Verzeichnisse auf den Host gemappt sind, wie du ja geschrieben hast, dann sollte das Problemlos so klappen.

    Ja, wollte dich genauso wenig zu irgendwas überreden, mir kamen die Vergleiche nur falsch vor und ich wollte das für Nachlesende nicht unwiedersprochen stehen lassen. Wenn du mit VMs besser zurecht kommst ist das auch vollkommen OK für mich.

    Für Administrationsaufgaben ist beides schnell genug, und für grafiklastige Anwendungen ist beides ungeeignet, da das NAS im Keller steht und keinen Monitorausgang hat.

    Das ist genau der Unterschied den ich hervorheben wollte: in der Linux Station kann man auf den Modellen mit HDMI Ausgang durchaus normale "grafiklastige" Anwendungen verwenden wenn man einen Monitor anschließt und das eben möchte. Ich schaue darüber jeden Abend fern (TV Livestreams, Netflix, Mediathek und Co) und spiele ab und an sogar Computerspiele darauf, auch wenn die schon etwas betagter sind (via RetroPie auf Super Nintendo und N64 Emulatoren).
    Solche Sachen sind mit der Linux Station duch die bessere Resourcennutzung eben möglich und mit einer VM eben nicht :)


    Eine Sache die mich an der Implementierung der VMs im QTS noch massiv gestört hat ist, dass dort USB Geräte nicht automatisch erneut zugewiesen werden, wenn die VM bzw. das NAS mal aus war. Das ist zum Glück bei der LS auch nicht der Fall, alles was dort in der entsprechenden Konfigurationsdatei hinterlegt wird ist auch Reboot-resistent.

    Ich musste Ubuntu, Linux Station löschen, einen neuen virtuellen Switch anlegen, LS und Ubuntu neu installieren

    Keine Ahnung was da schief gelaufen ist, aber ich kann dir versichern, dass diese Probleme rein gar nichts mit KDE zu tun haben.

    Also KDE nicht möglich.

    Das ist schon ziemlich subjektiv, ich nutze die Linux Station quasi seit dem sie veröffentlicht wurde ausschließlich mit KDE und habe keine Probleme. Sowohl früher mit Ubuntu 18.04 als auch später dann mit 20.04.

    Diese Smartphone-GUI von Ubuntu kann ich nicht ausstehen,

    Es gibt in der Linux Welt auch nicht nur KDE und Gnome, sondern z.B. auch noch Xfce oder diverse Tiling Window Manager, dann hat man auch keine "Smartphone GUI".


    ist bei einem NAS ohne Grafikkarte und ohne Bildschirm ohnehin nicht sinnvoll)

    Genau das macht aber den größten Unterschied aus. Während die Linux Station mit einer grafischen Benutzeroberfläche ganz gut nutzbar ist (bei mir ist das quasi mein "Fernseher") sieht die Sache bei einer ausgewachsenen VM deutlich anders aus. Das Windows, was ich in einer VM betreiben muss um meinen Scanner verwenden zu können ist um ein vielfaches träger und langsamer als die Linux Station. Du siehst ja Windows als einen Vorteil der VM und da frage ich mich schon wie du das komplett ohne grafische Benutzeroberfläche verwalten willst.


    Auch denke ich, dass man eine VM leichter auf ein anderes NAS oder einen anderen Rechner übernehmen kann.


    Denken != Wissen. Einen exportierten Container kann man genau so einfach auf ein anderes System migrieren und hat dabei sogar noch den Vorteil, dass die Dateigrößen des Exportes in der Regel wesentlich kleiner sind, weil sie sich besser komprimieren lassen und nur den Speicher einnehmen, der auch belegt ist.


    Daher meine Antwort: verallgemeinere persönliche Probleme nicht auf ganze Technologien und habe kein blindes Vertrauen in Werte, die dir Benchmarks liefern es gibt z.B. auch Benchmarks die deutlich zeigen, dass Containertechnologien deutlich performanter sind als Vollvirtualisierungen (https://de.slideshare.net/Bode…nchmarking-with-openstack), was ja auch logisch ist, wenn man bedenkt, dass ein Container nicht noch Geräte emulieren muss und einen eigenen Kernel bereitstellen muss.

    Ich würde beim Thema VPN empfehlen einfach ein weiteres Gerät zu verwenden und die notwendige Freigabe dann darauf einrichten. Dann ist zumindest das NAS nicht "direkt" über das Internet zu erreichen. So ein Gerät kann z.B. ein Raspberry Pi sein, der mittels PiVPN die Verbindung bereitstellt. Als Protokoll würde ich Wireguard empfehlen. Da gibt es Clients für alle Betriebsysteme (auch Android und iOS) und weil Wireguard "Romaning" beherrscht, bemerkt man gar nicht, dass man sich nicht im Heimnetz befindet.


    Als DynDNS Privider nutze ich Dynv6 mit einer eigenen Domain.

    Aber mit Treibern hat doch ein Docker Container auch gar nix am Hut. Der verwendet ja den Treiber von Hostsystem. Ich würde eher vermuten, dass es an irgendwelchen Rechten auf dem Device liegt. Andre77 bist du dir eigentlich sicher, dass --privileged ausreichend ist? Ich kenne es bisher nur in der Form --privileged=true.

    Also wenn die Container einmal gestartet wurden, tauchen sie auch "ganz normal" in der Container Station auf und können dort z.B. gestoppt oder neugestartet werden. Es wäre also nur das initiale docker-compose up was du per SSH machen müsstest.

    Also im Verzeichnis der Container Station habe ich kein Repo hinterlegt. Eigentlich spielt das Verzeichnis auch gar keine Rolle, denn er liest ja nur bei der Erstellung der Container die Konfiguration ein und legt dann die Container in deinem Standard Pfad an, also unter einem "normalen" Linux irgendwo unter /var/lib/docker und im QTS eben unter dem Pfad der Container Station. Du könntest sogar eine ganz normale Ordner Freigabe, wie z.B. den Public Ordner, nehmen, von deinem Rechner aus editieren und dann einfach nur auf dem NAS docker-compose up ausführen.

    Ok mit Remote Zugriff ist also der Webserver/Client gemeint, das war mir vorher nicht so klar. Tatsächlich benötigt der wirklich ein paar mehr Ressourcen, bei mir dauert dort die Erstellung der Vorschaubilder immer recht lang. Aber auch hier direkt nochmal der Hinweis: nur weil es möglicherweise "Remote Zugriff" heißt, sollte man den Dienst keinesfalls "einfach so" von außen zugänglich machen. Auch für diesen Einsatzzweck könnte die von mir oben genannte VPN Lösung hilfreich sein.

    Allerdings möchte ich auch schon gerne von unterwegs auf meine Dokumente zugreifen, was hier durch die Ausstattung der kleinen Beere wohl als erschwert anzusehen ist.

    Den Zusammenhang verstehe ich nicht so ganz. Was hat denn der Zugriff von außen mit der Leistungsfähigkeit des Raspis zu tun?

    Ich würde sogar behaupten, dass der Zugriff mit einem Rapsi einfacher ist, weil du dort mit Wireguard/piVPN ziemlich einfach ein VPN einrichten kannst, mit dem du dann sicher von außen auf die Dienste in deinem Heimnetz zugreifen kannst. Dieses Verfahren würde ich dir selbst mit dem neuen NAS ans Herz legen, bitte nicht "mal eben Portfreigaben an das NAS einrichten, damit man von außen zugreifen kann".


    Ich habe übrigens ein 251+ und war anfangs auch vom hohen Einstiegspreis abgeschreckt, muss aber jetzt nach einigen Jahren sagen, das es sich gelohnt hat.

    In der docker-compose.yml ist bei "app" der Port 80 vom Host auf den Port 80 vom Container gemappt. Ich vermute mal, dass Port 80 bereits von QNAP verwendet wird. Teste dort mal ob du z.B. Port 8888 nehmen kannst und dann über http://nas-IP-Adresse:8888 zugreifen kannst.

    Was genau hat denn deine Frage mit der Linux Station zu tun? Ich glaube es könnte sinnvoll sein diesen Beitrag zu verschieben.

    Müßte ich da am besten die IP Adressen der Clients freigeben oder noch besser

    IP-Adressen Bereiche ?

    Wenn du deinen Netzwerkteilnehmer:innen nicht vertraust, dann ja. Die Abgrenzung von IP Adressen ist ein zusätzlicher Schutz. In den meisten Heimnetzen ist das aber gar nicht möglich, weil dort die IP Adressen per DHCP zugeordet werden.


    Zur Frage ob NFS oder Samba: ich glaube heutzutage sind die Unterschiede ziemlich gering, es hält dich also nicht wirklich etwas davon ab auch mit dem QNAP NAS Samba zu verwenden.


    Zur Frage der Version: das kommt halt auf deine Clients an, aber ja in der Regel ist v4 schon eine gute Wahl, weil dort nützliche Features, wie z.B. server side copy, mit enthalten sind.


    Generell gibt es beim Thema NFS noch zu erwähnen, das der jeweilige mount im Kernel stattfindet. Das hat zwar den Vorteil, dass es äußerst performant sein kann, aber auch den entscheidenden Nachteil, dass die Systeme sich äußerst merkwürdig verhalten können, falls der Host mal nicht erreichbar ist. Das ist für mich der Grund warum ich auch auf Linux Systemen fast ausschließlich Samba einsetze.

    Das mit dem mount ist wohl richtig, war mir selbst noch gar nicht so bewusst.


    Zum Thema Steckdosenleiste: da meinte ich eine die man per USB schalten kann, ein Hersteller der sowas führt ist z.B. "EnerGenie". Ich habe für meine ca. 25€ bezahlt. Mit der dazu passenden Software, die auch direkt auf dem QNAP betrieben werden kann, kannst du einfach die Zeiten einstellen.

    Alternativ gibt es solche "smarten Steckdosen" auch mit WLAN. Dort hast du sogar die Möglichkeit einen genauen Zeitplan zu konfigurieren (die freie Firmware Tasmota ist hier der richtige Suchbegriff). Falls du dazu konkrete Fragen hast, kannst du gernen einen neuen Thread aufmachen und mich erwähnen, nicht das es hier zu sehr vom eigentlichen Thema abweicht.

    Ich hatte vor einer Weile mal ein ähnliches Szenario und habe es damit gelöst, dass ich die Platte an einer schaltbaren Steckdosenleiste angeschlossen habe, die ich dann nach dem Auswerfen der Platte ausgeschaltet und zu den Zeitpunkten kurz vor dem Backup wieder gestartet habe. Auf einem normalen Linux System wäre sonst mount das Mittel der Wahl, aber hier weiß ich nicht, ob QNAP da irgendwelche besonderen Parameter verwendet.

    Hm, gibt es vielleicht eine Möglichkeit, die benötige Software nativ und ohne den Umweg über einen Container auf dem NAS zu installieren?

    Kurze Antwort:
    Nein.

    Etwas ausführlichere Antwort:
    Kommt auf die Software drauf an. Manche Sachen kann man sich selbst kompilieren und zusammenstellen, das setzt aber
    a) tiefgreifendes Wissen (Linux im allgemeinen, Qnap spezifische Eigenheiten im besonderen) und
    b) einen erheblichen Zeitaufwand das Ganze per Trial & Error zum Laufen zu bekommen

    voraus.
    Meiner Meinung nach lohnt es sich da eher ein wenig Zeit in das Erlernen von Docker & Co zu investieren oder eben auf ein anderes Gerät zu setzen. Ein Raspberry Pi kann ohne Probleme passiv gekühlt werden und auch kleine Mini PCs wie Intel NUCs gibt es mit passiver Kühlung. Insbesondere wenn das NAS nicht durchgehend laufen muss, könnte sich ein anderes Gerät für die Heimautomatisierung lohnen (ggf. sogar um das NAS dadurch aufzuwecken, wenn es dann doch mal gebraucht wird)

    Und zu guter Letzt noch: wenn du keine Festplattengeräusche hören möchtest, dann kannst du doch (je nach Geldbeutel und Datenmengen) einfach welche einsetzen, die keine Geräusche machen, konkret also SSDs.

    Als komplett andere Alternative kann ich allen die mit Docker kämpfen noch die Linux Station ans Herz legen. Auch hier können Geräte in den Container "reingereicht" werden und darin kann man dann tatsächlich wie gewohnt sudo apt install XY ausführen.

    Fände es schon ganz nice wenn später alles auf der QNAP läuft und nicht noch irgendwo ein Raspberry rumfliegt

    Das hatte ich bisher auch immer so vor, aber mittlerweile habe ich extra für Home Assistant doch einen Pi eingesetzt. Mit den fertigen Images ist es viel einfacher, als sich mit so Problemchen wie dem Device auf dem NAS rumzuschlagen. Weiterhin kann ich mit einem separaten Gerät dem NAS sagen wann es z.B. schlafen gehen soll :)

    Eine PiHole Alternative names "Ad Guard Home" ist übrigens als Home Assistant Add On verfügbar und kann bequem über Home Assistant gemanaged werden.