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

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

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.

Auch auf dem inzwischen erschienenen openSUSE Leap 15.2 funktioniert diese Methode unverändert.

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.

Aug 18th, 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.

Aug 15th, 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.

Aug 10th, 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.

openSUSE Leap 15.1 Release und wie man darauf upgraded

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

May 6th, 2019

EasyTAG: Organisiere deine Musik unter openSUSE

Audiodateien in Formaten wie MP3, AAC und Ogg Vorbis haben Musik allgegenwärtig und tragbar gemacht. Mit dem explosionsartigen Wachstum der Speicherkapazität kannst du riesige Musikbibliotheken speichern. Aber wie hältst du all diese Musik organisiert? Tagge einfach deine Musik. Dann kannst du einfach lokal und in der Cloud darauf zugreifen. EasyTAG ist eine gute Wahl für die Kennzeichnung von Musik und ist unter openSUSE verfügbar.

Viele Audiodateitypen unterstützen das Tagging, einschließlich:

  • MP4, MP3, MP3, MP2
  • Ogg Speex, Ogg Vorbis, Ogg Opus
  • FLAC
  • MusePack
  • Monkey Audio

Installation von EasyTAG

EasyTAG ist einfach aus openSUSE-Repositories zu installieren:

Oder benutze Zypper in einem Terminal als Root:

# zypper install easytag

Dann startest du das Programm über das Anwendungsmenü auf deinem Desktop. Die unkomplizierte Benutzeroberfläche von EasyTAG eignet sich für die meisten Desktop-Umgebungen.

Musik taggen

Wähle einen Ordner aus, in dem du Musik hast, die du markieren möchtest. Standardmäßig lädt EasyTAG auch Unterordner. Du kannst jede Datei auswählen und Tag-Informationen wie Künstler, Titel, Jahr usw. hinzufügen. Du kannst auch Bilder im JPG- oder PNG-Format zu einer Datei hinzufügen, was die meisten Player auch verstehen.

Von dir geänderte Dateien werden in der Dateiliste fett gedruckt. Um alle zu speichern, drückst du Strg+S. Du kannst auch die gesamte Liste auswählen und mit Strg+Shift+S alle Dateien auf einmal speichern.

Eine der leistungsfähigsten Funktionen von EasyTAG ist der Dateiscanner. Der Scanner erkennt Muster auf der Grundlage einer von dir bereitgestellten Vorlage. Sobald du die richtigen Vorlagen und Scan-Dateien zur Verfügung gestellt hast, markiert EasyTAG automatisch alle für dich. Dann kannst du sie in großen Mengen speichern. Das spart viel Zeit und Frustration im Umgang mit großen Bibliotheken.

Wenn du deine getaggten Dateien zu einem Cloud-Service hochlädst, ermöglichen dir deine Tags, die gewünschte Musik jederzeit schnell zu finden und abzuspielen.

Dieser Artikel ist eine Adaption & Übersetzung von EasyTAG: Organize your music on Fedora unter der Creative Commons Lizenz.

Mar 7th, 2019

Die crowbyte Wiederbelebung

Ich. Bin. Zurück.

Dies ist die crowbyte Wiederbelebung. Neben der brandneuen Webseite gibt einige Änderungen unter der Haube. Bist Du neugierig, dann solltest Du ...

crowbyte ist endlich zurück

Ich weiß, es ist eine lange her - wirklich sehr sehr lange - dass mein Blog Liebe und Hingabe erfahren hat. Es tut mir Leid, mein lieber Blog und es tut mir Leid, liebe Leser.

Dieses Mal keine Versprechungen über mehr Content, denen ich nicht vielleicht gerecht werde. Mehr Zeit sich also auf die...

Kandidatur für das openSUSE Board

Du hast vielleicht schon gehört, dass die Wahlen für drei offene Sitze im openSUSE Board im Gange sind. Ich habe eine Weile darüber nachgedacht, für das Board zu kandidieren und jetzt scheint es der richtige Zeitpunkt zu sein, um mich einzubringen.

Der nachfolgende Text ist die deutsche Übersetzung einer einfachen, unbearbeiteten Kopie meiner Bewerbung.

Einführung, Biographie und Beiträge

Mein Name ist Vinzenz Vietzke, aber ich bevorzuge es, beim viel kürzeren “vinz” oder “vinzv” zu bleiben. Ich bin 34 Jahre alt, lebe in einer kleinen Stadt in Süddeutschland. Wie die meisten deutschen Linux-Anwender in meinem Alter habe ich bereits Ende der 90er Jahre meine ersten Schritte mit S.u.S.E. gemacht. Im Laufe der Jahre wechselte ich zwischen verschiedenen Distributionen und trug auf verschiedene Weise zu etlichen von ihnen bei. Mein Hauptberuf ist Produktmanagement und Marketing beim Linux-Hardwareanbieter TUXEDO Computers.

openSUSE und TUXEDO

Ausgehend von nur einem Laptop mit openSUSE bieten wir bei TUXEDO heute rund 20 verschiedene Modelle sowie eine große Auswahl an Desktop-PCs mit vorinstalliertem Leap 15. Kunden erhalten außerdem kostenlosen lebenslangen Support für ihr vorinstalliertes System. Deshalb muss natürlich auch unser kostenloses Telefon/E-Mail-Supportteam für openSUSE geschult werden. Für dieses ganze Projekt war und bin ich als Technik- und Projektleiter sozusagen verantwortlich, um openSUSE auf die Computer von TUXEDO zu “bringen”. Ich bin mit oS in Kontakt getreten, habe ausgearbeitet, wie und wann wir alles realisieren können.

Zusätzlich zu den technischen Angelegenheiten bin ich die treibende Kraft bei TUXEDO Computers, damit unser Unternehmen die Unterstützung von openSUSE intensiviert. Seit Oktober 2018 sponsern wir daher offiziell das openSUSE-Projekt. Wir bieten jedes unserer Modelle als Vorführ- und Workshop-Gerät kostenlos an und kümmern uns um die Logistik- und Event-Betreuung. Außerdem sponsern wir die oSC19 in Nürnberg mit Geräten zur Demonstration und für Installationsfeste.

Natürlich sind das vor allem finanzielle Anstrengungen und unternehmensinterne Projekte. Aber um openSUSE einen größeren Bekanntheitsgrad zu verschaffen, braucht es jemanden, der koordiniert, vorantreibt und sich kümmert. Deshalb nenne ich meine Beiträge zu openSUSE meist “Meta-Beiträge”.

i18n

Neben den teils bezahlten und teils Freizeitaktivitäten für TUXEDO koordiniere ich Upstream-Übersetzungsteams von Xfce, übersetze aktiv openSUSE und vielen anderen Projekten. Für Details siehe meine Profile bei Crowdin, Gnome, Transifex sowie meine persönliche Website..

Ziele

Wie jedes von Freiwilligen geführte Projekt hat auch openSUSE seine Probleme zu lösen. Die meisten von ihnen sind offensichtlich und bereits in Arbeit: Konsolidierung von Webauftritten, Reinigung des Wikis, Sortierung der Kommunikationsinfrastruktur und mögliche Erweiterungen. Ich glaube nicht, dass es noch etwas mehr braucht, um diese Dinge außer der Zeit voranzutreiben. Der Vorstand hat in der Vergangenheit bei diesen Dingen eine wirklich großartige Arbeit geleistet und wird es sicherlich auch in Zukunft tun.

Große und kleine Probleme

Eines der Hauptthemen, die ich erlebe, ist die öffentliche Wahrnehmung, z. B. wie openSUSE als Distribution wahrgenommen wird. Wenn Menschen über openSUSE sprechen, erzählen sie hauptsächlich von ihren Erfahrungen, die sie vor einem Jahrzehnt gemacht haben (wörtlich!). Du bist 2011 auf einige YaST-Themen gestoßen und deshalb hast du aufgehört, openSUSE zu empfehlen, und du hast nie deine Meinung geändert? Meine Güte. Diese Erinnerungen müssen überarbeitet und in einen korrekten Zusammenhang gebracht werden. Die meisten von ihnen sind sowieso Vorurteile.

Auf der anderen Seite setzen Menschen, die von Linux gehört haben, aber kaum Kenntnisse haben, meist eine bestimmte Distribution mit Linux gleich. Obwohl es technisch nicht korrekt ist, tun Endbenutzer dies – was in Ordnung ist. Aber sie setzen es nicht mit openSUSE gleich, und das ist schade. oS ist wirklich weit gekommen und ist einfach zu installieren, zu betreiben und zu bedienen. Die Menschen müssen nur etwas darüber wissen, und genau hier kommen die oben genannten Vorurteile ins Spiel. Der ” Technik-Typ ” in einem Freundeskreis ist ein Multiplikator und muss überzeugt werden, dass openSUSE etwas ist, das er mit gutem Gewissen uneingeschränkt empfehlen kann.

Rolle des Boards

Aus meiner Sicht hat das Board zwei Hauptrollen: In erster Linie ist es eine Art Dienstleister. Es dient dem gesamten Projekt als Anlaufstelle für Fragen, Projektkoordination und Richtungsweisung etc. Dies ist entscheidend für das gesamte openSUSE-Projekt und sollte nie geändert, sondern nach Möglichkeit nur erweitert werden.

Die zweite Rolle könnte als “Zündfunke für Ideen” bezeichnet werden. Die meisten Ideen aus der Community sind technischer Natur, was völlig logisch ist. Nur manchmal gibt es Dinge, von denen das ganze Projekt profitieren würde, aber niemand sieht sie oder hat Zeit dafür. Hier könnte das Board einspringen, um Zündfunken zu erzeugen und Input von jemandem zu geben, der in der Lage ist, einen Schritt zurückzutreten, um das Gesamtbild zu betrachten.

Meine Rolle in diesem Board-Team wäre sowohl für Teil eins zugänglich als auch hilfreich zu sein. Aber auch, wie im zweiten Teil erwähnt, bei Bedarf Überlegungen und Ideen zu äußern.

Warum solltest du für mich stimmen?

Ich beschäftige mich seit etwa 10 Jahren mit Linux und Open Source Communities. Obwohl ich kein langfristiger Mitwirkender bei openSUSE bin, weiß ich, wie in einem so großen, vielfältigen Projekt “Dinge laufen” und wie man damit umgeht. Wenn du jemanden ohne “Geekobrille” haben willst, solltest du für mich stimmen. Nicht, dass es schlecht ist, tief in der Community von openSUSE verankert zu sein! Aber ich kann neue Perspektiven einbringen, die meisten davon bezogen auf Endanwender, Windows-Flüchtlinge und neugierige, aber technisch nicht versierte Menschen. Ich verstehe sowohl Entwickler und Techniker auf der einen Seite als auch Leute, die vorinstallierte Linux-Hardware mit wenig Lust zum Basteln kaufen. Auf diese Weise fungiere ich als Stellvertreter zwischen den Welten, was am Ende für alle Beteiligten gut sein könnte.

Zusammenfassung

Wie bereits erwähnt, läuft mein Hauptziel darauf hinaus, dass Leute an einfaches, aber leistungsfähiges Linux denken, wenn sie openSUSE hören. Das Gesamtprojekt ist groß und stark genug, um wirklich als “die erste Wahl für Sysadmins, Entwickler und Desktop-Anwender” zu fungieren – und zwar alle!

Frag mich irgendwas

Wenn du es so weit geschafft hast – danke für deine Zeit und dein Interesse. Für Fragen, Kommentare oder Widersprüche stehe ich dir gerne zur Verfügung. Ich freue mich über alles davon via:

Jan 6th, 2019

board_candidates++ - or: running for the openSUSE Board again

About two years ago, I wrote a mail titled "Another openSUSE Board candidate". These two years passed quickly, and I really enjoyed being part of the Board and helping the community whenever needed.

I'd like to continue this "job", and therefore decided to run for re-election.

I use openSUSE since years (it was still named „SuSE Linux“ with lowercase „u“ back then) and started annoying people in bugzilla, err, started betatesting in the 9.2 beta phase. Since then, I reported more than 1300 bugs. Nowadays, OBS ruins my bugzilla statistics by introducing the option to send a SR ;-)

One of my current activities in openSUSE is working in the Heroes team, where I started with moving and upgrading the wiki. I also help out on various *.opensuse.org servers since someone was evil enough to give me root permissions on lots of them ;-) (Transparency note: I helped to setup the elections.opensuse.org server before last year's elections - but will of course not touch it until the elections finish.)

My other openSUSE hobbies ;-) are AppArmor and PostfixAdmin, where I'm active in upstream development and as packager. AppArmor also turned out to be a good opportunity for cross-distribution collaboration.

You can find me on several mailinglists and on IRC (nickname "cboltz"), and of course I still scare people in bugzilla. I‘m also a regular visitor and speaker at the openSUSE Conference, and visit other conferences as time permits.

My day job has nothing to do with computers. I produce something you can drink that is named after a software we ship in openSUSE ;-)

Oh, and I collect funny quotes from various mailinglists, IRC, bugzilla etc. that then end up as random [1] signatures under my mails, so be careful what you write ;-)

There are some things I‘ll never do (you might remember them from two years ago):

  • use a stable release on my main computer – Tumbleweed is just too good ;-)
  • open a bugreport if fxing the bug and sending a SR is faster
  • be too serious – hey, our motto is „Have a lot of fun...“ ;-)
  • drink beer ;-) (sorry, not even openSUSE beer)

If you want to read more from or about me, have a look at


I wish all candidates good luck, and hope that we‘ll see some more candidates and lots of voters!



[1] sometimes I hand-pick signatures, and this is one of these cases with a non-random signature ;-) (yes, I know it's unusual for a blog post to have a signature at all, so this will stay a rare exception)
--
Christian, there are times you are a pain in the ass, there are times I really like you.
This is one of both of those times ;)
[Richard Brown]