Hallo zusammen,
am Sonntag den 15.12.2019 wird die FHEM Infrastruktur zwischen 10:00 und 12:00 Uhr nur eingeschränkt zur Verfügung stehen aufgrund von anstehenden Wartungsarbeiten.
In diesem Zeitraum kann es zu Einschränkungen und temporärer Nichterreichbarkeit beim Zugriff auf FHEM-Dienste wie Forum, SVN, Wiki, fhem.de sowie dem Alexa FHEM Connector kommen.
Für evtl. Fragen/Probleme steht dieser Thread allen zur Verfügung.
Wir bitten um euer Verständnis
Viele Grüße
Markus
Zitat von: Markus Bloch am 02 Dezember 2019, 17:35:13
am Donnerstag den 15.12.2019
nach meinem Kalender : Sonntag :)
Betreffen solche Arbeiten auch den Connector für Alexa?
Ja.
Zitat von: Amenophis86 am 02 Dezember 2019, 20:35:47
Betreffen solche Arbeiten auch den Connector für Alexa?
Ja, leider. Wir werden den Server einmal durchstarten. Dadurch kommt es zu einer kurzen Unterbrechnung (wenige Minuten) der Alexa Tunnel.
Zitat von: Wzut am 02 Dezember 2019, 17:38:57
nach meinem Kalender : Sonntag :)
Copy-Paste Fehler 8) Danke Dir.
Gruß
Markus
Sehe ihr habt es auch in die Meldung oben aufgenommen. Denke das macht Sinn, auch, wenn es nur kurz sein wird.
Etwas Off-Topic aber:
Mir ist aufgefallen, das ihr noch TLS 1.0 und TLS 1.1 anbietet. Ggf. sollte das abgeschaltet werden.
Dabei auch gleich die Cipher Suites für TLS 1.2 prüfen.
Siehe auch: https://wiki.mozilla.org/Security/Server_Side_TLS
Viele Grüße
Marcel
Hallo Marcel,
vielen Dank für den Hinweis. Habe ich im Rahmen der Arbeiten ebenfalls mit angepasst. TLSv1 sowie TLSv1.1 sind deaktiviert und die Ciphers wurden auf aktuell sichere geändert. Hoffen wir mal, dass es keine Klagen gibt ;-)
Viele Grüße
Markus
Vielen Dank fuer die Aktualisierung, aus meiner Sicht schaut alles gut aus.
Hallo,
kann leider keinen Update mehr durchführen:
2019.12.15 13:12:57 1 : https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(2) to https://fhem.de:443: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Kann dies mit den Wartungsarbeiten in Zusammenhang stehen?
FHEM ist auf Raspberry installiert, dieser ist up-to-date.
Bin für Hinweise dankbar.
Viele Grüße
Hallo Suchard,
im Rahmen der Wartungsarbeiten wurden für sichere HTTP-Verbindungen (HTTPS) als unsicher geltende Protokollversionen (TLS 1.0/1.1) deaktiviert.
Zitat von: suchard am 15 Dezember 2019, 13:16:41
FHEM ist auf Raspberry installiert, dieser ist up-to-date.
Das muss ich leider bezweifeln. Offenbar benutzt du eine recht veraltete Version von Raspbian für die es wohl keine Updates für openssl gibt, welches TLS 1.2 unterstützt. Welche Raspbian Version genau benutzt du denn?
Ich selber habe auf meinem Raspberry Raspbian 8 (jessie) installiert. Ist zwar auch nicht mehr taufrisch, aber kann problemlos auf https://fhem.de/ zugreifen.
Viele Grüße
Markus
Ja, hab die gleiche Fehlermeldung. Hab zwar auch gestern fhem auf eine andere Diskstation umgezogen, aber da ich mit Ubuntu mit VMM arbeite, konnte es damit wohl weniger zusammenhängen.
Unter Ubuntu 16.04 tritt er auch auf.
Webbrowser Zugriff in Ubuntu funktioniert auch problemlos.
Zitat von: Markus Bloch am 15 Dezember 2019, 15:09:57
Hallo Suchard,
im Rahmen der Wartungsarbeiten wurden für sichere HTTP-Verbindungen (HTTPS) als unsicher geltende Protokollversionen (TLS 1.0/1.1) deaktiviert.
Das muss ich leider bezweifeln. Offenbar benutzt du eine recht veraltete Version von Raspbian für die es wohl keine Updates für openssl gibt, welches TLS 1.2 unterstützt. Welche Raspbian Version genau benutzt du denn?
Ich selber habe auf meinem Raspberry Raspbian 8 (jessie) installiert. Ist zwar auch nicht mehr taufrisch, aber kann problemlos auf https://fhem.de/ zugreifen.
Viele Grüße
Markus
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
Linux RaspberryPi3 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux
relativ aktuelles Raspbian stretch buster macht keine Probleme.
Edit: sollte buster heißen. Muss ich mich noch dran gewöhnen. ::)
Hallo,
Auch auf meinem Raspi mit Raspian Jessie 8 funktioniert der FHEM-Update nicht mehr.
fhem
https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(2) to https://fhem.de:443: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Das TLS was der Server fordert, wird aber unterstützt, weil ein " wget https://fhem.de" wunderbar funktioniert.
Es scheint iwie am Perl zu liegen, was das nicht unterstützt.
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Gruß
Ryker
Habe es auch gerade nochmal genauer getestet. Wie von Ryker angemerkt, funktioniert es beim Raspbian jessie via curl/wget problemlos, aber eben via Perl nicht, da dort die entsprechenden Ciphers, die aktuell als sicher gelten nicht unterstützt werden.
Hier hilft dann tatsächlich nur ein Update auf ein neueres Raspbian.
Ich hab gerade noch etwas probiert, die Perl-Module anstelle ausm APT-Repo von CPAN zu holen, aber auch das bringt keine Besserung.
Ich würde mir aktuell wünschen, dass die TLS-Einstellung am WebServer erstmal wieder zurückgenommen wird.
Evtl könnte man das mal im Vorraus ankündigen, sodaß man mit dem raspi 3 genug Zeit hat vorher auf stretch zu gehen.
Gruß
Ryker
mit stretch tut es jetzt.
und warum nicht auf Buster? Die aktuelle Version ist nun mal Buster.
Ich stimme einer Rückstellung nicht zu. Es macht keinen Sinn unsichere Verbindungen zu zu lassen nur damit etwas geht. Es gibt eine Lösung und die heißt Update machen auf eine aktuelle Debian Version.
Zustimm.
Ist ja "nur" das update, das nicht geht. Wer also ein FHEM-update machen will, muss halt vorher auf eine neuere(aktuell=sicherer) Debian-Version.
Ich hab übrigens kürzlich stretch -> buster per upgrade gemacht. War eigentlich(bis auf die Laufzeit !) recht easy mit der Anleitung, die ich im Inet gefunden hatte.
Ich habe gerade festgestellt dass ich auf meinem Rechner mit perl 5.18 die gleichen Probleme habe, auf der gleichen Maschine mit perl 5.30 aber keine.
Ein weiteres Workaround ist in FHEM/98_update.pm die Zeile 242
$src =~ s'^http://fhem\.de'https://fhem.de' if($upd_hasSSL);auszukomentieren oder zu entfernen.
ZitatEs gibt eine Lösung und die heißt Update machen auf eine aktuelle Debian Version.
Die ist fuer viele Anwender nicht einfach praktikabel (abgesehen vom Aufwand), und in bestimmten Faellen bedeutet ein Update das Wechseln der Server-Hardware. Ein Update ist fuer die, die beliebig viel Zeit/Energie fuer FHEM uebrig haben, sicher kein Problem, aber das sind nicht alle Anwender von FHEM.
Das Sicherheitsrisiko ist nur dann vorhanden, wenn die Clients auf die alte/verwundbare Protokollversion bestehen.
Ich wuerde das in Kauf nehmen, anstatt diese Anwender zu einem alten FHEM zu zwingen.
ZitatWar eigentlich(bis auf die Laufzeit !) recht easy mit der Anleitung, die ich im Inet gefunden hatte.
Und wir haben seit 10 Tagen ein Problem mit einem nicht funkionierenden SCC seit dem update auf buster, was immer noch nicht komplett geloest ist: https://forum.fhem.de/index.php/topic,106060.0.html (https://forum.fhem.de/index.php/topic,106060.0.html)
Ich kann bestätigen, das ich auf zwei Maschinen mit jessie das gleiche Problem habe.
wheezy, stretch und buster laufen problemlos. ::)
Dann ist wohl jetzt die Zeit gekommen :)
Meine wheezy mit Perl 5.014002 funktioniert auch noch
ich habe ebenso das problem mit eine jessyinstallation ( Perl:5.20.2).
Ein update auf eine aktuellere Version kann ich auf diesem System leider nicht machen , da Jessie die letzte Version ist mit der sich über fhem Playbulps steuern lassen !
... somit für mich unverzichtbar und es wäre schön , wenn es eine andere Lösung ( optional ) geben würde.
ich habe jetzt erstmal betreffende zeile in 98_update.pm auskommentiert und diese vom update ausgeschlossen.
gruss Byte09
Mal ´ne Idee in die Runde:
Macht es evtl. Sinn die Updates über eine eigene Subdomain zu verteilen, die für ältere Systeme etwas "kompatibler" konfiguriert ist?
Gruß
Danny
Hier die Anleitung (https://pimylifeup.com/upgrade-raspbian-stretch-to-raspbian-buster/), der ich gefolgt bin. Das dürfte genauso für jessie -> stretch funktionieren.
ZitatDie ist fuer viele Anwender nicht einfach praktikabel (abgesehen vom Aufwand),
Klar ist das unangenehm, aber meines Erachtens aus Sicherheitsgründen unabdingbar.
Zitatin bestimmten Faellen bedeutet ein Update das Wechseln der Server-Hardware
Übel, aber auch hier würde ich dem OS nicht lange vertrauen....
ZitatUnd wir haben seit 10 Tagen ein Problem mit einem nicht funkionierenden SCC seit dem update auf buster, was immer noch nicht komplett geloest ist: https://forum.fhem.de/index.php/topic,106060.0.html
Das ist natürlich Käse. Dann erst einmal -> stretch ?
Hallo,
ich benutze "Raspbian GNU/Linux 7 (wheezy)". Gerade nochmals aktualisiert. Leider kann ich ebenfalls kein Update mehr durchführen.
Viele Grüße
Rainer
Ubuntu 16.4 LTS will auch nicht. Hatte zwar schon mal vor, auf 18.04 upzugraden, war aber bisher gescheitert. Mit jetzt potenterer Hardware werde ich's noch mal versuchen.
Hallo zusammen,
das dies an meinen beiden Raspi B (1.Generation) irgendwann mal passieren würde, kann ich ja noch halbwegs verstehen.
Aber an einem Odroid C2 mit Ubuntu 16.04 LTS funktioniert auch kein FHEM-Update mehr.
Na klar, ich kann ja das Betriebsystem updaten, mal eben so, auf mindestens meinen drei eigenen Installationen.
So richtig spaßig finde ich das jetzt aber nicht, ich fühle mich da doch ein wenig bevormundet.
Ich fürchte auch mit einer so radikalen Änderung tun sich doch einige Leute sehr schwer und werden von einer weiteren Nutzung von FHEM eher absehen.
Also bitte, überdenkt eure schwerwiegende Entscheidung oder zeigt den Nutzern bitte eine nachvollziehbare Schritt-für-Schritt Lösung auf.
Liebe Grüße
Frank
Dem kann ich mich leider nur anschließen ! Bislang lief FHEM bei mir mehr als gut auf einem Raspi 2B mit Jessie, warum soll ich jetzt Hard- und Software updaten ?
Zitat von: cs-online am 16 Dezember 2019, 20:28:58
Dem kann ich mich leider nur anschließen ! Bislang lief FHEM bei mir mehr als gut auf einem Raspi 2B mit Jessie, warum soll ich jetzt Hard- und Software updaten ?
Warum HW!?
OS-SW reicht doch... ;)
Gruß, Joachim
Zitat von: CoolTux am 15 Dezember 2019, 17:59:09
und warum nicht auf Buster? Die aktuelle Version ist nun mal Buster.
Ah, danke für den Tipp, das war iwie an mir vorbeigegenagen, dass es ja seit einiger Zeit Buster gibt.
Weil ich nirgends im Inet was gefunden habe, wo jemand von Jessie auf Buster geupgraded hat, hab ich vorsichtshalber erstmal nur den Upgrade auf Stretch gemacht. Das lief anstandlos durch und damit klappt der FHEM-update nun auch wieder.
Der Upgrade auf Buster steht bei mir als nächstes an.
Gruß
Ryker
Ich würde aber (irgendwann) neu aufsetzen als (immer nur) upgraden...
Gerade zwischen Wheezy/Jessie und Stretch (Buster) hat sich so einiges am "Unterbau" geändert...
Außerdem ist es ein guter Zeitpunkt noch mal zu prüfen, ob man alles wirklich noch nutzt/braucht (z.B. auch OS-Pakete)...
(also mache ich so und bin froh, wenn ich wieder auf einige Pakete verzichten kann :) )
Ist auch immer ein guter Test, ob Restore klappt und die eigene Doku noch stimmt... ;)
Gruß, Joachim
Auf meinem Raspberry B läuft seit dem es Buster gibt Buster. Läuft bestimmt auch auf dem 2B ;)
Auf meinem wheezy mit Perl Version v5.14.2 läuft update check ohne Probleme. Haben die wheezy wo es nicht läuft ein anderes Perl?
Kann man auf ubuntu perl updaten?
I fixed this on MacOS (Perl v5.28.2) by reinstalling Net::SSLeay, but you need a recent OpenSSL library for this to work.
cpanm-5.28 --sudo --notest --reinstall Net::SSLeay
perl -MNet::SSLeay -E 'say Net::SSLeay::SSLeay_version(0)'
OpenSSL 1.1.1d 10 Sep 2019
Guten morgen,
ich habe jetzt geschlagene 4,5 Stunden damit verbracht den ersten Raspberry von Jessie auf Stretch zu aktualisieren.
War ja klar, daß nach dem Reboot FHEM mit einer Fehlermeldung startet.
"configfile: install Crypt::OpenSSL::AES to use Broadlink"
Nachdem ich alle Installationsschritte aus dem Broadlink-Thread wiederholt habe, läuft sowohl mein FHEM als auch das FHEM update-check jetzt wieder.
Bleiben noch zwei weitere Installationen, und wehe an Heiligabend lassen sich die Kerzen am Weihnachtsbaum nicht schalten. ;)
Viel Glück an alle, die diese Prozedur noch vor sich haben.
Frank
Hallo Zusammen,
ich bekomme seit gestern 16.12.2019 folgende Fehlermeldung beim Update Check
https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(2) to https://fhem.de:443: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Zwischen dem letzten update welches ich vor ca 4 Wochen gemacht habe und dem Versuch von Gestern hat sich nur eine Device geändert. Dieses Device ist eine ESP8266 als Fensterkontakt von diesen Devices habe ich aber weitere 10 Stück im Haus also kann es am Device nicht liegen.
Jetzt meine Frage woran kann es liegen das ich diese Fehlermeldung bekomme?
Gruß
Dieter
Zitat von: diepe am 17 Dezember 2019, 11:32:39
Jetzt meine Frage woran kann es liegen das ich diese Fehlermeldung bekomme?
Hallo Dieter,
eventuell daran, dass Du Jessie oder Ubuntu 16.04 als Betriebssystem hast?
Gruß Otto
Hallo Otto,
ja ich habe Jessie auf einem Raspberrypi 3 ich ahne es schon das nächste Update auf Stretch ist fällig oder?
Gruß
Dieter
Hallo Dieter,
der Thread ist nicht so lang, lies einfach ein bisschen rückwärts :'(
Gruß Otto
Hallo Otto,
ok mach ich nochmals Danke
Gruß Dieter
Hallo Otto,
bevor wir uns den ganzen Krams per Update zerschießen, fand ich den Ansatz von dir von oben eigentlich recht interessant, kann man nicht einfach Perl updaten ? Und ist denn eigentlich gesichert, dass es an der Perl-Version liegt ?
Grüße Christian
Hallo Christian,
na Nestor hat ja in #35 einen konkreten Ansatz geliefert.
ich für meinen Teil mache das System neu, das ist kein großes Ding. Stand sowieso an :)
Gruß Otto
Danke dir, ich wird mal schauen, ob ich da was mit erreiche, neu installieren ist immer so ein Kampf, bis alles wieder läuft und bei vielen Dingen weiß ich kaum noch, was wir da gemacht haben...
Grüße Christian
ich habe aktuell noch die Ubuntu 16.04LTS drauf.
da ja leider kein update von fhem funktioniert, hat schon mal einer das upgrade von 16.04 oder 18.04 gemacht ?geht das problemlos ? ich habe im netz ne anleitung gefunden :
https://www.tuxedocomputers.com/de/Infos/Hilfe-Support/Anleitungen/Ubuntu-Upgrade-von-16-04-auf-18-04.tuxedo
kann ich die benutzen oder gibts ne andere lösung?
Zitat von: Otto123 am 17 Dezember 2019, 22:04:16
#21 und #35
[Ironie]
Aber Otto, der Thread hat 4 Seiten, die liest doch keiner mehr vor dem posten...
[/ironie]
Moin zusammen,
meine Fhem Installation ist von diesem Change ebenso betroffen. Der neue Raspi 4 liegt schon da und Weihnachten sollte alles umgezogen werden, leider aktuell das Thema mit Buster und dem Busware SCC. Da muss ich die Lösung noch genau verstehen.
Unabhängig von der technischen Notwendigkeit, die IT Sicherheit immer auf dem bestmöglichen Status zu halten zu müssen, würde ich diesen Change als schiefgegangen bezeichnen, der, wenn das so bei mir in der Firma passiert wäre, zurückgerollt werden müsste.
Vielleicht habe ich nicht alle Ankündigungen in Gänze verstanden oder gelesen, aber eine Info, dass bestimmte Versionen des OS/Pearl nicht mit den neuen TLS Anforderungen kompatibel sind, habe ich nicht gefunden. Das empfinde ich als das eigentliche Problem.
Wir betreiben ein Nicht-kommerzielles Projekt mit vielen Freiwilligen.
Daher möchte ich auf keinen Fall zu streng sein.
Ich hätte gerne Folgendes:
- Eine gesonderte Doku zum Problem. Nicht in einem Thread mit ganz anderem Namen.
- Welche OS/Pearl Version ist betroffen?
- Wie viele Installationen davon haben wir ww? Also haben wir eigentlich ein größeres Problem?
- Welche Version eines temporären Workarounds sollen wir einrichten? Ich bin bei solchen Themen immer gerne verbindlich. Klare Ansage.
- Oder: Je nach Anzahl der betroffenen Installationen ww den TLS Teil des Changes zurücknehmen und neu terminieren, damit sich die betroffenen Systembetreiber einrichten können.
Herzliche Grüße und habt alle geruhsame Feiertage,
Helmut
Zitat von: dl4fb am 18 Dezember 2019, 09:22:09
Wir betreiben ein Nicht-kommerzielles Projekt mit vielen Freiwilligen.
Daher möchte ich auf keinen Fall zu streng sein.
Ich hätte gerne Folgendes:
- Eine gesonderte Doku zum Problem. Nicht in einem Thread mit ganz anderem Namen.
- Welche OS/Pearl Version ist betroffen?
- Wie viele Installationen davon haben wir ww? Also haben wir eigentlich ein größeres Problem?
- Welche Version eines temporären Workarounds sollen wir einrichten? Ich bin bei solchen Themen immer gerne verbindlich. Klare Ansage.
Dann leg doch mal los und hilf anderen damit oder wer sollte aus deinen Augen die Punkte umsetzen?
Zitat von: Homer1978 am 17 Dezember 2019, 19:11:15
ich habe aktuell noch die Ubuntu 16.04LTS drauf.
da ja leider kein update von fhem funktioniert, hat schon mal einer das upgrade von 16.04 oder 18.04 gemacht ?geht das problemlos ? ich habe im netz ne anleitung gefunden :
https://www.tuxedocomputers.com/de/Infos/Hilfe-Support/Anleitungen/Ubuntu-Upgrade-von-16-04-auf-18-04.tuxedo
Ich hab Ubuntu 16.04LTS in einer VM auf dem NAS laufen. Meine letzten Versuche einen Klon der VM auf 18.04 upzugraden sind kläglich gescheitert. Werde es jetzt noch mal auf dem neuen NAS versuchen.
Melde mich dann noch.
Klar helfe ich!
Ich muss allerdings gestehen, dass ich kein SSL/TSL/Perl Spezialist bin und dass es wahrscheinlich wichtig ist, schnell eine Ansage zum temporären Workaround zu bekommen.
Ich denke, es wäre erst mal wichtig zu besprechen, ob mein Vorschlag eines separaten Themas überhaupt umgesetzt werden soll.
In dem Zusammenhang und bei allem Respekt, wäre wahrscheinlich Rudis Statement das Wichtigste.
Es gibt übrigens im Wiki einen cmdalias, um das Update direkt über svn auszuführen. (https://wiki.fhem.de/wiki/Cmdalias#svnupdate (https://wiki.fhem.de/wiki/Cmdalias#svnupdate))
Damit werden allerdings keine Backups vor dem Update erstellt oder die CommandRef aktualisiert.
ZitatIn dem Zusammenhang und bei allem Respekt, wäre wahrscheinlich Rudis Statement das Wichtigste.
Wie man das hier (https://forum.fhem.de/index.php/topic,105944.msg1002199.html#msg1002199) lesen kann, wuerde ich die Aenderung lieber zuruecknehmen, ich wollte das aber nicht gegen den Willen der anderen Entwickler durchdruecken, die offensichtlich fuer die neuen TLS-Regeln und fuer ein OS-Update sind.
Mein aktueller Plan ist fuer fhem.de (aber nicht fuer forum/svn/etc) Ausnahmen fuer TLS-Regeln einzubauen, ich muss aber dafuer Zeit nehmen, weil ich mich damit (noch) nicht auskenne. Evtl. koennen wir fuer update auch eine separate Domaene einfuehren, ich habe aber noch kein Plan, wie die Migration stattfinden soll.
ZitatIch muss allerdings gestehen, dass ich kein SSL/TSL/Pearl Spezialist bin
Ich bin leider in etlichen Sachen, die erledigt werden muessen, auch kein Spezialist (unter anderem SSL/TLS und apache), und wollte auch nie sein, habe aber die Ehre mich einzuarbeiten, wenn keiner hilft.
Zitatschnell eine Ansage zum temporären Workaround zu bekommen.
Den gibt es im gleichen Beitrag von mir: https://forum.fhem.de/index.php/topic,105944.msg1002199.html#msg1002199
ZitatVielleicht habe ich nicht alle Ankündigungen in Gänze verstanden oder gelesen, aber eine Info, dass bestimmte Versionen des OS/Pearl nicht mit den neuen TLS Anforderungen kompatibel sind, habe ich nicht gefunden. Das empfinde ich als das eigentliche Problem.
Ich befuerchte, dass wir deine Erwartungen bezueglich Tests nicht erfuellen koennen und werden. Weder besitzt ein Entwickler alle Geraete/OS/Firmware Versionen, noch haette er Zeit diese alle durchzutesten. Fuer ausgiebige Tests verlassen wir uns auf die Benutzer, die in der Absicht den Entwicklern zu helfen regelmaessig und ohne weiteren Grund ein update durchfuehren.
Auch wenn das ganze für manche ärgerlich und unverständlich ist:
es gibt diverse workarounds, man muß die nur finden (was derzeit eher das Problem zu sein scheint)...
Vielleicht wäre es eine Idee, update (temporär!) so zu erweitern, dass man als Option "-noSSL" angeben kann und damit das "Auskommentieren" der betreffenden Zeile automatisiert durchführt? Dann wäre niemand gezwungen, Aktionen durchzuführen, die er (derzeit) noch nicht durchführen will, hätte den Hinweis, dass da noch was zu tun ist, und man kann es zu gegebener Zeit recht einfach wieder ausbauen?
(Das Problem, dass man "erst mal" auf diesen Stand kommen muß, löst das allerdings zugegebenermaßen nicht; hier muß dann halt notfalls einmalig die update aus dem svn geholt werden).
Zitat von: Beta-User am 18 Dezember 2019, 10:56:57
(Das Problem, dass man "erst mal" auf diesen Stand kommen muß, löst das allerdings zugegebenermaßen nicht; hier muß dann halt notfalls einmalig die update aus dem svn geholt werden).
Was ohne viel "Wissen" und ungefährlich gehen würde :)
svnupdate 98_update.pm;reload 98_update.pmvorher Raw Def ;)
defmod c3 cmdalias svnupdate .* AS {\
my ($e,$g) = (undef,(split(" ",$EVENT))[0]);;\
if (defined $g)\
{\
$e = qx(mkdir -p ./restoreDir/pm/"$year-$month-$mday"/FHEM/);;\
$e = qx(cp ./FHEM/$g ./restoreDir/pm/"$year-$month-$mday"/FHEM/);;\
qx(wget -qO ./FHEM/$g https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/$g)\
} else {\
$e = "use svnupdate Filename inside ./FHEM/"\
}\
return $e ? $e : "./FHEM/$g backuped and new loaded from SVN\nreload $g or shutdown restart to apply"\
}
:) An den cmdalias hatte ich auch gedacht ;D ...
(Der ist aber noch verbesserungsfähig ::) , es wird z.B. nicht geprüft, ob die Datei da ist (bzw. wenigstens im svn), man muß den ganzen Namen eingeben/kann nicht mit Wildcards arbeiten usw.)
ähm, verstehe ich das richtig, dass, wenn man die update.pm vom SVN auf den FHEM-Server kopiert und reloaded dann das update wieder gehen würde ?
Zitat von: Beta-User am 18 Dezember 2019, 11:53:12
man muß den ganzen Namen eingeben/kann nicht mit Wildcards arbeiten usw.)
Ja ja ja :)
Aber nur weil das svn / wget dort keine Wildcards kann. Es sollte ja genau für den Fall sein: Eine Datei mal schnell gefixed aus dem SVN holen, weil es gerade brennt. Und Otto Normaluser gar nix vom svn weiß, aber der Entwickler reagiert hat und den Hinweis gab. :D
Bei dem Thread Titel ist jetzt fast alles OT oder gerade nicht? ;D
Zitat von: cs-online am 18 Dezember 2019, 12:10:30
ähm, verstehe ich das richtig, dass, wenn man die update.pm vom SVN auf den FHEM-Server kopiert und reloaded dann das update wieder gehen würde ?
verstehst Du falsch, denn dazu müsste es ein geändertes update dort geben.
Nicht immer nur den letzten Post "wunsch" lesen :)
Doppelt genäht hält vielleicht besser...?
@cs-online: Derzeit: nein!
Heute muß man eine Zeile editieren, wie das Rudi geschrieben hatte. Das betraf die Frage, wie man "dauerhaft" eine Lösung vorhelten kann, bei der man nicht daran denken muß, ggf. 98_update.pm wieder zu ändern...
@Otto:
das wget nicht, man müßte vorher arrays auf Basis der vorhandenen files bilden und dann der Reihe nach abholen usw...
Zu meiner Frage / meinem Vorschlag:
- Welche OS/Perl Version ist betroffen?
- Perl 5.28 (eine Meldung hier im Forum)
- Perl 5.20
- Perl 5.18
- Vermutlich die früheren Versionen auch (nicht verifiziert), eine Meldung zu 5.01, damit funktioniert der Update.
- Wenn neuere Versionen auch betroffen sind, werde ich das heute Abend nachtragen
- Perl 5.30 funktioniert
- Welche Version eines temporären Workarounds sollen wir einrichten?
- Diese: https://forum.fhem.de/index.php/topic,105944.msg1002199.html#msg1002199
- Wie viele Installationen davon haben wir ww? Also haben wir eigentlich ein größeres Problem?
- Lt. Statistik mindestens 1074 FHEM mit Perl 5.20 Installationen
- Plus 57 Installationen mit Perl 5.18
- Plus womöglich ca. 400 noch ältere Perl Installationen.
Meine Meinung: Für Anspielungen jeder Art ist bei dem Umfang an potentiell betroffenen Installationen kein Platz.
Es ist bitte abzuwägen, was das größere Übel ist.
- Kein FHEM Udpate, den kleinen Patch einrichten oder den TLS Change zurückrollen und in einigen Monaten neu aufsetzen.
Ein Change der vielen betroffenen Installationen in wenigen Tagen ist unrealistisch.
Und Danke an Rudi für's Update.
Ja, das ist auch meine Erfahrung, dass viele Abhängigkeiten bei einem Change schwer oder gar nicht zu testen ist. Dafür gibt es in der Regel die Roll-Back Möglichkeit.
Gruß Helmut
Nur für's Protokoll.
Ich habe gerade Rudi's Vorschlag umgesetzt und für die Anfänger auch dokumentiert.
Nach dem Update steht im Log, dass fheminfo auch nicht mehr funktioniert.
Nun denn.
Gruß Helmut
Habe gerade TLS1 und TLS1.1 auf dem Server wieder aktiviert.
Weiterhin habe ich die -noSSL Option zu update hinzugefuegt.
Super Rudi, läuft wieder !!! Danke dir vielmals !!!
Grüße Christian
Auch von mir ein Dankeschön!
Danke für die schnelle Reaktion. Immerhin habe ich das gestern gleich zum Anlass genommen einen neuen Pi 4 zu bestellen und mein System hochzuziehen. Die Zeit vergeht echt so schnell, hätte nicht gedacht das es kein aktuelles Perl mehr für Jessie angeboten wird..
lg
Ich bin damit nicht wirklich glücklich. Wie immer wurde das eigentliche Problem damit nur verschoben. Die Update Faulheit der User beim Betriebssystem.
Im Prinzip hast du Recht.
Nur mit so vielen betroffenen Installationen muss der Change mit einem entsprechenden Vorlauf angekündigt werden.
Deswegen denke ich, ist es richtig, den erst mal zurück zu nehmen.
Sorry aber ein "Out of Lifing" Betriebssystem nicht mehr zu Unterstützen .. braucht eigentlich keinen Vorlauf mehr ..
Selbst Ubuntu 14.04 ist noch in "Extended Maintanance"! (EDIT: 12.04.03 seit dem Frühjahr nicht mehr)
Und hier waren auch Installationen genannt mit 16.04, das ist noch in LTS. Wer eine LTS-Version einsetzt, tut das ggf. auch, weil er sich nicht immer neue Installationen antun will...
So ganz kann ich die Tonlage daher nicht nachvollziehen. Aber so langsam ist das einigermaßen OT; schließlich muß jeder selbst wissen, was er tut.
Es ist ok bzw. sogar angebracht, ggf. mal darauf hinzuweisen, dass ein (FHEM-) Server KEIN fire&forget-Device ist (fast nichts in der IoT-Welt ist das), aber "Knall auf Fall" irgendwen zu seinem Glück zu zwingen (der immerhin sein FHEM aktuell halten will...!), muß andererseits auch nicht sein.
(OT: Aber es ist gut, die Diskussion zu führen, macht durchaus Sinn, wenn man den "update"-Aspekt hin und wieder eingehend beleuchtet ;D ).
(Ich bin übrigens auf aktuellem Debian 10, also kein "getroffener Hund"!)
Offenbar liegt es ja nicht primär an irgendeiner Systemversion sondern an der Perlversion, oder sogar bloß an einer Datei innerhalb Perl.
Offenbar bedeutet ja auch LTS nicht, dass über einen Zeitraum von 5 Jahren alle Eventualitäten des Internet Lebens bis in das letzte Perlmodul gefixt werden.
Können wir weiter an einer Lösung arbeiten? Ich würde gern helfen, aber wie?
Der sparsamste Ansatz für mich wäre: Austausch einer Perl Modul Datei (so in etwa verstehe ich Nestor #35) und schon wird TLS richtig ausgehandelt. Ist das nicht das eigentliche Problem?
Können wir erstmal den Spieß umdrehen und einen zweiten "update Server" (also nur link, Domäne) bereitstellen, der die jetzt als problematisch erwiesene Einstellung hat, wo einfach die User, die es wollen ein paar Dinge testen und untersuchen können? Vielleicht findet ja jemand eine einfache Lösung.
Mich wundert ja immer noch, dass bei mir nur Jessi das Problem hatte und wheezy funktionierte. Bei anderen offenbar nicht. Hab ich da in der Vergangenheit was gemacht? Eventuell habe ich da mal was an der SSL.pm gedreht weil sonst sendeEmail nicht funktionierte.
Gruß Otto
Wenn ich das richtig sehe, gibt es doch jetzt für den update-Befehl den Schalter
-noSSL:
ZitatMit -noSSL wird das http Protocol statt https verwendet, was bei bestimmten veralteten Distributionen notwendig sein kann.
D.h., man kann doch problemlos die Server wieder umstellen. Evtl. kann man ja hier im Forum in den Neuigkeiten ankündigen, daß jeder die neue Version von 98_update.pm benötigt und daß die Server in x Tagen umgestellt werden.
Sollte dann immer noch jemand später kommen, muß er eben einmal die Datei händisch runterladen und austauschen. (wie in #55 (https://forum.fhem.de/index.php/topic,105944.msg1003016.html#msg1003016) beschrieben)
Größere Probleme beim Upgrade gab es eigentlich nur von Wheezy nach Jessie, was hauptsächlich an der Umstellung von init nach systemd lag. Von Jessie nach Stretch und Buster war das Upgrade eigentlich relativ problemlos.
Jessie stammt immerhin aus 2015 und ist seit 6/2018 EOL (LTE auch nur noch bis 6/2020).
Aber wenn jemand eben partout kein OS- oder Perl-Update machen will, kann er die aktuelle Version ja weiterhin ohne SSL starten.
ZitatOffenbar liegt es ja nicht primär an irgendeiner Systemversion sondern an der Perlversion, oder sogar bloß an einer Datei innerhalb Perl.
Wenn ich es richtig verstanden habe, liegt es an der Version der vom perl verwendeten openssl Bibliothek.
Eine rueckwaertskompatible Loesung funktioniert (mW) nicht: das bisherige update.pm verbindet sich (nur falls IO::Socket::SSL installiert ist) per HTTPS mit fhem.de, und genau da wollen wir TLS1 abschalten. Mit der neuen update.pm kann man HTTPS manuell deaktivieren (-noSSL), das muss man aber erst haben, es ist also ein Henne-Ei Problem. Den funktionierenden Workaround mit Auskommentieren einer Zeile haben offensichtlich viele nicht verstanden, gefunden oder verwenden wollen, deswegen sehe ich schwarz fuer eine manuelle Installation der neuen update.pm.
Aktuell bin ich fuers Aktivieren von TLS1 in einem Jahr, und hoffe dass der Querschnitt von "update seltener als einmal pro Jahr" und "OS alt" gering ist.
Wer bessere Ideen hat, der soll sich melden.
Zitat von: CoolTux am 19 Dezember 2019, 09:04:05
Ich bin damit nicht wirklich glücklich. Wie immer wurde das eigentliche Problem damit nur verschoben. Die Update Faulheit der User beim Betriebssystem.
Genau, und ich bin einer von denen. Daher egal wie das hier ausgeht, über Weihnachten gibt es ein Upgrade. ;)
Dabei ist es noch nicht mal Faulheit, sondern geht eher in die Richtung ...
Zitat von: psycho160 am 19 Dezember 2019, 08:00:35
Die Zeit vergeht echt so schnell, hätte nicht gedacht das es kein aktuelles Perl mehr für Jessie angeboten wird..
Wenn ich das von Nestor richtig verstehe, hängt es daran, dass zum einen OpenSSL aktuell ist und zum anderen die Perl-lib Net::SSLeay neu initialisiert.
Was jeweils für OpenSSL und libnet-ssleay-perl ausgeliefert wird, kann man ja über die Suche bei Debian (zumindest in etwa) in Erfahrung bringen: https://packages.debian.org/search?searchon=names&keywords=openssl (https://packages.debian.org/search?searchon=names&keywords=openssl)
Für einen schnellen Test sollte es also so gehen (wheezy wird ja nicht aktueller sein, und funktioniert noch...):
sudo apt-get install --reinstall openssl libnet-ssleay-perl
@Otto123: Vielleicht testest du das auf deiner "Testmurmel" mal aus (du hattest doch ein betroffenes System, oder?)?
Ansonsten sollte man (in Anfängerbereich oder bei Linux-Server?) dazu einen neuen Thread aufmachen, das ist hier ein reichlich exotischer Platz für solche Diskussionen...
Zitat@Otto123: Vielleicht testest du das auf deiner "Testmurmel" mal aus (du hattest doch ein betroffenes System, oder?)?
Jaaa gerne, aber wie? Der update Server frisst ja jetzt wieder meine Testmurmel (ist im übrigen mein aktuelles aktives Haupt FHEM) 🙈
ich hatte ja "einfach" gedacht, wenn einer der Admins eine subdomain neussl.fhem.de (oder von mir aus auf irgendeiner Testmurmel) nach neuem Schema schaltet kann ich mit
update check https://neussl.fhem.de/fhemupdate/controls_fhem.txteinen Test machen.
Ich habe leider keinen Plan wie ich das intern bei mir bewerkstelligen könnte und dann wäre ich auch wieder der einzige 😂
Argh... Mal wieder zu kurz gedacht ::) .
Na ja, lassen wir das...
Zitat von: rudolfkoenig am 18 Dezember 2019, 18:47:51
Habe gerade TLS1 und TLS1.1 auf dem Server wieder aktiviert.
Weiterhin habe ich die -noSSL Option zu update hinzugefuegt.
Ähm, hilf mir bitte mal eben auf die Sprünge, wo wird das denn eingestellt ? Ich finde kein "update"-Device mit "list update"
Grüße Christian
...versuch's mal mit "help update"...
Oder sieh dir die commandref dazu an (was fast auf dasselbe rausläuft).
Vorerst wird dir -noSSL wohl keinen großen Vorteil bringen, weil im Moment noch (ziemlich alle?) "alte" Anfragen durchkommen bzw. deine "update" das noch gar nicht kann...
Subdomain ist nicht so einfach: da erst die SSL Verbindung aufgebaut wird, und dann die Domaene per HTTP Header uebermittelt wird, brauche ich eine weitere IP-Adresse, fuer IPv4 muesste ich es dazukaufen. Und ich bin noch nicht so fest im Apache-Konfigurieren, dass ich die separate SSL-Einstellung ohne Stoerung der Produktion versrpechen kann.
Nach etwas experimentieren (kurzzeitiges aendern der Konfiguration): das Problem bei mir wird nicht durch "SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1" ausgeloest, sondern durch SSLCipherSuite, die im Problemfall deutlich kuerzer ist:
% nmap --script ssl-enum-ciphers -p 443 fhem.de
Starting Nmap 6.47 ( http://nmap.org ) at 2019-12-19 12:54 CET
Nmap scan report for fhem.de (88.99.31.202)
Host is up (0.013s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0: No supported ciphers found
| TLSv1.1: No supported ciphers found
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 2.55 seconds
Ich habe jetzt wieder die grosse Cipher-Liste aktiviert.
Nachtrag: wenn man eine beliebige Webseite (xxx.org) mit der gleichen kurzen Cipher-Liste findet, dann muesste in FHEM "update https://xxx.org/" den gewuenschten Fehler erzeugen.
@rudolfkoenig
Wie schon mal gesagt: Wenn Du apache-Hilfe brauchst, sag Bescheid. Auch wenn ich jetzt nicht mehr soo fitt (in nder Firma sind wir zu 90% auf NGINX umgeschwenkt) mach ich es (fast) beruflich ...
Zitat von: Beta-User am 19 Dezember 2019, 12:44:50
...versuch's mal mit "help update"...
Oder sieh dir die commandref dazu an (was fast auf dasselbe rausläuft).
Vorerst wird dir -noSSL wohl keinen großen Vorteil bringen, weil im Moment noch (ziemlich alle?) "alte" Anfragen durchkommen bzw. deine "update" das noch gar nicht kann...
Danke dir :-)
Zitat von: rudolfkoenig am 19 Dezember 2019, 13:00:33
Nachtrag: wenn man eine beliebige Webseite (xxx.org) mit der gleichen kurzen Cipher-Liste findet, dann muesste in FHEM "update https://xxx.org/" den gewuenschten Fehler erzeugen.
Meine website https://resize2fs.de hat die "TLS Intermediate compatibility" nach Mozilla: https://ssl-config.mozilla.org/#server=apache&server-version=2.4.39&config=intermediate
Auf Client Seite muss allerdings auch SNI supported sein: https://metacpan.org/pod/IO::Socket::SSL#SNI-Support
Ähm, ggf. etwas off Topic, aber nachdem ich nun (ist ja kein Aufwand für einen Linux-Freak.... leider bin ich keiner) knapp zig Stunden gebraucht habe, einem RPI 2B Buster beizubringen (das war noch recht simpel) und dann mein FHEM da wieder drauf zu bügeln (das war dann schon tricky, weil zig Sachen nachinstalliert werden mussten, von denen ich gar nicht mehr auf dem Schirm hatte, dass ich die mal irgendwann in den letzten Jahren installiert habe...) kommt mir die Frage auf, ob es einen "simplen" Weg gibt, ein mittels "backup" erstelltes Archiv wieder so herzustellen, dass es auch läuft ? Als relativ unbefleckter Linux-Blinder hab ich das Archiv auf dem Ziel-RPI nämlich nicht aufbekommen (war evtl. zu gross) und musste daher auf meinem NAS entpackt und dann häppchenweise wieder zurück kopiert werden und weil Linux so nette Dinge wie "...keine Berechtigung" bereit hält................................. Einfach restore (was ja zu backup passen würde) stellt ja keine ganzen Archive wieder her oder ?
Grüße
Christian
Hallo Christian,
FHEM backup erzeugt ein tar Archiv im backup Pfad. Das kannst Du so wieder auspacken wie ich es hier u.a. beschrieben habe:
https://heinz-otto.blogspot.com/2019/07/neues-linux-system-nacharbeit.html
Der restore Befehl von FHEM stellt Dateien aus einem speziellen restore Pfad wieder her. Das ist eher gedacht: gestern beim update ging was schief -> schnell restore auf den Stand von gestern.
Gruß Otto
Hallo Otto,
das mit dem Restore hatte ich genau so verstanden, habe ich auch schon mal nutzen müssen... Die Info, wie ich das Archiv wieder zurück bekomme ist sicher beim nächsten Versuch Gold wert, danke dafür ! Richtig geil wäre das natürlich schon, wenn man das mal in den Restore-Befehl mit integrieren könnte ;-)
Soweit alles gut, läuft jetzt erstmal auf dem Testsystem, wenn der Weihnachtsmann den RPI4 bringen sollte, wird weiter getestet
Grüße
Christian
hmmm... seit gestern etwas merkwürdig, wenn ich "update noSSL" starte, kommt "nothing to do", wenn ich nur "update" starte, dann macht er das update...
update -noSSL ?
Bei update noSSL macht er was anderes (https://fhem.de/commandref_modular.html#update);) und hat nichts zu tun
hmmm... hat aber bis vorgestern noch funktioniert, da bin ich mir ziemlich sicher... und mit dem Minus davor hat das bei mir (links in der Leiste eingebunden) immer einen Fehler ausgegeben, weshalb ich das dann ohne probiert habe. Aber gut zu wissen... Ist aber auch nur noch kurze Zeit relevant, möglicherweise kommt hier bald ein RPI4 zum Einsatz und dann ist sozusagen Buster ;-)