SVN Umzug

Begonnen von rudolfkoenig, 05 März 2023, 17:48:51

Vorheriges Thema - Nächstes Thema

betateilchen

Eigentlich denke ich gerade über ein grundsätzliches Problem in 98_update.pm nach.
Da wird ja VERSUCHT, ob die SSL library überhaupt geladen werden kann, entsprechend werden im Modul flags gesetzt.
Im Modul sind die URL alle mit http:// hinterlegt. Das mag früher funktioniert haben.
Aber inzwischen leitet der FHEM Server alle Anfragen auf https:// um:


--2023-03-14 15:40:30--  http://fhem.de/fhemupdate/controls_fhem.txt
Resolving fhem.de (fhem.de)... 2a01:4f8:221:1b5a::2, 188.40.131.57
Connecting to fhem.de (fhem.de)|2a01:4f8:221:1b5a::2|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://fhem.de/fhemupdate/controls_fhem.txt [following]


Das bedeutet, dass die ganze Prüfung und die Flags im update-Modul eigentlich überflüssig weil wirkungslos sind.
Eine erfolgreich nutzbare https:// Verbindung ist inzwischen immer Voraussetzung für ein funktionierendes update.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: Beta-User am 14 März 2023, 15:29:54
allerdings ist mir nicht so recht klar, warum das dazu führt, dass 98_update.pm anscheinend nicht mehr geladen werden kann.

Das Modul wird doch bei Dir geladen - die von Dir zitierten Fehlermeldungen kommen doch aus dem geladenen Modul?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 14 März 2023, 15:47:26
Das Modul wird doch bei Dir geladen - die von Dir zitierten Fehlermeldungen kommen doch aus dem geladenen Modul?
Hmm, stimmt, irritierend ist halt das "Compilation failed", was in der Regel ja bedeutet, dass es wieder entladen wird. Hier bezieht sich das aber auf IO::Socket::SSL, das anscheinend dann _nochmal_ versucht wird zu laden?

Eben wegen der Umleitung, nehme ich an?
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

#33
Das zweite Laden der SSL-library kommt für mein Verständnis nicht aus 98_backup.pm 98_update.pm, sondern aus HttpUtils.pm, wenn in upd_getUrl() versucht wird, die URL per HttpUtils_BlockingGet() aufzurufen. Die Auswertung der Umleitung erfolgt dann in HttpUtils.pm und dort wird beim connect aufgrund der als Antwort beim Verbindungsversuch erhaltenen https://-adresse versucht, das SSL nachzuladen.


  if($hash->{protocol} eq "https" && $hash->{conn} && !$hash->{hu_sslAdded}) {
    eval "use IO::Socket::SSL";





Edit: vielleicht die update-Problematik mal aus diesem Umzugs-Thread abspalten und in einen eigenen Thread verschieben?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Hmm, dann ist das aber auch kein "non-blocking"-Aufruf, und der genannte Bug sollte ggf. auch nicht dazu führen, dass die ganze lib nicht geladen werden kann, oder?

Dass das IO::Socket::SSL-Paket via cpan installiert wurde (und FHEM zwischendurch dann auch neu gestartet), hatte ich angemerkt, oder? Und die Dateien liegen auch da, wo sie m.E. liegen sollten (da hatte ich unter anderem den "Bugs"-Link her).

Gestartet wird das Testsystem (unter Win 10 pro) über eine bat-Datei mit folgender Zeile:
perl\perl\bin\perl fhem.pl  fhem.cfg

Habe mal unter Powershell gestartet, hilft auch nicht weiter...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Was liefert { use IO::Socket::SSL } und { use Net::SSLeay } in der FHEM Kommandozeile?
Ich vermute, dass eine abhaengige Bibliothek (Net::SSLeay oder die "echte" SSL-Bibliothek) nicht geladen werden kann.
Eigentlich sollte IO::Socket::SSL bei Strawberry perl dabei sein.

krikan

Habe 3 FHEM Systeme mit Perl strawberry portable (jeweils Version 5.32.1 / MSWin32-x86-multi-thread-64int) unter Win 10 Pro. Alle habe ich gerade problemlos per update aktualisiert.

CPAN und SSL unter Windows ist nach meiner Erfahrung eine endlose "Bastelarbeit/Baustelle"; strawberry Perl hat für FHEM hier alles passend dabei.
Auch wenn es vorher mal funktioniert hat:
Sind die Umgebungsvariablen für strawberry perl korrekt gesetzt? Alternativ mal "portableshell.bat" gestartet und in der shell dann "perl fhem.pl fhem.cfg" aufgerufen?

Beta-User

Zitat von: rudolfkoenig am 14 März 2023, 18:08:35
Was liefert { use IO::Socket::SSL }
Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 256) line 1.
BEGIN failed--compilation aborted at (eval 256) line 1.

Zitat
und { use Net::SSLeay } in der FHEM Kommandozeile?
Attempt to reload Net/SSLeay.pm aborted.
Compilation failed in require at (eval 258) line 1.
BEGIN failed--compilation aborted at (eval 258) line 1.


Zitat von: krikan am 14 März 2023, 19:23:55
Sind die Umgebungsvariablen für strawberry perl korrekt gesetzt?
Dazu kann ich im Moment wenig sagen, aber
Zitat
Alternativ mal "portableshell.bat" gestartet und in der shell dann "perl fhem.pl fhem.cfg" aufgerufen?
Das klappt...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Oh, mal was ganz Neues...


svn: E230001: Unable to connect to a repository at URL 'https://svn.fhem.de/fhem/trunk/fhem'
svn: E230001: Server SSL certificate verification failed: certificate has expired

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

JoWiemann

#39
Zitat von: rudolfkoenig am 07 März 2023, 19:15:26
Hast mir einen Schrecken eingejagt, das haette auch bei der Uebertragung der Daten (svnadmin dump & load) schiefgehen koennen.
Ist aber ziemlich sicher nicht, siehe Anhang (Teil von Meta.pm).
72_FRITZBOX.pm ist mMn "einfach" kaputt.

Hm, die Umlaute waren seit Anbeginn des Moduls so in der commdRef des Moduls hinterlegt. Ich werde das mal auf HTML Namen umstellen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

rudolfkoenig

Zitatsvn: E230001: Server SSL certificate verification failed: certificate has expired

Bei mir steht "certificate is valid", und in den Details:
Common Name (CN) svn.fhem.de
Organization (O) <Not Part Of Certificate>
Organizational Unit (OU) <Not Part Of Certificate>
Common Name (CN) R3
Organization (O) Let's Encrypt
Organizational Unit (OU) <Not Part Of Certificate>
Issued On Sunday, March 5, 2023 at 5:22:27 PM
Expires On Saturday, June 3, 2023 at 6:22:26 PM

betateilchen

Im Moment habe ich nur eingeschränkte debug-Möglichkeiten, ich habe dieses mal nur ein ipad mit nach Serbien genommen, da macht ssh keinen Spaß.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Kannst Du die IP-Adresse fuer svn.fhem.de anzeigen?
Soll laut Internet in Safari@iPad gehen.
88.99.31.202 bzw. 2a01:4f8:10a:806::2 ist alt, 188.40.131.57 bzw. 2a01:4f8:221:1b5a::2 ist neu.
DNS Caching haben wir vor 3 Wochen von einem Tag auf 5 Minuten runtergesetzt.

Otto123

#43
Da erfolgt bei mir direkt eine Weiterleitung auf http://svn.fhem.de/fhem/trunk/fhem/  ::)
Nimmt man die IP Adresse erfolgt keine Weiterleitung aber das Zertifikat ist unsicher ...

Edit: jetzt funktioniert es - aber http://svn.fhem.de/fhem/trunk/fhem/ ist auch möglich und wird nicht auf https umgeleitet.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

betateilchen

Zitat von: rudolfkoenig am 17 März 2023, 12:16:43
Kannst Du die IP-Adresse fuer svn.fhem.de anzeigen?
Soll laut Internet in Safari@iPad gehen.

Das könnte ich natürlich tun, aber das Problem habe ich ja nicht auf dem ipad (da funktioniert svn.fhem.de problemlos) sondern auf dem RaspberryPi hier, der sein FHEM aktualisieren möchte.

Das schaue ich mir nächste Woche von zuhause an, von da habe ich Zugriff auf den Raspi.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!