VMware Workstation WS 11 unter Opensuse Leap 42.1

Habe heute ein Upgrade eines Opensuse 13.1-Systems auf Opensuse Leap 42.1 durchgeführt. Das ging – bis auf einige typische OS 42.1-Probleme, die ich bereits an anderer Stelle in diesem Blog beschrieben habe, ganz gut.

Gestolpert bin ich dann allerdings über ein Problem mit der VMware-Workstation. Die auf dem fraglichen System installierte Version war WS 11.1.0.

Da sich der Kernel gegenüber der Version von 13.1 inzwischen natürlich massiv verändert hatte (aktuelle Leap42.1-Kernelversion 4.1.27), führte der Versuch VMware WS zu starten, zu einer automatisch eingeleiteten Neu-Kompilation der wichtigsten VMware-Module. Dieser Kompilationsversuch scheitert aber leider an dem vmnet-Modul; nachfolgend ein Auszug aus der Log-Datei:

2016-09-26T14:13:52.987+02:00| vthread-4| I120: Successfully extracted the vmnet source.
2016-09-26T14:13:52.987+02:00| vthread-4| I120: Building module with command “/usr/bin/make -j8 -C /tmp/modconfig-jZLoM6/vmnet-only auto-build HEADER_DIR=/lib/modules/4.1.31-30-default/build/include CC=/usr/bin/gcc IS_GCC_3=no”
2016-09-26T14:13:54.615+02:00| vthread-4| W110: Failed to build vmnet. Failed to execute the build command.
….
2016-09-26T14:14:12.914+02:00| vthread-4| I120: Read 17587 symbol versions
2016-09-26T14:14:12.914+02:00| vthread-4| I120: Invoking modinfo on “vmmon”.
2016-09-26T14:14:12.919+02:00| vthread-4| I120: “/sbin/modinfo” exited with status 0.
2016-09-26T14:14:12.919+02:00| vthread-4| I120: Invoking modinfo on “vmnet”.
2016-09-26T14:14:12.924+02:00| vthread-4| I120: “/sbin/modinfo” exited with status 256.
2016-09-26T14:14:13.334+02:00| vthread-4| I120: Setting destination path for vmnet to “/lib/modules/4.1.31-30-default/misc/vmnet.ko”.
2016-09-26T14:14:13.334+02:00| vthread-4| I120: Extracting the vmnet source from “/usr/lib/vmware/modules/source/vmnet.tar”.
2016-09-26T14:14:13.344+02:00| vthread-4| I120: Successfully extracted the vmnet source.
2016-09-26T14:14:13.344+02:00| vthread-4| I120: Building module with command “/usr/bin/make -j8 -C /tmp/modconfig-sDUVWe/vmnet-only auto-build HEADER_DIR=/lib/modules/4.1.31-30-default/build/include CC=/usr/bin/gcc IS_GCC_3=no”
2016-09-26T14:14:14.951+02:00| vthread-4| W110: Failed to build vmnet. Failed to execute the build command.

Dieses Problem lässt sich beheben, ohne gleich für teures Geld auf die WS 12 upgraden zu müssen. Es handelt sich nämlich um einen Fehler, der in einer späteren Version behoben wurde.

Kurz gesagt: Version 11.1.4 der WS runterladen => Installieren => VM-Ware WS auch unter Opensuse Leap 42.1 weiter betreiben !

Open Visual Traceroute, Opensuse Leap 42.1 and sudo – howto – II

In the last article
https://linux-blog.anracom.com/2016/08/16/open-visual-traceroute-opensuse-leap-42-1-and-sudo-howto-i/
of this series I discussed basic steps to get OVT running on an Opensuse Leap 42.1 system. All recipes were based on assigning root rights to the Java-execution of the application’s jar. Root rights were required to perform network packet capturing.

Now, on a multiuser system

  • we want to restrict the access rights to OVT to a group of selected users,
  • we want to improve the startup – such that the selected users do not need to provide the root password.

Note that none of the steps below solves any security problems. It only makes things more convenient.

Change access rights to the OVT files

As in the first article we assume that the OVT-files were placed in a directory “/PATH/TO/OVT” – e.g. “/opt/ovt”.

  • Step 1 – Create a group “ovt” : We create a user group named “ovt” (e.g. with “yast2” or at the commandline with “groupadd”). Then we add the users who later on shall get the privilege to execute “ovtr.sh” – even without giving the root password!
  • Step 2 – Change ownership of “/PATH/TO/OVT” and its subdirectories/files:
    chown -R root.ovt /PATH/TO/OVT
  • Step 3 – Change access rights to “/PATH/TO/OVT” and subdirectories/files:
    chmod -R u+rwx,g+rx-w,o-rwx /PATH/TO/OVT

Changes to /etc/sudoers

We change the file “/etc/sudoers” by using the “visudo” command. (Do NOT edit the “/etc/sudoers”-file directly with an editor – get acquainted with elementary vi-commands if necessary!) I only show options which have an impact on the execution of the “ovtr.sh” file, which starts the OVT Java-program. I do not care about other settings and restrictions in comparison to the standard /etc/sudoers file Opensuse delivers.

  • Step 4 – Add a “Default” definition to the sudoers file:
    Below the last line of existing DEFAULT-definitions in the standard “/etc/sudoers”-file of Opensuse add a line
     
    Defaults!/PATH/TO/OVT/ovtr.sh env_keep += “DISPLAY XAUTHORIZATION XAUTHORITY”
     
    (With the double quotation marks! And, of course, you have to replace /PATH/TO/OVT by the path where you actually installed OVT.) This settings will later allow to keep up the named environment variables (DISPLAY, XAUTHORITY, …) when the command “ovtr.sh” is executed.
  • Step 5 – Add a group related definition to the sudoers file:
    Add a line at the end of your settings for users and groups saying
     
    %ovt ALL = (root) NOPASSWD: /PATH/TO/OVT/ovtr.sh

The last rule guarantees that all members of the group “ovt” can execute

sudo /PATH/TO/OVT/ovtr.sh

without providing the root passsword (or their own password depending on whether Opensuse’s default setting “Defaults targetpw” is kept up in your “sudoers”-file). The first rule preserves the present environment settings of user (member of group “ovt”) regarding DISPLAY and XAUTHORITY, thus enabling the access to the presently open X11-screen.

Simplify the contents of “ovtr.sh”

After the changes described above we only need a small modification to ovtr.sh:

#!/bin/bash
java -Djava.awt.headless=false  -Xmx512m -jar org.leo.
traceroute.jar

 
This is now all that is required!

Let us test it

me@mytux:/opt/ovt> sudo ./ovtr.sh 
12:43:54.768 [main] INFO  org.leo.traceroute.Main - Open Visual Traceroute 1.6.3 
12:43:54.776 [main] INFO  org.leo.traceroute.install.Env - Java run-time version: 1.8.0_101
12:43:54.777 [main] INFO  org.leo.traceroute.install.Env - NASA World Wind Java 2.0 2.0.0
12:43:54.777 [main] INFO  org.leo.traceroute.install.Env - /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
12:43:54.777 [main] INFO  org.leo.traceroute.install.Env - OS:Linux / arch:amd64
Locale en_GB
12:43:57.230 [SwingWorker-pool-1-thread-1] INFO  o.leo.traceroute.core.geo.GeoService - Use geoip db /root/ovtr/GeoLiteCity.dat which is 0 day(s) old
12:43:58.818 [pool-2-thread-1] INFO  o.leo.traceroute.core.ServiceFactory - Try using device eth0 null
12:43:59.056 [pool-2-thread-2] INFO  o.leo.traceroute.core.ServiceFactory - Try using device br0 null
12:43:59.251 [pool-2-thread-3] INFO  o.leo.traceroute.core.ServiceFactory - Try using device virbr_vmw null
12:44:00.389 [pool-2-thread-8] INFO  o.leo.traceroute.core.ServiceFactory - Try using device vmnet1 null
12:44:01.488 [pool-2-thread-9] INFO  o.leo.traceroute.core.ServiceFactory - Try using device virbr1 null
12:44:02.589 [pool-2-thread-10] INFO  o.leo.traceroute.core.ServiceFactory - Try using device virbr2 null
12:44:03.691 [pool-2-thread-11] INFO  o.leo.traceroute.core.ServiceFactory - Try using device vmnet3 null
12:44:04.799 [pool-2-thread-12] INFO  o.leo.traceroute.core.ServiceFactory - Try using device virbr3 null
12:44:05.908 [pool-2-thread-13] INFO  o.leo.traceroute.core.ServiceFactory - Try using device virbr4 null
12:44:07.027 [pool-2-thread-14] INFO  o.leo.traceroute.core.ServiceFactory - Try using device virbr5 null
12:44:08.124 [pool-2-thread-15] INFO  o.leo.traceroute.core.ServiceFactory - Try using device virbr6 null
12:44:09.231 [pool-2-thread-17] INFO  o.leo.traceroute.core.ServiceFactory - Try using device lo null
12:44:11.467 [AWT-EventQueue-0] INFO  org.leo.traceroute.Main - Startup completed in 16704ms

 
ovt6

Great !

Final convenience steps

We eventually add the path of our OVT installation to the system path variable or tell the users of group “ovt” to add it to their environment.
Another way for a user to simplify the OVT startup would be to put a small script “ovsh” in his home directory with just the lines :

#!/bin/bash
sudo /opt/ovt/ovtr.sh

Then he/she may start OVT by executing “ovsh”. The only difference is that we do not need to type the “sudo”.

Security?

In this article we have made the startup of OVT more convenient by using the /etc/sudoers” file. We also restricted access to OVT to members of a group. Still: Java is executed with root rights. This is something I, personally, do not like because of security reasons. The next article, therefore, concentrates on the possibility to start OVT in a chroot jail.

BIMP-Plugin für GIMP unter Opensuse LEAP

Manchmal benötigt man ein Tool, um unter GIMP typische Bild-Manipulations-Operationen wie etwa das Skalieren auf einen Stapel von mehreren ausgewählten Bildern anzuwenden.

Es gibt für das Skalieren oder andere elementare Bildoperationen unter Linux natürlich auch andere Werkzeuge zur Bild-Batchverarbeitung. Gwenview z.B. bietet unter dem Menüpunkt “Module >> Stapelverarbeitung” das Meiste an, was der Normal-Anwender so braucht. Aber warum nicht auch ein einfach zu bedienendes Plugin unter GIMP zur Verfügung haben?

BIMP heißt eine der möglichen Antworten. BIMP ist einfach zu installieren; der Prozess ist unter der Github-Adresse im README.md beschrieben. Man lädt z.B. von Github
https://github.com/alessandrofrancesconi/gimp-plugin-bimp
die gesamte Verzeichnisstruktur als ZIP-file herunter (grüner Knopf rechts oben: “Clone or download”) und expandiert es in ein Verzeichnis seiner Wahl.

Dann mittels eines Terminalfensters (Kommandozeile!) zum Verzeichnis navigieren und dort

make && make install

ausführen. Die Installation der kompilierten Plugin-Dateien erfolgt dann unter dem “/home/USER/gimp-2.8/plug-ins”-Verzeichnis. Eine Installation für alle User muss man dagegen als Root mit

make && sudo make install-admin

in die Wege leiten.

Fehlende Bibliotheken?

Leider klappt das angegebene Rezept auf einer Leap-(x86_64)-Standardinstalltion nicht unmittelbar, wenn man nicht noch weitere Bibliotheken lädt. Die im README angegebenen Bibliotheken gibt es aber unter Opensuse Leap nicht mit der für Ubuntu/Debian gültigen Bezeichnung.

Treten während der Kompilation Fehlermeldungen auf, etwa zu einem nicht gefundenen “gimptool-2.0”, so muss man unter Leap (z.B. mit YaST) vielmehr das RPM-Paket “gimp-devel” laden. Bei anderen Fehlermeldungen ggf. auch noch das Paket “pcre-devel”.
(Ansonsten waren bei mir neben dem “gimp”-Paket installiert “gimp”, “libgimp-2_0-0”, “libgimpui-2_0-0”, “libpcre1”, “libpcre16-0”, “libpcrecpp0”, “libpcreposix0”). Und weitere Bibliotheken, die hier aber nichts zur Sache tun.

Danach läßt sich BIMP kompilieren. Die auftretenden Warnungen habei ich tapfer ignoriert. Anschließend startet man GIMP und öffnet dort das BIMP-Interface über den Menüpunkt “Datei >> Batch Image Manipulation” öffnen. Die Bedienung ist logisch und simpel. Sehr schön ist,

  1. dass man eine Serie von hintereinander geschalteten Bearbeitungsschritten definieren kann
  2. und dass man jede unter GIMP verfügbare Bildverarbeitungsaktion bei Bedarf aus einer Liste verfügbarer Verfahren auswählen und parameterieren kann.

Die Zuordnung einer GIMP-Bildverarbeitungsaktion zu einem definierten Schritt erfolgt über ein Auswahlmenü mit Standardaktionen bzw. dem Punkt “Andere GIMP-Anwendung”.

bimp1
bimp2

Zudem kann man eine Serie von Verarbeitungsschritten auch abspeichern.

Einfach, gut und nützlich! Herzlichen Dank an den Entwickler Alessandro Francesconi!