Grid Autosport ist ein zwar älteres, aber immer noch exzellentes Rennspiel das zwar kein definitiv Arcaderacer ist, einen aber auch nicht mit einem Hardcoresimulationsanspruch erschlägt. Ähnlich wie Gran Tourismo findet es einen exzellenten Mittelweg und ist, im Gegensatz zu diesem, auch auf Linux spielbar. Es eignet sich somit also auch für ein kurzes Rennen in der Mittagspause, was nicht heißt, dass man keine Stunden darin versenken kann. Leider lässt es sich unter openSUSE 42.3 aber nachdem man es per Steam heruntergeladen hat nicht direkt starten.

Das Problem

Nach dem Start rödelt der rechner kurz, es kommt aber kein Spielfenster hoch. Startet man Steam aus einer Konsole, so erscheint dort beim Versuch das Spiel zu starten folgendes:

>>> Adding process 17089 for game ID 255220
>>> Adding process 17089 for game ID 255220Installing breakpad exception handler for appid(steam)/version(1506500000)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: /home/marix/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4)
>>> Adding process 17090 for game ID 255220
/ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/GridAutosport: relocation error: /ephemeral/steam/marix/steamapps/common/GRID Autosport/bin/../lib/x86_64/libcurl.so.4: symbol ENGINE_load_builtin_engines, version OPENSSL_1.0.0 not defined in file libcrypto.so.1.0.0 with link time reference
Game removed: AppID 255220 "GRID Autosport", ProcID 17086

Hier liegt also eine Inkompatibilität zwischen der vom Spiel mitgebrachten Curl-Bibliothek und den von Steam mitgebrachten Bibliotheken SSL und Crypto vor.

Die Lösung aus dem Netz

Beim Googeln findet sich schnell eine Lösung welche vorschlägt libcrypto.so.1.0.0 aus der Steam-Runtime entfernen. Dies löst auch das Problem mit Grid Autosport. Allerdings hat diese Lösung auch Nachteile. Da die Steam-Runtime modifiziert wird ist damit zu rechnen, dass das nächste Steam-Update die Dateien wiederherstellt und man die Datei erneut entfernen muss. Außerdem kann es damit zu Problemen in anderen Spielen kommen welche sich auf die von Steam mitgelieferte Version verlasen.

Die bessere Lösung

Die obige Lösung weißt aber bereits den Weg zu einer besseren Lösung, denn sie funktioniert deshalb, weil openSUSE bereits kompatible Versionen der beiden Bibliotheken enthält. Tatsächlich betrifft dieses Problem einige Spiele welche von Feral Interactive portiert wurden. So ist auch Dirt Rally von diesem Problem betroffen. Für dieses Spiel findet sich eine Lösung welche sich Analog auch auf Grid Autosport anwenden lässt:

1. Ins Spielverzeichnis wechseln: cd <steam library>/steamapps/common/Grid\ Autosport/lib/x86_64.
2. Dort auf die libcrypto des Systems linken:

   > ln -s /lib64/libcrypto.so.1.0.0
   > ln -s /lib64/libssl.so.1.0.0
   

Diese Lösung ist besser, weil sie nur das einzelne Spiel betrifft und nicht global die Steam-Runtime beschädigt. Sie hat allerdings den Nachteil, dass sie kaputt gehen kann falls Steam mal die Dateien anfasst, z.B. bei einem Update. Updates von Grid Autosport sind aber deutlich seltener als solche von Steam selbst, und auf meinem System hat der Fix auch schon einige Patches überlebt.

openSUSE Tumbleweed enthält jetzt zwei neue Pakete welche ich erstellt habe: python-emoji und python-ntfy. Ersteres hat es sogar noch in openSUSE Leap 15.0 geschafft.

Die Funktionalität von python-emoji ist schnell erklärt und trotzdem unglaublich nützlich, wie diese leichte Abwandlung des Beispiels aus der Paketbeschreibung auf PyPI zeigt:

>> import emoji
>> print(emoji.emojize('Python ist :thumbs_up:'))
Python ist 👍

Natürlich funktioniert dies sowohl in modernem Python als auch in klassischem Python.

Eines der Pakete welche von python-emoji profitieren ist python-ntfy. python-ntfy ermöglichte es aus der Konsole Benachritigungen zu verschicken. Diese können entweder auf der Arbeitsfläche angezeigt werden, oder über verschiedene Backends an ein Smartphone weitergeleitet werden. Allerdings sind momentan noch nicht Backends auch für openSUSE paketiert. Besonders praktisch ist der Befehl ntfy done. Nutzt man diesen um einen lange laufenden Prozess zu starten, so bekommt man, sobald dieser fertig ist, eine Nachricht welche auch über Erfolg oder Misserfolg und die Laufzeit des Prozesses informiert. Man kann sich also ganz gemütlich in die Hängematte legen während der Rechner ackert. 😉

Ich bin kein Dichter, und vor allem ist dies vermutlich für niemanden in irgendeiner Art besonders wertvoll, doch das ist ohnehin nicht das, was es sein soll. Es ist in egoistischer Weise allein für mich, denn die Person, die ich hiermit anspreche, wird es niemals lesen können.

Nichts desto trotz, Dad, da ich dich leider nicht einfach anrufen kann, um Dir zu gratulieren, wärst Du trotz allem heute 69 Jahre alt geworden, hätten wir dich nicht schon vor so vielen Jahren an den Dämon des Namens...

2018 beginnt mit einem großen Sicherheits-Bug auf Chip-Level, der aktuell Schlagzeilen macht und von Google-Forschern schon im Juni 2017 gefunden und veröffentlicht wurde.

Der Grund dafür, dass dieses Thema aktuell so heiß in den Medien diskutiert wird ist, dass dies ein signifikanter Bug auf Chip-Level ist, der alle modernen Intel CPUs der letzten Dekade und damit Millionen oder gar Milliarden Computer betrifft - und damit auch große Cloud-Anbieter wie Google, Microsoft, Amazon und auch alle...

Der Raspberry Pi 2 ist ein praktischer kleiner Rechner, und das dafür vorgesehene Raspbian auch eine gut gemachte Linux-Distribution. Hat man allerdings schon auf mehreren Rechner openSUSE im Einsatz ist es viel attraktiver dieses auch dort zu verwenden, zumal dies völlig problemlos möglich ist. Der Einsatz von Tumbleweed auf dem Raspberry Pi 2 ist im Wiki von openSUSE detailliert dokumentiert. Mit wenigen kleinen Änderungen lässt sich so auch openSUSE Leap auf dem Raspberry Pi 2 nutzen, und zwar ohne an diesen Monitor oder Maus anschließen zu müssen.

Die Installation eines Betriebssystem auf dem Raspberry PI erfolgt stets dadurch den passenden Installer auf seine SD-Karte zu kopieren. Beim ersten Start wird diese dann passend eingerichtet. Die passende Datei für openSUSE Leap 42.3 findet sich auf http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/. Für den Betrieb ohne Tastatur und Monitor bietet sich die Variante Just enough OS (JeOS) an. Damit findet man die passende Datei indem man die Downloadseite nach JeOS-raspberrypi2 durchsucht. Aktuell ist dies http://download.opensuse.org/ports/armv7hl/distribution/leap/42.3/appliances/openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l.raw.xz. Es empfiehlt sich auch die Prüfsumme zu checken.

> sha256sum -c openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz.sha256
openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz: OK
sha256sum: WARNUNG: 14 Zeilen sind nicht korrekt formatiert

Die Warnung zu den nicht formatierten Zeilen liegt daran, dass der Inhalt mit PGP signiert ist. Die Signatur lässt sich mit GPG prüfen.

> gpg --verify openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz.sha256
gpg: Signatur vom Mi 26 Jul 2017 19:39:17 CEST mittels RSA-Schlüssel ID 3DBDC284
gpg: Korrekte Signatur von "openSUSE Project Signing Key <opensuse@opensuse.org>" [vollständig]
note: random_seed file not updated

Jetzt wo klar ist, dass das Image nicht beschädigt ist, kann man der Anleitung für Tumbleweed im openSUSE-Wiki folgen.

Achtung! Das Schreiben auf die SD-Karte kann, wenn man den falschen Gerätebezeichner erwischt, Daten auf einer anderen Platte zerstören. Wenn man sich nicht 100% sicher ist welchen Gerätebezeichner die SD-Karte hat, dann kann man direkt nach dem Einstecken in dmesg nachsehen, welchen Bezeichner die Karte bekommen hat. In meinem Beispiel hat der Kartenleser mehrere Einschübe, so dass gleich mehrere Geräte auftauchen, aber nur für das Gerät mit der SD-Karte wird die Kapazität (sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)) und die Partitionsliste (sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3) ausgegeben.

> dmesg | tail -n 30
[13801.698740] EXT4-fs error (device sdi6): htree_dirblock_to_tree:986: inode #2: block 8582: comm dolphin: bad entry in directory: directory entry across range - offset=0(0), inode=4489218, rec_len=32780, name_len=129
[13814.445903] sdi: detected capacity change from 8026849280 to 0
[13897.279227] sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)
[13897.285959]  sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3
[14939.444590] usb 2-6: USB disconnect, device number 2
[37767.485975] usb 2-6: new SuperSpeed USB device number 3 using xhci_hcd
[37767.532474] usb 2-6: New USB device found, idVendor=8564, idProduct=4000
[37767.532478] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37767.532479] usb 2-6: Product: USB3.0 Card Reader
[37767.532479] usb 2-6: Manufacturer: Realtek
[37767.532480] usb 2-6: SerialNumber: 201412031053
[37767.539943] usb-storage 2-6:1.0: USB Mass Storage device detected
[37767.546235] scsi host8: usb-storage 2-6:1.0
[37768.558079] scsi 8:0:0:0: Direct-Access     Generic- USB3.0 CRW    -0 1.00 PQ: 0 ANSI: 6
[37768.558355] sd 8:0:0:0: Attached scsi generic sg6 type 0
[37768.569622] scsi 8:0:0:1: Direct-Access     Generic- USB3.0 CRW    -1 1.00 PQ: 0 ANSI: 6
[37768.569862] sd 8:0:0:1: Attached scsi generic sg7 type 0
[37768.582535] scsi 8:0:0:2: Direct-Access     Generic- USB3.0 CRW    -2 1.00 PQ: 0 ANSI: 6
[37768.582758] sd 8:0:0:2: Attached scsi generic sg8 type 0
[37768.601427] scsi 8:0:0:3: Direct-Access     Generic- USB3.0 CRW    -3 1.00 PQ: 0 ANSI: 6
[37768.601678] sd 8:0:0:3: Attached scsi generic sg9 type 0
[37769.473299] sd 8:0:0:3: [sdi] 15677440 512-byte logical blocks: (8.03 GB/7.48 GiB)
[37769.473958] sd 8:0:0:0: [sdf] Attached SCSI removable disk
[37769.475113] sd 8:0:0:3: [sdi] Write Protect is off
[37769.475116] sd 8:0:0:3: [sdi] Mode Sense: 2f 00 00 00
[37769.475608] sd 8:0:0:1: [sdg] Attached SCSI removable disk
[37769.477768] sd 8:0:0:3: [sdi] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[37769.478227] sd 8:0:0:2: [sdh] Attached SCSI removable disk
[37769.484922]  sdi: sdi1 sdi2 < sdi5 sdi6 > sdi3
[37769.488248] sd 8:0:0:3: [sdi] Attached SCSI removable disk

Um das Image auf die Karte zu schreiben benötigt man Root-Rechte. Das Gerät muss von /dev/sdX auf den korrekten Bezeichner angepasst werden. Für obiges Beispiel /dev/sdi.

> sudo -s
# xzcat openSUSE-Leap42.3-ARM-JeOS-raspberrypi2.armv7l-2017.07.26-Build1.1.raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct
328+1 records in
328+1 records out
1377828864 bytes (1.4 GB, 1.3 GiB) copied, 147.571 s, 9.3 MB/s
# sync

Hierbei passiert folgendes:

1. xzcat entpackt das Image auf die Standardausgabe.
2. dd übernimmt über die Standardeingabe das entpackte Image und schreibt es 1:1 auf das angegebene Gerät, und zwar ohne zu Puffern.
3. sync stellt sicher, dass alle Daten auch wirklich geschrieben wurden und die Karte sicher entnommen werden kann.

Anschließend kann man den Raspberry Pi 2 mit den üblichen Schritten in Betrieb nehmen:

1. Karte herausnehmen und in den Pi stecken,
2. Netzwerk an den Raspberry Pi 2 anschließen,
3. und dann Strom auf Pi geben.

Der initiale Start kann einige Zeit dauern. Bei mir waren dies gut anderthalb Stunden, mit einer schnelleren SD-Karte kann man hier aber Zeit sparen.

Hat man keinen Monitor am Raspberry Pi 2, so steht man nun vor der Herausforderung dessen Netzwerkadresse herauszufinden um sich mit dem zu verbinden. Prinzipiell kann man diese herausfinden indem man nach dem letzten Gerät schaut, dass sich am Router angemeldet hat. Löst der Router auch die von den Rechnern selbst gewählten Namen auf, so ist es sogar noch einfacher, da sich ein frisches openSUSE immer mit dem Rechnernamen linux meldet. An einer Fritz!Box ist er deshalb als linux.fritz.box erreichbar.

Nun kann man sich also das erste mal anmelden. Der Nutzer ist root und das Passwort linux. Hat man eine Fritz!Box also: ssh root@linux.fritz.box. Beim ersten Anmelden sollte man gleich noch die Inbetriebnahme das Basissystems abschließen:

• Das Passwort ändern,
• dem eigenen SSH-Key per ssh-copy-id auf dem Raspberry Pi Berechtigung zum Anmelden geben,
• Updates einspielen,
• und den Hostnamen ändern.

Letzterer Schritt ist wichtig, da es sonst bei Inbetriebnahme eines weiteren Raspberry Pi zu kollisionen kommen kann und man sich unnötig die Auflösung der Netzwerkadresse des neuen Systems erschwert.

Das Just enough in JeOS ist übrigens durchaus ernst gemeint. Wer sein System anschließend mit Ansible weiter einrichten möchte sollte dort noch Python komplett installieren: zypper in python3. Ohne diesen Schritt kann es zu kuriosen Fehlermeldungen kommen, da Teile der Standardbibliothek in der minimalen Installation von Python fehlen.

There is this old quote from LKML:

Get back there in front of the computer NOW. Christmas can wait.
[Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel]

The AppArmor developers followed this advise - John released AppArmor 2.12 yesterday (Dec 25), and I just submitted updated packages to openSUSE Tumbleweed (SR 560017).

The most visible changes in 2.12 are support for "owner" rules in aa-logprof and upstreaming of the aa-logprof --json interface (used by YaST). Of course that's only the tip of the christmas cookie ;-) - see the Release Notes for all details.

One important change in the openSUSE packages is that I intentionally broke "systemctl stop apparmor". The reason for this is "systemctl restart apparmor" - systemd maps this to stop, followed by start. This resulted in unloading all AppArmor profiles by the "stop" part and, even if they get loaded again a second later, running processes will stay unconfined unless you restart them. The systemd developers were unwilling to implement the proposed ExecRestart= option for unit files, therefore breaking "stop" is the best thing I can do. (See boo#996520 and boo#853019 for more details.)

"systemctl reload apparmor" will continue to work and is still the recommended way to reload the AppArmor profiles, but accidently typing "restart" instead of "reload" can easily happen. Therefore I chose to break "stop" - that's annoying, but more secure than accidently removing the AppArmor confinement from running processes.

If you really want to unload all AppArmor profiles, you can use the new "aa-teardown" command which does what "systemctl stop apparmor" did before - but who would do that? ;-)

Note that the above (except the recommendation to use "reload") only applies to Tumbleweed and Leap 15.

Solch ein Problem sollte bei einem wirklichen Könner der Computer Technologie nicht passieren, but unglücklicherweise sind wir alle nur Menschen. Das ist der Grund, warum ich versehentlich die EFI Boot Partition reformatierte, als ich Fedora 26 letztens installierte. Und deshalb hier also nun, wie man die Windows Daten auf der EFI Boot Partition wiederherstellt.

Voraussetzungen

Du brauchst

• einen Windows (10) USB-Stick oder eine Installations-DVD,
• und Deine EFI Boot Partition sollte in...

Die Beta für PC läuft noch bis zum 2. Oktober 2017, wer also noch einen Blick auf das neue Call of Duty werfen möchte, genauer gesagt den Multiplayer-Part, der muss sich nun beeilen. Für alle die es noch nicht haben und lieber ein paar Zeilen darüber lesen möchten, anstatt sich direkt selbst in die Multiplayer-Schlacht zu werfen, hier also meine erste Einschätzung.

Open Beta

Über Steam läuft seit dem 29. Oktober 2017 die Open Beta zu Call of Duty: WWII. Das Spiel wurde heiß ersehnt und scho...

Ein Traum wird wahr; ein Smartphone mit dem Fokus auf Sicherheit und Privatsphäre, das komplett auf Open Source Technologie basiert.

Das ist, was das Purism Librem 5 geplant wurde zu werden: das erste Smartphone vollständig aufgebaut auf Open Source Software und Open Source kopatibler Hardware. Zuletzt erhielt das Projekt eine Menge Aufmerksamkeit als KDE und GNOME eine Partnerschaft mit Purism bekannt gaben, um das Librem 5 und dessen Entwicklung zu unterstützen.

Da die Fund-Raising-C...

Wer das Handling von Tätigkeiten mit Administratorenrechten (“Root”) wie ich aus der Debian-Welt gewohnt ist, wird mit openSUSE zu Anfang so seine Schwierigkeiten haben. Mit zwei Benutzern geht es noch, da man ja das selbe Passwort sowohl für den User als auch für Root einstellen kann. Aber spätestens bei mehr Nutzerkonten ist damit schon Schluss, außer man gibt das Root-Passwort an alle weiter. Beide Lösungen sind sicher irgendwie praktikabel, aber schön ist das alles nicht. Vor allem weil ja eigentlich sudo installiert wäre – aber nur so halbgar genutzt wird.

Also habe ich mal bei meiner aktuellen openSUSE Tumbleweed daran gemacht, dem System ein vernünftiges sudo-Konzept beizubringen und dieses dann auch für YaST anzuwenden. Das war etwas fieselig herauszufinden, hat am Ende aber gut funktioniert.

Los geht’s!

visudo

Standardmäßig fragt sudo nach dem Root-Passwort. Das ist ziemlich unsinnig, also ändern wir es!

1. Im ersten Teil arbeiten wir noch als normaler Benutzer. Die Zeilenangaben können abweichen, je nach Alter der Datei/Systemversion und vorherigen Änderungen daran.
   

   sudo visudo

2. Die Parameter in Zeile 43 beginnend mit env_keep = “LANG… ergänzt du am Ende innerhalb der Anführungszeichen mit:
   

   DISPLAY XAUTHORITY

3. Die Zeilen 68 und 69 kommentierst du komplett aus, damit nicht mehr das Passwort des “Zielusers” abgefragt wird:
   

   #Defaults       targetpw
   #ALL    ALL = (ALL) ALL

4. Zusätzlich kommentierst du Zeile 81 ein, löschst also das Kommentarzeichen # weg:
   

   %wheel ALL=(ALL) ALL

5. Speichern, schließen und dann deine(n) Benutzer entweder über YaST oder direkt im Terminal der Gruppe “wheel” hinzufügen:
   

   gpasswd -a <dein-username> wheel

   Durch Aus- und wieder Einloggen wird die Änderung dann auch übernommen und sudo möchte ab sofort im Terminal immer dein Benutzerpasswort haben.

YaST

Für die grafische Version von YaST wird PolicyKit zur Authentifizierung genutzt, hier ist noch etwas mehr Arbeit nötig. Ab hier arbeitest du als root, wechsle also mit su – den Account.

1. Erstelle eine PolicyKit Action für YaST
   

   vim /usr/share/polkit-1/actions/org.opensuse.pkexec.yast2.policy

2. Folgenden XML-Block fügst du in die Datei ein. Achte dabei bitte auf Zeilenumbrüche beim Kopieren/Einfügen.
   

   <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
   <policyconfig>
   
     <action id="org.opensuse.pkexec.yast2">
       <message>Authentication is required to run YaST2</message>
       <icon_name>yast2</icon_name>
       <defaults>
         <allow_any>auth_self</allow_any>
         <allow_inactive>auth_self</allow_inactive>
         <allow_active>auth_self</allow_active>
       </defaults>
       <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/yast2</annotate>
       <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
     </action>
   
   </policyconfig>

   Speichern, schließen – der Erfolg lässt sich als regulärer Benutzer mit pkexec /usr/sbin/yast2 überprüfen.

3. Die vorgegebene Rechte-Konfiguration sicherst du und ersetzt sie durch die System-Konfiguration. Unsere Datei wird bei einem Upgrade übrigens nicht überschrieben.
   

   mv /etc/polkit-default-privs.local /etc/polkit-default-privs.local.bkup
   cp /etc/polkit-default-privs.standard /etc/polkit-default-privs.local

   Die nötige Anpassung ist überall auth_admin durch auth_self zu ersetzen. Du kannst das auch von Hand machen, mit sed geht das aber bequemer und schneller:
   

   sed -i 's/auth_admin/auth_self/g' /etc/polkit-default-privs.local

4. Damit die Authentifizierung über PolicyKit auch funktioniert, erstellst du ein kurzes Shellscript das künftig als Umweg aus dem Menü aufgerufen wird:
   

   vim /usr/local/sbin/yast2_polkit

5. Das Script sieht wie folgt aus, einfach in die Datei yast2_polkit einfügen:
   

   #!/bin/bash
   
   if [ $(which pkexec) ]; then
           pkexec --disable-internal-agent "/usr/sbin/yast2" "$@"
   else
           /usr/sbin/yast2 "$@"
   fi

6. Speichern und schließen. Abschließend machst du das Script noch ausführbar:

   chmod +x /usr/local/sbin/yast2_polkit

7. Als letztes erstellst du eine .desktop Datei. Damit erscheint der modifizierte YaST-Starter direkt im Hauptmenü und das systemweit für alle Benutzer. Beispielsweise wird er bei Xfce unter “Einstellungen” gelistet. Andere Desktops habe ich nicht getestet, gehe aber davon aus dass der Starter an einer sinnvollen Stelle landet da er ja nur eine angepasste Kopie des Originals ist.
   Natürlich könntest du auch die originale Datei für YaST (YaST.desktop) bearbeiten aber die wird bei einem Upgrade überschrieben. Und eine Kopie in /usr/local/share/applications ignorieren sowohl das Anwendungs- als auch das Whiskermenü.
   Also:
   

   vim /usr/share/applications/YaST2.desktop

8. Einfügen und speichern:
   

   [Desktop Entry]
   X-SuSE-translate=true
   Type=Application
   Categories=Settings;System;X-SuSE-Core-System;X-SuSE-ControlCenter-System;X-GNOME-SystemSettings;
   Name=YaST2
   Icon=yast
   GenericName=Administrator Settings
   Exec=/usr/local/sbin/yast2_polkit
   Encoding=UTF-8
   Comment=Manage system-wide settings
   Comment[DE]=Systemweite administrative Einstellungen
   NoDisplay=false

Das ist alles. Damit ist ein Login als Root nicht mehr nötig bzw. kann bequem über sudo su – mit deinem Benutzerpasswort erfolgen. Ob das Konzept von openSUSE jetzt schlechter oder besser ist, mag ich nicht entscheiden. Das ist Geschmackssache, denke ich.
Was mir auf jeden Fall gut gefallen hat, ist die klare Einhaltung von Standards. Das macht die Suche nach Lösungen deutlich leichter und schneller. Ich konnte dank guter Dokumentation und hilfreichen Forenbeiträgen alles innerhalb von rund einer Stunde fertigstellen – und das große Kenntnisse von PolicyKit!