Hi,
das solltes Du mit einem apt-get purge php5
wegbekommen - das sind configs die beim deinstall von php im system verbleiben.
lg
Christian
Neuere Versionen der WebApp bieten die Möglichkeit mit einfachen Mitteln die WebApp selbst zu gestalten: https://kopano.com/blog-de/new-json-themes-in-kopano-webapp/
Im Kopano4ucs Integrationspaket gibt es bereits einen ersten Entwurf für ein Univention Themen. Pullrequests mit Änderungen werden gerne entgegen genommen. https://stash.z-hub.io/projects/K4U/repos/kopano4ucs/browse/webapp
Hallo Exerna1 - danke für die Info.
Da ich bei der Installation von Kopano WebApp gesehen habe das PHP5 Pakete installiert werden - und diese auch wirklich da sind
bin ich eher vorsichtig mit “Reste” löschen.
Was sagt den Kopano-Team dazu - die Pakete wurden ja durch die WebApp installiert 
Beste Grüße
Pepe
Es sollte auch einfacher gehen siehe link:
lg
Christian
p.s. wenn du php5-common entfernst - musst du auch die webapp neu installieren - das war der weg den ich damals gegenagen bin
Hallo EXTERNA1,
das was dort geschrieben steht hat vielleicht mla so funktioniert - jedoch nicht wenn man mit den Versionen arbeitet die ich oben beschrieben habe. In der verwendetetn Kopano WebApp Version wurde zwar mein Hauptproblem elemeniert - jedoch erhalte ich nun alle 30 Minuten diese eMails.
Hatte eigentlich gehofft von Kopano hierzu in der letzten Woche eine Aussage zu bekommen - aber das war leider nicht so.
Oder fixen das die vom UCS Team?
Beste Grüße und danke für den Hinweis - aber noch sind wir nicht durch ;-(
Pepe
Der Kauf einer Kopano Subskription würde deine Chance auf eine Antwort erhöhen. Neben deinem Beitrag zur Weiterentwicklung von Kopano und der Univention Integration von Kopano erhältst du Zugriff auf den Kopano Support.
Und wenn du mittels https://appcenter.univention.de/kopano.html die Subskription erwirbst, hat sogar Univention was davon.
Hallo - klar kann man auch eine Subskription erwerben - nur dann würde ich mich richtig ärgern - da das Problem ja scheinbar immer noch besteht 
Der Grund warum Firmen FREE Modelle anbieten liegt darin begründet, dass es Nutzer gibt die Spaß an Technik haben - und schon einmal eher die neuste Version einsetzen. Das spart den Herstellern/Entwicklern einen Haufen kostenintensiver Kompatibilitätstests. Was am Ende zu einer Win-Win Situations führt.
Somit weiß ich nicht, ob der Hinweis auf eine Antwort mit Subskription an der Stelle angebracht ist - ist aber nur meine Meinung - und wer bin ich denn schon
Kurzes Update zu den eMail die keiner braucht:
/usr/lib/php5/sessionclean: 34: /usr/lib/php5/sessionclean: php5: not found
Auch nach dem aktualisieren
- UCS --> 4.3-1 errata229
- Kopano WebApp --> 3.4.19.1649
besteht das Problem leider immer noch.
Scheint wohl keine Prio bei der Behebung von Fixen zu haben
Updates folgen
Pepe
Huhu,
die Art und Weise, wie Debian-Paket-Management funktioniert, erlaubt hier schlicht keinen guten automatischen Fix:
- Der Cron-Job, durch den die E-Mails erzeugt werden (
/etc/cron.d/php5), gilt wohl als Konfigurationsdatei. Unter Debian werden Konfigurationsdateien nur dann gelöscht, wenn ein Paket gepurget wird (apt-get remove --purge <paketname>bzw.dpkg --purge <paketname>). - Pakete, die im Status
rcsind (removed, configured), werden vom Paketmanagement nie automatisch gepurget. Das ist immer Sache der Administratorin. - Pakete, die nicht mehr benötigt werden und automatisch entfernt werden, werden ebenfalls laut Debian-Policy nicht automatisch entfernt. Auch das ist Aufgabe der Administratorin.
- Pakete, die durchaus noch von anderen Paketen benötigt werden (z.B.
php5-commonwird beispielsweise noch vonphp5-cgibenötigt), werden erst Recht nicht automatisch entfernt, es sei denn, es kommt bei Upgrades durch explizite Konflikte dazu
Auf meiner Liste für Dinge, die ich nach jedem UCS-Update tun muss, stehen daher u.a. die folgenden Punkte:
- Automatisch installierte aber nicht mehr benötigte Pakete mit
apt-get autoremove --purgeentfernen - Pakete im Status
rcpurgen, sofern nicht benötigt; Liste mitdpkg -l | grep '^rc', purgen mitdpkg -l | awk '/^rc/ { print $2 }' | xargs -r dpkg --purge
Das Paket, um das es hier geht, stammt noch aus UCS 4.2, genauer: unverändert aus Debian 8. Es wäre also Job der Debian-Entwickler, den Cron-Job so anzupassen, dass er nur ausgeführt wird, wenn das php5-Binary noch existiert.
Die einfachste Lösungsmöglichkeit: du purgest das Paket (php5-common), zu dem der Cron-Job gehört, sofern du es nicht mehr benötigst (kannst ja sehen, was entfernt werden würde, wenn du apt-get remove --purge php5-common ausführst).
Möglichkeit 2: du schreibst einen Bugreport an Debian, dass der Cron-Job das Script nur ausführen sollte, wenn das Binary auch wirklich existiert. Andere Cron-Jobs enthalten solche Tests durchaus.
Lustige Beobachtung: das analoge Paket für PHP 7.0 enthält einen analogen Cron-Job /etc/cron.d/php, der das Script nur dann ausführt, wenn das System nicht mit systemd als init laufen sollte. Wenn es mit systemd läuft, so wird ein systemd-Timer für das Gleiche benutzt. Wenn man jemals in die Verlegenheit kommen sollte, zwar noch php7.0-common aber nicht mehr php7.0-cli installiert zu haben, so würde man daher trotzdem keine Mails bekommen, weil die Ausgabe von Timern erst mal nur im Journal landet.
2 Likes
Danke Moritz für deinen Beitrag - und die Ansätze zu einer Lösung.
Was mich hier (und damit ist nicht Deine Antwort gemeint) stört ist, dsas man sich mit der Installation von Kopano WebApp erst diese Pakete auf sein System installiert (siehe oben), und ich dann zum einen entscheiden soll, ob diese Pakete noch benötigt werden.
Ich hätte es auch OK gefunden, wenn es von Kopano dazu einen Hinweis gegeben hätte --> bitte führen Sie folgenden Befehl aus um das Problem zu beheben “apt-get remove --purge php5-common”. Sollten Sie eigenständig Pakete auf dem System installiert haben, dann …
Da ich mit einem Default System arbeite, gehe ich mal davon aus, dass die folgenden Pakete nicht mehr benötigt werden (sie sind auch nicht auf meinen beiden UCS DCs installiert - und waren vor der Kopano WebApp ja auch nicht auf dem System). Sicherheitshalber machen wir mal noch schnell einen Snapshot der VM.
root@ucs4:~# apt-get remove --purge php5-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
php5-common* php5-curl* php5-enchant* php5-json*
0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
After this operation, 1,615 kB disk space will be freed.
Do you want to continue? [Y/n]
Huhu,
So funktioniert das Debian-Paketmanagement halt. Daran ist weder Univention noch Kopano schuld. Bei Ugrades von einem Release (UCS 4.2 == Debian 8 zu UCS 4.3 == Debian 9) kommt es nun mal zu solchen Situationen. Es obliegt der Administratorin eines Debian-basierten Systems, nach Release-Upgrades manuell wieder für Ordnung zu sorgen.
Dem würde ich zustimmen.
Bevor Sie das machen — was sagt denn ein apt-get autoremove --purge?
m.
Danke Moritz für Deine schnelle Rückmeldung.
Ich habe gerade einmal auf einen meiner beiden UCS DCs das Kopano WepApp Paket zur Installation selektiert. In der Liste (siehe unten) werden auch noch jetzt diese “nicht benötigten” (?) Pakete (PHP5) weiterhin installiert - und lösen damit den beschriebenen Fehler aus.
Installation von Kopano WebApp
Bitte bestätigen Sie die Installation der Applikation Kopano WebApp auf diesem Rechner.
Die folgenden Software-Änderungen werden auf ucs2 angewendet: 56 Pakete werden installiert / aktualisiert, 2 Pakete werden deinstalliert
Folgende Pakete werden installiert bzw. aktualisiert:
libaspell15
aspell
aspell-en
libenchant1c2a
enchant
libgsoap-kopano-2.8.62
libkcutil0
libkcmapi0
libmapi1
libkcfreebusy0
libkcsoap0
libkcssl0
libkcsync0
kopano-lang
kopano-client
kopano-contacts
libical2
libkcicalmapi0
libvmime-kopano1
libkcinetmapi0
php7-mapi
php7.0-mbstring
php-mbstring
php-php-gettext
php-gettext
libzip4
php7.0-zip
php-zip
kopano-webapp
kopano-webapp-plugin-desktopnotifications
kopano-webapp-plugin-filepreviewer
--> php5-common
--> php5-curl
php7.0-curl
kopano-webapp-plugin-files
kopano-webapp-plugin-filesbackend-owncloud
php-smbclient
kopano-webapp-plugin-filesbackend-smb
kopano-webapp-plugin-folderwidgets
php7.0-soap
php-soap
kopano-webapp-plugin-mdm
php-kopano-smime
php7.0-bcmath
php-bcmath
kopano-webapp-plugin-smime
--> php5-enchant
php7.0-enchant
php-enchant
kopano-webapp-plugin-spell
kopano-webapp-plugin-spell-de-de
kopano-webapp-plugin-spell-en
kopano-webapp-plugin-spell-nl
kopano-webapp-plugin-titlecounter
kopano-webapp-plugin-webappmanual
kopano4ucs-webapp
Folgende Pakete werden deinstalliert:
linux-image-4.9.0-6-amd64-signed
linux-image-4.9.0-ucs109-amd64
Erst mit der Installation des Kopano WebApp Paketes sind diese mitgekommen. Somit kann ich das Argument des Upgrades hier nicht gelten lassen.
Was aber dann wieder die Frage aufwirft, warum werden auch jetzt noch diese Pakete installiert, wenn man diese gar nicht benötigt - oder benötigt man diese doch?
Zu Deiner Frage was bei apt-get autoremove --purge herauskommt
root@ucs4:~# apt-get autoremove --purge
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Ah OK, mir war nicht klar, dass das Paket weiterhin php5 als optionale Abhängigkeiten auflistet. Sorry.
Depends: php5-mapi | php7-mapi (>= 7.2.5), php5-json | php-json, php-gettext | php5-gettext, php-xml, php-zip, php-common
Ich weiß leider nicht genug über Debian-Paketmanagement, um genau sagen zu können, wie die Auflösung hier verfährt. Meine Vermutung ist, dass es reichen könnte, die Reihenfolge der ersten zwei optionalen Teile jeweils umzudrehen, also:
Depends: php7-mapi (>= 7.2.5) | php5-mapi, php-json | php5-json, php-gettext| php5-gettext, php-xml, php-zip, php-common
Aber das müsste @fbartels mal ausprobieren.
1 Like
Hi - kurzes Update zu den nerfigen eMails.
Auch die heute eingespielten Update:
- 4.3-2 errata287
- Kopano WebApp 3.4.21.1723
haben leider keine Verbesserung gebracht.
Die PHP5 Reste werden mir wohl noch weitere Monate treu bleiben ;-(
Ah, diese Antwort sehe ich erst jetzt. Ich hatte dieses Thread gemutet, da Pepe und ich nur bedingt kompatibel scheinen. Auch in meinem Augen ist hier die Lösung die Dependencies umzudrehen und PHP7 an erster Stelle stehen zu haben. Nach viel hin und her mit unserem WebApp Team wurde das auch bereits vor einigen Monaten für die Nightly Builds umgesetzt, scheinbar wurde diese Änderung nach wie vor nicht für die anderen Releasetypen übernommen. Ich habe das jetzt nochmal angeschoben:
$ apt -a show kopano-webapp
Package: kopano-webapp
Version: 3.4.23.1907+1058.1
Priority: optional
Section: web
Maintainer: Kopano Development <development@kopano.io>
Installed-Size: 28,2 MB
Depends: php7-mapi | php5-mapi (>= 7.2.5), php-json | php5-json, php-gettext | php5-gettext, php-xml, php-zip, php-common, php-mbstring
Download-Size: 4.932 kB
APT-Sources: https://download.kopano.io/supported/webapp:/master/Univention_4.3 Packages
Description: New and improved WebApp for Kopano
Provides a web-client written in PHP that uses JSON and Ext JS
to allow users to make full use of Kopano
through a modern web browser.
1 Like
Hi - kurzes Update zum aktuellen Status.
Auch die heute eingespielten Update:
- 4.3-2 errata376 (Neustadt)
- Kopano WebApp 3.4.22.1782
haben leider keine Verbesserung gebracht.
Die PHP5 Reste werden mir wohl noch weitere Monate treu bleiben ;-(
Bleibt die Frage ab wann denn die Version 3.4.23.1907+1058.1 zur Verfügung steht - und ob dann wirklich das Problem weg ist.
Vielleicht wird es ja noch ein Weihnachtsgeschenk ;-)))
siehe 
lg
Christian
Hallo - kurzes Update
Nach dem Update auf Kopano Core auf die Version 8.7.1.0 und UCS 4.4-0 errata137, kommen vom Core keine störenden eMails mehr - PERFEKT ! ! !
Nicht so gut sieht es leider auf dem Server aus, auf dem die WebApp läuft. Auch hier wurde die aktuelles Version die UCS anbietet installiert (3.5.5.2276+93.1). Bei den zu deinstallierenden Paketen sind die betroffenen jedoch auch nicht mit dabei:
Laut dem Kopano Support (siehe weiter oben) solle das bereits mit der Version 3.4.23.1907+1058.1 gefixt sein - tja, ist es aber nicht.
Wäre schön, wenn man den Fix denn für das WebApp Paket denn mal bald nachliefern könnte bevor der Post Geburtstag feiert
PS: Nein - ich möchte die zu deinstallierenden Dateien immer noch nicht von Hand bearbeiten
Kurzes Update - auch mit dem Update auf Kopano WebApp 3.5.14.2539-2 bleiben die eMails. Ein Uninstall für php5 scheint in dem Client Paket leider immer noch nicht vorgeseehn zu sein 
Bin gerade hingegangen und habe Kopano WebApp noch einmal komplett deinstalliert.
Reboot - und dann die App noch mal ausgewählt.
Auch dann befinden sich bei den 65 zu installierenden Paketen immer drei php5 Pakete:
Folgende Pakete werden installiert bzw. aktualisiert:
hunspell-de-de
libhunspell-1.4-0
libenchant1c2a
enchant
libgsoap-kopano-2.8.62
libkcutil0
libkcmapi0
libmapi1
libkcfreebusy0
libkcsoap0
libkcssl0
libkcsync0
kopano-lang
kopano-client
kopano-contacts
libical2
libkcicalmapi0
libvmime-kopano1
libkcinetmapi0
php-common
php7.0-common
php7.0-json
php7.0-opcache
php7.0-readline
php7.0-cli
libapache2-mod-php7.0
php7.0-cgi
php7-mapi
php7.0-xml
php-xml
libzip4
php7.0-zip
php-zip
php7.0-mbstring
php-mbstring
kopano-webapp
kopano-webapp-plugin-desktopnotifications
kopano-webapp-plugin-filepreviewer
php5-common
php5-curl
php7.0-curl
kopano-webapp-plugin-files
kopano-webapp-plugin-filesbackend-owncloud
php-smbclient
kopano-webapp-plugin-filesbackend-smb
kopano-webapp-plugin-folderwidgets
php7.0-soap
php-soap
kopano-webapp-plugin-mdm
php-kopano-smime
php7.0-bcmath
php-bcmath
kopano-webapp-plugin-smime
php5-enchant
php7.0-enchant
php-enchant
kopano-webapp-plugin-spell
kopano-webapp-plugin-spell-de-de
kopano-webapp-plugin-spell-en
kopano-webapp-plugin-spell-nl
kopano-webapp-plugin-titlecounter
kopano-webapp-plugin-webappmanual
kopano4ucs-app
kopano4ucs-lib
kopano4ucs-webapp
Version 3.5.14.2539-2 ist nun installiert - Reboot und 30mins warten.
Tja - leider immer noch da ;-(
Wie bekommt man das weg???