Opensuse 12.3 – OX 6.22 lässt sich mit systemd nicht starten

Nach dem Upgrade von Opensuse 12.2 auf Opensuse 12.3 musste ich leider feststellen, dass der Dienst “/etc/init.d/open-xchange” nicht mehr automatisch gestartet werden kann. Im Gegensatz zu Opensuse 12.2 führt ein "systemctl start open-xchange" nun leider ins Nirwana:

mysystem:/etc/init.d # systemctl status open-xchange.service
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:30:19 CET; 5min ago
Process: 13365 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 13349 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13349]: Starting open-xchange ..done
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
Mar 27 12:30:19 mysystem.mydomain.de su[13360]: (to open-xchange) root on none
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13365]: Shutting down open-xchange ..done

Jeder Start mit systemd führt also auch zu einem sofortigen Stop. Und der Service ist danach regelmäßig "dead".Was dem User beim Versuch, sich in OX 6 einzuloggen mit 503-Fehlermeldungen quittiert wird.

Na da freuen wir uns doch mal wieder herzlich über die "wunderbare" Welt von systemd! Was für OX 6.22 unter Opensuse 12.2 anstandslos lief, läuft unter Opensuse 12.3 nicht mehr. Und die Fehleranalyse ist für systend so kompliziert und unüberschaubar, dass ich im Moment keinerlei Lust verspüre, auf Fehlersuche zu gehen.

Workaround
Netterweise geht aber nach wie vor ein direkter Start über das Skript:

mysystem:/etc/init.d # ./open-xchange start
redirecting to systemctl start
Starting open-xchange done
mysystem:/etc/init.d # ./open-xchange status
Checking for service open-xchange running
Checking for service open-xchange running
mysystem:/etc/init.d # systemctl status open-xchange
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:57:05 CET; 1min 39s ago
Process: 15646 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 15636 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15636]: Starting open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15646]: Shutting down open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
mysystem:/etc/init.d #

Man beachte die Kleinigkeiten und erfreue sich an dieser berauschenden Logik: Das Startscript wird angeblich an systemctl redirected. Open-Xchange wird danach auch erfolgreich gestartet. Der Status ist bei normaler Abfrage per Script auch running. Man kann sich regulär per Browser in seinen OX6-Account einloggen. Aber systemd kann mit dem erfolgreichen Start offenbar gar nichts anfangen und sieht nicht mal, dass der Service läuft! Was für ein grandioses Chaos!

Jedenfalls läuft der Dienst nur nach einem normalen Start – also über /etc/init.d/open-xchange start regulär. Nicht aber das Rauf- und Runterfahren über systemd. Damit kann man den inzwischen auf ein Minimum reduzierten “Runlevel-Editor” von YaST für eine Aktivierung von OX 6.22 schlicht vergessen. Runlevels gibt es dort nicht mehr – und für OX funktioniert das Starten beim
Hochfahren in das Systemd-Default-Target mit systemd nicht.

Also gilt bis auf weiteres unter Opensuse 12.3: OX 6.22 händisch starten und vor dem Runterfahren auch wieder stoppen.
Schöne neue Welt …. Seufz ….

Nachtrag 08.06.2013 und Lösung:
Die Opensuse-Leute haben mir inzwischen wirklich geholfen, das Problem analysiert und ein service-file für den “open-xchange”-Service zusammengestellt. Dadurch ist nun ein Hochfahren von open-xchange beim Systemstart möglich.
Siehe
https://bugzilla.novell.com/show_bug.cgi?id=813767
Man beachte auch die gute Erklärung der Problem-Ursache.

Vielen Dank an Frederic Crozat !!

Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Ich habe ja vor kurzem auf zwei Systemen Opensuse 12.3 installiert. Im Zuge davon habe ich auch ein Update der Libreoffice-Installation vorgenommen. Danach wollte ich im Rahmen eines Projektes mit Hilfe der Clipart-Gallery ein paar Draw-Zeichnungen anfertigen. Die notwendigen Clipart-Pakete

  • libreoffice-openclipart
  • openclipart-svg (in der Version 0.18

hatte ich natürlich installiert.

Zur Voransicht der Cliparts gibt es in den Libreoffice-Anwendungen ein Fenster, in dem die Cliparts nach thematischen Bereichen gegliedert dargestellt werden. Soweit ich mich erinnern kann, hatte ich dort zumindest in einer OS 12.1 / LibreOffice 3.5-Installation für alle Themenbereiche der Gallery auch eine Voransicht zugehöriger Ciparts gefunden.

Leere Ansicht für viele Gallery-Themenbereiche unter OS 12.2 und OS 12.3

Leider wird nun für die meisten thematischen Gallery-Bereiche in Libreoffice 3.5 bis 4.0.2 unter Opensuse 12.2 oder Opensuse 12.3 gar nichts mehr angezeigt. Beispiele liefern "Science" oder "Shapes" ; im Gallery-Fenster ist zu beiden Themenbereichen kein Clip zu sehen:

gallery_leer_600

Das ist ein typischer Mangel an qualitätsgesicherter Paket-Aufbereitung, wie er mich an der Verbreitung von Opensource-Produkten durch einige Distributoren manchmal an den Rand der Verzweiflung treibt. Was macht denn eine normaler Anwender bei einem solchen Befund? Er zuckt mit den Achseln, wundert sich und geht davon aus, dass es da halt keine Bilder gibt. das ist zugleich falsch und schade!

Eine Fehlersuche zeigt, dass es im Verzeichnis /usr/lib64/libreoffice/share/gallery/ Softlinks auf *sdg-Dateien gibt, die im korrespondierenden Verzeichnis /usr/share/libreoffice/share/gallery/ leider ins Nirwana führen. Für die entsprechenden Themenbereich wird in der Clipart-Ansicht der Libre-Office-Bereiche deshalb nichts angezeigt, obwohl im thematischen Subverzeichnis unter /usr/share/openclipart/ haufenweise svg-Dateien vorhanden sind.

Ein Blick in die Verzeichnisliste des Openclipart-Pakets von Opensuse zeigt, dass die beschreibenden "sdg"-Dateien für viele Themenberieche tatsächlich nicht ausgeliefert werden – also bereits im RPM-Paket von Opensuse selbst fehlen. Warum auch immer …. Ein Bug?

Eine parallele Windows-Installation ist wenigstens ehrlicher – die bietet von Haus aus nur wenige gefüllte Themenbereich an. Den Rest muss man sich sowieso selbst zusammenstellen.

OpenClipart-Download als Alternative ? Nein !

Alternativ und naiv dachte ich nun daran, mir etwas von der OpenClipart-Seite im Web herunterzuladen. Da wurde alles nur schlimmer; ein Download aktuellerer Clipart-Pakete ab Version 0.19 führt in den Abgrund.

Man erhält dann nämlich keine vorsortierte thematische Zusammenstellung an Files mehr, die man in ein Subverzeichnis von "/user/share/clipart/" einfügen könnte. Stattdessen kommen HTML-Dateien mit Bildern aus einem Verzeichnis, das nach allen möglichem (u.a. Autoren) aber nicht thematisch untergliedert ist. Vielmehr wird hier eine komplexe Installation von HTML-Seiten mit PHP-MySQL-basierter Suchmaschine erwartet. Leider funktioniert das vorgesehen “make install” unter OS 12.3 gar nicht. Schauder … – in dieser Form ist OpenClipart 2.x weder für LibreOffice noch sonst irgendwie brauchbar. Keine Zeit, mich damit zu befassen. Ich will doch nur ein paar faktisch vorhandene Cliparts unter Libreoffice sehen und nutzen!

Workaround

Ich habe dann versuchsweise Libreoffice komplett deinstalliert, alle zugehörigen Konfigurationsdateien in meinem Home-Verzeichnis entfernt und Libreoffice neu installiert. Das half leider auch nichts. Aus Zeitmangel habe ich nun einen Workaround per Handarbeit vorgenommen:

Schritt 1: Man muss in Libreoffice im Gallery-Fenster selbst ein neues Thema zu einem der vorhandenen thematischen, aber leider als leer angzeigten Bereiche wie “Shapes” anlegen. Ich gebe dem neuen Thema z.B. den Namen "shapes_2".

Schritt 2: Im Subdialog-Fenster zu diesem neuen Thema lässt man im thematischen Unterverzeichnis von /usr/share/openclipart/ [hier also im Verzeichnis "/usr/share/clipart/openclipart/shapes/" ] alle passenden Dateien zusammensuchen, markiert dann alle oder eine Unterauswahl und drückt auf den Button "Hinzufügen". Die Anzeige des folgenden kleinen Dialoginhalts ist unter meinem KDE 4.10 dann leider nicht vollständig zu erkennen – aber man wartet einfach, bis der Übernahmeprozess erfolgt ist.

Schritt 3: Das Ergebnis sind dann 3 Dateien unter /home/USER/.config/libreoffice/4-suse/user/gallery/ (USER ist dabei dein Username):

  • sgxxx.sdg,
  • sgxxx.thm,
  • sgxxx.sdv

xxx steht dabei für eine 2- oder dreistellige Ziffer. Das eben installierte Clipart-Thema hat die höchste Nummer.
Man wird in unserem Beispiel feststellen, dass Libreoffice nun im Gallery-Fenster unter "shapes_2"alle svg-Dateien von "/usr/share/clipart/openclipart/shapes/" tatsächlich anzeigt. Die drei beschreibenden Dateien, im besonderen die sdg-Datei, sind dafür hinreichend.

Schritt 4:
Nun ermittelt man unter Libreoffice im Galleryfenster durch einen Rechtsklick auf das ursprüngliche “Shapes” dessen "Eigenschaften". In einem Dialofenster wird u.a. ein File-Pfad und ein File-Name einer zugehörigen Deskriptionsdatei sgxxx.sdg angezeigt – bei mir ist Shapes z.B. mit dem File "sg85" assoziiert.

Man fertige nun eine Kopie der obigen drei Dateien sgxxx.sdg, sgxxx.thm, sgxxx.sdv an und benenne die Ziffern "xxx" in "85" (bzw. die eben ermittelte Nummer) um. Danach verschiebe man diese deskriptiven Dateien als root (!) in das Verzeichnis "/usr/share/libreoffice/share/gallery/". (Root-rechte sind dort zum Schreiben erforderlich.

Danach funktioniert auch die Anzeige der Dateien unter dem ursprünglichen Themenbereich "Shapes" und nicht nur unter "shapes_2".

gallery_voll_600

Den für den Workaround angelegten Themenbereich "shapes_2" kann man nun eigentlich auch löschen löschen. Ich würde ihn aber behalten, da die Deskriptonsdateien für "Shapes" bei einer Neuinstallation der Opensuse-RPMs möglicherweise wieder gelöscht werden. Dann kann seine alte Auswahl im Eigenschaftsdialog von shapes_2 aktualisieren lassen und wie oben beschrieben weiterverfahren.

Nach diesem kleinen Desaster zur Korrektur einer unvollständigen OpenClipart-V18–Installation unter Opensuse 12.3 bleibt abzuwarten, wie Opensuse und LibreOffice mit der Integration von OpenClipart-Galleries der aktuellen Versionen 0.19 und 2.X umgehen werden.