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.

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.

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

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

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

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

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

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

The lucky winner of the openSUSE Jeopardy and the Geeko

AppArmor Crash Course slides, 2019 edition.

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.

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.

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:

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.

Ich nutze openSUSE Leap 15.0 bereits seit der Beta sogar in Produktiv-Systemen, weil es sich als absolut solides und stabiles Enterprise-OS herausgestellt hat. Mit openSUSE 15.1 bekommen wir nun alle Updates aus SUSE Enterprise Linux 15 Service Pack 1 für openSUSE Leap. Ich führe euch durch meine eigenen Erfahrungen mit openSUSE Leap 15.0, sowie durch den Upgrade-Prozess auf Leap 15.1 auf allen meinen Systemen.

Meine openSUSE Leap 15.0 Erfahrung

Alles begann damit, dass ein Fedora 28 Upgrad...