Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


On 04.09.15 11:20, habe ich mir einen langen Diskussionbeitrag zum Javaldx Problem mit verschiedenen Analysen abgerungen. Am 22.9.2015 11:16 hat harald.koester@mail.de darauf geantwortet. (Diese Mail ist mir leider verloren gegangen, habe ich aber im Archiv gefunden.)
Hallo Harald erstmal danke für Deine Antwort.
Ja, man kann all diese schönen Zillas und Lists füttern.
Habe das früher schon mal gemacht und auch was erreicht.
Aber oft gebiert der Berg nach endlosem Kreissen nur eine Maus

Heute stehe ich wieder vor dieser "Javaldx" Fehlermeldung und es dämmert mir: "Da war doch was." Schön, dass ich damals in die Tiefe gegraben habe, schöner, dass ich das irgendwo gepostet habe und am schönsten, dass ich's wiedergefunden habe.

Trotzdem bin ich seit einem Jahr offensichtlich nicht weiter gekommen und stehe immer noch vor demselben Problem ohne eine Lösung.

Ich will's nochmal ganz anders beschreiben und vielleicht gelingts mir auf Deutsch besser, mich verständlich zu machen.

Ein Benutzer läd das Libreoffice Paket herunter und installiert das ganze Libreoffice Paket in seinem Homedirectory mit seinen Rechten um es selbst zu nutzen. Wohlgemerkt, er ist nicht root und kann also keine Systeminstallation machen. Er macht eine Userinstallation.

Alles ist gut, denn wo immer sein Libreoffice in Zukunft Files anlegen möchte, sind das ja die Files des Benutzers, die vom Benutzer mit den Rechten des Benutzers angelegt werden und werden dürfen. Es geht dabei nicht um die OD-Dokumente, die der Benutzer anlegt, sondern um die Konfigurationsfiles, Templates, Galleryobjekte usw.. Frühere Installationen haben dafür immer explizit ein Verzeichnis in $HOME/.soffice... oder $Home/.config/libreoffice/4 verwendet, wo der Benutzer ja selbst schreiben darf.

Eine Userinstallation von Libreoffice verhält sich jedoch anders. Bei der Userinstallation ist für die Konfigurationsfiles, Templates, Galleryobjekte usw. offensichtlich im Installationsbaum selbst ein Platz vorgesehen. Wenn man also das soffice einer Userinstallation startet, dann versuchen die Startscripten und -routinen nicht auf $HOME/.config... zuzugreifen, sondern auf ($LIBREOFFICE_HOME ist das bei der Installation angegebene Installationsverzeichnis, z.B. $HOME/opt/libreoffice4.4) $LIBREOFFICE_HOME/program/../../UserInstallation/user/config/..... zuzugreifen. Wenn das nicht existiert, wird versucht es anzulegen und zu initialisieren. Das geht wunderbar, wenn $LIBREOFFICE_HOME im Verzeichnis des Benutzers liegt. Es geht aber nicht mehr, wenn $LIBREOFFICE_HOME nach der Installation in einen schreibgeschützten Bereich verschoben wurde, z.B. auf ein Netzwerklaufwerk.

Hat man also Libreoffice als Userinstallation installiert und dann mit einem einzigen privilegierten Befehl in einen schreibgeschützten Bereich verschoben, dann lässt sich eine Userinstallation nicht mehr verwenden, da sie davon ausgeht, innerhalb des Installationsbaums schreiben zu können. Wenn das nicht gelingt, kann Libreoffice die Userkonfiguration nicht anlegen und endet mit dem Fehler

 117) soffice
[Java framework] Error in function createSettingsDocument (elements.cxx).
javaldx failed!
Warning: failed to read path from javaldx

Was sagt Google dazu?
Die Suche nach "javaldx failed libreoffice" ergibt 1170 Treffer mit teils haarsträubenden Fragen, Analysen und Empfehlungen. Meistens ist das Problem nicht verstanden und es werden mehrere Installationsversuche unternommen. Oft geht's dann und keiner weiss warum. Das ist dann ein sehr mulmiges Gefühl, wenn man eine solche Installation wieder anfassen muss. Für den Einzelbenutzer und auch für einen Systemadministrator,
der Software und Lösungen für andere bereitstellt.

Aber zurück zu meiner Vorgehensweise: Ja wer macht denn sowas??? Eine fertige Installation verschiebt man doch nicht! Das kann ja nicht gut gehen!

Doch doch, Systemadministratoren und Netzwerkmanager kommen immer wieder auf solche Ideen.

Was also habe ich mir dabei gedacht? Ich möchte Libreoffice auf einer unbekannten Anzahl von Rechnern anbieten, ohne es auf allen Rechnern installieren zu müssen. Also installiere ich es auf dem Server A in einem Filesystem, das exportiert wird. Dann importiere ich auf allen Klienten das Filesystem vom Server A. Natürlich dürfen die Klienten nicht schreiben, sondern nur lesen und schon habe ich die Misere.

Noch besser: ich installiere auf dem Server A, habe dort aber privilegiert mit Schreibrechten eine Filesystem des Fileservers F importiert, auf dem ich Libreoffice anlege. Dafür bin ich auf A nicht root geworden. Ich habe nur das Privileg zum Schreiben auf F bekommen. Ich kann jetzt die Software auf F anlegen und gebe das Privileg dann zurück. Nach der Installation stelle ich allen Klienten des Fileservers F nur eine ReadOnly Version des Filesystems zur Verfügung. Der ursprüngliche Installationsserver A hat mit Libreoffice gar nichts mehr zu tun. Die nächste Installation oder Wartung mache ich möglicherweise von einem anderen Server B, der lediglich das Filesystem F sieht und von A gar nichts mehr weiss.

Also mit dieser Schilderung bin ich nun meiner eigenen Lösung schon sehr nahe gekommen.
Ich befürchte aber, es versteht mich mal wieder keiner.
Ich schick's trotzdem ab.

Ich wünsche einen schönen Abend.

Karl








--
Liste abmelden mit E-Mail an: discuss+unsubscribe@de.libreoffice.org
Probleme? http://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: http://listarchives.libreoffice.org/de/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.