Offizielles FHEM Docker Basis Image für verschiedene Plattformen

Begonnen von Loredo, 28 Juli 2018, 21:24:57

Vorheriges Thema - Nächstes Thema

balli1187

Zitat von: Wernieman am 20 Mai 2020, 11:37:59
Naja .. kommt drauf an wie Docker configuriert ist.

Aber unabhängig davon ... Du willst per "docker exec" praktisch einen Befehl auf einem anderen Container anstoßen? Der Anderweitig nicht erreichbar ist?
An Docker selbst kann ich nur bendingt was Konfigurieren, da das (sehr wahrscheinlich) durch das QNAP OS geblockt oder beim nächsten Update wieder zurückgesetzt wird.

Der NC-Container ist schon von außen erreichbar (sonst würde es ja mit dem Sync auf die Clients, etc. nicht funktionieren) aber auf dem Weg kann man keine Kommandos an das backend schicken. Das ist ja auch gut so, sonst könnte ja jeder von draußen in meiner Config rumbasteln und Sicherheitsmechanismen aushebeln etc.
Per 'Docker exec' (oder über die Shell in portainer) kann man diese Befehle aber absetzen. Ich könnte mir vorstellen, dass es auch mit einer ssh-Verbindung in den Container gehen könnte aber dafür müssten beide Container wieder ins selbe Netz.

Wahrscheinlich übersteigt es auch ein wenig mein Docker-/Netzwerkwissen aber ich suche nach eine möglichkeit ohne ein großes Sicherheitsloch reinzureißen....


Gesendet von iPhone mit Tapatalk
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

Wernieman

Sicherheitstechnisch ist es nicht schön, wenn ein Container aus seinem Container raus docker steuern kann. Mit docker geht mehr als nur "exec". Genau so unschön ist es, wenn in einem Container (=Dienst) mehr als ein Dienst enthalten ist. Besser ist: Ein Dienst - Ein Container. Du hast z.B. auch einen eigenen mysql-Container und baust nicht alles in einen ein.

(Btw: Deshalb baut man in der Containerwelt für jedes Projekt sogar eigene Container, obwohl z.B. mysql auch mehrere Datenbanken könnte)

Da ich nicht weiß, wie genau der Notifikation-Versand bei nextcloud funktioniert, steuerbar ist, kann ich Dir da wenig Hilfestellung geben. Muß das Script wirklich auf der gleichen Instanz laufen?

Auch wenn es jetzt OT wird:
Rein von der Basis her ist Docker kein Sicherheitsgewinn. Der Vorteil von Docker sind übersichtliche Dienste -> dadurch einfach zu Konfigurieren und nur notwendige Libarys/Erweiterungen -> dadurch sicherer. Das ist anders als z.B. VMs, die auch einen Sicherheitsgewinn darstellen. Es ist einfacher aus Docker auszubrechen als aus einer VM
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

balli1187

Zitat von: Wernieman am 20 Mai 2020, 12:24:39
Sicherheitstechnisch ist es nicht schön, wenn ein Container aus seinem Container raus docker steuern kann. Mit docker geht mehr als nur "exec". Genau so unschön ist es, wenn in einem Container (=Dienst) mehr als ein Dienst enthalten ist. Besser ist: Ein Dienst - Ein Container. Du hast z.B. auch einen eigenen mysql-Container und baust nicht alles in einen ein.

(Btw: Deshalb baut man in der Containerwelt für jedes Projekt sogar eigene Container, obwohl z.B. mysql auch mehrere Datenbanken könnte)
Soweit klar. Habe ich auch so angefangen/aufgebaut. Meine NC und FHEM haben jeweils eigene Maria-DB-Container, um es nicht zu mischen.

ZitatDa ich nicht weiß, wie genau der Notifikation-Versand bei nextcloud funktioniert, steuerbar ist, kann ich Dir da wenig Hilfestellung geben. Muß das Script wirklich auf der gleichen Instanz laufen?
Nextcloud nutzt die OCC (OenCloud Console) als command-line Interface.
Laut Doku ist das ein php-Skript. Was dieses dann wiederum genau macht und ob es auf einem anderen Server laufen könnte, müsste man wohl die NC-Entwickler fragen. Ich würde das aber von der Sache her eher nicht 'zerreißen' wollen.

ZitatAuch wenn es jetzt OT wird:
Rein von der Basis her ist Docker kein Sicherheitsgewinn. Der Vorteil von Docker sind übersichtliche Dienste -> dadurch einfach zu Konfigurieren und nur notwendige Libarys/Erweiterungen -> dadurch sicherer. Das ist anders als z.B. VMs, die auch einen Sicherheitsgewinn darstellen. Es ist einfacher aus Docker auszubrechen als aus einer VM
Hm.... wie gesagt... übersteigt vielleicht mein Wissen/Verständniss (daher bitte das folgende als Frage verstehen) aber wie man an dem Beispiel hier sieht, sind ja durch Docker hier doch ein paar weitere Hürden eingebaut. Hätte ich alles direkt auf dem Host, wäre es in FHEM mit einem einfachen {system ()} getan, richtig?!

Würdest du das nicht als sicherheitsgewinn sehen?


Gesendet von iPhone mit Tapatalk
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

Wernieman

Der Vorteil von docker auf einer NAS ist, das Du unabhängig vom Betriebsystem der NAS bist. Wenn durch ein Update der NAS-Software etwas geändert wird, funktioniert Dein installiertes FHEM nicht, bei docker dagegen schon. Auch mußt Du dazu auch nichts mehr auf dem NAS installieren ....

Das FHEM-Docker ist quasi ein "fertiges-Produkt".

Habe jetzt mich mal wegen OCC informiert, da es mich privat interessiert, aber nichts rausgefunden ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

balli1187

Zitat von: Wernieman am 20 Mai 2020, 13:02:42
Der Vorteil von docker auf einer NAS ist, das Du unabhängig vom Betriebsystem der NAS bist. Wenn durch ein Update der NAS-Software etwas geändert wird, funktioniert Dein installiertes FHEM nicht, bei docker dagegen schon. Auch mußt Du dazu auch nichts mehr auf dem NAS installieren ....

Das FHEM-Docker ist quasi ein "fertiges-Produkt".

Habe jetzt mich mal wegen OCC informiert, da es mich privat interessiert, aber nichts rausgefunden ...
Wie gesagt... Vorteile sind soweit verstanden. Ich habe es bisher auch als kleines Plus an Sicherheit verstanden. Sollte dem nicht so sein, würde ich gern verstehen warum.

Spricht denn etwas dagegen die docker-cli im Container zu installieren? Wenn es denn anders nicht geht?

Push notifications sind schon nett aber dafür eine extra App usw. würde ich nicht installieren (krieg ich auch der Frau nicht vermittelt).


Gesendet von iPhone mit Tapatalk
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

Wernieman

Ja geht ... irgendwie kann man im fhem-docker so etwas auch festlegen. Wenn Du es manuell machst, mußt Du es beim nächsten Containerupdate manuell nachziehen.

Weiß jetzt aktuell nur nicht, ob das ubuntu-docker ausreicht, oder Du eine externe apt-Quelle dazunehmen müsstest (siehe ubuntu-install auf der docker-Webside).
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

volschin

Zitat von: Wernieman am 20 Mai 2020, 12:24:39Rein von der Basis her ist Docker kein Sicherheitsgewinn. Der Vorteil von Docker sind übersichtliche Dienste -> dadurch einfach zu Konfigurieren und nur notwendige Libarys/Erweiterungen -> dadurch sicherer. Das ist anders als z.B. VMs, die auch einen Sicherheitsgewinn darstellen. Es ist einfacher aus Docker auszubrechen als aus einer VM
Die Aussage halte ich so nicht für korrekt. Docker bringt eine Reihe an Sicherheitsfeatures mit und wenn man die nicht mit privileged=true, cap-add=all und seccomp=unconfined gleich unbedarft abschaltet, weil das in irgendeiner Anleitung gepostet wurde, dann funktioniert das ziemlich gut.
In einem guten Image läuft wie Du geschrieben hast im wesentlichen der eine Prozess. Sonstige Betriebsystem-Dateien, oftmals ausgenutzt stehen kaum zur Verfügung.
Das FHEM Basisimage ist aber nun leider eher das Gegenteil. Keine Spur von Dienstetrennung, leider auch weil die FHEM-Software so entwickelt ist, dass sie es an vielen Stellen nicht zulässt.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

BAfH

Guten Abend,
ich hatte FHEM im Docker auf einen PI3 nach Matthias Kleine https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html vermutlich waren 1 GB RAM zu wenig, also Umzug auf einen PI4 mit 4GB RAM.
Alle neu, nur diesmal habe ich mir das offizielle FHEM Docker Image gezogen. Meine docker-compose.yml
version: '3'

services:
    fhem:
        image: fhem/fhem:latest
        restart: always
        ports:
            - "8083:8083"
            - "8084:8084"
            - "7072:7072"
            - "8090:8090"
        volumes:
         - /etc/localtime:/etc/localtime:ro
         - /etc/timezone:/etc/timezone:ro
         - ./fhem/core/:/opt/fhem/
        network_mode: host
#
#        networks:
#            - fhem-network
        devices:
            - "/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0:/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0"
            - "/dev/ttyUSB0:/dev/ttyUSB0"
            - "/dev/ttyUSB1:/dev/ttyUSB1"
        environment:
            #FHEM_UID: 1000
            #FHEM_GID: 1000
            # User root           
            #FHEM_UID: 0
            #FHEM_GID: 0
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
        depends_on:
            - "mysql"
            - "mqtt"
    mysql:
        restart: always
        expose:
            - "3306"
            - "33060"
        ports:
            - "3306:3306"
            - "33060:33060"
        image: hypriot/rpi-mysql
        volumes:
            - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
            - ./mysql/data:/var/lib/mysql
        environment:
            - MYSQL_ROOT_PASSWORD=KQW8JgZEDb4CpSMaz
            - MYSQL_DATABASE=fhem
        networks:
            - fhem-network
    mqtt:
        restart: always
        expose:
            - "1883"
            - "9001"
        ports:
            - "1883:1883"
            - "9001:9001"
        image: pascaldevink/rpi-mosquitto
        networks:
            - fhem-network
        volumes:
            - ./mqtt/config/:/mqtt/config/
            - ./mqtt/log/:/mqtt/log/
            - ./mqtt/data/:/mqtt/data/

    xiaomibridge:
        restart: always
        image: koenkk/zigbee2mqtt
        devices:
          - "/dev/ttyACM0:/dev/ttyACM0"
        volumes:
            - /dev/serial/by-id:/dev/serial/by-id
            - ./xiaomibridge/data/:/app/data
        ports:
            - "4000:4000"
        networks:
            - fhem-network
        depends_on:
            - "mqtt"
    unifi:
        image: ryansch/unifi-rpi:latest
        container_name: unifi
        restart: always
        network_mode: host
        ports:
            - "8443:8443"
        # Uncomment the following to set java options
        # environment:
        #   JAVA_OPTS: -Xmx512M
        volumes:
           # Unifi v5.0.7 creates all of these directories (some remain empty)
           - config:/var/lib/unifi
           - log:/usr/lib/unifi/logs
           - log2:/var/log/unifi
           - run:/usr/lib/unifi/run
           - run2:/run/unifi
           - work:/usr/lib/unifi/work
volumes:
  config:
    driver: local
  log:
    driver: local
  log2:
    driver: local
  run:
    driver: local
  run2:
    driver: local
  work:
    driver: local


networks:
    fhem-network:
        driver: bridge


irgendwie sind die Rechte verwirrt....
aufgefallen war mir es, als ich ssh remote eingerichtet habe. Im Altsystem nach Ottos Anleitung läuft es im Neusystem nicht. Hier merkt eich auch, das der User fhem nicht existiert.
Startlog im Altsystem
ZitatPreparing user environment ...
1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
5. Correcting group ownership for /dev/tty* ...
6. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
7. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
8. Updating /etc/sudoers.d/fhem ...
9. Updating SSH key pinning and SSH client permissions for user 'fhem' ...
Preparing configuration ...
Starting FHEM ...
Rechte im Altsystem
Zitatpi@FHEM-OLD:~ $ ls -lha fhem-docker/fhem/core/
insgesamt 996K
drwxr-xr-x 14 6061 6061 4,0K Mai 27 19:42 .
drwxrwxr-x  3 pi   pi   4,0K Feb 27  2019 ..
drwxr-xr-x  2 6061 6061 4,0K Mai 24 23:59 backup
-rw-r--r--  1 6061 6061 321K Mär  6 10:22 CHANGED
-rw-r--r--  1 6061 6061  145 Mär  6  2019 configDB.conf
-rw-r--r--  1 6061 6061  40K Mär  6 10:22 configDB.pm
drwxr-xr-x 44 6061 6061 4,0K Feb 27  2019 contrib
-rw-r--r--  1 6061 6061  18K Feb 27  2019 COPYING
drwxr-xr-x  3 6061 6061 4,0K Feb 27  2019 demolog
drwxr-xr-x  4 6061 6061 4,0K Feb 27  2019 docs
drwxr-xr-x  6 6061 6061  24K Mär 12 07:53 FHEM
-rwxrwxrwx  1 6061 6061 113K Mai 27 19:42 fhem.cfg
-rw-r--r--  1 6061 6061 113K Apr 15 10:52 fhem.cfg.bak
-rw-r--r--  1 6061 6061  516 Feb 27  2019 fhem.cfg.default
-rw-r--r--  1 6061 6061  25K Feb 25 13:34 fhem.cfg.demo
-rwxr-xr-x  1 6061 6061 157K Mär  6 10:22 fhem.pl
-rw-r--r--  1 6061 6061  28K Feb 27  2019 HISTORY
drwxr-xr-x  2 6061 6061 4,0K Mai 27 19:42 log
-rw-r--r--  1 6061 6061  42K Feb 25 13:34 MAINTAINER.txt
-rw-r--r--  1 6061 6061 5,0K Feb 27  2019 Makefile
drwxr-xr-x  3 6061 6061 4,0K Mär  6  2019 mnt
-rw-r--r--  1 6061 6061  13K Dez 23 11:31 muellkalender.ics
-rw-r--r--  1 6061 6061  935 Feb 27  2019 README_DEMO.txt
-rw-r--r--  1 6061 6061  374 Feb 27  2019 README.SVN
drwxr-xr-x  4 6061 6061 4,0K Feb 27  2019 restoreDir
drwx------  2 6061 6061 4,0K Mai 27 19:42 .ssh
drwxr-xr-x  2 6061 6061 4,0K Apr 10  2019 unused
-rw-r--r--  1 6061 6061 1,8K Feb 27  2019 UPGRADE
drwxr-xr-x  6 6061 6061 4,0K Feb 27  2019 webfrontend
drwxrwxrwx 11 6061 6061 4,0K Jul  4  2019 www

Startlog im Neusystem
ZitatPreparing initial start:
1. Installing FHEM to /opt/fhem
2. Patching fhem.cfg default configuration
3. Adding pre-defined devices to fhem.cfg

Preparing user environment ...
1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Creating log directory /opt/fhem/./log ...
5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
6. Enforcing file and directory permissions for /opt/fhem ...
7. Correcting group ownership for /dev/tty* ...
8. Correcting group ownership for /dev/serial/* ...
9. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
10. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
11. Updating /etc/sudoers.d/fhem-docker ...
12. Generating SSH Ed25519 client certificate for user 'fhem' ...
13. Generating SSH RSA client certificate for user 'fhem' ...
14. Generating SSH client configuration for user 'fhem' ...
15. Adding gateway.docker.internal to /etc/hosts ...
16. Adding host.docker.internal to /etc/hosts ...
17. Pre-authorizing SSH to Docker host for user 'fhem' ...
18. Updating SSH key pinning and SSH client permissions for user 'fhem' ...
Preparing configuration ... done

Rechte im Neusystem
Zitatpi@FHEM:~ $ sudo ls -lha fhem-docker/fhem/core/
insgesamt 868K
drwxr-x--- 15 6061 6061 4,0K Mai 25 15:04 .
drwxr-xr-x  3 root root 4,0K Mai 25 13:48 ..
-rw-r-----  1 6061 6061 335K Mai 25 15:01 CHANGED
drwxr-x---  3 6061 6061 4,0K Mai 25 13:49 .config
-rw-r--r--  1 root root  146 Mai 25 14:22 configDB.conf
-rw-r-----  1 6061 6061  39K Mai 11 13:17 configDB.pm
drwxr-x--- 48 6061 6061 4,0K Mai  4 13:29 contrib
-rw-r-----  1 6061 6061  18K Dez 30 15:02 COPYING
drwxr-x---  3 6061 6061 4,0K Dez 30 15:02 demolog
drwxr-x---  4 6061 6061 4,0K Mai 25 13:48 docs
drwxr-x---  6 6061 6061  20K Mai 25 15:01 FHEM
-rw-r-----  1 6061 6061  82K Mai 27 11:10 fhem.cfg
-rw-r-----  1 6061 6061 2,2K Mai 25 13:55 fhem.cfg.bak
-rw-r-----  1 6061 6061  516 Mai 25 13:48 fhem.cfg.default
-rw-r-----  1 6061 6061  25K Dez 30 15:02 fhem.cfg.demo
-rwxr-----  1 6061 6061 160K Mai 25 15:01 fhem.pl
-rw-r-----  1 6061 6061  28K Dez 30 15:02 HISTORY
drwxr-x---  2 6061 6061 4,0K Mai 27 00:00 log
-rw-r-----  1 6061 6061  42K Mai 25 15:01 MAINTAINER.txt
-rw-r-----  1 6061 6061 5,0K Jan 27 12:22 Makefile
-rwxr-xr--  1 root root  13K Mai 25 14:24 muellkalender.ics
drwxr-x---  3 6061 6061 4,0K Mai 25 13:49 .npm
-rw-r-----  1 6061 6061   25 Mai 18 13:17 .proverc
-rw-r-----  1 6061 6061  935 Dez 30 15:02 README_DEMO.txt
-rw-r-----  1 6061 6061  374 Dez 30 15:02 README.SVN
drwxr-----  4 6061 6061 4,0K Mai 25 14:05 restoreDir
drwx------  2 6061 6061 4,0K Mai 25 13:56 .ssh
drwxr-----  2 6061 6061 4,0K Mai 25 14:04 unused
-rw-r-----  1 6061 6061 2,2K Mär  9 12:13 UPGRADE
drwxr-x---  6 6061 6061 4,0K Dez 30 15:02 webfrontend
drwxr-x---  9 6061 6061 4,0K Mai 25 14:04 www

Den user fhem habe ich neuangelegt
Zitatsudo useradd --system --home /home/pi/fhem-docker/fhem/core --gid dialout --shell /bin/false fhem

Komme irgendwie nicht weiter, gesucht jede Menge und nichts gefunden...
bin über jeden tipp dankbar
Gruß Thorben
mit sonnige Grüße aus Schönow

volschin

Der User fhem existiert schon, aber im Docker Container. Mir scheint du suchst ihn im Host System? Wie soll er da hin kommen? Was bezweckst Du damit?
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

BAfH

Ich möchte z.B. remote SSH im FHEM für sysmon... Ging im Altsystem.  Auch nutze in WINSCP um z.B. ale HTML File zu kopieren. Nur hat PI keine Rechte, im Altsystem ja. Daher bin ich verwirrt.
Gruß Thorben
mit sonnige Grüße aus Schönow

kadettilac89

du hast scheinbar den user fhem schon auf dem Host angelegt, jedoch mit /bin/false ... welcher Test schlägt fehl? Damit kannst du keine Console öffnen. War das der Fehler den du siehst? Fehlermeldungen?

Setzte mal /bin/bash als shell und teste nur mal    ssh <ip host> und dann solltest du einen Login-Screen erhalten. Wenn das geht prüfst du nochmal ob ssh-keys eingetragen sind und postest die Fehler die du erhälst.

führe mal

whoami
ssh fhem@host.docker.internal


du schreibst dass du die Anleitung von Otto ausgeführt hast, für welchen Host? Wenn du gateway.docker.internal verwendet hast, dann den obigen Befehl auch damit testen.

Ich denke es liegt am EDSA-Fingerprint-Meldung oder an einem Key-Problem, falscher Host, User ... was auch immer




BAfH

Sorry, Pfingsten.
Ich haben jetzt die Schritte aus Otto's Blog

  • ssh-keygen -t rsa
  • ssh-copy-id -i ~/.ssh/id_rsa pi@<remote-system>
in der Console des Docker pi ausgeführt.
Fehlermeldung
Host key verification failed.
Jetzt die o.g. Befehle mittels Portainer Console im FHEM Container ausgeführt. Siehe da Remote ssh klappt.
defmod RPIPOOL SYSMON ssh:pi@192.168.10.60
Liefert mir Ergebnisse. Danke für den Hinweis...
Was mich nur wundert... Am Altsystem habe ich definitiv das nur auf der Console des Host durchgeführt.
Vermutlich habe ich soviel gefummelt und geändert, das ist der erste Versuch fhem und Docker, das ich wohl unbewusst quasi alles irgendwie geschafft habe.  ::)
Eigentlich ist das alles logisch, nur diesen Hinweis benötigte ich.

Jetzt geht es mir noch um die Rechte. Ziel ist hier, alle (viele) Daten ändere ich auf meinem Rechner ist halt eleganter (für mich) übertrage diese nur mittels WinSCP.
Gerade die HTML Files für TabletUI.
Nach dem Start von FHEM im Docker hat der User pi keine Rechte mehr auf das Filesystem.
Hier mal die Rechte lt fhem Console
root@FHEM:/opt/fhem# ls -lha
total 948K
drwxr-x--- 15 root root 4,0K Jun  2 08:59 .
drwxr-xr-x  1 root root 4,0K Mai 25 13:43 ..
-rw-r-----  1 root root 335K Mai 25 15:01 CHANGED
drwxr-x---  3 root root 4,0K Mai 25 13:49 .config
-rw-r-----  1 root root  146 Mai 25 14:22 configDB.conf
-rw-r-----  1 root root  39K Mai 11 13:17 configDB.pm
drwxr-x--- 48 root root 4,0K Mai  4 13:29 contrib
-rw-r-----  1 root root  18K Dez 30 15:02 COPYING
drwxr-x---  3 root root 4,0K Dez 30 15:02 demolog
drwxr-x---  4 root root 4,0K Mai 25 13:48 docs
drwxr-x---  6 root root  20K Jun  2 08:59 FHEM
-rw-r-----  1 root root  84K Jun  2 08:59 fhem.cfg
-rw-r-----  1 root root  82K Mai 28 19:39 fhem.cfg.bak
-rw-r-----  1 root root  516 Mai 25 13:48 fhem.cfg.default
-rw-r-----  1 root root  25K Dez 30 15:02 fhem.cfg.demo
-rwxr-----  1 root root 160K Mai 25 15:01 fhem.pl
-rw-r-----  1 root root  28K Dez 30 15:02 HISTORY
drwxr-x---  2 root root 4,0K Jun  2 09:01 log
-rw-r-----  1 root root  42K Mai 25 15:01 MAINTAINER.txt
-rw-r-----  1 root root 5,0K Jan 27 12:22 Makefile
-rw-r-----  1 root root  13K Mai 25 14:24 muellkalender.ics
drwxr-x---  3 root root 4,0K Mai 25 13:49 .npm
-rw-r-----  1 root root   25 Mai 18 13:17 .proverc
-rw-r-----  1 root root  935 Dez 30 15:02 README_DEMO.txt
-rw-r-----  1 root root  374 Dez 30 15:02 README.SVN
drwxr-x---  4 root root 4,0K Mai 25 14:05 restoreDir
drwx------  2 root root 4,0K Mai 29 10:38 .ssh
drwxr-x---  3 root root 4,0K Mai 18 13:17 t
drwxr-x---  2 root root 4,0K Mai 25 14:04 unused
-rw-r-----  1 root root 2,2K Mär  9 12:13 UPGRADE
drwxr-x---  6 root root 4,0K Dez 30 15:02 webfrontend
drwxr-x---  9 root root 4,0K Mai 25 14:04 www

Kann ich hier was dauerhaft ändern??
Danke
Gruß Thorben
mit sonnige Grüße aus Schönow

kadettilac89

Zitat von: BAfH am 02 Juni 2020, 11:23:38

Liefert mir Ergebnisse. Danke für den Hinweis...

Kann ich hier was dauerhaft ändern??
Danke

wenn du pi als User auf dem Host nutzt dann kannst du den angelegten User fhem wieder löschen wenn du diesen nicht brauchst - auf dem Host, nicht im Container.

Dauerhaft ändern? Erstmal die Rechte wieder korrekt setzen auf 6061:6061 (oder dem User den du nutzt). Im Folgenden gehe ich davon aus, dass du default 6061:6061 nutzt.



Du könntest dir einen User auf dem Host anlegen der die UID:GID 6061:6061 hat. Diesen dann für WinSCP nutzen. Dann sind die Rechte immer korrekt.

Erstmal Ownership übernehmen ... dazu musst du im Docker-Verzeichnis sitzen - am Host nicth im Docker Container -, sonst überschreibst du dir alles andere auch ...

sudo chown 6061:6061 ./*


Dann User mit UID 6061 anlegen

sudo useradd fhemusr --uid 6061
sudo passwd fhemusr geheimespasswort


mit den beiden Befehlen erstellst du dir auf dem Host einen User der die UID vom Fhem-Container hat. Diesen User fhemusr mit Password geheimespasswort nutzt du in WinScp und hast automatisch die richtigen Rechte.

... und vorher ein Backup machen sollte etwas schief laufen ...

BAfH


  • User fhem auf dem Host gelöscht
  • root@FHEM:/home/pi/fhem-docker/fhem/core# sudo chown 6061:6061 ./*
Hat nicht das gebrach was ich hoffte,  alles nochmal gründlich geprüft und siehe da, Fehler gefunden.
In der docker-compose.yml waren die Zeilen auskommentiert
   
FHEM_UID: 1000
FHEM_GID: 1000

Geändert, neu gestartet. Jetzt läuft wieder alles so wie ich es erwarte, ich hatte den user pi des Host schon vorher zur Gruppe 6061 hinzugefügt habe.
Machmal sieht man den wald vor lauter Bäume nicht. Danke für Ratschläge.
Gruß Thorben
mit sonnige Grüße aus Schönow

kadettilac89

Zitat von: BAfH am 02 Juni 2020, 16:35:18
Geändert, neu gestartet. Jetzt läuft wieder alles so wie ich es erwarte, ich hatte den user pi des Host schon vorher zur Gruppe 6061 hinzugefügt habe.
Damit werden neue DAteien mit Owner pi angelegt wenn du über WinScp hochlädst. Rechte sind per Default rw-r--r-- ... dann fhem diese nicht lesen. Lade mal etwas hoch und schau dir in WinScp an wie die Rechte aussehen. Oder Lade mal das Log runter, lösche es und lade es wieder hoch und schau ob Fhem das Log anzeigen kann.

Ich dachte die Rechteänderungen willst du verhindern.