Hallo ich habe gegoogelt. Es gibt auch einen Thread aber aus dem werde ich nicht schlau.
Ich habe meinen FHEM nach Docker umgestellt und möchte einfach nur einen WOL absetzen.
Das geht nicht mehr.
Auch etherwake direkt aus dem Fhem Container als Root kommt auch nicht an.
Ein WOL von einer anderen Maschine kommt jedoch an.
Was mache ich falsch oder muss gemacht werden.
Mein bisheriger Code der (ausserhalb von Docker funktioniert hat):
define KG.WzK.PC_AK WOL 74:D4:35:08:2C:73 192.168.0.45 UDP
attr KG.WzK.PC_AK room Keller
attr KG.WzK.PC_AK useUdpBroadcast 192.168.0.255
Danke für Eure Hilfe.
Gruss Andreas
Wie ist Dein Docker-Container eingerichtet? Was für ein "Netwerkmode"?
Ich denke Du meinst das hier:
bridge System - bridge false default 172.17.0.0/16 172.17.0.1 - - public
fhem-docker_fhem-network fhem-docker bridge true default 172.27.0.0/16 172.27.0.1 - - administrators
host System - host false default - - - - public
none System - null false default - - - - public
Also Bridge!
Thema gabs schon öfter. Docker routed die nötigen Pakete nicht. Workaround z. B. WOL-Modul über SSH oder Fritzbox ... schau mal den Thread, vielleicht findest was.
WOL Modul kann mittlerweile nativ SSH, meine Änderung im Thread ist mittlerweile im Standard ...
https://forum.fhem.de/index.php?topic=87714.0
Hintergrund:
WOL-Packete werden nicht geroutet, d.h. funktionieren nur im gleichen Netzwerk. (Können nicht geroutet werden).
Damit geht es eben aus dem Docker Netzwerk nicht
Hallo danke für die Antworten.
Ich habe die Antworten oder anderen Threads gesehen aber ich verstehe da nur Bahnhof.
Kannst Du mir bitte sagen wie ich dann tr064 in meinem Fhem benutze oder ssh benutzt word.
Ein kurzes Beispiel wäre echt super.
Danke Andreas
tr064 funktioniert wie bekannt
ssh raus oder reingehende? raus .. wie bekannt
ssh: du konfigurierst von Docker eine ssh-Verbindung zum Host. WOL ruft dann das etherwake oder entsprechenden Befehlt auf dem Host auf. Da der Host direkt Zugriff auf das Netzwerk hat geht das WOL Paket durch.
Otto123 hat für ssh-Konfiguration gute Anleitungen im Forum und in seinem Blog. Sollte über die Suche auffindbar sein.
Zum WOL-MOdul gibt es einen Thread, da sollte auch ein Beispiel drin sein wenn in der Doku zum Modul nichts zu finden ist ... https://forum.fhem.de/index.php/topic,97064.msg1017655.html#msg1017655
In dem Thread hat Otto auch weiterführende Links für Fritzbox gepostet. Ich nutze aber WOL per SSH.
SChreib am besten mal wo du genau Probleme hast.
Das ist echt Neuland für mich.
-Wol via ssh,
Mein Problem ist wie sieht das in Fhem aus (.cfg) um meinen PC 192.168.0.45 aufzuwecken.
Es waere am besten wenn Ihr mal die Fhem Statements benennt.
Danke A. Krause
P.S.: per ssh komme ich auf den Pc. Getestet mit container konsole via Portainer
Du sollst nicht per ssh auf den PC "hüpfen" der aufzuwecken ist, sondern nur auf den Host. Host ist der Rechner auf dem Docker läuft. Z. B. Raspberry.
Wenn das geht -- ohne Passworteingabe!!! -- dann ist der nächste Schritt zu testen ob du mit "sudo etherwake [MAC]" den PC wecken kannst.
Wichtig bei ssh, das muss der User können unter dem auch fhem läuft. Vermutlich musst du in Portainer "su fhem" eingeben damit du mit dem User fhem testest.
Wenn beides funktioniert, dann gebe ich dir ein Beispiel. Aber erstmal müssen die beiden Dinge gehen sonst bringt das in Fhem nichts.
Hallo ich komme irgendwie nicht via ssh auf den host. Auch mit Passwort nicht.
Gibst Du mir noch einen Tip.
Danke
kannst du aus dem Docker den Host pingen?
Host müsste sowas wie ... sein. Im Fhem-Docker ist auch ein Alias "host.docker.internal" gesetzt.
172.18.0.1 host.docker.internal
Gute Anleitung von Otto123 ... einfach mal ein Backup machen und abarbeiten. Wenn du was zerschießt hast ein Backup das du zurückspielen kannst.
http://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html
Lokaler HOst = Docker-Container
Lokaler user = fhem (oder der User unter dem dein fehm läuft)
Remote HOst = dein Host
Remote User = pi bei Raspberry, wobei ein eigener User für ssh empfohlen ist. Mein User heißt remote z. B. fhem_WOL
Dank aber könntest Du Dir nochmals meinen ersten Post anschauen da habe ich eine Übersicht und dort kommt auch host vor aber ohne
IP Adresse.
dein erster Post zeigt den PC den du wecken willst
Der gewünschte Weg:
Docker-Container ------ ssh ------> Docker-Host ----- WOL -----> PC (den du wecken willst)
kannst du im Docker-Container den Docker-Host pingen? Welche IP oder Hostname nutzt du? Wenn du den Docker-Host nichtmal pingen kannst liegt es daran. War schon mal hier ein Problem darum frage ich explizit nach.
Hallo sorry ich meinte den 3ten Post dieses Threads.
Dort ist leider keine Adresse fuer Host angegeben.
Bitte nicht aufgeben. Ich wuerde das gerne loesen und
Vertstehen.
Den Weg habe ich verstanden.
Danke Andreas
was willst du verstehen, woran scheitert es? Der Blog von Otto ist sehr ausführlich. Kann dir irgendwie nicht folgen ...
Ich wierde gerne wissen was meine host ip ist aus Sicht des Containers ist oder wo diese steht.
Zitat von: Hackstall am 14 November 2020, 11:16:41
Ich wierde gerne wissen was meine host ip ist aus Sicht des Containers ist oder wo diese steht.
OK, wenn du das default Image nutzt dann solltest du die Einträge in der hosts Datei haben. IP des Hosts ist bei mir 172.18.0.1, bei dir dürte es 172.17.0.1 sein dem 3. Post nach. Ich empfehle dir den Alias host.docker.internal oder gateway.docker.internal zu nutzen. Wenn du Netzwerk was änderst kann die IP auch anders gesetzt werden, der Alias müsste aber immer gleich bleiben.
Beispiel meiner Hosts-Datei
root@12d93a948873:/opt/fhem# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.18.0.2 12d93a948873
172.18.0.1 gateway.docker.internal
172.18.0.1 host.docker.internal
Anzeigen kannst du diese mit
cat /etc/hosts
Wenn wider Erwarten hier bei dir nichts drin steht dann teste mal 172.17.0.1
Danke hat geholfen.
So ich habe so glaube ich nun die Vorraussetzungen geschaffen.
Ich kann mittels ssh auf meinen host zugreifen und das ohne PASSWORT einzugeben.
Wie geht es denn jetzt weiter:
Meine Device sieht nun wie folgt aus:
define KG.WzK.PC_AK WOL 74:D4:35:08:2C:75 192.168.0.45 CMD
setuuid KG.WzK.PC_AK 5fafda34-f33f-7267-a80a-03afa4d030421ca0
attr KG.WzK.PC_AK room Keller
attr KG.WzK.PC_AK sshHost pi@172.27.0.1
also mein PC der per WOL eingeschaltet wird liegt auf 192.168.0.45 mit MAC 74:D4:35:08:2C:75
Danke Andreas
wenn du alles richtig eingerichtet hast muss das hier funktionieren. Die Platzhalter in <> mit deinen Werten ersetzen
su fhem <----- ich ggf. durch den User mit dem fhem läuft ersetzen
ssh <servername> -p <port> -l <username> -t "<remote-command>
Beispiel ssh host.docker.internal -p 22 -l pi -t "sudo etherwake 74:D4:35:08:2C:75"
Das müsste dann deinen PC wecken.
Fehler: etherwake not found --> sudo apt-get install etherwake
Fehler: Passwort wird abgefragt: ssh Konfig passt noch nicht ganz
Fehler: Passwort wird abgefragt: etherwake muss noch in die SUDO Konfiguration
Wenn das soweit ohne Fehler durchläuft und WOL funktioniert kannst das in FHEM einrichten
defmod WOL_PC <MAC deines PC> <IP deines PC> CMD
attr WOL_PC devStateIcon off:message_presence_disabled on:message_presence ---- optional, Symbole statt Text
attr WOL_PC icon it_pc
attr WOL_PC interval 60
attr WOL_PC sshHost <user auf dem host>@<Hostname / IP des Host> -p 22
attr WOL_PC wolCmd sudo etherwake $MAC ---- $MAC muss so bleiben, das nimmt das Modul aus der Definition
Hallo,
alles gut. Es funktioniert.
Vielen Dank,
Gruss Andreas
noch ein abschließender Tipp, mach nur den etherwake Befehl in SUDO-Config rein. Sei da vorsichtig.
Es gibt mehrere Personen die hier ganz großzügig All:all mit * konfiguriert haben. Alles was du ohne Passwort erlaubst könnte im Falle eines Hackangriffs ausgenutzt werden.
Oder um es kurz zu machen: Dann sind alle Sicherheitsmechanismen ausgehebelt und man könnte gleich alles unter root laufen lassen ....
Moin,
da ich hier etwas mit Stirnrunzeln mitgelesen habe - ich mag das "dünne Brett: sudo für alle" nicht besonders, weil es dann meist die "Lösung" für alle Probleme sein soll.
Da ich unter Windows einen fast "Einzeiler" habe, um aus Powershell heraus WOL - ohne erhöhte Rechte - zu machen, habe ich nach etwas vergleichbaren unter Linux gesucht. Ich habe zwar einen Einzeiler mit netcat gefunden, aber offenbar kursieren von nc unterschiedliche Versionen oder ich bin zu doof dafür.
Aber in FHEM lieben wie ja Perl :) da gibt es ein - im Internet viel zitiertes - Script von José Pedro Oliveira.
Das geht dann ganz ohne erhöhte Rechte (die braucht man für die UDP Methode von WOL nicht)
In diesem Thread: auf dem Host (als user)
wget -qO wakeonlan https://raw.githubusercontent.com/jpoliv/wakeonlan/master/wakeonlan
chmod +x wakeonlan
Dann testen im Container
ssh user@host ./wakeonlan 11:22:33:AA:BB:CC
Dann weiter wie beschrieben :)
Für die stille Ausführung gibt es den Parameter -q.
Im Übrigen geht Wake On Lan sehr wohl über Router hinweg, zumindest wenn der Router "nicht speziell" konfiguriert ist. Es gibt den "directed broadcast" - der wird vom Router an das entsprechende Subnetz weitergeleitet. Die typischen Heimnetz Router konnten das in meiner Umgebung bisher immer.
Nur der Broadcast an alle (255.255.255.255) wird vom Router geblockt und bleibt damit nur im eigenen Subnetz wirksam.
Beispiel -> ins Netzwerksegment 192.168.11.0 senden:
./wakeonlan -q -i 192.168.11.255 11:22:33:AA:BB:CC
Diese Methode ist ja auch im WOL Modul implementiert (attr useUdpBroadcast)
Gruß Otto
Jep .. bei ANgabe von der Broadcast-Adresse hast Du Recht. Nur welche "Normaluser" macht das schon ... ;o)
ich habe mal noch eine Perl /Shell Sub für die 99_myUtils gemacht womit man über einen Remotehost (oder den Dockerhost) per ssh WOL machen kann - ohne erhöhte Rechte, ohne jegliche Installation. Nur ssh mit public key einrichten :)
sub wol
{
my ($ziel,$mac,$bc,$port) = @_;
my $usage = 'use: wol \'user@host\',\'aa:bb:cc:11:22:33\'';
if (!defined $ziel or $ziel eq ''){return $usage}
if (!defined $mac or $mac eq '') {return $usage}
if (!defined $bc) {$bc ='255.255.255.255'}
if (!defined $port) {$port='9'}
my $script = <<"EOF";
MAC=$mac
Broadcast=$bc
PortNumber=$port
EOF
$script .= <<'EOF';
echo -e $(echo $(printf 'f%.0s' {1..12}; printf "$(echo $MAC | sed 's/://g')%.0s" {1..16}) | sed -e 's/../\\x&/g') | nc -w1 -u -b $Broadcast $PortNumber
EOF
system('ssh',$ziel,$script);
}
Gruß Otto
Hallo,
ich wollte das alte The noch einmal aufgreifen.
Bei mir läuft FHEM auch im container. das WOL-Modul ist aber nicht einsichtig, was meine ssh-Konfiguration anbelangt.
Ein "ssh USERUSER@host.docker.internal wakeonlan FF:F4:AB:E7:FF:FF" in der container CLI läuft sauber, das NAS wacht auf.
attr WOL_NAS sshHost USERUSER@host.docker.internal
attr WOL_NAS wolCmd wakeonlan FF:F4:AB:E7:FF:FF
wird allerdings außer acht gelassen und es wir immer der interne ether-wake Befehl abgesetzt, der natürlich nicht durch das Docketnetz geroutet werden kann.
Hat wer ne Idee? Besten Dank!
ZitatEin "ssh USERUSER@host.docker.internal wakeonlan FF:F4:AB:E7:FF:FF" in der container CLI läuft sauber, das NAS wacht auf.
Mit welchem user hast Du das getestet? Mit welchem user läuft FHEM?
In der FHEM Kommandozeile
{qx(id)}in der container cli
idFalls Du da Hilfe brauchst wie Du ssh für den FHEM User einrichten sollst: https://heinz-otto.blogspot.com/2020/09/ssh-mit-public-key.html
Hi,
der SSH Key mit dem User läuft einwandfrei. Ich hab FHEM über den user fhem laufen, dessen public key im host unter .ssh schlummert.. Testweise aber gerade auf root hochgeschraubt, auf beiden systemen (Host und Container). Das WOL Modul mag einfach nicht den String ausführen, der im wolCmd hinterlegt ist.
Ein {my_wol("root\@host.docker.internal","5C:F4:AB:E7:CF:3D")} als attr wolCmd (deine Funktion Testweise in myutils geparkt) wird auch nicht angenommen, im Log bleibt es weiter beim
2022.02.06 15:33:57 3: [WOL_NAS] waking WOL_NAS with MAC 5C:F4:AB:E7:CF:3D IP 192.168.50.250 via BOTH
2022.02.06 15:33:57 1: [WOL_NAS] Guessing broadcast address: 192.168.50.255
was dank des Docker routings nicht laufen wird.
Rufe ich die Funktion über die Eingabezeile auf funktioniert auch das. Irgendwie mag das WOL-Modul seit dem Umzug in den Container nimmer.
EDIT:
Ich kann machen, was ich will. Das WOL Modul nutzt für das Magic packet immer die interne Funktion statt sich auf das attr wolCmd zu beziehen.
ssh fhem@host.docker.internal wakeonlan -i 192.168.50.255 5C:F4:AB:E7:CF:3D functioniert als .sh oder auch direkt als fhem-Benutzer in der Container-CLI.
attr WOL_NAS shutdownCmd "./NAS_shutdown.sh" <--- läuft zuverlässig, früher auf einem Pi, nun im Docker
attr WOL_NAS wolCmd "./NAS_WOL.sh" <---- wird nicht herangezogen, Egal ob ein .sh, in Kombination mit sshHost oder mit einer FHEM internen my_utils Funktion.
Zitat von: SonOfAbaddon am 06 Februar 2022, 15:40:33
EDIT:
Ich kann machen, was ich will. Das WOL Modul nutzt für das Magic packet immer die interne Funktion statt sich auf das attr wolCmd zu beziehen.
Poste mal ein List deines WOL-Devices. Hast du bei der Definition hinten "CMD" angegeben?
Ohne Details ist es nur Rätselraten.
Um mehr Input zu bekommen. Setze auch mal Verbose 5 und poste das Log des WOL-Versuchs.
defmod WOL_NAS WOL 5C:F4:AB:E7:CF:3D 192.168.50.250 BOTH
attr WOL_NAS devStateIcon on:general_an@orange:off off:general_aus@black:on
attr WOL_NAS event-on-change-reading state
attr WOL_NAS icon it_nas@3399FF
attr WOL_NAS interval 30
attr WOL_NAS room System->Funktionen
attr WOL_NAS shutdownCmd "./NAS_shutdown.sh"
attr WOL_NAS wolCmd "./NAS_WOL.sh"
oder
defmod WOL_NAS WOL 5C:F4:AB:E7:CF:3D 192.168.50.250 BOTH
attr WOL_NAS devStateIcon on:general_an@orange:off off:general_aus@black:on
attr WOL_NAS event-on-change-reading state
attr WOL_NAS icon it_nas@3399FF
attr WOL_NAS interval 30
attr WOL_NAS room System->Funktionen
attr WOL_NAS sshHost fhem@host.docker.internal
attr WOL_NAS shutdownCmd "./NAS_shutdown.sh"
attr WOL_NAS wolCmd "wakeonlan 5C:F4:AB:E7:CF:3D"
Auszug aus dem Log:
2022.02.06 16:40:44 4: WEB_192.168.100.32_50016 POST /fhem?cmd.WOL_NAS=set%20WOL_NAS%20on&XHR=1&fwcsrf=csrf_643243148991735&fw_id=3880; BUFLEN:0
2022.02.06 16:40:44 5: Cmd: >set WOL_NAS on<
2022.02.06 16:40:44 3: [WOL_NAS] set WOL_NAS on
2022.02.06 16:40:44 3: [WOL_NAS] waking WOL_NAS with MAC 5C:F4:AB:E7:CF:3D IP 192.168.50.250 via BOTH
2022.02.06 16:40:44 1: [WOL_NAS] Guessing broadcast address: 192.168.50.255
2022.02.06 16:40:44 4: [WOL_NAS] keeping WOL_NAS with MAC 5C:F4:AB:E7:CF:3D IP 192.168.50.255 busy
2022.02.06 16:40:44 4: [WOL_NAS] executing /usr/sbin/etherwake 5C:F4:AB:E7:CF:3D
2022.02.06 16:40:44 4: WEB: /fhem?cmd.WOL_NAS=set%20WOL_NAS%20on&XHR=1&fwcsrf=csrf_643243148991735&fw_id=3880 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate
Der shutdown per .sh läuft sauber an und wird ausgeführt.
Bei dem was Du machen willst gehört das BOTH nicht dahin.
Und gestellte Fragen solltest Du beantworten, nicht mit Prosa sondern mit Fakten.
Wird denn Dein name host.docker.internal aufgelöst? Was liefert:
{qx(host host.docker.internal)}
in der FHEM Kommandozeile?
Zitat von: Otto123 am 06 Februar 2022, 16:50:35
Bei dem was Du machen willst gehört das BOTH nicht dahin.
Und gestellte Fragen solltest Du beantworten, nicht mit Prosa sondern mit Fakten.
OK, ich teste ohne both. Hatte nicht mehr im Hinterkopf, dass damit der FHEM-Modus gezündet wird. Ist ein wenig her, dass ich das Modul imtegriert habe.
Worauf willst du hiinaus?
Du hast gefragt welche Benutz - habe ich beschriben.
kadettilac hat nach Logs und der device config gefragt - habe ich beschrieben?
Was soll der Ton?
Zitat von: Otto123 am 06 Februar 2022, 15:20:26
Mit welchem user hast Du das getestet? Mit welchem user läuft FHEM?
In der FHEM Kommandozeile
{qx(id)}
in der container cli
id
Falls Du da Hilfe brauchst wie Du ssh für den FHEM User einrichten sollst: https://heinz-otto.blogspot.com/2020/09/ssh-mit-public-key.html
Zitat von: Otto123 am 06 Februar 2022, 16:54:28
wie beschrieben fhem
FHEM
uid=6061(fhem) gid=6061(fhem) groups=6061(fhem),5(tty),8(mail),20(dialout),29(audio),44(video),6001(bluetooth),6002(gpio),6003(i2c)
container
uid=6061(fhem) gid=6061(fhem) groups=6061(fhem),5(tty),8(mail),20(dialout),29(audio),44(video),6001(bluetooth),6002(gpio),6003(i2c)
qx zum host
Host host.docker.internal not found: 3(NXDOMAIN)
Da kommen wir der Sache näher. Interessant: nslookup im container löst auch nicht auf, ein ssh fhem@host..... wakeonlan ..... läuft sauber durch.
Was liefert der?
{qx(ls -lha wakeonlan)}
Funktioniert das in der FHEM Kommandozeile?
"wakeonlan 5C:F4:AB:E7:CF:3D"
Ach ne quatsch das soll ja per ssh - sorry ich lasse es mal stehen
Hab es hinbekommen. Der entscheidende Hinweis war das "BOTH" auf "CMD" zu drehen.
Dieser device build läuft nun für WOL und shutdown:
defmod WOL_NAS WOL 5C:F4:AB:E7:CF:3D 192.168.50.250 CMD
attr WOL_NAS devStateIcon on:general_an@orange:off off:general_aus@black:on
attr WOL_NAS event-on-change-reading state
attr WOL_NAS icon it_nas@3399FF
attr WOL_NAS interval 30
attr WOL_NAS room System->Funktionen
attr WOL_NAS shutdownCmd "./NAS_shutdown.sh"
attr WOL_NAS sshHost fhem@host.docker.internal
attr WOL_NAS wolCmd wakeonlan 5C:F4:AB:E7:CF:3D
Danke für die Detailhilfe! dem UDP/BOTH/CMD Parameter bin ich nicht mehr auf die Schliche gekommen.
Zitat von: Otto123 am 06 Februar 2022, 17:03:06
Was liefert der?
{qx(ls -lha wakeonlan)}
kommt gar nichts zurück, kein Ergebnis, kein Fehler
Zitat von: Otto123 am 06 Februar 2022, 17:03:06
Funktioniert das in der FHEM Kommandozeile?
"wakeonlan 5C:F4:AB:E7:CF:3D"
Ach ne quatsch das soll ja per ssh - sorry ich lasse es mal stehen
Unknown command wakeonlan, try help. Ist aber von mir erwartet, da das wakeonlan auf dem host liegt und per SSH getriggert wird, genau.
ja sorry, sollte nicht gehen, war ein Denkfehler.
Kein Ding, passiert.
Allerdings sind mein Log zum WOL so aus, wenn über FHEM getriggert:
2022.02.06 17:06:36 3: [WOL_NAS] Executing command >"ssh fhem@host.docker.internal -T wakeonlan 5C:F4:AB:E7:CF:3D"<
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_ADDRESS = "de_DE.UTF-8",
LC_NAME = "de_DE.UTF-8",
LC_MONETARY = "de_DE.UTF-8",
LC_PAPER = "de_DE.UTF-8",
LC_TELEPHONE = "de_DE.UTF-8",
LC_MESSAGES = "en_DK.UTF-8",
LC_MEASUREMENT = "de_DE.UTF-8",
LC_TIME = "de_DE.UTF-8",
LC_NUMERIC = "de_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Sending magic packet to 255.255.255.255:9 with 5C:F4:AB:E7:CF:3D
Kann ich den Container noch irgendwie tweaken, das er mit der locale besser klarkommt? -e LC_ALL="en_US.UTF-8", oder was hätte FHEM gerne aus unterbau?
Schau mal hier https://www.thomas-krenn.com/de/wiki/Perl_warning_Setting_locale_failed_unter_Debian
Ich meine dpkg-reconfigure ... löst am Ende das Problem. Hatt ich schon mal bei einer älteren Installation :-[
Liegt ev. hier am ssh Befehl
ZitatFalls das Problem nur per SSH auftritt, kann die Deaktivierung der SSH Client Option SendEnv LANG LC_* helfen.
Könnte aber sicher auch woanders auftreten
Ich hab das DEV-experimental image von FHEM laufen. Da der Fehler bei jedem container rebuild auftauchen wird wird's wohl Zeit für einiges ein eigenes docker build zu bauen. Im swarm ist ein container schneller weg als einem lieb ist. :D
Danke!
Aber auch dem Image gab es doch sowas wie ein Script / Mechanismus für eigene Add Ons. Bin Da nur spontan nicht so fit :)
Zitat von: SonOfAbaddon am 06 Februar 2022, 17:52:30
Ich hab das DEV-experimental image von FHEM laufen. Da der Fehler bei jedem container rebuild auftauchen wird wird's wohl Zeit für einiges ein eigenes docker build zu bauen. Im swarm ist ein container schneller weg als einem lieb ist. :D
Danke!
Spricht was dagegen deinen Container mit selben Locals zu betreiben wie auch den Host? Mein Setup ohne die besagte Meldung:
Paraemeter in Docker:
LANG: "de_DE.UTF-8"
LC_ALL: "de_DE.UTF-8"
Host:
<<<<<< locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Container:
<<<<<< locale
LANG=de_DE.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=de_DE.UTF-8
Ein paar Worte zu "Da der Fehler bei jedem container rebuild auftauchen"
Pakete per Parameter
Debian APT packages:
-e APT_PKGS="package1 package2"
Perl CPAN modules:
-e CPAN_PKGS="App::Name1 App::Name2"
Python PIP packages:
-e PIP_PKGS="package1 package2"
Node.js NPM packages:
-e NPM_PKGS="package1 package2"
Scripte:
Should you require any different permissions, you may read the next section to learn more about how to make any changes using custom pre start script /pre-start.sh or /docker/pre-start.sh.
Dazu habe ich mir ein pre-start.sh in ein Volume gelegt. Das wird auch ausgeführt.
volumes:
- ./fhem:/opt/fhem <<<<< default volume
- ./fhemscripts:/docker <<<<< Script folder
ein eigenes Dockerfile ist natürlich Crème de la Crème aber "dein" Problem solltewst du mit den vorhandenen Mitteln auch lösen können.
Zitat von: kadettilac89 am 07 Februar 2022, 08:38:47
Spricht was dagegen deinen Container mit selben Locals zu betreiben wie auch den Host?
Gute Idee :)
Dann konsequenterweise die Parameter im docker yml:
environment:
- TZ=Europe/Berlin
- LC_ALL
- LANG
um das Environment aus dem Host zu übernehmen.
getestet und funktioniert ;)
Da auf meinen hosts en_US vorherrscht musste ich tatsächlich für FHEM wie von kadettilac die locale definiert vorgeben. mit durchgeschobenen en_US hat sich nichts geändert. Mit gesetzten Deutsch-localen ist Ruhe. die ZEitzone habe ich Global in alle Container meines swarms eingetrichtert.
Über -e APT_PKGS="package1 package2" habe ich schon versicht ein Paket nachzuschieben. War danach aber nicht im container verfügbar.
Jetzt muss ich nur noch über die Containerstartskripte StrictHostKeyChecking=accept-new in ~/.ssh/config unterbringen, damit der fingerprint des hosts nicht beim containerstart den Aufbau blockiert.
Edit:
Oder man nutzt in der WOL CMD einen Parameter, das geht bie mir auch nach frisch erstelltem Container sauber durch und übergeht den Fingerprintcheck (Meinem eigenen Dockerhost vertraue ich da mal):
attr WOL_NAS shutdownCmd -o StrictHostKeyChecking=no 'expect' < /opt/fhem/NAS_shutdown.sh
attr WOL_NAS wolCmd -o StrictHostKeyChecking=no wakeonlan 5C:F4:AB:E7:CF:3D