SVN Umzug

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

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Ich werden in den naechsten Minuten/Stunden den Umzug des SVN Servers auf die neue Umgebung durchfuehren.
Solange schalte ich den alten SVN Server ab fuers Einchecken ab.

Wenn ich fertig bin, werde ich das hier melden, eine Anpassung bzw. Aenderung der Konfiguration sollte nicht erforderlich sein.

betateilchen

Ist von dem Umzug auch commandref.fhem.de betroffen? Es gibt erste Meldungen wegen Zertifikatsfehlern.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Der Umzug sollte jetzt abgeschlossen sein, wenn irgendwelche Probleme zu sehen sind, bitte melden.

Umgezogen sind auch:
- fhem.de / www.fhem.de / commandref.fhem.de, und damit auch die Quelle der FHEM update.
- svn.fhem.de samt trac (mit upgrade auf trac 1.53)

Immer noch auf dem alten Host sind wiki und forum.

ZitatIst von dem Umzug auch commandref.fhem.de betroffen? Es gibt erste Meldungen wegen Zertifikatsfehlern.
Ja, und danke fuer den Hinweis, habs verpennt dafuer auch ein Zertifikat zu erstellen.
Und bei IPV6 habe ich in DNS die Adresse verhunzt, das zu finden hat lange gedauert.

DeeSPe

Zitat von: rudolfkoenig am 05 März 2023, 19:36:59
- svn.fhem.de samt trac (mit upgrade auf trac 1.53)

Danke für die sonntägliche Arbeit!
Ist es normal bzw. beabsichtigt dass nun keine Einrückungen mehr in der Codeansicht von Trac angezeigt werden?
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

rudolfkoenig

ZitatIst es normal bzw. beabsichtigt dass nun keine Einrückungen mehr in der Codeansicht von Trac angezeigt werden?
Natuerlich nicht, danke fuer den Hinweis.
Offensichtlich greift die CSS Anweisung "monospace" nicht, ich habs jetzt mal auf Courier geaendert, schaut fuer mich besser aus.

Wenn jemand bessere Ideen hat....

TomLee

#5
Ich kann alle Template-Dateien unter https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/ aufrufen wie bisher und mir wird der Code angezeigt, nur nicht die mqtt2.template https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template, da sieht es bei mir bisher so aus so aus wie auf dem Screenshot ?

edit:

auch bei anderen Dateien die > 256.0 KB sind ist das so.

rudolfkoenig

Habe in trac.ini ein 0-er drangehaengt.

TomLee

#7
Es ist einfach nur Zufall das ich es bemerkt habe, hier ist bspw. weiterhin Handlungsbedarf ?

DeeSPe

Zitat von: rudolfkoenig am 05 März 2023, 21:25:20
Natuerlich nicht, danke fuer den Hinweis.
Offensichtlich greift die CSS Anweisung "monospace" nicht, ich habs jetzt mal auf Courier geaendert, schaut fuer mich besser aus.

Wenn jemand bessere Ideen hat....

Die Einrückungen sind wieder da, danke!
Die Schrift ist jetzt aber wesentlich größer. Für meine älter werdenden Augen gut, aber sicherlich auch nicht so gedacht.
Wenn ich den Zoom der Webseite auf 80% stelle sieht es ungefähr aus wie vorher.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

erwin

Hi Rudi,
ich bekomme:
Downloading https://fhem.de/fhemupdate/controls_fhem.txt
fhem
https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(2) to https://fhem.de:443:  SSL connect attempt failed because of handshake problems error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

beim update check -
allerdings bei wheezy und jessie distr. - die hab ich ganz bewusst in Betrieb zum Backward testen....
mit buster u. bullseye gehts natürlich!
l.g. erwin
PS: ein svn update geht natürlich auch nicht!
l.g.erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Matscher

#10
Hi Rudi,
aktuell wird mein Key abgelehnt.  :( An der Konfig hat sich bei mir nichts geändert. Ist mein PubKey noch hinterlegt?
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

rudolfkoenig

@Erwin:
Hab ne Weile nach Loesung gesucht, ohne Ergebnis.
Beide Apache Server (Alt und Neu) haben "SSLProtocol all -SSLv3" in den Einstellungen.
Falls jemand eine Idee hat, bitte melden.

@Matcher:
Ich habe alle oeffentlichen Schluessel der Entwickler kopiert, und selbst den Host-Key des Rechners uebernommen.
Den Eintrag fuer Matscher auch, es hoert mit "HvsSQ==" auf.
Womoeglich versuchst Du die alte IP zu verwenden, das geht nicht mehr.
P.S.: Kannst Du bitte den "Anhang"  in einem anderen Format hinterlegen?

Matscher

Hallo Rudi,
der PubKey passt und der SVN Zugriff funktioniert auch wieder. Komisch, wer weiß was das war... :/
Danke Dir.Gruß,Steve
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

DeeSPe

UTF8 scheint auch noch ein Problem in Trac zu sein.
Zumindest werden bei mir die Umlaute verstümmelt dargestellt.
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

rudolfkoenig

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.

DeeSPe

Tschuldigung! Wollte Dir keinen Schrecken einjagen. ;)
War mir nur beim Überfliegen aufgefallen und ich habe auch keine anderen Module gegengeprüft.
Ist natürlich möglich das die Datei vom Ersteller/Bearbeiter mit falschem Encoding gespeichert wurde.
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

xenos1984

Ich kann mich irren, aber gab es vorher im Trac nicht eine (zumindest rudimentäre) Syntax-Hervorherbung? Ich meine mich zumindest daran zu erinnern, dass Schlüsselwörter wie "sub" in dunkelrot waren...

rudolfkoenig

ZitatIch kann mich irren, aber gab es vorher im Trac nicht eine (zumindest rudimentäre) Syntax-Hervorherbung?
Du irrst dich nicht, siehe Anhang.

Syntax-Highlighting wurde von einem python library Namens pygments implementiert, die ich auf dem neuen Server auch installiert habe, nachdem ich die zwei Konfigurationszeilen vom alten trac.ini uebernommen habe.
Trac Doku fuer syntax Hihlighting gibts nur bis Trac Version 1.2 (wir haben 1.5), und da steht nur, dass, wenn pygments vorhanden ist, sie automatisch verwendet wird.
Wenn ich Trac-Logging auf DEBUG setze dann steht im Log nur folgende "pygments" Zeile:
Loading plugin "trac.mimeview.pygments" from "/usr/local/lib/python3.10/dist-packages"
sonst nichts. Ich habe jetzt 'ne Weile gesucht und probiert, ohne Ergebnis. Wenn jemand eine Idee hat, bitte melden.

xenos1984

Ich konnte nur diesen (alten) Beitrag finden:

http://stackoverflow.com/questions/2564732/source-code-syntax-highlighting-for-trac

Per Kommandozeile sollte
mimetype fhem.pl
und
svn proplist -v fhem.pl
dazu Info liefern, ob da irgendetwas falsch ist.

betateilchen

Ist es eigentlich tatsächlich so, dass seit ca. 1 Woche keine Änderungen eingecheckt wurden?
Irgendwie kann ich mir das nur schwer vorstellen.

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

TomLee

Laut Änderungshistorie unter https://svn.fhem.de/trac/browser/trunk/fhem ist das wirklich so.

rudolfkoenig

Einchecken funktioniert, gerade mit CHANGED getestet.

betateilchen

Zitat von: TomLee am 13 März 2023, 12:11:03
Laut Änderungshistorie

Das sagt für mich erstmal gar nix aus, da vermutlich beides aus der gleichen Quelle stammt.

Was mich darüber hinaus irritiert, sind die unterschiedlichen Zeiten, zu denen die controls-Dateien in den vergangenen Tagen erstellt wurden.
"Normalerweise" war das immer um ca. 07:45 / 07:46 Uhr, aber in den letzten Tagen sind da Ausreißer mit 08:30 und 08:01 Uhr dabei.
-----------------------
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: rudolfkoenig am 13 März 2023, 12:15:24
Einchecken funktioniert, gerade mit CHANGED getestet.

Ja, das habe ich auch gerade getestet.
Hast Du noch eine Erklärung für die unterschiedlichen Uhrzeiten des morgendlichen Update-Laufs?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Otto123

@Rudi Was ich die ganze Zeit schon mit leichter Sorge betrachte: Die neuen Zeiten im testweise migrierten Forum sind noch mal kolossal anders. Sieht man jetzt nur am letzten Eintrag aber mit zunehmender Anzahl wird die große Differenz sichtbarer.
Beeinflussen sich hier die beiden Prozesse (die ja identisch eingerichtet sind)?
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

rudolfkoenig

ZitatHast Du noch eine Erklärung für die unterschiedlichen Uhrzeiten des morgendlichen Update-Laufs?
Kurz: nein.

Lang:
Die Eintraege werden vom SMF Plugin RSS FeedPoster geholt, auf beiden Forums-Installationen, alle 15 Minuten, jeweils von der Seite
https://svn.fhem.de/trac/log/trunk?format=rss&rev=HEAD&limit=200&mode=stop_on_copy
Das automatische Einchecken heute ist im RSS mit 06:45:15 GMT gestempelt.
svn.fhem.de ist seit kurzem auf dem anderen Server, mit einem neuen Trac Version.
Trac kriegt das Eingecheckte per SVN post-commit Hook mit.
Auch im Trac HTML-Frontend wird das Ereignis mit 06:45 angegeben.
Keine Ahnung, wie der Feed Poster auf diese Zeiten kommt.

Es waere auch nett, wenn der Feed Poster andere Felder (z.Bsp. creator) aus dem RSS extrahieren koennte, ich habe aber in der Konfiguration keine Moeglichkeit dafuer gesehen.

Otto123

Um einen Einfluss auszuschließen stoppe ich mal die zweite Instanz, brauchen wir bis zum nächsten Umzug Test ja nicht.
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

Beta-User

Seit neuestem will update auf meinem Testsystem nicht mehr, es beschwert sich wie folgt:
ZitatDownloading http://fhem.de/fhemupdate/controls_fhem.txt
https://fhem.de:443: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 280) line 1.
BEGIN failed--compilation aborted at (eval 280) line 1.
Bisher war das updaten dieses Systems kein Problem, aber selbst die Installation von IO/Socket/SSL via cpan hat nicht geholfen, und auch das Aufrufen mit der -noSSL-Option liefert obige Meldung (aus der ich wegen des eval in update.pm#L29 aber auch nicht schlau werde).

Eine mögliche Erklärung, die ich dazu gefunden habe, wäre in https://metacpan.org/pod/IO::Socket::SSL#BUGS zu finden - es handelt sich um ein Win32-strawberry-Perl...

Kann das mit dem aktuellen Server-Update zusammenhängen?
Server: HP-elitedesk@Debian 12, 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

ZitatEine mögliche Erklärung, die ich dazu gefunden habe, wäre in https://metacpan.org/pod/IO::Socket::SSL#BUGS zu finden - es handelt sich um ein Win32-strawberry-Perl...
Unter Windows wird fork mit threads realisiert, insofern kann das schon die Ursache beschreiben.
Gibt es auch Probleme, wenn du "attr global updateInBackground 0" setzt?

ZitatKann das mit dem aktuellen Server-Update zusammenhängen?
Indirekt schon. Wir verwenden da eine deutlich aktuellere Version der SSL Bibliothek (1.0.2g  1 Mar 2016 vs. 3.0.2 15 Mar 2022).

Beta-User

Das global-Attribut sollte ja sofort wirksam werden, oder? Na ja, so oder so: es hilft nicht....

Hatte schon vermutet, dass es an einem update der SSL-Version liegt, allerdings ist mir nicht so recht klar, warum das dazu führt, dass 98_update.pm anscheinend nicht mehr geladen werden kann.
Server: HP-elitedesk@Debian 12, 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

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-elitedesk@Debian 12, 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-elitedesk@Debian 12, 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-elitedesk@Debian 12, 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!

Otto123

Zitat von: Otto123 am 13 März 2023, 17:22:25Um einen Einfluss auszuschließen stoppe ich mal die zweite Instanz, brauchen wir bis zum nächsten Umzug Test ja nicht.
Aus meiner Sicht haben die Zeiten seitdem gestimmt.
Ich habe im neuen Forum den Poster Feed aktiv und im alten Forum deaktiviert. Ich hoffe es läuft rund. ;)
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: betateilchen am 17 März 2023, 15:24:18Das 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.

Lustig...

Updating '.':
Error validating server certificate for 'https://svn.fhem.de:443':
 - The certificate has expired.
Certificate information:
 - Hostname: svn.fhem.de
 - Valid: from Mar  5 16:22:27 2023 GMT until Jun  3 16:22:26 2023 GMT
 - Issuer: Let's Encrypt, US
 - Fingerprint: 23:25:69:65:8F:5D:15:EB:DC:94:2C:C9:4F:00:E0:B6:0A:18:27:8B

Ich habe das Zertifikat jetzt manuell permanent akzeptiert, nun funktioniert auch das svn update wieder.
Vermutlich bis zum 03.06.2023...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitat- The certificate has expired.
[...]
 - Valid: from Mar  5 16:22:27 2023 GMT until Jun  3 16:22:26 2023 GMT
Bei einem Anfaenger wuerde ich jetzt fragen, ob die Datumseinstellung auf dem Client richtig ist.

erwin

Hi community, ich habe meinen Zoo von Debian/Raspian installationen mal gecheckt:
SYSTEM    uname-a  vers *release wget fhemupdate 
CL_RPI-2  4.9.35     8  jessie   cert ok
CL-RPI-3  5.10.103  10  buster   ok   na
CL-CT-1   3.4.103    8  jessie   TLS  na
MH-RPI-1  3.18.7+    7  wheezy   TLS  OK
MH-RPI-4  3.18.7+    7  wheezy   TLS  OK
MH-RPI-10 4.2.13     8  jessie   ok   SSL
MH-RPI-21 6.1.19    11  bullseye ok   ok
MH-RPI-22 5.15.76   11  bullseye ok   na

Erklärung:
Spalte wget: Ergebnis von "wget https://svn.fhem.de"
 -cert -> ceritifikat expired
 -TLS  -> TLS error
Spalte fhemupdate: Ergebnis v. "fhem update check"
 -na  -> FHEM nicht installiert....
 -SSL  -> SSL error
conclusio: ich hab ein jessie system, wo zwar das wget fehlschlägt, fhem update aber funktioniert...
... ein zweites jessie system, wo das wget funktioniert, aber fhem update fehlschlägt...
... und noch zwei wheezy systeme, wo as wget fehlschlägt, fhem update aber funktioniert...

Es liegt also nicht unbedingt an der release ()wheezy,jessie,...), sondern vermutlich an openssl,... versionen, die mit "normalen" mitteln nicht mehr upgedatet werden können.

..und bevor jemand auf die Idee kommt, das ich upgraden soll: ich betreibe diese Versionen ganz bewusst, um meine Module auf backward compatibility zu checken. Das FHEM-update ist mir dabei auch nicht wirklich wichtig, da nutze ich andere Möglichkeiten.
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Otto123

Auf meinem wheezy System liefert
openssl s_client -connect svn.fhem.de:443|grep 'Certificate chain' -A13
Zitatdepth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
Certificate chain
 0 s:/CN=commandref.fhem.de
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
auf einem aktuellen ubuntu
Zitatdepth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = svn.fhem.de
verify return:1
Certificate chain
 0 s:CN = svn.fhem.de
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  5 16:22:27 2023 GMT; NotAfter: Jun  3 16:22:26 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT

Wieso liefert die gleiche Adresse unterschiedliche Zertifikate aus?
Auf der Adresse wiki.fhem.de (noch der alte Server) ist das ähnlich. Ist das ein Hinweis oder ist mein Test Unsinn?
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

rudolfkoenig

Das sind keine unterschiedlichen Zertifikate, sondern die Zertifikats-Kette.
Lets-Encrypt hats fuer fhem.de erstellt, und Lets-Encrypt darf das, weil "Digital Signature Trust" es denen erlaubt hat.

Was mir noch nicht ganz klar ist, worauf sich "certificate expired" bezieht.
Ich tippe auf den Linux Zertifikats-Store in /etc/ca-certificates, da muss die von "Digital Signature Trust" hinterlegt sein, sonst koennte ja jeder kommen.

rudolfkoenig

@erwin: was muss man machen, damit wheezy bzw. jessie ein fhem-update durchfuehren kann?

Otto123

#52
an fhem update kann man "das Problem" mMn nicht festmachen, das funktioniert auf dem wheezy. Bei mir und bei Erwin ja auch  :-[

ich habe oben nur die Certifate Chain raus gefiltert um die Namen zu zeigen. Das Zertifikate ist mMn nach ein anderes:
wheezy
AjZISlT+Q3tOZ4oiJAiVCSKhaxp7TJkZAXrTVZGX
-----END CERTIFICATE-----
subject=/CN=commandref.fhem.de
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
---
SSL handshake has read 4593 bytes and written 484 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
ubuntu
/Sd1Ll9o/njp0WMN/fo/yp8=
-----END CERTIFICATE-----
subject=CN = svn.fhem.de
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4569 bytes and written 393 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
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

erwin

HI Rudolf,
ZitatIch tippe auf den Linux Zertifikats-Store in /etc/ca-certificates, ...
Ja, das ist auch meine Vermutung und dort ist das certifikat DST Root CA X3 expired.
Das Problem ist, das man auf dem betreffenden system kein funktionales apt-get... mehr hat, um die crt's upzudaten...
Zu deiner 2ten Frage: keine Idee... sonst hätte ich das schon gefixt, Vermutung: entweder SSL-version oder /etc/ca-certificates/.. updaten, aber wie?
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Otto123

#54
Man kann das eigentlich so machen?
update-ca-certificates (-f)Aber das behebt nicht das TLS Problem. Und es behebt nicht das Problem, dass er eigentlich das ISRG Root X1 und nicht das DST Root CA X3 nehmen sollte.

Aber ich verstehe das Ganze nicht wirklich, ich will nur Infos liefern.

Edit:
gerade was schräges probiert - bei mir ein Link /etc/ssl/certs/DST_Root_CA_X3.pem -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt , den mal gelöscht und es sieht aus als ob TLS geht :)
sudo rm /etc/ssl/certs/DST_Root_CA_X3.pemIn neueren Systemen ist der nämlich nicht mehr vorhanden.
Vorher:
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 57D48A51C53F04CD742A369EEE7BC797436C9CF302F9046208F157CD925920FA
    Session-ID-ctx:
    Master-Key: 6449E43AD1081A5534A522526CCD02A71EB7E3D88E74787A655E1FCEA68D0AF33A8FBE48FBA2A3E4877FC50827B2DD9D
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1680687523
    Timeout   : 300 (sec)
    Verify return code: 10 (certificate has expired)
---
nachher
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: FD38F212BBC8652F9A66F6BA976CAE08C9783F68102043A5012CF998DE163784
    Session-ID-ctx:
    Master-Key: 932D91B7B31111C9113FE31BC09AD139B2F07C85954000A4DD499036DA0DD2383E8C3BE468DA26A677569BB3CDD126B3
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1680689520
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
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

Wernieman

Hat LetsEncrypt nicht mal eine Zeitlang 2 verschieden Codierte Zertifikate ausgeliefert? Aus Kompartibilitätsgründen? Und genau in dem Zusammenhang ist mir irgendwo geläufig, das Jessy damit ein Problem hat ... habe nur aktuell keine Zeit es zu regergieren (Sorry) ..

Man kann übrigens manuell Stammzertifikate im System installieren/Löschen.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Otto123

Hier gibt es noch einen Fall der in die Richtung geht: https://forum.fhem.de/index.php?topic=133026
Es liegt bei ihm offenbar nicht am System, sondern an FHEM, welches bis in den Februar 2023 aktualisiert werden konnte.
Wenn er dieses FHEM auf einem aktuellen Ubuntu restored kann er auch nicht mehr updaten.

Nach was kann man da suchen? ich stochere in diesem Thread nur rum ;)

Sieht aber so aus als ob bei ihm in einem FHEM Modul etwas nicht stimmt?
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

erwin

#57
Vermutung: global sslArgs...
edit:
richtig ist: attr global SSLVersion
... und die Vermutung ist, dass da SSLv23 drin steht, was offensichtlich nicht mehr funktioniert...
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Otto123

Zitat von: erwin am 08 April 2023, 02:47:25richtig ist: attr global SSLVersion
... und die Vermutung ist, dass da SSLv23 drin steht, was offensichtlich nicht mehr funktioniert...

Was aber mMn laut dieser Schilderung nicht der Grund sein kann?
Zitat von: roadghost am 07 April 2023, 23:04:483. Ubuntu 22.04 installiert, fhem frisch installiert, fhem.cfg aus dem Ubuntu 16.04 in die 22er Installation kopiert >>> Update funktioniert
@erwin kannst Du in deinem "Zoo" mal bitte die Existenz von
ls -l /etc/ssl/certs/DST_Root_CA_X3.pemprüfen?
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

erwin

...mein Zoo, die 2 jessie systeme, die sich unterschiedlich benehmen:
### jessie 4.2.13
### OpenSSL 1.0.1t  3 May 2016
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = commandref.fhem.de
verify return:1
Certificate chain
 0 s:/CN=commandref.fhem.de
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

kein /etc/ssl/certs/DST_Root_CA_X3.*
... ich hab vorige Woche eins gelöscht, und zwar aus:  /usr/share/ca-certificates/mozilla
auf diesen system funktioniert ein svn update/commit, aber KEIN fhem update

### jessie 4.9.35
### OpenSSL 1.0.1t  3 May 2016
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
Certificate chain
 0 s:/CN=commandref.fhem.de
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

sudo find -name DST_Root_CA_X3.*
./usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt Timestamp aus 2018!!!
./etc/ssl/certs/DST_Root_CA_X3.pem
auf diesem system FUNKTIONIERT fhem update!!!
daraus werde ich nicht schlau!

auf einem bullseye system:
sudo find -name DST_Root_CA_X3.*
./usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt allerdings mit einem Timestamp Jan 19 2021
./etc/ssl/certs/DST_Root_CA_X3.pem

l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

TomLee

#60
Nur aus Interesse (vom SVN hab ich eh nach wie vor keine Ahnung).
Find es der Nachvollziehbarkeit wegen gut das manche Maintainer bei Änderung einer Datei in Nachricht einen Link angeben, der auf den Thread verweist auf dessen Basis die Änderung stattfand.
Bisher war es so das da in der Nachricht hinten in Klammern auch wirklich ein Link zum anklicken war, das ist seit dem Umzug nicht mehr so.
Geht es nicht mehr anders oder ist es einfach bisher keinem aufgefallen und irgendwas muss einfach nur noch umgestellt werden das die Angabe wieder ein Link ist ?

rudolfkoenig

Das hat Markus irgendwo/irgendwie eingebaut, und da ich ihn leider nicht mehr fragen kann, muss ich schauen, wo ich das finde. Ich pack das auf die TODO Liste, wenn jemand helfen kann, bitte melden.

Otto123

Ich habe schon mal geschaut, es aber nicht auf Anhieb gefunden. Ich muss es mit der alten Installation noch im Detail vergleichen.
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

Otto123

#63
auf die Schnelle geht es leider nicht. :(
Es ist ein plugin eingebaut gewesen, dies verwendet aber ein Modul Genshi, dies wird in der Version von Trac ab 1.5.1 nicht mehr unterstützt.
https://trac.edgewall.org/wiki/TracDev/ApiChanges/1.6#Genshiremoved

Ich suche weiter nach einer Lösung. funktioniert wieder ;)
https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja#tag
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