Linux, Opensuse 13.2, Firefox: Flash bei Bedarf über Wrapper aktivieren

Ich bin wahrlich kein Freund von Flash. Aber es gibt einige (veraltete) Webseiten, auf denen man bestimmte sinnvolle Inhalte halt nur mit Flash ansehen kann. So hängen ja u.a. einige deutsche Fernsehsender der technischen Entwicklung hinterher. Und dann gibt es da in unserer Familie auch noch ein paar Enkel, die zwar einen Linux-Laptop nutzen, aber trotzdem irgendwelche Flash-Inhalte “unbedingt(!!Opa, unbedingt!!)” sehen “müssen”. Welche Optionen hat man dann?

Erstens kann man auf den “Chrome” oder vorzugsweise auf den “Chromium”-Browser ausweichen. Für beide gibt es ja bekanntermaßen das “Pepper-Flash”-Plugin von Google. “Pepper” steht dabei für eine neue Art von generellem Browser-Plugin-Interface (PPAPI), das aber z.Z. auf Chrome/Chromium begrenzt ist. Siehe hierzu u.a.
http://www.howtogeek.com/193876/using-firefox-on-linux-your-flash-player-is-old-and-outdated/
Dieses Plugin ist möglicherweise nicht sicherer, aber immerhin schneller als das originale Flash von Adobe.

Was aber tun Firefox-Anwender, nachdem Adobe Linux ja generell nicht mehr unterstützt und das mit den Linux-Distributionen noch erhältliche Plugin in der Version 11.2 uralt und mit Sicherheit unsicher ist?

Mozilla selbst unterstützt die Flash-Plugin-Technologie nicht mehr aktiv – und unter Linux schon gar nicht (s. u.a. http://www.linux-magazin.de/NEWS/Firefox-blockiert-Flash-Inhalte). Ich finde das völlig OK – aber was mache ich nun mit veralteten Webseiten oder den lieben Enkeln, die Flash unter FF “unbedingt” nutzen “müssen”?

Nun, ein paar nette Leute haben solche Situationen wohl vorhergesehen und eine Wrapper-SW – das sog. “Fresh Player Plugin” – für das Chrome/Chromium pepper-based Flash-Plugin entwickelt. Siehe etwa:
http://www.makeuseof.com/tag/how-to-get-chromes-latest-flash-player-to-work-in-firefox-on-linux/
http://www.webupd8.org/2014/05/fresh-player-plugin-pepper-flash.html
https://github.com/i-rinat/freshplayerplugin

Es war aber gar nicht so einfach herauszufinden, wie man eine Installation unter Opensuse 13.2 auf einfache Art über Pakete und ohne Kompilieren hinbekommt. Dann fand ich nach etwas Herumsuchen im Packman Repository http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_13.2/
das Paket “freshplayerplugin”.

Das habe ich mal testweise installiert, und damit war das Problem auch schon gelöst. Allerdings hatte ich auf dem betroffenen System bereits eine Chromium-Installation aus den SuSE-Standard-Repositories an Bord, die ich um das Paket “chromium-pepper-flash” – ebenfalls aus dem Packman-Repository – ergänzt hatte. Wer bislang weder Chrome noch Chromium auf seinem Linux-System zur Verfügung hat, kommt jetzt nicht darum herum, entweder Chrome komplett – oder aber zumindest das Paket “chromium-pepper-flash” zu installieren. (Vorzugsweise verzichtet man auf Chrome – und nutzt Chromium.)

Zum “freshplayerplugin” – also dem Wrapper für FF – gehört eine umfangreiche Konfigurationsdatei. Die steht nach der Paketinstallation unter “/etc/freshwrapper.conf”. Sie enthält eine Zeile, in der der Pfad zur eigentlichen Bibliothek für den Chrome- oder Chromium Pepper-Flash-Player “libpepflashplayer.so”. [Die “so”-Datei wird im Zuge der Installation von “chromium-pepper-flash” angelegt.]

Da ich Chrome, wegen der ständigen Ausforschung durch Google nicht benutze, habe ich bei
mir die Pfadangabe auf das Chromium-Verzeichnis verkürzt.

#pepperflash_path = “/opt/google/chrome/PepperFlash/libpepflashplayer.so:/usr/lib64/chromium/PepperFlash/libpepflashplayer.so”
pepperflash_path = “/usr/lib64/chromium/PepperFlash/libpepflashplayer.so”

Danach muss man im Firefox unter “Extras >> Add-Ons >> Plugins” das aktuelle (pepper-based) Shockwave Flash Plugin nur noch aktivieren.

pepper1

Bei mir haben der Wrapper und das pepper-based Flash auf den (wenigen) Flash-Seiten, die ich mir angesehen habe, problemlos funktioniert. Herzlichen Dank also – im Besonderen von den Enkeln – an die Entwickler des Wrappers!

Wer Wert auf Sicherheit legt, für den mag folgender Hinweis noch interessant sein:
Man kann Firefox (bei aktiviertem Flash Plugin) mit Hilfe von “firejail” auch in einer Art Sandbox-Umgebung laufen lassen. Sieh dazu einen ausführlichen Artikel im aktuellen Linuxuser-Magazin 10/2015.

Opensuse 13.2, Libreoffice, fehlendes Paket libreoffice-clipart

Bestimmte Themen tauchen komischerweise immer wieder auf. Im Zusammenhang mit Opensuse 12.3 hatte ich vor ein paar Jahren darauf hingewiesen, dass zeitweise die deskriptiven Dateien “*.sdg, *.sdv, *.str, *.thm” für die thematische Gliederung der Openclipart-Dateien fehlten. Siehe
Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Im Moment ist es unter Opensuse 13.2 ähnlich schlimm:

Man kann zwar die Openclipart-Pakete herunterladen. Leider bietet aber keines der üblichen Repositories ein Paket an, dass dafür sorgen würde,

  • dass die Verlinkung der Clipart-Verzeichnisse in das zu Libreoffice gehörige “gallery”-Verzeichnis (/usr/lib64/libreoffice/share/gallery/) ordnungsgemäß vorgenommen wird
  • dass die notwendigen deskriptiven Dateien für die Themenfelder der Openclipart-Sammlung bereitgestellt werden.

Üblicherweise gab es hierfür in der Vergangenheit ein Paket namens “libreoffice-openclipart”. Debian und Ubuntu bieten entsprechende, aktuelle “deb”-Pakete nach wie vor an. Bei SuSE ist das entsprechende RPM jedoch verschütt gegangen.

Deshalb sind vielen netten Openclipart-Bilder leider unter Libreoffice auf einem aktuellen Opensuse 13.2-System nicht unmittelbar und nicht ohne Klimmzüge nutzbar. Ich selbst merkte das natürlich auch erst, als ich für eine anstehende Kunden-Präsentation dringend ein paar Cliparts benötigte. Der in meinem früheren Beitrag erwähnte Workaround ist jedoch für die Menge der aktuellen Openclipart-Themenbereiche leider viel zu umständlich. Die alternativ einsetzbare Libreoffice-Erweiterung “openclipart.oxt” , mit der man ggf. Cliparts auch direkt aus dem Internet beziehen kann, finde ich viel zu träge. Man erhält aufgrund der notwendigen Suchvorgänge auch keinen schnellen Überblick. Ferner wird die Erweiterung seit längerem nicht mehr gepflegt. Was also tun ?

Möglicher Workaround
Man kann schlicht auf eine ältere Version aus Opensuse 13.1-Zeiten zurückgreifen. Ich habe mir z.B. aus dem Repository
http://rpmfind.net/linux/opensuse/distribution/13.1/repo/oss/suse/noarch/
die Pakete

  • openclipart-svg-0.18-155.1.2.noarch.rpm
  • openclipart-png-0.18-155.1.2.noarch.rpm
  • libreoffice-openclipart-4.1-2.1.3.noarch.rpm

heruntergeladen und in dieser Reihenfolge zusätzlich zum laufenden Libreoffice 4.3.5 installiert. Die Datei “libreoffice-openclipart-4.1-2.1.3.noarch.rpm” stellt dann wie gewohnt die erforderlichen deskriptiven Dateien bereit.

Danach ist u.U. noch ein wenig Aufräumen angesagt. In meinem Fall war es so, dass es im Verzeichnis “/usr/share/clipart” bereits ein Unterverzeichnis

“/usr/share/clipart/openclipart”

gab. Und zwar aus der früheren Installation der aktuellen Openclipart-Variante, zu denen Opensuse ja leider keine deskriptiven Dateien anbietet. Der Installer hatte die Dateien zur älteren Openclipart-Version 0.18 deshalb unter einem zusätzlichen Verzeichnis:
“/usr/share/clipart/openclipart-0.18”
angelegt. Das verträgt sich jedoch nicht mit den Links der deskriptiven Dateien. Also (als user root oder mit sudo):

mytux:~ # mv /usr/share/clipart/openclipart /usr/share/clipart/openclipart-0.20
mytux:~ # mv /usr/share/clipart/openclipart-0.18 /usr/share/clipart/openclipart

Danach noch checken, dass unter “/usr/lib64/libreoffice/share/gallery” die notwendigen deskriptiven Dateien der Openclipart-Themenbereiche tatsächlich als Links angelegt wurden – man erkennt diese (vielen) Links leicht am führenden ”
openclipart” im Namen. Ferner zur Sicherheit noch folgenden Link prüfen und ggf. ersetzen:

mytux:~ # rm /usr/lib64/libreoffice/share/gallery/clipart
mytux:~ # ln -s /usr/share/clipart/openclipart/ /usr/lib64/libreoffice/share/gallery/clipart

Nun mit dem aktuellen Libreoffice-Writer testen. Bei mir hat dann alles einwandfrei funktioniert. Ich bin damit zwar nicht auf dem neuesten Stand – kann aber wenigstens die Cliparts von Opensuse 13.1 nutzen.

Hoffentlich merkt ein Verantwortlicher bei Opensuse für das aktuelle Libreoffice-Repository bald mal, dass die dortigen Pakete nicht zusammen mit den Openclipart-Dateien funktionieren.

Opensuse 13.2, Subversion – sysconfig File "svnserve" fehlt

Opensuse 13.2 bietet einige Überaschungen und nicht immer positive. So wollte ich kürzlich auf einem neu installierten OS 13.2 einen einfachen Subversion-Server einrichten. Hierzu installierte ich mir die erforderlichen Pakete.

Natürlich unterliegt auch das Programm “svnserve” inzwischen der Kontrolle von systemd. Ein Startup-Skript unter “/etc/init.d” sollte also überflüssig sein und findet sich unter Opensuse 13.2 (im Gegensatz zu OS 13.1) auch nicht mehr.

Leider führte ein versuchsweises Absetzen des Kommandos

systemctl start svnserve.service”<&/p>
zu einem Fehler:

mytux:~ # systemctl start svnserve.service   
Job for svnserve.service failed. See "systemctl status svnserve.service" and "journalctl -xn" for details.
mytux:~ # systemctl status svnserve.service 
svnserve.service - Subversion protocol daemon
   Loaded: loaded (/usr/lib/systemd/system/svnserve.service; enabled)
   Active: failed (Result: resources) since Fri 2015-01-16 11:58:37 CET; 21s ago
  Process: 14949 ExecStart=/usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid $SVNSERVE_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 14950 (code=killed, signal=TERM)

Jan 16 11:54:03 rux svnserve[14949]: DIGEST-MD5 common mech free
Jan 16 11:58:42 rux systemd[1]: svnserve.service failed to run 'start' task: No such file or directory
Jan 16 11:58:42 rux systemd[1]: Failed to start Subversion protocol daemon.
mytux:~ #

Fragt sich, was das fehlende File ist. Dazu muss man in der schönen Welt von “systemd” etwas in der Tiefe graben. Die Antwort findet sich im Verzeichnis “/etc/systemd/system/multi-user.target.wants/”. Dort gibt es einen Link “svnserve.service”, der auf die Datei
“/usr/lib/systemd/system/svnserve.service” verweist. Inhalt:

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/svnserve
User=svn
Group=svn
PIDFile=/var/run/svnserve/svnserve.pid
ExecStart=/usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid $SVNSERVE_OPTIONS

[Install]
WantedBy=multi-user.target

Aha! Es stellt sich also die Frage, ob es das EnvironmentFile, das ich von früheren Opensuse-Versionen sehr gut kenne, im “/etc/sysconfig”-Bereich überhaupt noch findet? Antwort: Leider nein!

Da stimmt also womöglich was nicht mit dem Subversion-Paket. Ein Deinstallieren und Neuinstallieren half aber leider nichts. Eine anschließende Suche im gesamten Filesystem zeigte, das eine geeignete Konfigurationsdatei auch sonst nirgends zu finden war/ist.

Was also tun? Ich habe mir dann einfach ein entsprechendes sysconfig-File “svnserve” aus einer früheren Opensuse 13.1-Installation in das Verzeichnis “/etc/sysconfig” kopiert. In der nicht ganz unberechtigten Annahme, dass das File hoffentlich auch für systemd auswertbar sein würde, wenn es in der systemd-Konfiguration dort als “EnvironmentFile” erwartet wird. Inhalt:

## Path:	/etc/sysconfig/svnserve
## Description:	Basic configuration for svnserve
## Type:	string
## Default	"-d -R -r /srv/svn/repos"
#
# Default options for the svnserve process.
# The -R option enforces read-only access, i.e. write operations to the
# repository (such as commits) will not be allowed.
# Authentication should be configured before allowing write access.
# See http://svnbook.red-bean.com/en/1.8/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth
#
SVNSERVE_OPTIONS="-d -r /projekte/SVNserv"

## Type:	string
## Default	"svn"
#
# svnserve should 
run as unprivileged user.
# If you want to expose the repository via both svnserve and mod_dav_svn
# (Apache httpd) in parallel, ensure that the apache user is part of the
# svn group and the setgid flag is set on the repositories
# usermod -A svn wwwrun
# chmod -R g+s /srv/svn/repos
# See http://svnbook.red-bean.com/en/1.8/svn.serverconfig.multimethod.html
#
SVNSERVE_USERID="svn"

## Type:	string
## Default	"svn"
#
# svnserve should run as unprivileged user.
# If you want to expose the repository via both svnserve and mod_dav_svn
# (Apache httpd) in parallel, ensure that the apache user is part of the
# svn group and the setgid flag is set on the repositories
# usermod -A svn wwwrun
# chmod -R g+s /srv/svn/repos
# See http://svnbook.red-bean.com/en/1.8/svn.serverconfig.multimethod.html
#
SVNSERVE_GROUPID="svn"

Die Directory-Angabe am Ende der Variablen SVNSERVE_OPTIONS bezieht sich auf das Haupt-Repository, das ich auf besagtem System unter “/projekte” angelegt hatte. Diese Angabe muss man natürlich an eigene Verhältnisse anpassen. [Standard wäre unter Opensuse ein Repository namens “svn” im Verzeichnis “/srv/svn/”.]

Und siehe da:

mytux:~ # systemctl status svnserve.service 
svnserve.service - Subversion protocol daemon
   Loaded: loaded (/usr/lib/systemd/system/svnserve.service; enabled)
   Active: active (running) since Fri 2015-01-16 12:00:12 CET; 1h 18min ago
  Process: 15198 ExecStart=/usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid $SVNSERVE_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 15199 (svnserve)
   CGroup: /system.slice/svnserve.service
           └─15199 /usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid -d -r /projekte/SVNserv

Jan 16 12:00:12 rux svnserve[15198]: DIGEST-MD5 common mech free

Hier erkennt man auch, dass systemd beim Start von “svnserve” den Inhalt der Variable SVNSERVE_OPTIONS aus dem EnvironmentFile zieht.

Ich hoffe, das hilft dem einen oder anderen OS 13.2-Umsteiger/Einsteiger weiter.