Kopano WebApp --> PHP mapi extension not found (nearly fixed - how to fix included)

Apps & App Center
, , ,
#1

Hallo - ja ich habe mir die bereits hinterlegten Posts im Forum bereits durchgelesen - die Antworten haben allerdings nicht wirklich weitergeholfen - auch der Post im Kopano Forum war eher sehr dünn
Komapa Forum

Kurz was gemacht wurde:

  • UCS Server 3 (Kopano Core) von 4.2-3 errata418 auf 4.3-1 errata157 gehoben
  • UCS Server 4 (Kopano WebApp) von 4.2-3 errata418 auf 4.3-1 errata157 gehoben

Keine Fehlermeldungen - bis zum Start der WebApp.

Beim Start der WebApp kommt die Meldung --> PHP mapi extension not found

Das es Problem mit PHP 5 und der erwarteten PHP 7 Version gibt, das habe ich verstanden.

Was aber kurz und knann zu tun ist um das umzusetzen - konnte ich als Kommandozeilen-Anfänger nicht nachvollziehen. Auch das Paket was das alles fixen soll, wird mir via UCS nicht angeboten - und ich wollte eigentlich nicht selber Pakete oder Konfigs anpassen - die dann nachher das automatische Update beeinträchtigen.

Anyway - wie bekommen wir die Kuh vom Eis ohne das System so zu verbiegen dass es danach nicht mehr läuft - aber ich möglichst schnell die WebApp wieder zur Verfügung stellen kann.

NACHTRAG: Den Hinweis “add provisions in join script to force usage of php7” habe ich auch noch gefunden. Wie geht denn das - und hilft das?

Vorschläge?

Vielen Dank vorab
Pepe

#2

Ko-Pa-No und das verlinkte ist kein Forum, sondern ein Knowledge Base Eintrag.

Aber welche Version der Kopano WebApp App Ist installiert? Die neuste Version macht die Umstellung auf php7 automatisch und es müssen keine Kommandos manuell ausgeführt werden.

#3

Nah wenn sich der Rest auch so einfach lösen lässt wie der falsche Buchstabe und die falsche Bezeichnung - nah dann sollte das ja bis zum Mittagessen durch sein :wink:

Anyway - installiert ist 3.4.15.1513. - eine neuere Version wird mir aber auch nicht angeboten via UCS.

Warum wird diese denn nicht angeboten wenn die die Lösung ist?
Anyway - wie findet diese Version denn den Weg zu mir?

Beste Grüße
Pepe

#4

Das ist bereits die Version, die die PHP Version automatisch setzt. Ich würde dann empfehlen ein Ticket bei unserem Support aufzumachen, damit sich jemand auf dem System anschauen kann was dort schief läuft.

#5

Hhmmm - interessant - da ich die freie Version verwende, wird der Support wohl kauf auf mein System schauen wollen.

Anyway - ich bekomme die folgenden beiden Fehlermeldungen vom Cron Daemon:

UCS 3 (Kopano Core):
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/mapi.so' - /usr/lib/php5/20131226/mapi.so: cannot open shared object file: No such file or directory in Unknown on line 0

UCS 4 (Kopano WebApp):
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/mapi.so' - /usr/lib/libkcfreebusy.so.0: version `KC_8.4' not found (required by /usr/lib/php5/20131226/mapi.so) in Unknown on line 0

Da ich auf den Core via Thunderbird Client via IMAP zugreifen kann und eMails rein und raus gehen, werde ich mal versuchen ob eine UCS 4-3-x Neuinstallation (incl Kopano WebApp) eine Verbesserung bringen.

Ansonsten Roll-Back beider Systeme auf UCS 4-2-3 - was sehr unschön wäre ;-(

Ideen/Anregungen - immer gern

ERGÄNZUNG: Auf dem UCS4 läuft auch Kopano WebMeeting (3.0.1.100) - kann es hierdurch einen Einfluss geben (z.B. weil hier PHP5 weiter verwendet werden muss???).

#6

Update:
Bevor ich mit der Neuinstallation anfange, habe ich noch folgende Dinge versucht:

  • Kopano WebMeeting deinstalliert - reboot --> leider keine Verbesserung
  • Ich habe mir noch die installierten PHP Pakete angesehen (via UCS Management Console - und sowohl PHP5 als auch PHP 7 sind installiert
  • Deinstalliert man auch Kopano WebApp, sind auch alle PHP Versionen weg
    • Kling für mich so, als wenn UCS selber kein PHP benötigt
  • Nach einem erneuten Reboot habe ich dann KoPano WebApp wieder installiert (3.4.15.1513)
    • Bei den zu installierenden Paketen tauchen zwar auch wieder PHP5 Pakete mit auf - jedoch weniger
  • Nach Reboot - habe ich mir noch mal angesehen (via UCS Management Console), welche Pakete dieses mal installiert wurden. Dieses mal wurde “libapache2-mod-php5” nicht installiert.

Und PENG - es geht. Kopano WebApp lässt sich wieder öffnen !!!

Mache jetzt noch einen Domainen-Re-Join, dann noch einen erneuten Reboot und dann schauen wir mal.

#7

Die Kopano WebApp selber geht - jedoch erhalte ich noch Nachrichten vom Cron Daemon:

UCS 3 (Kopano Core):
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/mapi.so' - /usr/lib/php5/20131226/mapi.so: cannot open shared object file: No such file or directory in Unknown on line 0

UCS 4 (Kopano WebApp):
/usr/lib/php5/sessionclean: 34: /usr/lib/php5/sessionclean: php5: not found

Die Installation von kopano WebMeeting verschiebe ich mal - und schaue mal ob es noch einen Fix für die beiden Fehlermeldungen gibt.

PS: Das neue Hintergrundbild finde ich weniger schön - die Naturlandschaft war da beruhigender.

Sollte mir noch etwas auffallen, werde ich entsprechend ergänzen.

Sollte es einen Fix (für die Meldungen) geben - freue ich mich auf eine Nachricht.

Beste Grüße
Pepe

#8

Hi,

das solltes Du mit einem apt-get purge php5

wegbekommen - das sind configs die beim deinstall von php im system verbleiben.

lg
Christian

#9

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

#10

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
image

bin ich eher vorsichtig mit “Reste” löschen.

Was sagt den Kopano-Team dazu - die Pakete wurden ja durch die WebApp installiert :wink:

Beste Grüße
Pepe

#11

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

#12

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.
image

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

#13

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.

#14

Hallo - klar kann man auch eine Subskription erwerben - nur dann würde ich mich richtig ärgern - da das Problem ja scheinbar immer noch besteht :wink:

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 :wink:

#15

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 :wink:

Updates folgen

Pepe

#16

Huhu,

die Art und Weise, wie Debian-Paket-Management funktioniert, erlaubt hier schlicht keinen guten automatischen Fix:

  1. 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>).
  2. Pakete, die im Status rc sind (removed, configured), werden vom Paketmanagement nie automatisch gepurget. Das ist immer Sache der Administratorin.
  3. 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.
  4. Pakete, die durchaus noch von anderen Paketen benötigt werden (z.B. php5-common wird beispielsweise noch von php5-cgi benö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 --purge entfernen
  • Pakete im Status rc purgen, sofern nicht benötigt; Liste mit dpkg -l | grep '^rc', purgen mit dpkg -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
#17

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]
#18

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.

#19

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.

:wink:

#20

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
Mastodon