Docker Image pipp37/fhem_jessie Online

[pipp37]

Hallo.
Mein Docker Image in der 2. Version (1/2017) ist ab sofort online.

https://hub.docker.com/r/pipp37/fhem_jessie/

Grundlage ist Debian 8 (jessie).
Im Image laufen einige Damons für cron, Nfs Client, Autofs mit Netzwerk-Mounts  in /net, SSH usw. 
Der SSH Daemon ist über Port 2222 zu erreichen: root / fhem!
Weiters wurden auch die USB Tools installiert und ein HM-CFG Adapter zum Testen eingebunden.

Features:
* volume /opt/fhem
* volume /opt/yowsup-config
* Imagemagic
* avrdude - firmware flash
* Python - yowsup (separate volume) for whatsapp client - volume: /opt/yowsup-config
* Open-SSH daemon
* Exposed ports: 2222/SSH, 7072 Fhem-raw, 8083-8085 Fhem Web, 9001 supervisord
* supervisord for fhem, ssh
* cron daemon / at
* NFS client and autofs /net
* ssh root password: fhem!
* USB tools for CUL hardware
* Fhem start mit PID
* supervisor web-ui at port 9001 (user:admin pass:admin) (** new **)
* perl db Module für dblog (Tested SQLITE + MYSQL) (** new **)


Holen:

Code Auswählen Erweitern

docker pull pipp37/fhem_jessie

Run:

Code Auswählen Erweitern


docker run -d --name fhem --cap-add SYS_ADMIN -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 pipp37/fhem_jessie


Wenn NFS nicht funktioniert mit 

Code Auswählen Erweitern

--privileged     starten.

Code Auswählen Erweitern

docker run -d --name fhem --privileged -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222  pipp37/fhem_jessie

Run with volume on host:

Code Auswählen Erweitern

docker run -d --name fhem --cap-add SYS_ADMIN -v /var/fhemdocker/fhem:/opt/fhem -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 -p 9001:9001 pipp37/fhem_jessie

USB:
Parameter z.B.

Code Auswählen Erweitern

--device=/dev/bus/usb/001/002
Mit

Code Auswählen Erweitern

lsusb am host die devices suchen.

Code Auswählen Erweitern

lsusb -v | grep -E '\<(Bus|iProduct|bDeviceClass|bDeviceProtocol)' 2>/dev/null


Diverse Befehle:
Running containers:

Code Auswählen Erweitern

docker ps

Code Auswählen Erweitern

docker ps -a

Attach shell to container with:

Code Auswählen Erweitern

docker exec -it ContainerID /bin/bash

Stop FHEM inside container

Code Auswählen Erweitern

supervisorctl stop fhem Start FHEM inside container

Code Auswählen Erweitern

supervisorctl start fhem
Stop

Code Auswählen Erweitern

docker stop fhem

Start

Code Auswählen Erweitern

docker start fhem

GUI FHEM:

Code Auswählen Erweitern

http://ipaddress:8083 GUI supervisord:

Code Auswählen Erweitern

http://ipaddress:9001

[betateilchen]

Kannst Du mir mal bitte die Stelle aus dem Dockerfile zeigen, an der Du ENTRYPOINT oder CMD definiert hast?

Ich scheitere bei meinen eigenen Docker-Basteleien seit Stunden daran, das automatische Starten von fhem im container zu realisieren.

[pipp37]

https://github.com/pipp37/fhem_jessie


Ich hab alles auch auf Github.


Info: Ich hab den Fhem Start mit dem supervisord gemacht.

Dockerfile ..

Code Auswählen Erweitern

ADD run.sh /root/run.sh
ADD supervisord.conf /etc/supervisor/conf.d/supervisord.conf
ENTRYPOINT ["./run.sh"]


run.sh

Code Auswählen Erweitern


#!/bin/bash
# Run command for docker service fhem and sshd

# check if ssh-keys exists
test -x /etc/ssh/ssh_host_dsa_key || dpkg-reconfigure openssh-server
/etc/init.d/ssh start
echo "Current directory : $(pwd)"
echo "Environment RUNVAR: $RUNVAR"
echo "There are $# arguments: $@"

# make pidfile rundir for fhem (because /var/run  ist tmpfs in ram)
if [ ! -d /var/run/fhem  ]; then
    mkdir /var/run/fhem
    chown -R fhem:root /var/run/fhem
fi

if [ -z "$1" ]; then
    echo "No argument supplied. Start supervisord"
    /etc/init.d/dbus restart

    # nfsclient / rpcbind
    mkdir /run/sendsigs.omit.d
    service rpcbind restart

    # autofs
    service autofs restart

    service avahi-daemon start
    service cron restart
    /usr/bin/supervisord
  else
    echo "Execute: $1 "
    $1
fi




supervisord

Code Auswählen Erweitern


[supervisord]
nodaemon=true

[program:fhem]
command=/etc/init.d/fhem start
# autostart=true
# autorestart=true
# stopasgroup=true

stderr_logfile=/var/log/fhem.err.log
stdout_logfile=/var/log/fhem.out.log


[pipp37]

Nachtrag:
Fhem darf nicht als Daemon laufen - darum der supervsord.
LG

[betateilchen]

ok, danke. Ich schau mal, ob ich damit weiterkomme.

[Chris8888]

Hallo,
ich habe dein Dockerimage gerade auf meiner Qnap installiert.

Läuft bisher super, die Perfomance ist deutlich besser als mein Pi1.

Nur leider bekomme ich den CUL nicht aktiviert.

Die Qnap erkennt den CUL sauber:
[~] # lsusb
Bus 001 Device 002: ID 1c05:2074 
Bus 001 Device 003: ID 1005:b155 Apacer Technology, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
...

Alle Testversuche per
define CUL_HM CUL /dev/ttyUSB0 4333
define CUL_HM1 CUL /dev/ttyACM0 4444
define CUL_HM2 CUL /dev/ttyAMA0 4555
enden in einem "Disconnected".

Liegt es an einem falschen "Pfad" oder kann der Container gar kein USB durchgereicht bekommen?
In den Settings habe ich den Container als "Priviliegert" markiert und alle "Geräte" freigegeben.

Muss man da noch mehr machen?

Vielen Dank für eine Idee vorab!

Viele Grüße
Christian

[betateilchen]

Du musst das usb device genauso wie ein Speichervolume als mountpoint an docker uebergeben.

Code Auswählen Erweitern

docker run -t -i --privileged -v /dev/bus/usb:/dev/bus/usb <image> <command>

[Chris8888]

Hallo Betateilchen,

danke für deinen Tip.
Da ich bisher alles per Web-Gui eingerichtet habe, muss ich mich wohl erst einmal mit der Kommandozeile von Docker beschäftigen.

Ich fürchte, ich werde verzweifeln....ich schubse eigentlich nur Mäuse.

VG
Christian

[fhemwallah]

Hi Armin,

ich bin gerade dabei, Dein Docker file sevolino/fhem zu installieren.

Hast Du Rückmeldungen, ob es sich auf Synology installieren lässt?

Hast Du Erfahrungen mit ModBus? Ist 99_modbus.pm in Deinem Paket enthalten? Muss ich bei einer Docker-Installation etwas mehr tun, als bei einer "normalen" Installation?
(https://forum.fhem.de/index.php/topic,12655.0.html)

Wieviel UI/Frontend ist in Deinem Dockerfile bereits enthalten?

Vielen Dank,

FHEMwallah

[pipp37]

Hallo.
Das Image sollte laufen - habe jedoch noch keine Rückmeldung zu Synology.
Installiere es einfach mal.  Geht ja rasch dank Docker.

Modbus verwende ich selbst nicht. Ich habe es auch nicht in das Image integriert. Du kannst aber jedes zusätzliche Modul per SSH Port 2222 in das Docker Image installieren.

Ich habe gerade das Image zum Testen in einer nackten virt. Maschine installiert und ein update mit shutdown restart im Fhem Frontend gefahren. Alles problemlos und ohne Fehler.
LG

[wopl]

Hallo,
auch ich versuche gerade FHEM unter Docker im QNAP zu installieren.
Ich bekomme jedoch auch den USB Cul nicht eingebunden.

Du musst das usb device genauso wie ein Speichervolume als mountpoint an docker uebergeben.

Code Auswählen Erweitern

docker run -t -i --privileged -v /dev/bus/usb:/dev/bus/usb <image> <command>

Muß da wirklich /dev/bus/usb stehen oder muß ich mir erst den Richtigen raussuchen?
Weder im QNAP noch im Docker ist ein /dev/ttyACM0 (oder so ähnlich) sichtbar. Muß ich hier noch den CDC-ACM Treiber installieren oder sollte es mit obigem Kommando direkt laufen?
Sollte der CUL dann in Docker auch unter /dev/ttyACM0 oder etwa unter /dev/bus/usb/001/002 via FHEM angesprochen werden?

Zu viele Fragen, um alle kombinatorischen Möglichkeiten auszuprobieren. Daher vielen Dank für jede Hilfe.
Gruß Wolfram

So, nach ein paar Stunden googeln und probieren hab ich den CUL jetzt endlich initialisiert bekommen.
Zunächst habe ich im QNAP Server den cdc-acm Treiber eingebunden:

Code Auswählen Erweitern


depmod cdc-acm

!!! nur aktiv bis zum nächsten Boot, da muß ich mich noch drum kümmern !!!

Dann ein RUN des Docker-Containers (von der Konsole, da ich z.Zt. noch nicht weiß, ob die grafische Oberfläche das --device einbinden kann:

Code Auswählen Erweitern


docker run -t -i --name fhemtest --privileged -p 7072:7072 -p 2323:2323 -p 8083:8083 -v /share/Data/docker/fhem/usrsharefhem:/usr/share/fhem --device=/dev/ttyACM0 woppl/fhem /bin/bash

!!! auch obiger Code nur als Beispiel. Läuft z.Zt. interaktiv in der bash. Wenn ich nun FHEM in /opt/fhem starte, ist mein CUL zumindest mal initialisiert.

Vielleicht hilfts ja jemandem ein wenig Zeit bei der Recherche zu sparen.
Gruß Wolfram

[somansch]

Hallo Pipp37,

ich habe deinen Docker-Container gerade auf meiner QNAP getestet, da ich diesen Lösungsansatz sehr charmant finde 

Prinzipiell funktioniert FHEM, jedoch habe ich kein DNS verfügbar und kann somit später FHEM nicht aktualisieren 

Dies ist die Rückmeldung nach "update check": "http://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: Bad hostname 'fhem.de:80'"

Beim Starten kommt folgender Eintrag, welcher sehr wahrscheinlich dafür verantwortlich ist:
"[....] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemonTimeout reached while wating for return value                                                                                                                                   
Could not receive return value from daemon process.                                                                                                                                                                                   
(warning).  "

Habe auch schon ein Downgrade der "Container Station" durchgeführt, da laut QNAP mit der aktuellen Version noch Probleme bestehen?! Siehe: https://forum.qnapclub.de/thread/38713-internetzugriff-aus-containern-nicht-mehr-m%C3%B6glich/

Komme aus der IT-Welt, habe jedoch kein tiefgehendes Wissen über Linux und Docker, daher wäre eine "DAU-Anleitung" für weiteres Troubleshooting hilfreich 

Danke im voraus,
Andreas

[Bastler]

Hallo Andreas,

hatte auch mal versucht auf einer QNAP TS-251 FHEM in dem Docker von Pipp37 zum laufen zu bekommen.
Bin aber daran gescheitert, dass die NAS den Jeelink als UPS erkennt und 100% Systemlast erzeugt.
In der QNAP gibt es im aktuellen Stand keine Möglichkeit den UPS Support auszuschalten.
Alle Tricks die ich im Internet gelesen habe waren keine dauerhafte Lösung.
Der Support ist auch nicht wirklich gewillt das Problem zu lösen. Nach drei Wochen Mailverkehr habe ich aufgegeben.

Wenn Du aber keinen Jeelink hast der per USB angeschlossen ist, dann ist der Docker Container von Pipp37 die erste Wahl.

Gruß
Otto

[somansch]

Hallo Otto,

danke für dein Feedback. Ich plane, einen CUL einzusetzen, welcher diese Woche geliefert wird. Bezieht das "UPS" Problem generell auf alle USB Devices?

Im Moment scheitert es jedoch schon am fehlenden DNS...

Viele Grüße,
Andreas

[Bastler]

Hallo Andreas,

das Problem liegt an dem USB-Serial Chip des Jeelink. Die QNAP NAS ordnet den FTDI Chipsatz des Jeelink der UPS Stromversorgung zu.
Glaub mir es gibt schönere Mölichkeiten seine Zeit zu verschwenden.
QNAP hat in der Version 6 den Punkt zur Deaktivierung der UPS aus dem Konfigurationsmenü herausgenommen.

Wenn Du FHEM auf der QNAP betreiben willst, dann versuch es mal mit dem LacrosseGateway über das Netzwerk. Das sollte gehen, habe ich aber noch nicht getestet.

Gruß
Otto

[wopl]

Hallo somansch,
habe in den letzten Tagen auch ein wenig Mühe gehabt, FHEM unter Docker lauffähig zu bekommen. Jetzt wirds so langsam.

Ich plane, einen CUL einzusetzen

Der Trick hier: Du mußt auf dem QNAP den cdc-acm Treiber aktivieren (depmod cdc-acm). Dann taucht für den CUL auch /dev/ttyACM0 auf, den Du dann im Container wie gewohnt ansprechen kannst. (siehe mein vorheriger Beitrag)

Bei Bedarf gerne mehr Info.
Gruß Wolfram

[DS_Starter]

Hallo zusammen,

jetzt habe ich mich auch mal an Docker rangewagt und dein Image auf dem Docker meiner Synology 415+ installiert. Das hat soweit problemlos geklappt.
USB-Devices sind noch nicht eingebunden. Ich spiele und teste etwas herum.

Das Erste was mir auffiel ist foilgendes. Habe "update" ausgeführt und alle Module aktualisiert . Hat geklappt.
Stoppe ich aber den Container und starte ihn wieder sind die Aktualisierungen wieder weg.

Wie gesagt, ich taste mich erst an diese Technologie heran, setze bisher phpVirtualBox ein.
Was muß man denn tun damit Änderungen nach einem Restart erhalten bleiben ?

Probiert habe ich es bereits mit "docker commit <Signatur>  pipp37/fhem_jessie:latest" nach dem update, hat aber nicht geholfen.

viele Grüße
Heiko

[DS_Starter]

Hallo zusammen,

kurzes Update.
Durch das Mounten eines auf der Synology DS befindlichen FHEM-Verzeichnisses nach /opt/fhem konnte ich nun fhem update fahren und nach dem Container-Restart auch erhalten.
Es bleiben  ebenfalls zusätzlich installierte perl Pakete nach einem Containerrestart erhalten wenn "docker commit" ausgeführt wurde (so sollte es auch sein). Warum das für FHEM nicht klappen wollte, konnte ich bisher nicht ergründen.
Nun bin ich auch darauf gestoßen dass Synology-docker zumindest im DSM 5.2 die --net Option nicht unterstützt und ich somit nicht in der Lage bin Multicastpakete (SMAEM) an Docker weiterzureichen. Damit ist Docker für mich, zumindest solange ich keine Lösung für dieses Problem gefunden habe, keine vollwertige Ablösung für mein Virtualbox.
Vielleicht ist es mit DSM 6 weiterentwickelt. Allerdings kann ich erst updaten wenn Virtualbox kompatibel mit der neuesten 6er Version ist, momentan nicht.

viele Grüße
Heiko

[DS_Starter]

Hallo zusammen,

die Sache mit dem Multicast lässt mir doch keine Ruhe weil ich Docker inzwischen mit FHEM ganz gut als Test laufen habe, nur dieser Punkt ist momentan noch offen.

Also nochmal die Frage in die Runde ob jemand eine Möglichkeit kennt Multicast-Pakete in einen Dockercontainer weiterzuleiten und es schon realisiert hat. (Synology unterstützt den net-Parameter nicht!).

Ganz allgemein scheint Multicast-Weiterleitung wohl noch eine Baustelle bei Docker zu sein wenn man diesebezüglich etwas im Netz rumsucht. Aber vielleicht habe ich den richtigen Einstiegspunkt auch nicht gefunden.

viele Grüße und ein schönes WE

[Chris8888]

Hallo somansch,
habe in den letzten Tagen auch ein wenig Mühe gehabt, FHEM unter Docker lauffähig zu bekommen. Jetzt wirds so langsam.

Der Trick hier: Du mußt auf dem QNAP den cdc-acm Treiber aktivieren (depmod cdc-acm). Dann taucht für den CUL auch /dev/ttyACM0 auf, den Du dann im Container wie gewohnt ansprechen kannst. (siehe mein vorheriger Beitrag)

Bei Bedarf gerne mehr Info.
Gruß Wolfram

Hallo Wolfram,

dann gerne her mit dem "mehr".

Das Image läuft soweit, echt super.
Nur den CUL bekomme ich nicht eingebunden.

Kannst du deinen Weg etwas genauer beschreiben?
Besten Dank!

VG
Christian

[pipp37]

Hallo.
Das überarbeitete Image (V2) ist ab sofort online.
Infos dazu sind auf der ersten Seite.

https://forum.fhem.de/index.php/topic,51190.0.html

Mehr Infos auch auf Github.
https://github.com/pipp37/fhem_jessie

Die große Änderung ist die Behandlung von Host Volumes.
Bei Verwendung des -v /hostdir:/opt/fhem  wird die initiale FHEM Installation im Dockerimage in das Host Verzeichnis extrahiert.
Das allerdings nur, wenn es leer ist.

Auch läuft nun Fhem vollständig unter der Kontrolle von supervisord und wird bei Fehlern automatisch neu gestartet.
Dazu muß Fhem mit einem Pid-File arbeiten. Das ist bereits konfiguriert.


Weiters kann auch FHEM über eine Web-UI des supervisord neu gestartet werden.
Port: 9001
User und Pass: admin

[Spezialtrick]

Hallo.
Mein Docker Image in der 2. Version (1/2017) ist ab sofort online.

https://hub.docker.com/r/pipp37/fhem_jessie/

Grundlage ist Debian 8 (jessie).
Im Image laufen einige Damons für cron, Nfs Client, Autofs mit Netzwerk-Mounts  in /net, SSH usw. 
Der SSH Daemon ist über Port 2222 zu erreichen: root / fhem!
Weiters wurden auch die USB Tools installiert und ein HM-CFG Adapter zum Testen eingebunden.

Features:
* volume /opt/fhem
* volume /opt/yowsup-config
* Imagemagic
* avrdude - firmware flash
* Python - yowsup (separate volume) for whatsapp client - volume: /opt/yowsup-config
* Open-SSH daemon
* Exposed ports: 2222/SSH, 7072 Fhem-raw, 8083-8085 Fhem Web, 9001 supervisord
* supervisord for fhem, ssh
* cron daemon / at
* NFS client and autofs /net
* ssh root password: fhem!
* USB tools for CUL hardware
* Fhem start mit PID
* supervisor web-ui at port 9001 (user:admin pass:admin) (** new **)
* perl db Module für dblog (Tested SQLITE + MYSQL) (** new **)

Gibt es eine Möglichkeit eine bestehende FHEM Instanz mit ConfigDB und DBLog in den Docker Container zu migrieren? 

[Gizmoh]

Gibt es eine Möglichkeit eine bestehende FHEM Instanz mit ConfigDB und DBLog in den Docker Container zu migrieren? 

Vermutlich musst du nur den Docker Container bei dir installieren und dann deine kompeltte FHEM Instanz in das entsprechend gemountete Verzeichnis kopieren.

[marty29ak]

Ich teste auch gerade auf einer Synology und habe ohne Probleme ein Backup von meinem Aktuellen Raspberry nutzen können.
Was ich mich allerdings frage, ist es auch möglich eine Soundkarte für Text2Speech zu nutzen?
Sonst brauche ich ja trotzdem einen zusätzlichen Raspberry für diese Funktion.

[Fistandantilus]

Hi,

das Starten funktioniert auf meiner Syno, allerdings bleibt das Host Verzeichnis leer, woran könnte das liegen?

Code Auswählen Erweitern

docker run -d --name Fhem --cap-add SYS_ADMIN -v /var/fhemdocker/fhem:/volume1/Docker/fhem -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 -p 9001:9001 pipp37/fhem_jessie

/opt/fhem hat vorher auch nicht funktioniert. Mein /opt ist nur ein Symlink auf /volume1/@optware

VG
F.

[Fistandantilus]

OK, vergesst es. Man muss nur richtig lesen Ziel:Quelle und nicht anders herum. Hab den Folder gefunden 

[lewej]

Hallo Zusammen,

ich setze gerade Docker auf und soweit läuft alles, mein Problem ist eigentlich, wie bekomme ich am besten den kompletten /opt/fhem wieder zurück auf den HOSTServer.
Wenn ich ein dockerbuild mache, kann man ja keine Host Volumes reinhängen, erst danach. Jetzt will ich aber fhem bereits beim build installiert haben.

Wie habt ihr dieses Problem gelöst?

Gruß
lewej

[botze]

Servus Zusammen,

ich bin vor kurzem auf eine Synology DS916+ umgestiegen und wollte daher auch meine FHEM Installation von meinem Raspberry auf das NAS umziehen. Da habe ich dein pipp37/fhem_jessie Image gefunden und war schon total Happy, da mir das Konzept am Besten gefallen hat und gleichzeitig nicht zu viel Schnick Schnack mit dabei ist.

Ich habe den Container per SSH auf meiner Diskstation wie folgt gestartet/erstellt:

Code Auswählen Erweitern


sudo docker run -d --name Fhem --cap-add SYS_ADMIN -v /volume1/Documents/docker/k32fhem01/fhem:/opt/fhem -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 -p 9001:9001 pipp37/fhem_jessie


Allerdings kann FHEM nicht gestartet werden, wenn ich ein Volume mounte. Hier kommt folgender Error Log:

Code Auswählen Erweitern


date stream content
2017-07-22 12:22:58 stdout 2017-07-22 14:22:58,645 INFO gave up: fhem entered FATAL state, too many start retries too quickly
2017-07-22 12:22:57 stdout 2017-07-22 14:22:57,643 INFO exited: fhem (exit status 13; not expected)
2017-07-22 12:22:57 stdout 2017-07-22 14:22:57,487 INFO spawned: 'fhem' with pid 266
2017-07-22 12:22:54 stdout 2017-07-22 14:22:54,481 INFO exited: fhem (exit status 13; not expected)
2017-07-22 12:22:54 stdout 2017-07-22 14:22:54,324 INFO spawned: 'fhem' with pid 264
2017-07-22 12:22:52 stdout 2017-07-22 14:22:52,319 INFO exited: fhem (exit status 13; not expected)
2017-07-22 12:22:52 stdout 2017-07-22 14:22:52,161 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2017-07-22 12:22:52 stdout 2017-07-22 14:22:52,161 INFO spawned: 'fhem' with pid 262
2017-07-22 12:22:51 stdout 2017-07-22 14:22:51,157 INFO exited: fhem (exit status 13; not expected)
2017-07-22 12:22:50 stdout 2017-07-22 14:22:50,936 INFO spawned: 'sshd' with pid 260
2017-07-22 12:22:50 stdout 2017-07-22 14:22:50,933 INFO spawned: 'fhem' with pid 259
2017-07-22 12:22:49 stdout 2017-07-22 14:22:49,929 INFO supervisord started with pid 256
2017-07-22 12:22:49 stdout 2017-07-22 14:22:49,929 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2017-07-22 12:22:49 stdout 2017-07-22 14:22:49,929 INFO RPC interface 'supervisor' initialized
2017-07-22 12:22:49 stdout 2017-07-22 14:22:49,928 INFO RPC interface 'supervisor' initialized
2017-07-22 12:22:49 stdout 2017-07-22 14:22:49,905 WARN Included extra file "/etc/supervisor/conf.d/supervisord.conf" during parsing
2017-07-22 12:22:49 stdout 2017-07-22 14:22:49,905 CRIT Supervisor running as root (no user in config file)
2017-07-22 12:22:49 stdout   'Supervisord is running as root and it is searching '
2017-07-22 12:22:49 stdout /usr/lib/python2.7/dist-packages/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
2017-07-22 12:22:48 stdout [....] Starting periodic command scheduler: cron[?25l7[ ok 8[?12l[?25h.
2017-07-22 12:22:48 stdout [....] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon[?25l7[ ok 8[?12l[?25h.
2017-07-22 12:22:48 stdout [....] Starting automount...[?25l7[FAIL8[?12l[?25hfailed (failed to load autofs4 module).
2017-07-22 12:22:48 stdout [....] Starting rpcbind daemon...[?25l7[ ok 8[?12l[?25h.
2017-07-22 12:22:48 stdout [....] Starting system message bus: dbus[?25l7[ ok 8[?12l[?25h.
2017-07-22 12:22:47 stdout /opt/yowsup-config not empty - no extraction, exit!
2017-07-22 12:22:47 stdout /opt/fhem not empty - no extraction, exit!
2017-07-22 12:22:47 stdout No argument supplied. Start supervisord and services.
2017-07-22 12:22:47 stdout There are 0 arguments:
2017-07-22 12:22:47 stdout Environment RUNVAR: fhem
2017-07-22 12:22:47 stdout Current directory : /root
2017-07-22 12:22:47 stdout invoke-rc.d: policy-rc.d denied execution of restart.
2017-07-22 12:22:46 stdout 256 53:4e:82:ed:5b:4d:a7:3a:14:5c:42:21:18:46:4e:dd /etc/ssh/ssh_host_ed25519_key.pub (ED25519)
2017-07-22 12:22:46 stdout Creating SSH2 ED25519 key; this may take some time ...
2017-07-22 12:22:46 stdout 256 91:db:4c:31:ec:77:89:6d:d8:68:1c:fb:05:87:88:fe /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA)
2017-07-22 12:22:46 stdout Creating SSH2 ECDSA key; this may take some time ...
2017-07-22 12:22:46 stdout 1024 16:93:7b:18:fc:07:a6:f2:19:dc:ac:95:09:13:41:e1 /etc/ssh/ssh_host_dsa_key.pub (DSA)
2017-07-22 12:22:46 stdout Creating SSH2 DSA key; this may take some time ...
2017-07-22 12:22:45 stdout 2048 5d:f3:1d:ba:cd:9d:17:c3:b0:46:36:6b:4d:f6:80:dc /etc/ssh/ssh_host_rsa_key.pub (RSA)
2017-07-22 12:22:45 stdout Creating SSH2 RSA key; this may take some time ...


Im Ordner volume1/Documents/docker/k32fhem01/fhem sind nach dem ersten Start alle FHEM Dateien.

Wenn ich allerdings den Container wie folgt starte (ohne den Mount Punkt):

Code Auswählen Erweitern


sudo docker run -d --name Fhem --cap-add SYS_ADMIN -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 -p 9001:9001 pipp37/fhem_jessie


Hier startet FHEM wunderbar. Ich habe auch einiges ausprobiert. Auch der folgende Aufruf hat keine Auswirkung auf das Verhalten:

Code Auswählen Erweitern


sudo docker run -d --name Fhem --privileged -v /volume1/Documents/docker/k32fhem01/fhem:/opt/fhem -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 -p 9001:9001 pipp37/fhem_jessie


Hat jemand eine Idee von euch?

Danke und viele Grüße,
botze

----------------------------------------------------
Nachtrag:

Hallo Zusammen,

ich habe was gefunden. Wenn ich einen anderen Pfad nehme, dann funktioniert's. Der Pfad /volume1/Documents ist zwar verschlüsselt, aber bei anderen Docker Containern war das nie ein Problem.

Mit folgendem Aufruf konnte ich den Pfad richtig mounten (/volume1/docker ist nicht verschlüsselt):

Code Auswählen Erweitern


sudo docker run -d --name k32fhem01 --cap-add SYS_ADMIN -v /volume1/docker/k32fhem01/fhem:/opt/fhem -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 -p 9001:9001 pipp37/fhem_jessie


Viele Grüße,
botze

[der-Lolo]

Hallo Zusammen,
auch ich dachte ich versuch mich mal an fhem in Docker - aber irgendwie bekomme ich den Container nicht gestartet...

Code Auswählen Erweitern


root@cubietruck:~# docker start fhem
fhem
root@cubietruck:~# docker ps -a
CONTAINER ID        IMAGE                COMMAND             CREATED             STATUS                      PORTS               NAMES
b3c8c525ba02        pipp37/fhem_jessie   "./run.sh"          2 hours ago         Exited (1) 18 seconds ago                       fhem
225da23c3935        hello-world          "/hello"            3 hours ago         Exited (1) 3 hours ago                          elastic_montalcini
e50cd3c60d3e        hello-world          "/hello"            3 hours ago         Exited (1) 3 hours ago                          upbeat_lalande
root@cubietruck:~#

Wobei ich jetzt ehrlich gesagt keine Ahnung habe ob überhaupt ein Container startet und nicht vielleicht ein problem mit der Docker installation besteht.

[FunkOdyssey]

Weiters wurden auch die USB Tools installiert und ein HM-CFG Adapter zum Testen eingebunden.

Darf ich fragen wie du das gemacht hast?
Ich finde den Stick nicht und kann ihn daher nicht durchreichen.
Oder hast du das per ,,privileged" gelöst?

[FunkOdyssey]

Was mir gerade aufgefallen ist:

Code Auswählen Erweitern

# sshd on port 2222 and allow root login / password = fhem!
RUN apt-get -y --force-yes install openssh-server && apt-get clean   \
&& sed -i 's/Port 22/Port 2222/g' /etc/ssh/sshd_config  \
&& sed -i 's/PermitRootLogin no/PermitRootLogin yes/g' /etc/ssh/sshd_config \
&& sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/g' /etc/ssh/sshd_config \
&& echo "root:fhem!" | chpasswd \
&& /bin/rm  /etc/ssh/ssh_host_*

Ändert zwar die entsprechenden Zeilen, aber bei einer Standardinstallation von openssh sind diese alle auskommentiert. Somit werden die Änderungen nicht aktiv.

[budda85]

Guten Abend,
ich möchte einmal auf einen Beitrag von mir in einem anderen Thread aufmerksam machen.
Ich habe das Problem das FHEM anscheinend doppelt gestartet wird.
pipp37 hast du vielleicht eine Idee woran das liegen kann?
https://forum.fhem.de/index.php/topic,56339.msg701196.html#msg701196

[budda85]

Guten Morgen,
Ich habe jetzt über das Terminal die FHEM Instanz vom Supervisor gestoppt.
Nun werden auch keine Logs mehr mit Probleme geschrieben.
FHEM läuft aber nach wie vor 

[speedy-g]

Hallo,

hatte das gleiche Problem. Ich hatte meine alte Konfiguration übernommen und da fehlte das anlegen des PID-Files...

Code Auswählen Erweitern

attr global pidfilename /var/run/fhem/fhem.pid
hinzugefügt und siehe da es läuft 

[uwe28]

Hallo,

Ich tüftel nun schon eine ganze Weile dran, bekomme es aber nicht hin meinen Selbstbau-nanoCUL an den Docker container zu übergeben.

Code Auswählen Erweitern

docker run -d --name fhem --privileged -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222  pipp37/fhem_jessie --device=/dev/bus/usb/001/002 wird ausgeführt. fhem wird auch gestartet und ist erreichbar.

Beim hinzufügen des CUL über:

Code Auswählen Erweitern

define nanoCUL CUL /dev/bus/usb/001/002 1234 wird der CUL auch erstellt, aber es bleibt bei STATE: disconnected

Die Docker Software läuft auf einnem NAS mit openmediavault 3.0.94

Anbei noch die Einstellungen die ich vornehmen kann.

Hoffe mir kann geholfen werden.

MFG Uwe

[FunkOdyssey]

Ich würde das minimal anders schreiben:

Code Auswählen Erweitern

docker run -d --name fhem --privileged -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222  pipp37/fhem_jessie --device=/dev/bus/usb/001/002:/dev/bus/usb/001/002

Quelle und Ziel müssen bzw. sollten angegeben werden. Genau wie bei den Ports.

[uwe28]

Ich würde das minimal anders schreiben:

Code Auswählen Erweitern

docker run -d --name fhem --privileged -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222  pipp37/fhem_jessie --device=/dev/bus/usb/001/002:/dev/bus/usb/001/002

Quelle und Ziel müssen bzw. sollten angegeben werden. Genau wie bei den Ports.

Bringt leider auch keine Veränderung mit sich. :-/

[FunkOdyssey]

Kann das sein, dass dir /dev/bus/usb/001/002 im Container gar nicht angezeigt wird?
Ich selbst mach das mit /dev/serial/by-id/ bei allen meinen USB-Geräten ohne Probleme. Okay, anderes Image.

Versuche doch mal folgendes:

Code Auswählen Erweitern

docker run -d --name fhem --privileged -p 7072:7072 -p 8083:8083 -p 8084:8084 -p 8085:8085 -p 2222:2222 --device=/dev/bus/usb/001/002:/dev/bus/usb/001/002 pipp37/fhem_jessie

[uwe28]

Wenn ich per ssh auf den Container verbinde und "lsusb" ausführe wird der CUL angezeigt.

Der Neue Code brachte leider auch keine Veränderung.

Im Log von fhem steht:

Code Auswählen Erweitern

Can't open /dev/bus/usb/001/004: Permission denied
falls das weiter hilft. (Schon seit meinen ersten Versuchen) Die Berechtigungen sind dabei eigentlich richtig gesetzt.
Kann man den fhem Benutzer eigentlich per ssh einloggen? Hab da kein PW gefunden bisher.

[FunkOdyssey]

Ich kenne deine Docker-WebUI nicht. Ist das normal, dass USB-Geräte im Bereich "Volumes" gemappt werden?

Im Log von fhem steht:

Code Auswählen Erweitern

Can't open /dev/bus/usb/001/004: Permission denied
falls das weiter hilft. (Schon seit meinen ersten Versuchen) Die Berechtigungen sind dabei eigentlich richtig gesetzt.

Ich kann mir nicht vorstellen, dass das etwas mit Berechtigungen zu tun hat. Im Container läuft sowieso alles als Root. Im pipp37-Image wird nur leider zusätzlich supervisord genutzt. Eigentlich unnötig, denn es reicht doch der FHEM-Dienst im Container. Aber dennoch dürfte sich das auf deine Situation nicht auswirken.

Du könntest ja evtl. den Container mit mehr Rechten starten. Finde ich aber nicht so gut. Aber wenigstens zum Ausschließen von Berechtigungsproblemen.

Code Auswählen Erweitern

docker run --cap-add=SYS_ADMIN ...

Ansonsten prüfe doch bitte noch einmal die Pfade. Mountest du "Müll" in den Container, so kann der damit auch nichts anfangen. Prüfe mal, ob beides der gewünschte nanoCul ist.

Wie gesagt: Ich würde das sowieso mit nem anderen Pfad machen: /dev/serial/by-id/...

Kann man den fhem Benutzer eigentlich per ssh einloggen? Hab da kein PW gefunden bisher.

Eigentlich läuft alles als root. Der FHEM-User wird in den FHEM-Docker-Images häufig direkt wieder gelöscht.
Du kannst dich auf die Konsole des Containers wie folgt einloggen:

Code Auswählen Erweitern

docker exec --it fhem bash

Auch hier könnte supervisord sich wieder anders verhalten.

[uwe28]

Das mappen über Volumes war nur ein Test, der leider keine Veräanderung brachte.

Habe deine Tipps nun alle ausprobiert. Leider immernoch alle mit dem selben Resultat.

Auch das mit dem

Code Auswählen Erweitern

/dev/serial/by-id/ und

Code Auswählen Erweitern

docker run --cap-add=SYS_ADMIN

Habe außerdem testhalber versucht einen Harmony-Hub der im Netzwerk hängt einzubinden. Auch zu dem kann keine Verbindung hergestellt werden.
Außerdem habe ich noch Docker CE versucht zu verwenden. Auch das brachte keine Veränderung.

Schonmal vielen Dank für die Hilfestellung.

EDIT: Habe aus dem Beitrag https://forum.openmediavault.org/index.php/Thread/19553-OMV-Docker-plugin-media-server-Plex-PlexPy-Ombi-Libresonic-NZBGet-ruTorrent-Sona/ erfahren, dass noch ein Benutzer in OMV angelegt werden und auch in dem Docker Container eingetragen werden muss. Desweiteren scheint man die Verzeichnisse beim erstellen des Containers mit übergeben zu müssen. Habe dort den "/dev/serial/by-id" Ordner mit übergeben.

Das Resultat ist , dass der Cul jetzt mit STATE opened eingetragen ist. Ich hoffe nur das mich das der Lösung des Problems näher brachte.

EDIT2: Das war scheinbar der Durchbruch. Nach einem erneuten Starten des Containers und eines erneuten einbinden des CUL ging es dann plötzlich. Nun muss ich nur zusehen wie ich den Zustand aufrecht erhalte!


Danke FunkOdyssey für die Unterstützung!

mfg Uwe

[FunkOdyssey]

Ach so. OpenMediaVault habe ich überlesen. Das scheint dort irgendwie anders zu laufen.

Poste doch mal deine Lösung für die Nachwelt.

Ich habe Docker CE auf nem Debian-Serversystem aktiviert und habe meine USB-Geräte problemlos über docker run und via docker-compose problemlos eingefunden. Hier waren keine zusätzlichen Schritte erforderlich.

[uwe28]

Also:

Um in OMV3 den Docker Container einzubinden muss, IN OMV, ein Benutzer angelegt werden der in den Gruppen "users" und "docker" Mitgleid ist.
Anschließend muss die für den nächsten Schritt benötigte uid und gid bestimmt werden.
Dies geschieht indem man sich über ssh auf dem host einloggt und den den befehl "id <der neu angelegte Benutzer>" ausführt.

Nun kann die image in den Container überführt werden. Dafür auf "run image" im OMV Menü > Docker anklicken und unter "Enviorment Variables" die Punkte PUID(uid) und PGID(gid) manuell hinzufügen. Außerdem muss der Container im Network mode "Host" und mit dem Hacken bei "privileged mode" ausgeführt werden.

Unter "Volume and Bind mounts" wird nun der Pfad des CUls eingetragen: "Hostpath": /dev/serial/by-id/usb-FTDI..., "Containerpath": /dev/serial/by-id/usb-FTDI...

Hab noch ein paar Bilder zur Unterstützung angehangen.