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?
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.
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
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?
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.
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???).
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.
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.
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 ;-(
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.
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
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 rc sind (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-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.
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]
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?
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.
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:
