Der schusselige WLAN-Client

Das Lenovo Thinkpad E470 ist ein wunderbarer Laptop und openSUSE Leap funktioniert darauf hervorragend, wäre da nicht ein kleines Problem mit dem WLAN: Der Laptop ist etwas schusselig was das Passwort für das WLAN angeht. Immer wieder scheint er es zu vergessen und fragt per Dialog nach. Scheinbar scheint er einen dann aber nicht zu verstehen, und fragt immer wieder. Gibt man aber erst einmal auf, bricht den Verbindungsversuch ab und bittet ihn kurz darauf nochmal die Verbindung aufzubauen, so erinnert er sich plötzlich und verbindet sich ohne weitere Nachfragen.

KDE fragt per Dialog nach einem Passwort fürs WLAN

Beim Versuch dem Problem auf den Grund zu gehen stellte ich schnell fest, dass es offensichtlich nicht am seit vielen Jahren immer wieder migrierten Nutzer liegt, denn das Problem tritt auch für einen neuen Nutzer auf. Es ist aber auch nie zu hundert Prozent zuverlässig reproduzierbar, was die Fehlersuche zusätzlich erschwert. So dachte ich zunächst, dass es eventuell mit der Initialisierung der Hardware zu hat, da es sehr häufig nach einem Neustart des Rechners auftauchte. Auch trat das Problem eigentlich immer nur bei einem automatischen Verbindungsaufbau auf, also z.B. wenn das Netzwerk komplett deaktiviert wurde. War die WLAN-Hardware hingegen ohne aufgebaute Verbindung aktiv und ich wählte das Netzwerk über das Netzwerkapplet von KDE aus, so verband sich der Rechner zuverlässig. Allerdings habe ich das Problem aber nie nach einem Suspend beobachtet, was diese Theorie zumindest unwahrscheinlicher machte.

Eine Nachfrage auf der Mailingliste von openSUSE brachte mich dann mit einem Verweis auf eine Diskussion auf der deutschsprachigen Liste auf die Lösung des Problems: Anscheinend verursacht die MAC address randomization das Problem. Seit jene abgeschaltet ist trat das Problem nicht mehr auf.

Ein einfacher weg die MAC address randomization abzuschalten findet sich auf https://blog.muench-johannes.de/networkmanager-disable-mac-randomization-314. Es ist lediglich die Datei /etc/NetworkManager/conf.d/100-disable-wifi-mac-randomization.conf mit folgendem Inhalt anzulegen:

[connection]
wifi.mac-address-randomization=1

[device]
wifi.scan-rand-mac-address=no

Wieso dieses Vorgehen in einem Netzwerk ohne MAC-Adressen-Filter notwendig sein sollte ist mir zwar schleierhaft, aber solange es hilft…

Die randomisierten MAC-Adressen zu deaktivieren hat natürlich eine Auswirkung auf die Privatsphäre. Da dieser Rechner aber ausschließlich zuhause oder bei öffentlichen Auftritten genutzt wird ist dies in diesem Fall verschmerzbar.

Sunday

26 January, 2020

Kandidatur für das openSUSE Board #2: Neue Leute an Bord holen

Anknüpfend an die Fragen von Gerald stellte Ariez J. Vachha nun eine weitere Frage an die Kandidaten.

Ein Hinweis: Fragen und Antworten sind ursprünglich auf Englisch. Dies ist nur eine Übersetzung.

Ich würde gerne wissen, wie die Kandidaten es denjenigen, die sich beteiligen wollen, vor allem den Nicht-Programmierern, leichter machen wollen das auch tun zu können.

Danke, dass du diese Frage stellst, denn sie berührt ein (wenn nicht gar das) entscheidende Thema für openSUSE als Gemeinschaft in der nahen Zukunft.

Ich möchte meine Ansicht dazu an einem einfachen Beispiel veranschaulichen:
Wenn man opensuse.org besucht, gibt es oben rechts einen Menüpunkt namens “Mitarbeiten”. Ein Klick darauf bringt dich zum Teil der Seite über Beiträge. Dort hat man die Wahl zwischen zwei Dingen: Code und Hardware. Wenn wir Glück haben, klickt ein potenzieller Beitragender auf “Code” und bekommt vier leicht unmotivierte Textzeilen und eine Schaltfläche “mehr herausfinden” präsentiert. So kann man nicht freundlich und einladend sein. Hoffen wir, dass nicht zu viele Leute dadurch abgeschreckt werden.

Aber was ich als ein weitaus größeres Problem sehe – und eine Art Grundmuster in oS – ist, dass sich hinter dem “Finden Sie es heraus…”-Knopf in der Tat wirklich gute und detaillierte Informationen darüber befinden, wie man einen Beitrag leisten kann. Dokumentation, Tests, Übersetzungen und so weiter ist alles da. Aber es wird nicht in einer vernünftigen Weise kommuniziert! Es ist an verschiedenen Orten versteckt, tief im Wiki vergraben. Das Wiki ist ein guter Ort für ausführliche schriftliche Erklärungen, aber nicht, um einen ersten Schritt in den Pool zu machen.

Meine Idee ist also Teil einer ganzen noch zu definierenden Umstrukturierung von opensuse.org. Ich habe vor einer Weile einige Gedanken vorgeschlagen, wurde aber aufgrund der damaligen Umbenennungs-/Umbenennungsdiskussion gebremst. Dennoch habe ich diese Dinge immer noch auf meiner Liste, die ich diskutieren und in Angriff nehmen möchte. [1]

Natürlich ist die Website nur ein Puzzleteil. Das ganze “frisches Blut bekommen” (wie Du es nennst) muss weiter vorangetrieben werden. Daher die Initiative des Marketing-Teams, spezielle T-Shirts für Leap 15.2 Betatester zu beschaffen. [2]
Dies ist etwas, das leicht nach außen kommuniziert werden kann und ein Türöffner für neue Menschen sein kann. Allerdings ist es dort nicht die Aufgabe eines Board-Mitglieds. Aber ich denke, es ist gut, wenn sich das Board an dieser ganzen Kommunikationsinitiative beteiligt.

Du hast weitere Fragen? Schreib mir!

[1] https://lists.opensuse.org/opensuse-project/2019-06/msg00195.html
[2] https://en.opensuse.org/openSUSE:Marketing_meeting:2020-01-08#1.3_Leap_15.2_Beta:_Promote_beta_testing

Kandidatur für das openSUSE Board #2: Fragen und Antworten

Bereits Anfang 2019 habe ich für das Board von openSUSE kandidiert. Nachdem inzwischen wieder zwei Plätze offen sind, stehe ich auch diesmal wieder für die Aufgabe zur Verfügung und stelle mich zur Wahl.

Einen allgemeinen Überblick über meine Vorstellungen und Ziele gibt es hier.

Im Vorfeld zur Wahl stehen alle Kandidaten der Community natürlich für Fragen offen. Einen Katalog aus 5 Fragen von Gerald Pfeifer, derzeit Chairman des Boards, habe ich beantwortet und möchte diesen auch hier bereitstellen.

Ein Hinweis: Fragen und Antworten sind ursprünglich auf Englisch. Dies ist nur eine Übersetzung.

1. Was sind deiner Meinung nach die drei, vier Stärken von openSUSE, die wir kultivieren und auf denen wir aufbauen sollten?

1) Vielfalt der Features
OpenSUSE ist vor allem für die Distributionen Leap und Tumbleweed bekannt. Die große Bandbreite der verschiedenen Teilprojekte und wie sie zusammenpassen, ist eine große Stärke. Wir sollten einen Weg finden, oS mit den ganzen Projektteilen wie YaST, OBS, openQA etc. in Verbindung zu bringen.

2) “Erbe”
Linux-Distributionen kommen und gehen, manche bleiben jahrelang, andere verschwinden in den Tiefen des Internets. OpenSUSE gibt es nun schon seit Jahrzehnten und es muss diese Tatsache in Richtung einer Anerkennung als zuverlässiger Freund für den Betrieb von Computern verändern.

3) Genehmigungsfreie Gemeinschaft
Die openSUSE-Community lebt von Menschen, die einfach Dinge tun und versuchen, andere durch Ergebnisse zu überzeugen. Das ist nicht überall bei FOSS üblich. Einige andere Gemeinschaften versuchen, die Dinge über Komitees und Oberbosse zu vereinheitlichen.

2. Was sind die drei größten Risiken, die du für openSUSE siehst? (Und vielleicht Ideen, wie man sie angehen kann?)

1) Vergessen werden
2) Teilweise unbekannt bleiben
3) Im eigenen Saft schmoren

Es könnte auch andere Risiken geben, aber diese drei passen alle zu einem großen Thema: Kommunikation – oder eher dem Fehlen einer solchen.

Meine Idee, dies anzugehen, ist es, das Marketingteam (irgendwie) wiederzubeleben und als treibende Kraft für alles, was von openSUSE in Richtung des Restes der Welt geht, zu pushen. Es gibt bereits Initiativen, Artikel zu schreiben, mit Community-Leuten in Interviews zu sprechen und neues Marketingmaterial zu erstellen. Dies erfordert natürlich Koordination und Manpower, aber es läuft bereits recht gut.

Das Marketing-Team, das ich im Sinn habe, ist eine Initiative, die in zwei Richtungen arbeitet: Neben der Arbeit in Eigenregie möchte ich es offen haben für Menschen, die Ideen, Wünsche und Projekte einbringen. Mitglieder können Tickets öffnen, Nichtmitglieder können E-Mails senden oder in Chatrooms erklären, was sie wollen oder brauchen. Die Marketingleute erledigen dann entweder die Anfrage selbst oder versuchen, jemanden zu finden, der bereit ist, dies zu tun, z.B. in Artwork, l10n oder einem anderen geeigneten Team.

Das Hauptziel ist es, einen konstanten Fluss interessanter Inhalte für den Rest der Gemeinschaft und für jeden außerhalb von openSUSE aufrechtzuerhalten.

Die Antwort auf die folgende Frage erweitert diesen Punkt noch ein wenig.

3. Was sollte der Vorstand anders / mehr tun?

Kommunizieren. Obwohl die meisten Leute hier (einschließlich mir) die Sache mit der Hierarchie nicht mögen, ist es etwas, das nicht ungenutzt bleiben sollte. Kurz gesagt: Wenn das Board etwas sagt, wird es weithin als etwas Wichtiges und Offizielles angesehen.
Obwohl das nur teilweise wahr ist und diametral zu dem steht, was der Vorstand wirklich ist (ein “Diener” der Gemeinschaft), ist es sicherlich ein Weg, um Aufmerksamkeit für das gesamte Projekt zu gewinnen.

Ein Beispiel: Wählt relevante Dinge aus den Meetingnotizen aus, macht einen monatlichen Beitrag auf news-o-o, fügt ein nettes “Board News” Emblem hinzu.

4. Wenn du einen Blanko-Gutschein vom SUSE-CEO für einen Wunsch hättest, welcher wäre das?

Ich würde ihn dafür verwenden, die Prozesse mit Heroes und der technischen Infrastruktur zu vereinfachen. Obwohl ich nicht so sehr Details kenne, höre ich oft, dass die Dinge langsam laufen und viel nachgebohrt werden muss. Und ich gehe davon aus, dass das, was dort öffentlich sichtbar ist, nur die Spitze des Eisbergs ist.

5. Was hältst du von der Stiftung? Was hältst du für ein realistisches Ergebnis dieses Unterfangens? (Und falls anders, welches Ergebnis würdest du gerne sehen?)

SUSE ist in rechtliche und finanzielle Angelegenheiten der Community involviert und wird sich höchstwahrscheinlich niemals zurückziehen. Und es würde sich falsch anfühlen, wenn man versuchen würde, alle Verbindungen dort zu kappen. Aber meine Vermutung und Hoffnung für die Stiftung ist, dass sie die Dinge klarer und getrennter gestalten wird.

Du hast weitere Fragen? Schreib mir!

(Quelle der Fragen ist hier.)

Hotels und Betriebssysteme

macOS ist wie ein Hotel. Alles ist auf Hochglanz poliert, gestaltet und sorgfältig betreut. Aber es ist auch steril und man kann keine eigenen Möbel mitbringen oder selbst kochen. Unter Linux musst du selbst den Abwasch erledigen und den Müll entsorgen. Aber es ist deins. Niemand zwingt dir seine Agenda auf. Es fühlt sich einfach wie zu Hause an.

Going from macOS to Ubuntu | kvz.io

openSUSE Projekt: Abstimmung über Namenänderung

Das openSUSE-Projekt hat am 09.10.2019 in einer Rundmail seine Mitglieder aufgerufen ihre Stimme abzugeben. Die Frist für die Stimmenabgabe wurde nun bis zum 07.11.2019 um 23:59 Uhr UTC verlängert. In einem Wiki-Artikel haben das openSUSE-Board und das Election Committee zudem eine Zusammenfassung der Argumente für und wider einer Namensänderung den Mitgliedern bereit gestellt.

Die Hintergründe

Heise berichtet bereits am 12.06.2019 in einem Artikel darüber, dass das openSUSE-Projekt...

Highlights vom openSUSE Asia Summit 2019

Der openSUSE.Asia Summit ist eine der großen Veranstaltungen für die openSUSE-Community (d.h. sowohl Beitragende als auch Benutzer) in Asien. Diejenigen, die normalerweise online kommunizieren, können sich aus der ganzen Welt treffen, sich persönlich unterhalten und Spaß haben. Mitglieder der Community teilen ihr aktuelles Wissen, ihre Erfahrungen und lernen FLOSS-Technologien rund um openSUSE. Das openSUSE.Asia Summit 2019 fand vom 5. Oktober bis 6. Oktober 2019 am Information Technology Department, Faculty of Engineering, Udayana University, auf Bali statt.

Highlight-Videos Tag 1 und 2

YouTube Video

YouTube Video

Weitere Videos mit Vorträgen und Workshops sind auf YouTube verfügbar.

Wednesday

21 August, 2019

openSUSE Leap 15.1 mit USB-Stick als Schlüssel für die Festplattenverschlüsselung

Ich nutzte schon seit 2011 einen USB-Stick um bei meinem mit openSUSE laufenden Heimserver beim Start das Passwort für die Festplattenverschlüsselung „eingeben“ zu können ohne eine Tastatur oder einen Monitor am System angeschlossen zu haben. Den dafür genutzten Mechanismus habe ich auch schon damals hier im Blog dokumentiert. Leider funktionierte der dort beschriebene Mechanismus aber seit openSUSE Leap 42.2 nicht mehr. Auf openSUSE Leap 42.2, 42.3, 15.0 und 15.1 gibt es aber einen neuen Mechanismus, der sogar noch besser funktioniert.

Festplattenverschlüsselung

Für die Festplattenverschlüsselung wird ganz klassisch LUKS genutzt, so wie auch openSUSE ein System mit Festplattenverschlüsselung aufsetzen würde. Da der Schlüssel vom USB-Stick während des initialen Boots aus der Initrd gelesen wird muss /boot allerdings unverschlüsselt sein. Moderne Versionen von openSUSE erlauben auch einen Boot mit verschlüsselter Boot-Partition. In diesem Fall wird der Schlüssel aber bereits von Grub abgefragt. Diese Variante wird vom hier beschriebenen Mechanismus nicht unterstützt.

Da LUKS die Nutzung mehrerer alternativer Schüssel unterstützt empfiehlt es sich das System zunächst mit einer klassischen Passphrase einzurichten. Dies erleichtert Offline-Upgrades des Systems und das Einbinden der Festplatten zu Wiederherstellungs- und Wartungszwecken.

USB-Stick als Schlüssel

Da der USB-Stick später aus der Initramfs gelesen werden soll, empfiehlt es sich ein dort sowieso eingebundenes Dateisystem zu nutzen. Ich nutze hierfür immer noch Ext2. Ist der Stick als /dev/sdb im System zu sehen, kann er wie folgt passend formatiert werden.

mkfs.ext2 -L keystick /dev/sdb

Das Label keystick ist wichtig um den Schüssel später leicht referenzieren zu können. Außerdem ist es beim Mount mit Label möglich eine zweite Kopie des Sticks zu erstellen falls das Original mal zerstört wird.

Anschließend sollte ein Schlüssel generiert und auf dem USB-Stick hinterlegen werden. Dies kann mit pwgen gemacht werden:

pwgen -s 1024 1 > /media/keystick/keyfile

Und schließlich muss der Schlüssel der verschlüsselten Partition hinzugefügt werden.

cryptsetup luksAddKey /dev/sda2 /media/keystick/keyfile

In diesem Beispiel befindet sich die verschlüsselte Partition auf /dev/sda2.

USB-Stick beim Booten nutzen

Um den Schlüssel beim Booten vom USB-Stick zu lesen muss der Kernelparameter rd.luks.key auf die Schlüsseldatei zeigen.

rd.luks.key=/keyfile:LABEL=keystick

Hier wird wieder das, bei der Formatierung des Sticks vergebene, Label für das Dateisystem genutzt. Der Pfad ist relativ zum per Label referenzierten Dateisystem. Konfigurieren lässt sich der Kernelparameter am einfachsten über die Bootloaderkonfiguration in Yast.

Damit der Parameter rd.luks.key funktioniert benötigt es allerdings noch eine Änderung. In der Standardkonfiguration nutzt die Initrd bei openSUSE Systemd. Dann hat der Parameter allerdings keinen Effekt. Deshalb muss Dracut, welches in openSUSE die Initrd baut, so konfiguriert werden, dass es eine Initrd ohne Systemd baut. Dazu ist eine neue Datei /etc/dracut.conf.d/50-keystick.conf mit folgendem Inhalt anzulegen:

omit_dracutmodules+="systemd"

Ein anschließendes mkinitrd erzeugt eine Initrd ohne Systemd und das System kann zukünftig bei eingestecktem USB-Stick ohne Passworteingabe gestartet werden.

Vorteile gegenüber der alten Methode

Bei der alten Methode blieb das System in einer Schleife hängen wenn der USB-Stick beim Boot nicht gesteckt war. Ohne Stick konnte das System gar nicht mehr gebootet werden. Bei der hier beschriebenen Methode versucht das System zunächst die Schüsseldatei vom USB-Stick zu lesen. Kann es diese aber nicht finden, so fällt es auf die klassische Passworteingabe zurück. Wurde der USB-Stick also nicht als einziges Passwort eingerichtet lässt sich das System im Notfall auch noch so starten.

Sunday

18 August, 2019

FrOSCon 2019 - openSUSE booth & AppArmor Crash Course

The lucky winner of the openSUSE Jeopardy and the Geeko
AppArmor Crash Course slides, 2019 edition.
Last weekend, I was at FrOSCon - a great Open Source conference in Sankt Augustin, Germany. We (Sarah, Marcel and I) ran the openSUSE booth, answered lots of questions about openSUSE and gave the visitors some goodies - serious and funny (hi OBS team!) stickers, openSUSE hats, backpacks and magazines featuring openSUSE Leap. We also had a big plush geeko, but instead of doing a boring raffle, we played openSUSE Jeopardy where the candidates had to ask the right questions about Linux and openSUSE for the answers I provided.

To avoid getting bored ;-) I did a sub-booth featuring my other two hobbies - AppArmor and PostfixAdmin. As expected, I didn't get too many questions about them, but it was a nice addition and side job while running the openSUSE booth ;-)

I also gave an updated version of my "AppArmor Crash Course" talk. You can find the slides on the right, and the video recording (in german) on media.ccc.de.

Thursday

15 August, 2019

Alte Kernelversionen installiert behalten

OpenSUSE behält in seiner Standardkonfiguration bei einer Aktualisierung des Kernels stets die letzte zuvor installierte Version. Diese kann beim Systemstart über die erweiterten Startmodi ausgewählt werden. Das hat den großen Vorteil, dass sollte der neue Kernel einen Fehler haben, man noch zu einem funktionierenden System zurückkehren kann. Man kann also einfach mit dem alten Kernel weiterarbeiten und auf eine Behebung des Fehlers warten.

Doch was passiert bei der nächsten Aktualisierung? Hier gibt es mehrere Optionen. Löst die nächste Aktualisierung das Problem, kann man wieder auf den aktuellen Kernel wechseln und die alten Versionen können einem egal sein. Ist das Problem mit der nächsten Aktualisierung nicht behoben gibt es zwei mögliche Fälle. Im einfachen Fall startet das System mit dem neuen Kernel gar nicht. In diesem Fall kann man weiterhin mit dem alten Kernel weiterarbeiten, denn das System behält stets den aktuell laufenden Kernel installiert Solange neuere Kernel gar nicht starten können die alten Versionen somit auch nicht entfernt werden. Spannender wird es, wenn der neue Kernel zwar startet, aber trotzdem nicht korrekt funktioniert. So läuft womöglich der proprietäre Treiber von NVIDIA nicht oder ein Fehler im Kernel tritt nur in bestimmten Situationen auf. In diesem Fall würde das System in der Standardkonfiguration nach dem, aus seiner Sicht erfolgreichen, Start den alten Kernel entfernen und nur die zwei defekten Kernel behalten.

Zum Glück lässt sich die Menge der aufbewahrten Kernel sehr flexibel Konfigurieren. Die Konfiguration findet sich in der Datei /etc/zypp/zypp.conf Entscheiden ist der Wert der Option multiversion.kernels. Diese wird standardmäßig wie folgt gesetzt:

multiversion.kernels = latest,latest-1,running

Damit werden die neuesten beiden und der aktuell laufende Kernel behalten. Hier lassen sich aber auch explizite Versionen eintragen. Damit sieht die Zeile dann wie folgt aus:

multiversion.kernels = latest,latest-1,running,4.12.14-lp151.28.10.1

Wichtig ist, dass hier die Paketversion benötigt wird, nicht die vom Kernel bei einem uname -a ausgegebene Version. Letzteres würde lautet für den im Beispiel benutzen Kernel folgendes ausgeben.

Linux test 4.12.14-lp151.28.10-default #1 SMP Sat Jul 13 17:59:31 UTC 2019 (0ab03b7) x86_64 x86_64 x86_64 GNU/Linux

Die dazugehörige Paketversion lässt sich per rpm oder zypper abfragen:

> rpm -qa kernel-default
kernel-default-4.12.14-lp151.28.10.1.x86_64
kernel-default-4.12.14-lp151.28.13.1.x86_64

> zypper search -s kernel-default
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                 | Typ        | Version               | Arch   | Repository
---+----------------------+------------+-----------------------+--------+--------------------------------
i+ | kernel-default       | Paket      | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
i+ | kernel-default       | Paket      | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default       | Paket      | 4.12.14-lp151.28.7.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default       | Paket      | 4.12.14-lp151.28.4.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default       | Paket      | 4.12.14-lp151.27.3    | x86_64 | Haupt-Repository (OSS)
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.13.1 | noarch | Hauptaktualisierungs-Repository
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.10.1 | noarch | Hauptaktualisierungs-Repository
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.7.1  | noarch | Hauptaktualisierungs-Repository
   | kernel-default       | Quellpaket | 4.12.14-lp151.28.4.1  | noarch | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.7.1  | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.28.4.1  | x86_64 | Hauptaktualisierungs-Repository
   | kernel-default-base  | Paket      | 4.12.14-lp151.27.3    | x86_64 | Haupt-Repository (OSS)
i+ | kernel-default-devel | Paket      | 4.12.14-lp151.28.13.1 | x86_64 | Hauptaktualisierungs-Repository
i+ | kernel-default-devel | Paket      | 4.12.14-lp151.28.10.1 | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default-devel | Paket      | 4.12.14-lp151.28.7.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default-devel | Paket      | 4.12.14-lp151.28.4.1  | x86_64 | Hauptaktualisierungs-Repository
v  | kernel-default-devel | Paket      | 4.12.14-lp151.27.3    | x86_64 | Haupt-Repository (OSS)

Wie im Beispiel zu sehen ist, liefert zypper die einfacher zu lesende Ausgabe, rpm aber eine deutlich kompaktere.

Hat man so den funktionierenden Kernel vor dem automatischen Aufräumen geschützt, lässt es sich ganz entspannt auf eine reparierte Version warten. Wurde der Fehler behoben, und spätestens nach dem nächsten Distributionsupgrade, sollte man allerdings die Konfiguration wieder zurücksetzen um nicht unnötig alte Kernel mit sich herumzuschleppen. Denn diese benötigen nicht nur Platz, sie verlängern auch die Installationszeit mancher Updates.

Weitere Informationen zur Installation mehrerer Kernelversionen finden sich in der englischen Referenzdokumentation von openSUSE Leap.

Saturday

10 August, 2019

Automatisiertes Tippen von Passwörtern auf openSUSE

Die Passwortverwaltung KeePass hat das äußerst praktische Feature Auto-Type um Anmeldeformulare in jeglicher Software, also nicht nur im Browser, per Knopfdruck ausfüllen zu können. Damit spart man sich das manuelle Kopieren und Einfügen, was nicht nur komfortabler ist, sondern auch verhindert, dass das Passwort auf diesem Weg doch an einer falschen Stelle landet. Leider funktionierte dies in openSUSE bisher nur, wenn man manuell das Paket xdotool nachinstalliert. Ansonsten begrüßt folgende Fehlermeldung:

The 'xdotool' utility package is required for auto-type. Install this package and try again.

Die Fehlermeldung sagt dem Nutzer zwar bereits wie das Problem zu beheben ist, aber ich als Nutzer bevorzuge es eigentlich, wenn Dinge einfach funktionieren. Von daher sollte die Installation des Paketes keepass eigentlich dafür sorgen, dass auch xdotool installiert wird.

Zum Glück hat openSUSE einen gut Dokumentierten Prozess um Korrekturen zu Paketen beizutragen. Das Paket zu reparieren ist also fast genau so schnell erledigt wie die fehlende Abhängigkeit zu installieren. Und als Bonus muss ich es auf dem nächsten System dann nicht wiederholen.

Wie man an meinem Request sehen kann habe ich xdotool übrigens nicht einfach als Abhängigkeit zu keepass hinzugefügt, denn KeePass funktioniert ja auch ohne xdotool fehlerfrei. Stattdessen nutze ich den Vorschlagsmechanismus, also Recommends statt Depends. So bekommt ein normaler Nutzer das empfohlene Paket automatisch mitinstalliert. Wer aber --no-recommends nutzt, um beispielsweise aus Sicherheitsgründen oder wegen beschränktem Platz auf der Systemfestplatte, nur die absolut notwendigen Pakete installieren möchte, bekommt weiterhin die gleiche minimale Installation wie bisher.

Leider habe ich meine Korrektur minimal zu spät beigetragen, als dass sie es noch in openSUSE Leap 15.1 geschafft hätte. Von daher profitiert man bisher in in Tumbleweed davon. Mit der nächsten Leap-Version können dann aber auch Leap-Nutzer ohne manuelle Nacharbeit Auto-Type nutzen.