Neues YouTube-Video: Visualisierung im Devices-Adapter

[Codierknecht]

Ich bin kein wirklicher Docker-Experte und weiß auch nicht, was diese "hohe Priorität" im Container-Manager wirklich bewirkt.
Ich könnte mir vorstellen, dass darüber geregelt wird, unter welchem Account ein Container läuft (eingeschränkte oder Root-Rechte).
Dann könnte evtl sowas helfen:

[OliverIO]

Geht man dazu über @Codierknecht

Nicht ganz
Der Container erhält zwar mehr Rechte, aber eher so in Bezug Netzwerk und weiteres Mounting von Geräten.

Bei Verzeichnissen gelten die gleichen Zugriffsregeln wie immer. Der Prozess muss das Recht haben, auf die Datei oder den Ordner zugreifen zu können.

Früher haben die meisten Container mit Root gearbeitet. Mittlerweile geht man dazu über mit dem Standard User oder sogar mit einzelnen speziellen User Ids zu arbeiten.

[Codierknecht]

@OliverIO
Ich bezog mich hier auf das Problem mit dem Z-Wave Container und der "hohen Priorität" im Synology Container-Manager.

By the way: Vom Handy gesendet? Dann hat die KI den Sinn reichlich entstellt

[OliverIO]

@Codierknecht

Ja, vom Handy, aber nein nicht mit KI sondern nur diktiert (und nicht gut genug kontrolliert)

[juggi1962]

@codierknecht , @oliverio
Wenn ich darf habe ich was gefunden was mir auch die KI (Copilot) vorgeschlagen hat.
Ich weiß, dass man das hier nicht so gerne sieht aber ich habe es ausprobiert und was soll ich sagen es hat funktioniert.

services:
  zwave_js_ui:
    container_name: zwave_js_ui_ARCANE
    image: zwavejs/zwave-js-ui
    hostname: zwave_js_ui
    network_mode: "host"
    volumes:
      - /volume1/docker/zwavejs:/usr/src/app/store
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
    environment:
      PACKAGES: "nano openssh-server"
      AVAHI: true
    restart: unless-stopped
    cpu_shares: 2048

das mit
devices:
- /dev/ttyACM0:/dev/ttyACM0
und
cpu_shares: 2048

ist neu, Devices ist klar das ist der zWave USB Stick
und das (cpu_shares: 2048) sollte die Einstellung für die hohe Priorität sein.
zumindest hat das so die Ki erklärt

[Homoran]

@juggi1962 sagte:

Ich weiß, dass man das hier nicht so gerne sieht

Das musst du missverstanden haben!
Du sollst die Antwort verstehen und bewerten können.

So ist z.b.

@juggi1962 sagte:

dev/ttyACM0:/dev/ttyACM0

Relativ unspezifisch und die dev werden ggf. Bei einem Neustart anders vergeben.
In einer nativen Installation soll man daher mit /dev/serial/by-id/ arbeiten, weil das hardwareselektiv ist.

Ob und wie das bei Docker gehandhabt wird, entzieht sich meiner Kenntnis

[juggi1962]

@Homoran sagte:

Das musst du missverstanden haben!
Du sollst die Antwort verstehen und bewerten können.

So ist z.b.

ja das ist ja gut und recht wenn man sich damit auskennt, ich bin jemand der es versucht solange ich weiß, dass ich wenn es nicht geht wieder zurück kann. Ob das immer schlau ist, wahrscheinlich nicht, ich kann es halt nur so versuchen und

@Homoran sagte:

Relativ unspezifisch und die dev werden ggf. Bei einem Neustart anders vergeben.
In einer nativen Installation soll man daher mit /dev/serial/by-id/ arbeiten, weil das hardwareselektiv ist.

und das ist schon wieder mal was was ich nicht verstehe (/dev/serial/by-id/ arbeiten) :-)

Wenn jemand eine bessere Lösung für mich hat dann bitte gern, momentan bin ich froh, dass nach der ganzen Umstellung alles läuft.

[Thomas Braun]

@juggi1962

https://wiki.archlinux.org/title/Persistent_block_device_naming

If your machine has more than one drive sharing a naming scheme, the order in which their corresponding device nodes are added is arbitrary. This may result in block device names (e.g. /dev/sda and /dev/sdb, /dev/nvme0n1 and /dev/nvme1n1, /dev/mmcblk0 and /dev/mmcblk1) switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.

Kurz: Die Zuordnung zu den Geräte-Dateien unter /dev/tty* können sich jederzeit zufällig ändern. Deswegen spricht man die Geräte besser über andere Wege an. Einer dieser Wege ist 'by-id'.

[juggi1962]

@codierknecht , @thomas-braun , @oliverio

Hallo noch mal ich.
Mir ist gerade aufgefallen, dass ich im Container Manager vom Synology NAS das

juggi1962 sagte:

devices:

• /dev/ttyACM0:/dev/ttyACM0

Gar nicht im Compose stehen hatte, sondern nur das (mit hoher Priorität ausführen) nachträglich im Container angeklickt hatte.

Jetzt habe ich wieder mal die KI von Google bemüht weil mir euer Bedenken keine Ruhe gelassen hat, was die dazu meint und jetzt geht es mit diesem Zusatz privileged: true im Compose ohne

• /dev/ttyACM0:/dev/ttyACM0
  Das sieht mir eher aus dass das passt und wirklich die hohe Priorität einschaltet.
  Wenn ich es jetzt so mache brauche ich die Zeile die nicht wirklich richtig war gar nicht mehr.

services:
  zwave_js_ui:
    container_name: zwave_js_ui_ARCANE
    image: zwavejs/zwave-js-ui
    hostname: zwave_js_ui
    network_mode: "host"
    privileged: true # <-- Das schaltet die hohe Priorität für USB-Rechte ein
    volumes:
      - /volume1/docker/zwavejs:/usr/src/app/store
    environment:
      PACKAGES: "nano openssh-server"
      AVAHI: "true"
    restart: unless-stopped

Im Synology NAS habe ich schon wie ich mit den Containern angefangen habe im Aufgabeplaner ein kleines Skript von dieser Seite
https://mariushosting.com/synology-how-to-add-usb-support-on-dsm-7/
nachgebaut, denn ab Synology DSM 7 fehlen die USB Treiber und deshalb werden keine USB Sticks oder Geräte gefunden.
Alles andere steht sehr gut auf dieser Seite beschrieben.

Ich hoffe der Link darf sein wenn nicht bitte ändern.

Ich denke einige werden das schon wissen was USB und Synology DSM 7 betrifft aber ich wollte es einfach sagen.
Danke noch mal an ALLE für eure Hilfe und Geduld.
Gruß Jürgen

[OliverIO]

@juggi1962

nochmal ne frage zu den extra packages nano und openssh

den openssh server solltest du eigentlich nicht benötigen,
da sicherlich auch die synologie irgendwo in der containerverwaltung einen knopf hat, der dir eine shell "IM" container öffnet.

dem internet nach müsste das so gehen

• Container Manager öffnen.
• Zu Container wechseln.
• Gewünschten Container auswählen.
• Auf Terminal oder Details → Terminal klicken.
• /bin/bash oder generischer /bin/sh eingeben um die shell zu starten (nicht in allen containern ist bash die standard shell, aber gott sei dank bei den meisten)

nano ist meines erachtens ok für das betrachten von dateien "IM" container.
du solltest da allerdings nichts ändern,
da alle relevanten dateien/verzeichnis an denen nu etwas ändern solltest als volume bereitgestellt werden und du auch auf deine festplatte mappen kannst. auf diese kannst du ja auch ohne laufenden container bzw. mit den normalen Möglichkeiten deines Host-systems (synology) zugreifen.

würdest du an anderen dateien, welche nicht per volume definition abgedeckt ist etwas ändern, dann wären diese Änderungen bei der nächsten container regeneration oder update wieder weg.
als nie tun. sonst gibt es später überraschungen.

falls du in besonderen fällen doch mal an so einer datei was ändern willst, dann kannst du selbst mit einer volumedefinition so eine datei nach "draussen" legen. dann passt das auch beim nächsten update oder regeneration.

ich hoffe ich hab dich damit noch überfordert. ansonsten stelle bitte fragen.
das sind die feinen unterschiede zwischen docker und einer VM.
wenn man das verstanden hat, macht das, das konzept sehr flexibel, updates von applikation und betriebssystem sind super easy.

würdest du IM container andere

[juggi1962]

@OliverIO sagte:

nochmal ne frage zu den extra packages nano und openssh

Hallo leider überfordert es mich gerade, aber die Zusammenstellung in den Compose habe ich von @codierknecht bekommen, leider sagt mir das alles noch nichts. Werde mich aber Morgen mal mit dem was du gerade geschrieben hast befassen.
Danke und gute Nach

[Codierknecht]

@juggi1962
Du kannst natürlich auch beide Packages weglassen.
In die Shell kommt man auch direkt über Arcane. Meiner Meinung nach sogar komfortabler als über den eingebauten Weg in Synology.

Und "nano" braucht man auch nur, um Dateien zu bearbeiten. Dürfte bei Dir auch nicht nötig sein.
Ich pack den einfach reflexartig in meine Container, da mir "vi" nicht zusagt.

[juggi1962]

@Codierknecht sagte:

@juggi1962
Du kannst natürlich auch beide Packages weglassen.
In die Shell kommt man auch direkt über Arcane. Meiner Meinung nach sogar komfortabler als über den eingebauten Weg in Synology.

Und "nano" braucht man auch nur, um Dateien zu bearbeiten. Dürfte bei Dir auch nicht nötig sein.
Ich pack den einfach reflexartig in meine Container, da mir "vi" nicht zusagt.

Alles Klar eigentlich habe ich nicht vor irgend was in einer Datei zu ändern, außer es gibt Probleme und ihr oder sonst jemand wo sich damit auskennt sagt mir wie wo und was. Bin hauptsächlich Anwender und versuche die Sachen die es schon fertig gibt mir beizubringen und ich denke jetzt habe ich ein Container System das einfach zum aktualisieren ist und das wollte ich.
Dazu hätte ich aber noch eine Frage es gibt für das Zwave js iu Image ein Update. Ich habe unter Projekte ganz rechts auf Pullen & neu Deployen geklickt, ich hoffe das passt so. Auf alle fälle wurde der Container gestoppt und wieder gestartet und alles läuft wie es soll. Bei den Image war jetzt ein Zweites Zwave image das aber gelb war ich denke das kann man löschen, oder? Ich habe dort auf ungenutzte bereinigen geklickt. Unter Container gibt es oben Container Aktualisieren oder nur Aktualisieren für was braucht man das. Falls es eine gute Beschreibung von Arcane auf Deutsch gibt bitte sagen englisch hilft mir nicht wirklich weiter

[OliverIO]

@juggi1962

ja genau so:

• pull des images (damit wird das image heruntergeladen)
• stoppen des containers
• starten des containers (dadurch wird dann automatisch das neue image verwendet)
• fertig

zum automatischen aktualisieren bzw. nur die information darüber kann man mit
https://hub.docker.com/r/containrrr/watchtower
machen.
es funktioniert noch,
aber leider wird das projekt aktuell nicht weitergeführt, es gibt aber alternativen

ich würde das aber nur über den monitor modus durchführen.
man sollte aber regelmäßige backups seiner docker volumes haben, so das man ggfs. das auch wieder rückgängig machen kann, falls was nicht richtig funktioniert

evtl mal noch was zu den gefahren von docker containern.
der ersteller kann in das image reinmachen was er will. ggfs auch schadcode.
ein container ist in der regel vom host gekapselt, allerdings kann ohne weitere maßnahmen der container in deinem LAN aktiv sein und auch nach raussen ins internet funken.

daher bitte nur images von geprüften quellen übernehmen oder selbst einen review durchführen (je nach eigener fähigkeit), das da nichts drin ist was man nicht haben will.
ist aber das gleiche wie mit jeder anderen software auf deinem computer

auf dockerhub sieht man das an den folgenden badges am image

ein weiterer hinweis (auch wenn nicht ganz so sicher) ist die Anzahl der pulls oder man recherchiert im netz nach artikel zum image. wenn darüber öfters geschrieben wird kann man es schon nutzen, aber wie gesagt, letztendlich keine 100% sicherheit

[juggi1962]

@OliverIO sagte:

@juggi1962

ja genau so:

• pull des images (damit wird das image heruntergeladen)
• stoppen des containers
• starten des containers (dadurch wird dann automatisch das neue image verwendet)
• fertig

zum automatischen aktualisieren bzw. nur die information darüber kann man mit
https://hub.docker.com/r/containrrr/watchtower
machen.
es funktioniert noch,
aber leider wird das projekt aktuell nicht weitergeführt, es gibt aber alternativen

ich würde das aber nur über den monitor modus durchführen.
man sollte aber regelmäßige backups seiner docker volumes haben, so das man ggfs. das auch wieder rückgängig machen kann, falls was nicht richtig funktioniert

evtl mal noch was zu den gefahren von docker containern.
der ersteller kann in das image reinmachen was er will. ggfs auch schadcode.
ein container ist in der regel vom host gekapselt, allerdings kann ohne weitere maßnahmen der container in deinem LAN aktiv sein und auch nach raussen ins internet funken.

daher bitte nur images von geprüften quellen übernehmen oder selbst einen review durchführen (je nach eigener fähigkeit), das da nichts drin ist was man nicht haben will.
ist aber das gleiche wie mit jeder anderen software auf deinem computer

auf dockerhub sieht man das an den folgenden badges am image

ein weiterer hinweis (auch wenn nicht ganz so sicher) ist die Anzahl der pulls oder man recherchiert im netz nach artikel zum image. wenn darüber öfters geschrieben wird kann man es schon nutzen, aber wie gesagt, letztendlich keine 100% sicherheit

Super, danke ich betreibe nur die 4 Container mehr brauche ich nicht und automatisch muss das Update nicht laufen. Schaue sowieso fast jeden Tag mal rein ob alles läuft wie es soll und ja ich mache Tägliche Backups von dem Docker Ordner und dem Rest einmal im 10 und 22 Uhr und das auf 2 externen Festplatten und auf ein reines Backup Nas das bei meiner Tochter steht. Besser kann man sich nicht mehr absichern 😀
Danke noch mal für eure Hilfe, hab wieder einiges gelernt.