Mehrere Fehler nach update von 16.1 auf 17.1

[StefS]

Hallo,

nach dem Update auf die 17.1er Version (via debian Package) gibt es einige Fehler, die teilweise auch bei anderen aufgetreten sind:

• Adressbuch zeigt keine Fotos mehr an
• Dateiverknüpfungen bei Projekten liefern im download nur 0 Byte

Ein rekursives Ändern der Zugriffsrechte in /var/lib/egroupware/ zum User www-data (Debian/Apache) mit anschließendem Neustart hat nur teilweise geholfen. Danach waren zumindest einige der Dateiverknüpfungen in den Projekten wieder lesbar. Einige sind aber immer noch Fehlerhaft. Fotos sind auch nicht da.

Gibt es eine Möglichkeit via SQL-Select alle Dateiverknüfungen mit deren Dateinamen zu bekommen, um einfach zu checken, welche Dateien betroffen sind?

Ansonsten sehe ich im Error-Log des Apache auch weitere Fehler (insbs. aus der iCal Ecke…)
Zu dem fehlerhaften 0-Byte Download der Projekt-Dateiverknüpfung habe ich nichts gefunden.

[Mon Dec 11 08:22:35.788235 2017] [:error] [pid 9532] [client 92.213.31.39:51944] EGroupware\\Api\\Vfs\\Sqlfs\\StreamWrapper::stream_open(links://mydomain/apps/addressbook/188/.files/photo.jpeg,r,0) file does not exist or can not be created!
[Mon Dec 11 08:22:35.788329 2017] [:error] [pid 9532] [client 92.213.31.39:51944] PHP Warning: file_get_contents(links://mydomain/apps/addressbook/188/.files/photo.jpeg): failed to open st
ream: "EGroupware\\Api\\Vfs\\Links\\StreamWrapper::stream_open" call failed in /usr/share/egroupware/addressbook/inc/class.addressbook_vcal.inc.php on line 316
[Mon Dec 11 08:22:35.788342 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #1 /usr/share/egroupware/addressbook/inc/class.addressbook_vcal.inc.php(316): file_get_contents('links://mydomain...')
[Mon Dec 11 08:22:35.788348 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #2 /usr/share/egroupware/addressbook/inc/class.addressbook_groupdav.inc.php(554): addressbook_vcal->getVCard('188', 'utf-8', false)
[Mon Dec 11 08:22:35.788353 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #3 /usr/share/egroupware/api/src/CalDAV.php(996): addressbook_groupdav->get(Array, '188.vcf')
[Mon Dec 11 08:22:35.788358 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #4 /usr/share/egroupware/api/src/WebDAV/Server.php(1278): EGroupware\\Api\\CalDAV->GET(Array)
[Mon Dec 11 08:22:35.788364 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #5 /usr/share/egroupware/api/src/WebDAV/Server.php(306): HTTP_WebDAV_Server->http_GET()
[Mon Dec 11 08:22:35.788369 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #6 /usr/share/egroupware/api/src/CalDAV.php(2052): HTTP_WebDAV_Server->ServeRequest(NULL)
[Mon Dec 11 08:22:35.788374 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #7 /usr/share/egroupware/groupdav.php(52): EGroupware\\Api\\CalDAV->ServeRequest()
[Mon Dec 11 08:22:35.788379 2017] [:error] [pid 9532] [client 92.213.31.39:51944] #8 {main}
[Mon Dec 11 08:22:35.788388 2017] [:error] [pid 9532] [client 92.213.31.39:51944] # Instance=trilobyte, User=stefan, Request=GET https://mydomain/egw/groupdav.php/addressbook/1
88.vcf, User-agent=Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 Lightning/5.4.5
[Mon Dec 11 08:22:35.809027 2017] [:error] [pid 9532] [client 92.213.31.39:51944] EGroupware\\Api\\Vfs\\Sqlfs\\StreamWrapper::stream_open(links://mydomain/apps/addressbook/188/.files/smime-pubkey.crt,r,0) file does not exist or can not be created!
[Mon Dec 11 09:58:07.960272 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] EGroupware\\Api\\Vfs\\Sqlfs\\StreamWrapper::stream_open(links://mydomain/apps/addressbook/188/.files/photo.jpeg,r,0) file does not exist or can not be created!
[Mon Dec 11 09:58:07.960350 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] PHP Warning: file_get_contents(links://mydomain/apps/addressbook/188/.files/photo.jpeg): failed to open stream: "EGroupware\\Api\\Vfs\\Links\\StreamWrapper::stream_open" call failed in /usr/share/egroupware/addressbook/inc/class.addressbook_vcal.inc.php on line 316
[Mon Dec 11 09:58:07.960361 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #1 /usr/share/egroupware/addressbook/inc/class.addressbook_vcal.inc.php(316): file
_get_contents('links://mydomain...')
[Mon Dec 11 09:58:07.960367 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #2 /usr/share/egroupware/addressbook/inc/class.addressbook_groupdav.inc.php(554): 
addressbook_vcal->getVCard('188', 'utf-8', false)
[Mon Dec 11 09:58:07.960372 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #3 /usr/share/egroupware/api/src/CalDAV.php(996): addressbook_groupdav->get(Array, '188.vcf')
[Mon Dec 11 09:58:07.960377 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #4 /usr/share/egroupware/api/src/WebDAV/Server.php(1278): EGroupware\\Api\\CalDAV-
>GET(Array)
[Mon Dec 11 09:58:07.960393 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #5 /usr/share/egroupware/api/src/WebDAV/Server.php(306): HTTP_WebDAV_Server->http_GET()
[Mon Dec 11 09:58:07.960398 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #6 /usr/share/egroupware/api/src/CalDAV.php(2052): HTTP_WebDAV_Server->ServeRequest(NULL)
[Mon Dec 11 09:58:07.960403 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #7 /usr/share/egroupware/groupdav.php(52): EGroupware\\Api\\CalDAV->ServeRequest()
[Mon Dec 11 09:58:07.960407 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] #8 {main}
[Mon Dec 11 09:58:07.960416 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] # Instance=mydomain, User=stefan, Request=GET https://mydomain/egw/groupdav.php/addressbook/188.vcf, User-agent=Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Lightning/5.4
[Mon Dec 11 09:58:08.007928 2017] [:error] [pid 11982] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38496] EGroupware\\Api\\Vfs\\Sqlfs\\StreamWrapper::stream_open(links://mydomain/apps/addressbook/188/.files/smime-pubkey.crt,r,0) file does not exist or can not be created!
Mon Dec 11 09:59:04.272823 2017] [:error] [pid 9531] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38528] calendar_ical::vevent2egw() attribute=Array([name] => DTSTART[params] => Array([TZID] => Europe/Berlin)[value] => 1513164600[values] => Array([0] => 1513164600))
[Mon Dec 11 09:59:04.272908 2017] [:error] [pid 9531] [client 2003:6:233e:ae43:f889:b8d5:cee7:841b:38528] calendar_ical::vevent2egw() attribute=Array([name] => DTEND[params] => Array([TZID] => Europe/Berlin)[value] => 1513168200[values] => Array([0] => 1513168200))
[Mon Dec 11 10:30:56.159155 2017] [:error] [pid 12981] [client 2003:6:233e:ae43:9162:c5bf:67d8:73ee:63897] calendar_ical::vevent2egw() attribute=Array([name] => DTSTART[params] => Array([VALUE] => DATE)[value] => Array([year] => 2006[month] => 01[mday] => 01)[values] => Array([0] => Array([year] => 2006[month] => 01[mday] => 01))), referer: https://mydomain/egw/index.php?cd=yes
[Mon Dec 11 10:30:56.159255 2017] [:error] [pid 12981] [client 2003:6:233e:ae43:9162:c5bf:67d8:73ee:63897] calendar_ical::vevent2egw() attribute=Array([name] => DTEND[params] => Array([VALUE] => DATE)[value] => Array([year] => 2006[month] => 01[mday] => 02)[values] => Array([0] => Array([year] => 2006[month] => 01[mday] => 02))), referer: https://mydomain/egw/index.php?cd=yes
[Mon Dec 11 10:30:56.161220 2017] [:error] [pid 12981] [client 2003:6:233e:ae43:9162:c5bf:67d8:73ee:63897] calendar_ical::vevent2egw() attribute=Array([name] => DTSTART[params] => Array([VALUE] => DATE)[value] => Array([year] => 2006[month] => 01[mday] => 06)[values] => Array([0] => Array([year] => 2006[month] => 01[mday] => 06))), referer: https://mydomain/egw/index.php?cd=yes

-> letzte ical Meldungen wiederholt ad infinitum (oder zumindest fast...)

[StefS]

Achja - hatte letzten Donnerstag Update von einer 16.1er direkt auf die Version 17.1.20171130 gemacht. Etwaige vorherige 17er Versionen hatte ich nicht installiert.

[StefanU]

Hallo StefS,

zwei Hinweise zu recherchieren:

Benutze einmal:
Admin/Anwendungen/Dateimanager/Virtuelles Dateisystem überprüfen
und schau mal was dabei heraus kommt.

Prüfe mal bei einem Kontakt mit fehlendem Foto:
Adressbucheintrag/Kontextmenü:Dateimanager und dann "Zeige versteckte Dateien"
Foto in .files vorhanden?

Gruß
Stefan

[StefS]

Als “admin” die Überprüfung angestossen meldet “Überprüfung des Dateisystems ergab keine Probleme”.

Bei einem Kontakt mit ehemals Foto gibt es keinen “.files” Ordner oder Datei. Der Dateimanager für diese Kontakte ist leer…

Wenn ich das Adressbuch öffne, sehe ich aber immer noch deutlich bei welchem Kontakt es ehemals ein Foto gab und bei welchem nicht, Mit dem neuen Design (iDots) wird bei Kontakten mit Foto der schwarze Kopf doppelt dargestellt (klein und darüber gross - Screenshot oben), bei den Kontakten wo es kein Foto gab gibt es nur den kleinen schwarzen Kopf (unten).
Beim anderen Design (jDots?) war dort ein kleiner Koopf und darueber ein EGW Schriftzug (oder sowas) gewesen… Also der weiss genau, das da eigentlich ein Foto hingehören muesste.

Das Apache Error-Log enthält da auch entsprechende Fehlermeldungen…

[Wed Dec 13 10:05:37.498412 2017] [:error] [pid 14651] [client 2003:6:233e:ae95:694a:2325:587a:490f:38636] PHP Warning: filesize(): stat failed for links://mydomain/apps/addressbook/178/.files/photo.jpeg in /usr/share/egroupware/addressbook/inc/class.addressbook_ui.inc.php on line 3168, referer: https://mydomain/egw/index.php?cd=yes
[Wed Dec 13 10:05:37.498440 2017] [:error] [pid 14651] [client 2003:6:233e:ae95:694a:2325:587a:490f:38636] #1 /usr/share/egroupware/addressbook/inc/class.addressbook_ui.inc.php(3168): filesize('links://mydomain...'), referer: https://mydomain/egw/index.php?cd=yes
[Wed Dec 13 10:05:37.498456 2017] [:error] [pid 14651] [client 2003:6:233e:ae95:694a:2325:587a:490f:38636] #2 /usr/share/egroupware/index.php(155): addressbook_ui->photo(), referer: https://mydomain/egw/index.php?cd=yes
[Wed Dec 13 10:05:37.498461 2017] [:error] [pid 14651] [client 2003:6:233e:ae95:694a:2325:587a:490f:38636] #3 {main}, referer: https://mydomain/egw/index.php?cd=yes
[Wed Dec 13 10:05:37.498469 2017] [:error] [pid 14651] [client 2003:6:233e:ae95:694a:2325:587a:490f:38636] # Instance=mydomain, User=stefan, Request=GET https://mydomain/egw/index.php?menuaction=addressbook.addressbook_ui.photo&contact_id=178&etag=8, User-agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.97 Safari/537.36 Vivaldi/1.95.1036.3, referer: https://mydomain/egw/index.php?cd=yes

[StefS]

Nach Update auf aktuelle Version (17.1.20180413) nochmal geschaut und Problem besteht immer noch. Überprüfung als Admin meldet keine Probleme

Die Order der Kontakte, wo es eigentlich ein Foto geben sollte, sind komplett leer. Es werden auch keine versteckten Sachen angezeigt. Das Foto der Kontakte ist wie eingangs beschrieben auch immer noch mit doppeltem Platzhalterbild vorhanden (kleiner Kopf plus großer).

Im Serverlog (noch Apache) folgende Fehler in dem Zusammenhang - jeweils einmal pro fehlendem Foto:

[Thu May 03 13:34:37.050324 2018] [:error] [pid 24094] [client 2003:6:238f:2874:550:2bdd:776d:37f6:37706] PHP Warning: filesize(): stat failed for links://default/apps/addressbook/2273/.files/photo.jpeg in /usr/share/egroupware/addressbook/inc/class.addressbook_ui.inc.php on line 3172, referer: https://<server>/egw/index.php?menuaction=addressbook.addressbook_ui.edit&contact_id=2273
[Thu May 03 13:34:37.050364 2018] [:error] [pid 24094] [client 2003:6:238f:2874:550:2bdd:776d:37f6:37706] #1 /usr/share/egroupware/addressbook/inc/class.addressbook_ui.inc.php(3172): filesize('links://default...'), referer: https://<server>/egw/index.php?menuaction=addressbook.addressbook_ui.edit&contact_id=2273
[Thu May 03 13:34:37.050374 2018] [:error] [pid 24094] [client 2003:6:238f:2874:550:2bdd:776d:37f6:37706] #2 /usr/share/egroupware/index.php(155): addressbook_ui->photo(), referer: https://<server>/egw/index.php?menuaction=addressbook.addressbook_ui.edit&contact_id=2273
[Thu May 03 13:34:37.050382 2018] [:error] [pid 24094] [client 2003:6:238f:2874:550:2bdd:776d:37f6:37706] #3 {main}, referer: https://<server>/egw/index.php?menuaction=addressbook.addressbook_ui.edit&contact_id=2273
[Thu May 03 13:34:37.050395 2018] [:error] [pid 24094] [client 2003:6:238f:2874:550:2bdd:776d:37f6:37706] # Instance=default, User=stefan, Request=GET https://<server>/egw/index.php?menuaction=addressbook.addressbook_ui.photo&contact_id=2273, User-agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.183 Safari/537.36 Vivaldi/1.96.1147.32, referer: https://<serverY/egw/index.php?menuaction=addressbook.addressbook_ui.edit&contact_id=2273

Von daher, keine Änderung und Bilder noch nicht wieder aufgetaucht…
Auch einige Dateien die als Anhänge wo dran waren, sind nicht mehr da.

[StefanU]

Hallo Stefan.

Also Updates werden da jetzt auch nichts mehr bringen (können). Wo nichts ist, kann auch nichts angezeigt werden.
Da wird bei der Daten-Übernahme bei dem 16=>17-Upgrade etwas schief gelaufen zu sein. Dort wurden die Fotos aus der DB in das Filesystem übernommen. Das ist aber sicherlich ein anderes Thema als das Problem mit den Filesystem-Rechte.

@RalfBecker
Wäre es möglich bei der Dateisystem-Prüfung auch die Adressbuch-Fotos in den versteckten Verzeichnissen zu überprüfen?
Dann hätte Stefan zumindest eine Möglichkeit herauszufinden wo Fotos fehlen.

Gruß
Stefan

[StefanU]

@StefS
Wenn du jetzt ein Foto hinterlegst wird das angezeigt und findest du das Verzeichnis?

[StefS]

Bei der Dateisystem Prüfung wäre es wirklich sehr hilfreich, wenn dort alle Referenzen, die irgendwo in der Datenbank hinterlegt sind, überprüft werden ob die entsprechende Datei in Filesystem auch existiert.

Wenn der umgekehrte Fall auch geht - also alle im Filesystem vorhanden Dateien prüfen, ob sie mindestens einmal in der DB referenziert sind, dann wäre das sicherlich auch sehr gut, um irgendwelche Leichen aufzuspüren (und Platz frei zu geben)… Oder kann es in Filesystem Dateien geben, die nirgends in der DB referenziert sind?

VG,
Stefan

[StefS]

Ja - neu angelegte Fotos sind da. und werden richtig angezeigt.

[RalfBecker]

Stefan hat absolute recht: eine Änderung der Software kann an der Stelle das Problem nicht lösen!

Einzige Erfolg versprechende Vorgehensweise:

• Teilweise oder vollständiger Restore der Datenbank aus einem Backup
• Das Update nochmals laufen lassen und etwaige Fehler(-meldungen) melden

Ein teilweiser Restore & Update könnte so aussehen:

• alle egw_addressbook* Tabellen werden auf dem Stand vor dem 17.1 Update gebracht
• die Version der API wird auf 16.9.002 gebracht

UPDATE egw_applications SET app_version='16.9.002' WHERE app_name='api'

• Das Update wir über Setup nochmal angestoßen

Bei der Vorgehensweise gehen nur Änderungen am Adressbuch seit dem Update verloren. Natürlich kann man die Änderungen auch vorher noch sichern, das ist etwas was ich jetzt aber nicht so einfach im Detail hier auflisten kann.

Ralf

[RalfBecker]

Bei der Dateisystem Prüfung wäre es wirklich sehr hilfreich, wenn dort alle Referenzen, die irgendwo in der Datenbank hinterlegt sind, überprüft werden ob die entsprechende Datei in Filesystem auch existiert.

Die Dateisystemüberprüfung macht unter anderem genau das.

Es prüft ob alle in der egw_sqlfs Tabelle aufgeführten Dateien im Dateisystem auf dem Server auch tatsächlich existieren.

Wenn der umgekehrte Fall auch geht - also alle im Filesystem vorhanden Dateien prüfen, ob sie mindestens einmal in der DB referenziert sind, dann wäre das sicherlich auch sehr gut, um irgendwelche Leichen aufzuspüren (und Platz frei zu geben)… Oder kann es in Filesystem Dateien geben, die nirgends in der DB referenziert sind?

Wenn Du nur von /var/lib/egroupware/default/files/sqlfs redest, ja. Darunter sollten nur Dateinen sein, die auch in der egw_sqlfs referenziert sind.

Ralf

[StefanU]

Die Dateisystemüberprüfung macht unter anderem genau das.
Es prüft ob alle in der egw_sqlfs Tabelle aufgeführten Dateien im Dateisystem auf dem Server auch tatsächlich existieren.

Gerade mal getestet und nachgeschaut: Für die Adressbuch-Fotos gilt das nicht. Für die Fotos gibt es keine Referenz in der Tabelle.

Wäre das eine Lösung (Als Alternative zu Ralf seiner Lösung)?:
Auf einem Testsystem (Kopier der aktuellen…) das letzte Backup der 16 einspielen und auf 17 migrieren (bis es funktioniert) und die Dateien per WebDAV aus …/apps/Adressbuch/Adressbuchxy$ in das aktuelle 17er-System kopieren. Wenn keine Dateien gelöscht oder geändert wurden, würden die fehlenden Dateien nur hinzukopiert. Zur Not muss man die Nicht-Fotos vorher löschen.

Wenn da nur wenige Adressen wären könnte man auch per WebDAV einzeln herüber kopieren. Dann weiß man ganz genau was man macht.

Gruß
Stefan

[RalfBecker]

Gerade mal getestet und nachgeschaut: Für die Adressbuch-Fotos gilt das nicht. Für die Fotos gibt es keine Referenz in der Tabelle.

Wenn die Fotos da wären und nur im Dateisystem gelöscht, gäbe es die Referenz. Die Verknüpfung mit dem Adressbuch ist nur implizite, sprich das Foto hat einen festen Pfad (/apps/addressbook/$contact_id/.files/photo.jpg), wenn es da liegt, wird es im Adressbuch angezeigt, wenn nicht nicht.

Das Problem trat früher auf, und ist jetzt nicht mehr zu heilen.

Ralf

[StefanU]

Die Referenzen scheinen bei Stefan vorhanden. In dem Fall sieht das Symbol tatsächlich anders aus. Ist aber auch schnell mit ein paar Stichproben getestet…

Stefan

[StefS]

Wenn der umgekehrte Fall auch geht - also alle im Filesystem vorhanden Dateien prüfen, ob sie mindestens einmal in der DB referenziert sind, dann wäre das sicherlich auch sehr gut, um irgendwelche Leichen aufzuspüren (und Platz frei zu geben)… Oder kann es in Filesystem Dateien geben, die nirgends in der DB referenziert sind?

Wenn Du nur von /var/lib/egroupware/default/files/sqlfs redest, ja. Darunter sollten nur Dateinen sein, die auch in der egw_sqlfs referenziert sind.

Ja, ich meinte das …/default/files/sqlfs Verzeichnis.

Und wegen der Bilder werde ich die Tage nochmal ein neues Testsystem mit dem Backup aufsetzten. Sind aber nicht so viele Bilder und ist dann eher Interesse halber… Wenn ich da was finde an Fehlern melde ich mich noch mal.

Einzig interessant wohl noch, warum der bei allen Kontakten, die früher Fotos hatten und das jetzt fehlt, heute immer noch das “doppelte” Profilbild anzeigt wird - also muss er irgendwo eine Referenz/Info haben, das es da ein Bild geben muss. Es kann nicht nur einfach das Foto in “.files/photo.jpeg” sein. Weil da existiert ja weder der “.files” Ordner, noch die “photo.jpeg” Datei…

Gruß,
Stefan