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...

Well it’s been many many years and many many releases that we’ve been carrying a large number of patches for the cloud-init package in openSUSE and SUSE Linux Enterprise. I remember the first semi serious implementation of SLES support happened when I worked with HP to get SLES into the HP Public Cloud offering, which was based on OpenStack. The offer was eventually named Helion Public Cloud and then eventually shut down. Yes, it’s been many many years and I have received many questions about when is SUSE support going to be upstreamed, and my answer was always, “when I get around to it“. Well, it finally happened, in big part thanks to the cloud-init summit which was held for the first time earlier this year. Google in Seattle was a great host and I very much appreciate that I was invited.

Anyway, long story short spending some face time with other contributors and working out the kinks that existed in the pipeline worked wonders.  Rather than sending a small patch here and there the main implementation for openSUSE and SLE, lots of code, were accepted shortly after the cloud-init summit and over the last couple of days another couple of patches took us another step forward.

There are a few more loose ends that need work but with 17 patches removed from the package build, currently building in Cloud:Tools:Next in OBS we’ve made major progress.

Well, I for one am happy about this, and those that want to install from source can do so and have openSUSE and SLE support working from the upstream sources and not just from the packages included with openSUSE and SLE.

Thanks to Canonical for organizing the summit to get everyone together and thanks to Google for hosting the summit.

Oh and before I forget, getting the changes accepted was not the only major step forward, openSUSE Leap 42.3 will, in the not too distant future, like in the next couple of days, be integrated into cloud-init testing using containers the lxd project builds, go figure who knew these even existed.

I had to apply a fix for a FCoE module in YaST, and I had no idea.

After learning a couple of things I still only have a vague idea, but I am writing it down to help my future self, my team mates, and perhaps you too.

FCoE stands for "Fibre channel over Ethernet". Apparently if you have some disk on a Fibre Channel SAN (storage area network), you can use FCoE to extend the reachability of that disk to the ethernet parts of your network. It still needs to be a kind of special ethernet (10Gb, with special network cards) but that seems less special than FC hardware.

For a better overview, including a diagram, see: SUSE Linux Enterprise Server Documentation / Storage Administration Guide / Fibre Channel Storage over Ethernet Networks: FCoE.

FCoE typically uses a virtual LAN, (VLAN, IEEE 802.1Q).

There needs to be a Fibre Channel Forwarder (FCF) between the FC and ethernet parts. It has a MAC address. Note a difference from iSCSI which works on the IP level, one layer up.

YaST helps you set things up. The rest of this article could be useful if you cannot use YaST for some reason.

SLES uses open-fcoe. On SLES-12 the package is called fcoe-utils.

fipvlan (stands for FCoE Initialization Protocol VLAN discovery) shows FCFs and which interface and VLAN they are reachable with:

# fipvlan --auto
Fibre Channel Forwarders Discovered
interface       | VLAN | FCF MAC
------------------------------------------
eth1            | 500  | 00:0d:ec:b3:ca:00

It can also --create the VLAN interface and --start up the FCoE connection, but it won't make that permanent for the next boot

To make it permanent you need to

1. enable the FCoE service (SLE11:/etc/init.d/boot.fcoe, SLE12: fcoe.service). Under the hood it uses two programs: fcoemon is the daemon, fcoeadm is a front end (fcoeadm -p shows the pid of fcoemon).
2. write a config file, /etc/fcoe/cfg-*IFACE*, where IFACE is
   • eth1.500 if AUTO_VLAN is no; in this case, you also need /etc/sysconfig/network/ifcfg-eth1.500, see man ifcfg-vlan.
   • eth1 if AUTO_VLAN is yes; in this case, the interface is named eth1.500-fcoe. Note the unusual -fcoe suffix!

With the config files in place, rcfcoe start (and ifup eth1.500, unless AUTO_VLAN). Then you should see the disk devices:

# fcoeadm --target
    Interface:        eth1.500
    Roles:            FCP Target
    Node Name:        0x50060160BB600160
    Port Name:        0x500601663B600160
    Target ID:        0
    MaxFrameSize:     2048
    OS Device Name:   rport-2:0-2
    FC-ID (Port ID):  0x710D00
    State:            Online

    LUN ID  Device Name   Capacity   Block Size  Description
    ------  -----------  ----------  ----------  ----------------------------
         0  /dev/sdb      16.00 GiB      512     DGC VRAID (rev 0430)
[...]

People who actually know their way around FCoE will note that I have omitted many important details. Let me know in the comments whether I should come back to this and expand on some topics.

If you are used to handling activities with administrator rights (“root”) like I am from the Debian world, you will have some difficulties with openSUSE in the beginning. With two users it is still possible, because you can set the same password for both user and root. But at the latest with more user accounts this is already over, unless you give the root password to everyone. Both solutions are certainly somehow practicable, but it’s not very nice. Especially since sudo would actually be installed – but only halfway through.

So I started with my current openSUSE Tumbleweed to teach the system a reasonable sudo concept and then apply it to YaST. It was a bit nasty to find out, but in the end it worked well.

Let’s go!

visudo

By default sudo asks for the root password. This is pretty nonsensical, so let’s change it!

1. In the first part we still work as normal users. The line details may vary depending on the age of the file/system version and previous changes to it.
   

   sudo visudo

2. The parameters in line 43 starting with env_keep = “LANG… at the end within the quotation marks:
   

   DISPLAY XAUTHORITY

3. Comment out lines 68 and 69 completely, so that the password of the “target user” is no longer requested:
   

   #Defaults       targetpw
   #ALL    ALL = (ALL) ALL

4. Additionally you uncomment line 81, so delete the comment character #:
   

   %wheel ALL=(ALL) ALL

5. Save, close and then add your user(s) to the group “wheel” either via YaST or directly in the terminal:
   

   gpasswd -a <dein-username> wheel

   By logging out and in again, the change will be applied and sudo wants to have your user password in the terminal from now on.

YaST

For the graphical version of YaST, PolicyKit is used for authentication, a little more work is needed here. From here on, you work as root, so change the account with su –.

1. Create a PolicyKit Action for YaST
   

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

2. Insert the following XML block into the file. Please pay attention to line breaks when copying/pasting.
   

   <?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>

   Save, close – the success can be checked as a regular user with pkexec /usr/sbin/yast2.

3. Save the default rights configuration and replace it with the system configuration. Our file will not be overwritten during an upgrade.
   

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

   The necessary adjustment is to replace auth_admin with auth_self everywhere. You can also do this by hand, but with sed it is more convenient and faster:
   

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

4. To make the authentication via PolicyKit work, create a short shell script that will be called from the menu in the future:
   

   vim /usr/local/sbin/yast2_polkit

5. The script looks like this, just add it to the yast2_polkit file:
   

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

6. Save and close. Finally you make the script executable:

   chmod +x /usr/local/sbin/yast2_polkit

7. Finally, you create a .desktop file. This will make the modified YaST starter appear directly in the main menu, system-wide for all users. For example, in Xfce it is listed under “Settings”. I have not tested other desktops, but I assume that the starter will end up in a useful place, since it is only a customized copy of the original.
   Of course you could also edit the original file for YaST (YaST.desktop) but it will be overwritten during an upgrade. And a copy in /usr/local/share/applications ignores both the application and whisker menus.
   So:

   vim /usr/share/applications/YaST2.desktop

8. Insert and save:
   

   [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

That’s all. With this, a login as root is no longer necessary or can be done comfortably via sudo su – with your user password. Whether the concept of openSUSE is now worse or better, I don’t want to decide. That is a matter of taste, I think.
What I liked in any case is the clear adherence to standards. This makes finding solutions much easier and faster. Thanks to good documentation and helpful forum posts I was able to finish everything within about an hour – and the great knowledge of PolicyKit!

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!