Geplante Wartungsarbeiten am 15.12.2019

[Beta-User]

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...

[isy]

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

[isy]

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

[rudolfkoenig]

Habe gerade TLS1 und TLS1.1 auf dem Server wieder aktiviert.

Weiterhin habe ich die -noSSL Option zu update hinzugefuegt.

[cs-online]

Super Rudi, läuft wieder !!! Danke dir vielmals !!!

Grüße Christian

[CarlosTT]

Auch von mir ein Dankeschön!

[psycho160]

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

[CoolTux]

Ich bin damit nicht wirklich glücklich. Wie immer wurde das eigentliche Problem damit nur verschoben. Die Update Faulheit der User beim Betriebssystem.

[isy]

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.

[Wernieman]

Sorry aber ein "Out of Lifing" Betriebssystem nicht mehr zu Unterstützen .. braucht eigentlich keinen Vorlauf mehr ..

[Beta-User]

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 ).

(Ich bin übrigens auf aktuellem Debian 10, also kein "getroffener Hund"!)

[Otto123]

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

[mahowi]

Wenn ich das richtig sehe, gibt es doch jetzt für den update-Befehl den Schalter -noSSL:

Mit -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 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.

[rudolfkoenig]

Offenbar 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.

[tomcat.x]

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 ...

Die Zeit vergeht echt so schnell, hätte nicht gedacht das es kein aktuelles Perl mehr für Jessie angeboten wird..