[smartVISU v2.9] Calender Widget zeigt nichts an

[whe]

Du hast geschrieben, dass auch das neue Image zunächst richtig funktioniert hat, bevor Du das System upgedated hast. Habe ich das richtig verstanden?

ja, ich bin sicher, dass es mit 2.9.a funktioniert hat.
letzte Woche habe ich dann 2x gitpull gemacht für shng und smartvisu

Korrektur:
- nach dem Linux Update hat es schon nicht mehr funktioniert.
- git pull war später und hat es nicht korrigiert.

Dei Fehlermeldungen zeigen IMHO, dass überhaupt keine Antwort vom Server kommt. Kann es sein, dass Zertifikate für die SSL-Kommunikation fehlen? Und warum ist als host eine offensichtlich interene IP-Adresse x.x.x.47 angegeben?

Die SSL Sachen sind m.E. Folgefehler.
ich rufe doch nur einfach lokal iCloud.php auf.
und die Fehlermeldungen kommen doch aus dem service.php
wieso kriegt der da keine parameter ?

[whe]

wenn ich die Aufrufe zwischen den beiden Umgebungen vergleiche (mit debug=1) finde ich im Apache log folgende Zeile:

[Wed Jul 08 11:23:20.403150 2020] [:error] [pid 26675] [client 192.168.178.21:54036] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/smartVISU2.9/lib/service.php:118) in /var/www/html/smartVISU2.9/lib/service.php on line 101

aber im nginx error log:

2020/07/08 11:43:54 [error] 695#695: *2120 FastCGI sent in stderr:
PHP message: PHP Notice:  Undefined index: server in /var/www/html/smartvisu/lib/service.php on line 43
PHP message: PHP Notice:  Undefined index: port in /var/www/html/smartvisu/lib/service.php on line 44
PHP message: PHP Notice:  Undefined index: url in /var/www/html/smartvisu/lib/service.php on line 45
PHP message: PHP Notice:  Undefined index: user in /var/www/html/smartvisu/lib/service.php on line 46
PHP message: PHP Notice:  Undefined index: pass in /var/www/html/smartvisu/lib/service.php on line 47
PHP message: PHP Notice:  Undefined index: count in /var/www/html/smartvisu/lib/calendar/calendar.php on line 41
PHP message: PHP Notice:  Undefined index: calendar in /var/www/html/smartvisu/lib/calendar/calendar.php on line 42

Da sind doch anscheinend Werte nicht versorgt.
das muss doch eine Ursache haben.
wer ruft denn diese service.php auf ?

[wvhn]

Da ich bisher keine Kalender genutzt habe, muss ich mich da erst einfuchsen. Über Mithilfe der erfahreneren iCloud-Nutzer wäre ich dankbar.

Das Probem ist offenbar mehrdimensional. Hier meine bisherigen Erkenntnisse:

1. Für die Nutzung von iCloud-Kalendern mit SV muss gemäß Apple-Richtlinien ein App-spezifisches Passwort festgelegt werden. Das macht man in der Verwaltung der Apple-ID.
2. Mit diesem Passwort kann sich mein Apache2-basiertes Testsystem (shNG auf Pi, SV auf Windows10-Rechner mit XAMPP) mit iCloud verbinden. Ich sehe in der Debug-Information die Antwort des iCloud-Servers: sowohl die individuelle numerische Kennung des Kalenders, als auch die verfügbaren Kalender und die ICS-Daten für die Kalendereinträge. Der ICS-Parser iCal.php setzt diese aber nicht korrekt in json um. Ich vermute, dass dies mit der PHP-Version zusammenhängt und werde in den nächsten Tagen ein Update des (extern bezogenen) Parsers versuchen. (siehe Link in der iCal.php - Mithilfe willkommen.)
   Die oben genannten php-Notices werden trotz erfolgreicher Verbindung ins Apache-Log geschmissen. Das ist eine IMHO vernachlässigbare Warnung. Service.php wird im Verbund mit calendar.php und CalDav.php eingebunden.
3. Da ich auf Windows10 natürlich kein Problem mit https habe, klappt die Verbindung. Anders sieht es auf meinem Pi aus. Hier kommt zusätzlich die Meldung, dass die Krypto-Verbindung nicht aufgebaut werden kann. Ich vermute, dies liegt an fehlenden Zertifikaten bzw. in meinem Fall schlecht aufgesetztem openSSL (ich verwende nicht das Image von Onkelandy ).

whe ich vermute, dass Du auf Deinem alten System noch PHP5 drauf hast. Kannst Du das bitte mal checken?

Ansonsten bin ich für Hinweise aller derjenigen dankbar (z.B. BlackCrow ?), die iCloud Kalender erfolgreich zum Laufen gebracht haben.

Gruß
Wolfram

[whe]

mein altes System hat PHP7.0
es hat m.E. auch auf dem neuen System mit shng 1.7.1 und visu 2.9.a unter nginx funktioniert.
nach sudo apt upgrade aber nicht mehr.

hier mein Altsystem mit php7.0

php.PNG

[whe]

könnte es evtl. hiermit zu tun haben ?
das ist mir schon ein paarmal über den Weg gelaufen, dabei habe ich aber mit onewire nichts am Hut.

[smarthome@SmartHomeNG2 ~]$ systemctl status owhttpd.service
● owhttpd.service - Tiny webserver for 1-wire control
   Loaded: loaded (/lib/systemd/system/owhttpd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-07-09 19:30:30 CEST; 5min ago
     Docs: man:owhttpd(1)
  Process: 7566 ExecStart=/usr/bin/owhttpd --foreground -c /etc/owfs.conf (code=exited, status=1/FAILURE)
 Main PID: 7566 (code=exited, status=1/FAILURE)

[bmx]

whe Onewire sollte damit nichts zu tun haben.

Du kannst das aber durchaus entweder deinstallieren (Ich vermute, Du nutzt das Image von Onkelandy ?!?) oder aber mit

sudo systemctl stop owhttpd.service
sudo systemctl disable owhttpd.service

ausschalten. Konsequenterweise sollte man dann ggf. auch alle anderen dazugehörigen Dienste aussschalten (owserver, owfs, ...) Schau einfach welche Sachen noch ausgeführt werden die zum Thema owserver gehören.

[whe]

zu #15,

ja ich bin mir ziemlich sicher, dass es mit shng 1.7.1 und smartvisu 2.9.a schon funktioniert hat.

Und warum ist als host eine offensichtlich interene IP-Adresse x.x.x.47 angegeben?

das ist doch mein raspi, ich simuliere doch damit den Aufruf zu iCloud.

mit SSL hat das m.E. überhaupt nichts zu tun, auf meinem Altsystem mit Apache gibt es auch kein SSL.
wenn ich von außen auf mein System zugreifen möchte benutze ich den VPN Zugriff meiner Fritzbox.

Code:

http://192.168.178.47/smartvisu/lib/...lender&debug=1

dieser Test liefert mir auf meinem Altsystem eine Liste mit den gefundenen Terminen, auf dem neuen System aber nicht;
deshalb bin ich mir ziemlich sicher, dass irgendetwas innerhalb von smartvisu nicht funktioniert.

und ich denke, dass die wesentlichen Meldungen oben (#14) am Anfang stehen:

2020/07/06 17:35:18 [error] 695#695: *1742 FastCGI sent in stderr: "
PHP message: PHP Notice:  [MARKIEREN]Undefined index: server[/MARKIEREN] in /var/www/html/smartvisu/lib/service.php on line 43
PHP message: PHP Notice:  [MARKIEREN]Undefined index: port [/MARKIEREN]in /var/www/html/smartvisu/lib/service.php on line 44
PHP message: PHP Notice:  [MARKIEREN]Undefined index: url[/MARKIEREN] in /var/www/html/smartvisu/lib/service.php on line 45
PHP message: PHP Notice:  [MARKIEREN]Undefined index: user [/MARKIEREN]in /var/www/html/smartvisu/lib/service.php on line 46
PHP message: PHP Notice:  [MARKIEREN]Undefined index: pass[/MARKIEREN] in /var/www/html/smartvisu/lib/service.php on line 47
PHP message: PHP Notice:  [MARKIEREN]Undefined index: count [/MARKIEREN]in /var/www/html/smartvisu/lib/calendar/calendar.php on line 41
PHP message: PHP Notice:  [MARKIEREN]Undefined index: calendar[/MARKIEREN] in /var/www/html/smartvisu/lib/calendar/calendar.php on line 42

PHP message: PHP Warning:  file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed in

[wvhn]

Die gelb markierten Meldungen kommen aus der init-Methode von service.php. Da service.php für alle Services zuständig ist - also auch Telefonanlage, Wetter &Co -, werden hier erst mal alle möglichen Parameter initialisiert. Calendar verwendet z.B. den server und den port nicht, was Du auch in der config.ini sehen kannst. Ich habe die zum Kalender gehörenden php-Dateien nochmal durchsucht und auch nirgends eine Verwendung von $this->server gefunden. Das kannst Du gerne auch nochmal prüfen.

Wenn Dich die Meldungen stören, rufe doch den Kalender mal mit allen Parametern auf:

http://localhost/svngt/lib/calendar/service/iCloud.php?count=10&calendar=kalender&debug=1&url=https://caldav.icloud.com/&user=Dein_iCloudUser&pass=Dein_iCloudPasswort&server=192.168.2.13&port=80

Ich fürchte, dass dann der Kalender weiterhin leer bleibt und die unterste (nicht gelb markierte) Meldung aus Deinem letzten Post weiterhin erscheint. Das ist das SSL-Problem. Wenn Die Adresse der iCloud-Servers https://... ist, braucht man natürlich die SSL-Zertifikate.

Wie schon geschrieben, sieht das Ganze bei mir auf dem Windows-System so aus:

Notice:  Undefined index: server in C:\xampp2\htdocs\svngt\lib\service.php on line 43
Notice:  Undefined index: port in C:\xampp2\htdocs\svngt\lib\service.php on line 44
Notice:  Undefined index: url in C:\xampp2\htdocs\svngt\lib\service.php on line 45
Notice:  Undefined index: user in C:\xampp2\htdocs\svngt\lib\service.php on line 46
Notice:  Undefined index: pass in C:\xampp2\htdocs\svngt\lib\service.php on line 47
/*******************************************************************************
principle_url
--------------------------------------------------------------------------------
/12345678/principal/
*******************************************************************************/

/*******************************************************************************
calendar_home_url
--------------------------------------------------------------------------------
https://p41-caldav.icloud.com:443/12345678/calendars/
*******************************************************************************/

/*******************************************************************************
calendar_url of 'kalender'
--------------------------------------------------------------------------------
/12345678/calendars/BEF7alle-sgan-zgeh-eim!-xxxxxxxxxxxx/
*******************************************************************************/

/*******************************************************************************
calendar_url of 'privat'
--------------------------------------------------------------------------------
/12345678/calendars/home/
*******************************************************************************/

/*******************************************************************************
ICS Data of 'https://p41-caldav.icloud.com:443/12345678/calendars/BEF7alle-sgan-zgeh-eim!-xxxxxxxxxxxx/'
--------------------------------------------------------------------------------
BEGIN:VCALENDAR
BEGIN:VEVENT
CREATED:20200710T104026Z
DTEND;TZID=Europe/Berlin:20200712T150000
DTSTAMP:20200710T104026Z
DTSTART;TZID=Europe/Berlin:20200712T140000
LAST-MODIFIED:20200710T104026Z
SEQUENCE:0
SUMMARY:Test
UID:F3E7alle-sgan-zgeh-eim!-xxxxxxxxxxxx
URL;VALUE=URI:
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

Das bedeutet, dass trotz der php-Notices und wegen des Fehlens der SSL-Meldung die Verbindung steht, der User mit Passwort angemeldet ist, die Kalender erkannt werden und Kalenderdaten übermittelt werden.

Auf meinem Raspberry klappt das leider nicht. Hier kommt auch die SSL-Meldung.

Beim letzten System-Update auf dem Raspberry wurden php-Pakete aktualisiert. Deshalb vermute ich, dass PHP die Zertifikate nicht mehr findet und keine SSL-Verbindung aufbaut. Also muss man PHP beibringen, die Zertifikate zu finden. Zudem scheint der ICS-Parser die oben gezeigten ICS-Daten nicht mehr zu verstehen. Das kann ebenfalls mit der PHP-Version zusammen hängen.

An beiden Themen bin ich dran, bin aber noch in der Einarbeitung.
Gruß
Wolfram


Edit:
also die PHP-Version ist nicht die Ursache für das Problem mit dem ICS-Parser. Ein Downgrade meines XAMPP auf PHP v5.6 bringt keine Änderung.

[whe]

Zudem scheint der ICS-Parser die oben gezeigten ICS-Daten nicht mehr zu verstehen.

das ist mir auch schon aufgefallen.

in einem anderen Forum habe ich gelesen man könnte die ca-certificates neu installieren; an solche Dinge traue ich mich nicht ran, weil ich die Auswirkungen nicht kenne. Habe jetzt das neue System schon 2-3 Wochen in Produktion und möchte es nicht gefährden.

danke, dass Du da so viel Energie reinsteckst, gerne helfe ich mit so gut ich kann.

habe gerade mal: var_dump(openssl_get_cert_locations()); ausgeführt; liefert das, was es soll und auf beiden Systemen identisch.
auch die SSL Verzeichnisse sind auf beiden Systemen identisch.

denke auch dass es mit dem update und PHP oder nginx zusammen hängt.

Nachtrag:

Habe jetzt mit phpinfo auch noch mal die beiden php Installationen verglichen.
auf dem alten system ist es 7.0 auf dem neuen 7.3
mir fällt da nichts auf in Sachen openSSL und certificates, das sieht alles identisch aus.
kann es nicht doch nginx sein ? aber bei solchen upgrades wird doch an der Konfiguration nichts geändert.

ein größerer Aufwand wäre jetzt das image von Onkelandy noch mal auf einem anderen stick aufzusetzen und zu testen.
habe ich letzte Woche für meinen Sohn gemacht aber upgrade und hochrüsten auf shng 1.7.2 auch schon vollzogen.
da ist aber smartvisu noch nicht konfiguriert, weil das ja bei ihm anders ist.

[wvhn]

Ich bin jetzt schonmal einen Schritt weiter:

openssl s_client -connect caldav.icloud.com:443

lieferte mir die Fehlermeldung "unable to get local issuer certificate". Daraufhin bin ich nach dieser Anleitung vorgegangen und habe zunächst einmal nachgeschaut, wo php die Zertifikatsdatei erwartet:

php -r "print_r(openssl_get_cert_locations());"
Array
(
    [default_cert_file] => /usr/lib/ssl/cert.pem
    [default_cert_file_env] => SSL_CERT_FILE
    [default_cert_dir] => /usr/lib/ssl/certs
    [default_cert_dir_env] => SSL_CERT_DIR
    [default_private_dir] => /usr/lib/ssl/private
    [default_default_cert_area] => /usr/lib/ssl
    [ini_cafile] =>
    [ini_capath] =>
)

Da das default_cert_file in meinem Fall nicht vorhanden war, habe ich es nach der o.g. Anleitung dorthin kopiert und dann in den erwarteten Namen (cert.pem) umbenannt.

Das kann keine Dauerlösung sein, aber wenigstens bekomme ich jetzt erstmal die iCloud ICS-Daten angezeigt. Leider klappt das Parsen aber noch nicht.

[whe]

bei mir kommt auf das obige openssl command auch die gleiche Fehlermeldung.
.

    Start Time: 1594630331
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: yes
---
closed
 [smarthome@SmartHomeNG2 ~]$ php -r "print_r(openssl_get_cert_locations());"
Array
(
    [default_cert_file] => /usr/lib/ssl/cert.pem
    [default_cert_file_env] => SSL_CERT_FILE
    [default_cert_dir] => /usr/lib/ssl/certs
    [default_cert_dir_env] => SSL_CERT_DIR
    [default_private_dir] => /usr/lib/ssl/private
    [default_default_cert_area] => /usr/lib/ssl
    [ini_cafile] =>
    [ini_capath] =>
)

das ist aber alles identisch mit dem Altsystem. Aber dort funktioniert der iCloud call ( mit Apache ).

übrigens Dein link in #25 zeigt nicht auf die Anleitung, sondern downloaded das Zertifikat

[wvhn]

Danke für den Hinweis zum Link. Den habe ich korrigiert.

Bei mir war die cert.pem nicht existent. Seit ich das korrigiert habe, ist die Fehlermeldung

Read request to "https://caldav.icloud.com/“ failed with mesage ""

weg.

[whe]

Bei mir ist auf dem alten Raspi auch kein cert.pem vorhanden, trotzdem funktioniert der iCloud call dort einwandfrei.

[wvhn]

Da sind halt inzwischen 3 PHP-Versionen drüber gegangen. Was genau da geändert wurde, kann ich nicht sagen. Wenn Du sagst, dass der Kalender auch auf dem neuen System bis zum letzten Update funktioniert hat, kannst Du mal in die update history schauen und das Ergebis hier als Textdatei anhängen:

cat /var/log/apt/history.log

Die History dürfte hoffentlich nicht allzu lang sein, wenn Du das Image vorher frisch installiert hattest. Dann können wir vlt. in den Dokus der PHP-updates nachsehen, was geändert wurde.

Die aktuelle CalDav.php in 'smartVISU/lib/calendar/service' wurde von smai am 8.11.2019 erstellt. Kannst Du bitte mal prüfen, von welchem Datum die Version auf Deinem alten System ist?

[whe]

die histories hänge ich hier mal an (die sind wohl gezippt, keine Ahnung womit man die entpacken kann).
das ist doch dann recht mühsam, ich versuche da mal selbst zu recherchieren.

CalDav.php vom Altsystem habe ich am 17.3. händisch ausgetauscht, das ist dann wohl die Version von smai.
damals kamen keine Daten. Es gibt dazu auch eine Thread im Forum.

Nachtrag:
das Problem müsste doch dann Onkelandy in seinem neuen image auch haben, oder vielleicht auch andere user, die ihr System aktualisieren.

Nachtrag 2:
am 2.5. wurde wohl ein update von OpenSSL auf 1.1.1.d gemacht. das ist die Version die heute noch auf meinem Pi läuft.
dazu gibt es wohl 2 Nachbesserungen. soll ich das mal hochrüsten ?