Willkommen zum openSUSE Planeten

Dies ist eine Zusammführung der Blog-Einträge von Mitwirkenden im openSUSE-Projekt.

Zum Hinzufügen eines Blog-Feeds bitte die Anleitung lesen.


Sonntag
26. Januar 2020


face

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


Donnerstag
16. Januar 2020


face

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


Donnerstag
07. November 2019


face

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


Mittwoch
23. Oktober 2019


face

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


Sonntag
13. Oktober 2019


face

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.


Mittwoch
21. August 2019


face

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


Sonntag
18. August 2019


face

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.


Donnerstag
15. August 2019


face

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 

Samstag
10. August 2019


face

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.


Samstag
01. Juni 2019


face

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


Montag
06. Mai 2019


face

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.


Donnerstag
07. März 2019


face

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


Sonntag
06. Januar 2019


face

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


Sonntag
09. Dezember 2018


face

Kmail, das Mailprogramm des KDE Projekts, kommt ja nicht alleine daher. Mit dabei ist auch ein Adressbuch, eine Terminverwaltung, ein Benachrichtigungsdienst und noch einiges mehr. Das ganze wird von Akonadi, dem dahinterliegenden Backend der gesamten KDE PIM Suite, sozusagen am Laufen gehalten.

Standardmäßig läuft Akonadi mit MySQL als Datenbanksystem, was bei mir aber immer wieder Zicken gemacht hat. Daher habe ich mich mal nach Alternativen umgesehen und bin neben SQLite bei PostgreSQL gelandet. Über SQLite und die Implementierung in Akonadi gab es leider einige negative Berichte, darum habe ich es direkt aussortiert.
Mit PostgreSQL hatte ich keine Erfahrungen, konnte es aber recht schnell einrichten. Die Anbindung von Akonadi und somit Kmail an PostgreSQL war ebenfalls einfach.

Alle Schritte unter openSUSE

Zuerst installieren wir alle nötigen Pakete für PostgreSQL und die Akonadi-Anbindung:

# zypper in postgresql-server libQt5Sql5-postgresql

PostgreSQL Server aktivieren und starten:

# systemctl enable --now postgresql

Postgres-Nutzer und -Datenbank anlegen:

# su - postgres
$ createuser <dein-nutzername>
$ psql postgres
postgres=# alter user <dein-nutzername> createdb;
postgres=# \q;
# exit

Dann richten wir – mit deinem regulären Nutzerkonto – den Datenbankzugriff einrichten:

$ createdb akonadi-<dein-nutzername>

Nun stoppen wir Akonadi und löschen bzw. verschieben die Einstellungen. Das ist besonders wichtig, falls du Akonadi schon einmal gestartet hast!

$ akonadictl stop
$ rm -rf ~/.local/share/akonadi

Die Verbindung zum Datenbankserver passen wir in der Datei ~/.config/akonadi/akonadiserverrc wie folgt an:

[%General]
Driver=QPSQL

[QPSQL]
Host=/tmp/akonadi-<dein-nutzername>.hash
InitDbPath=/usr/bin/initdb
Name=akonadi
Options=
ServerPath=/usr/bin/pg_ctl
StartServer=true

Abschließend Akonadi neu starten und du bist startklar:

$ akonadictl start

Sonntag
11. November 2018


face

Keybase gehört zu den Diensten, die zwar irgendwie wahnsinnig nützlich sind, denen der breite Erfolg bisher aber leider verwehrt wurde. Das Kernfeature besteht darin, dass es einen Weg bietet eine verschlüsselte Kommunikation mit Personen aufzubauen von denen man nur einen Social-Media-Account kennt. Durch das Verfahren, einen Beweis über die Eigentümerschaft des Schlüssels im Social-Media-Account zu hinterlegen, kann man diesen, anders als Schlüsseln welche man von einem PGP-Keyserver erhalten hat, recht gut Vertrauen. Leider bietet allerdings Keybase kein Installationspaket seiner Software für openSUSE an, so dass ich nun selber Pakete erstellt habe.

Die grundlegenden Funktionen von Keybase sind über das Kommandozeilenwerkzeug keybase verfügbar. Dieses wird vom Paket keybase-client bereitgestellt und lässt sich in Tumbleweed durch ein einfaches sudo zypper install keybase-client installieren. Für Leap 15.0 ist das Paket leider nur als Versuchspaket verfügbar, welches sich am besten per 1-Klick-Installation von software.opensuse.org installieren lässt.

Außerdem bietet Keybase noch zwei weitere nützliche Funktionen. Mit dem dazugehörigen Dateisystem lassen sich Daten verschlüsselt und signiert mit anderen Nutzer tauschen. Auch öffentlich lassen sich darüber Dateien anbieten. Diese erscheinen dann unter https://<nutzername>.keybase.pub, und sind natürlich nicht verschlüsselt sondern nur signiert. Hierfür wird das Paket kbfs benötigt. Ist diese installiert, kann man per systemctl --user start kbfs das Dateisystem starten, welches dann unter ${XDG_RUNTIME_DIR}/keybase/kbfs erscheint.

Die zweite nützliche Funktion ist es Git-Repositories verschlüsselt in Keybase abzulegen. Hierzu wird das Paket kbfs-git benötigt. Sobald diese installiert ist, und das Dateisystem aktiv, kann Git auf Repositories welche das Protokoll keybase nutzen zugreifen. Die Verwaltung erfolgt hierbei über das Kommando keybase git.


Dienstag
30. Oktober 2018


face

Seit letzter Woche ist Piper in openSUSE Tumbleweed als Paket enthalten. Piper erlaubt es für eine ganze Reihe Spielermäuse diese auch unter Linux ganz genau so zu konfigurieren, wie es sonst die nur unter Windows verfügbaren Programme der Hersteller tun.

Ein Screenshot von Piper

Bei meiner Logitech G502 kann ich mit Piper nicht nur grafisch zwischen den einzelnen Profilen wechseln, sonder ich kann auch für jedes Profil die Auflösungsstufen, die Tastenbelegung und die LEDs konfigurieren.

Zur Installation muss das Paket piper ausgewählt werden, entweder in der grafischen Paketverwaltung, per 1-Klick-Installation auf software.opensuse.org oder auf der Kommandozeile:

sudo zypper install piper

In openSUSE Leap ist Piper aktuell leider nicht nutzbar. Der darunterliegende Service Ratbagd hatte seine Sicherheitsbegutachtung beim Release von Leap 15.0 leider noch nicht abgeschlossen. Mit der kommenden Version 15.1 sollte der Nutzung von Piper auf Leap dann aber auch nichts mehr im Wege stehen.


Montag
22. Oktober 2018


face

Nachdem es inzwischen keine Version von openSUSE mehr gibt in welcher der Apache zu alt ist um HTTP/2 zu unterstützen, gibt es eigentlich keine Ausrede mehr um dieses nicht einzusetzen. Tatsächlich ist die Installation auf openSUSE auch schon hervorragend vorbereitet, man muss lediglich berücksichtigen, dass HTTP/2 nicht mit dem Multi-Processing-Module (MPM) Worker kompatibel ist, welches immer noch der Standard ist.

Um HTTP/2 zu aktivieren ist zunächst ein kompatibles MPM zu installieren. Eine gute Wahl ist hierbei das MPM Event, welches unter openSUSE durch das Paket apache2-event bereitgestellt wird.

sudo zypper install apache2-event

Alle notwendige Konfiguration kann anschließend in der Datei /etc/sysconfig/apache2 vorgenommen werden:

  1. Das korrekte MPM auswählen: APACHE_MPM=event.
  2. Das HTTP2-Module durch hinzufügen von http2 zum Wert von APACHE_MODULES aktivieren.
  3. Den Wert HTTP2 zu APACHE_SERVER_FLAGS um die von openSUSE mitgelieferte Konfiguration für HTTP/2 zu aktivieren.

Ab dem nächsten, per systemctl restart apache2 durchführbaren, Neustart ist der Server dann per HTTP/2 zu erreichen.

Um für Browser per HTTP/2 nutzbar zu sein muss der Server übrigens TLS reden, da Firefox und Chrome HTTP/2 nur für sichere Verbindungen unterstützen. Das sollte heutzutage aber sowieso der Standard sein.


Samstag
13. Oktober 2018


Matthias Bach: GameMode

22:00 UTC

face

Beim Spielen möchte man am liebsten ungestört sein. Deshalb bietet es sich häufig an so manches Program beim Starten eines Spieles zu schließen. Auch weisen viele Spiele von Feral Interactive, z.B. F1 2017, weisen einen beim Start recht deutlich darauf hin, dass sie für die CPU eigentlich gerne den Performance-Modus aktiviert hätten. Programme zu beenden und den Energiesparmodus zu wechseln, vor allem aber dies nach Ende der Spielesitzung alles wieder rückgängig zu machen, ist mühselig und steht dem spontanen Spielegenuß im Weg. Hier hilft der von Feral Interactive entwickelte GameMode.

GameMode läuft als Prozess im Hintergrund und bietet eine einfache Funktion: Über die dazugehörige Bibliothek können Spiele den Rechner in einen Spielemodus schalten. Im Spielemodus wird die CPU in den Performance-Modus geschaltet. Außerdem lassen sich beliebige weitere beim Start des Spielemodus auszuführende Aktionen definieren um beispielsweiße den Mail-Client für die dauer der Spielesitzung zu beenden. Am Ende der Spielesitzung schaltet GameMode die CPU dann von alleine wieder in den balancierten Modus, so dass nicht weiter unnötig viel Energie verbraucht wird.

Da selbst Spiele von Feral Interactive noch nicht durchgängig GameMode unterstützen gibt es außerdem libgamemodeauto. Libgamemodeauto kann per LD_PRELOAD mit einer Anwendung mitgeladen werden und sorgt dann automatisch für den Wechsel in den Spielemodus. Installiert man libgamemodeauto über das openSUSE-Paket libgamemodeauto0, so findet es sich in /usr/lib64/libgamemodeauto.so.0. Um es im Spiel game zu nutzen ist diese dann wie folgt zu starten:

LD_PRELOAD=/usr/lib64/libgamemodeauto.so.0 game

Um Spiele per Steam mit libgamemodeauto zu starten ist in den Startoptionen des Spieles folgendes einzutragen:

LD_PRELOAD=$LD_PRELOAD:/usr/lib64/libgamemodeauto.so.0 %command%

Diese Kommandozeilen finden sich auch in der Paketbeschreibung von libgamemodeauto0, welche sich per zypper info libgamemodeauto0 anzeigen lässt.

Der einfachste Weg GameMode zu installieren ist den Download oder die Anleitung von software.opensuse.org zu nutzen. In Tumbleweed reicht ein einfaches zypper install ligbamemodeauto0. In Leap ist libgameodeauto leider noch nicht eingezogen, so dass zuvor das Repository games:tools hinzugefügt werden muss.

Zusätzliche Aktionen für den Start und das Ende des Spielemodus lassen sich in der Datei ~/.config/gamemode.ini definieren. Bei mir sieht diese so aus:

[custom]
start=
  cd && boinccmd --set_run_mode never
  akonadictl stop
  balooctl suspend
  notify-send "GameMode started"
end=
  notify-send "GameMode ended"
  akonadictl start
  balooctl resume
  cd && boinccmd --set_run_mode auto

Mit boinccmd wird Boinc für die dauer der Spielesitzung angehalten. Mit akonadictl halte ich effektiv mein Emailprogram an und mit balooctl schalte ich für die Dauer der Spielesitzung die Indizierung der Desktopsuche aus. Nach Änderungen an der Konfigurationsdatei muss GameMode einmal beendet werden, am einfachsten über killall gamemoded. Durch die nächste Anwendung, welche den GameMode nutzen möchte, wird der Prozess automatisch wieder gestartet, dann mit der neuen Konfiguration.

Für einfache Tests gibt es außerdem noch die Möglichkeit den Spielemodus mittels gamemode -r explizit zu aktivieren. Beenden des Programmes per


Samstag
09. Juni 2018


face

Seit dem 25. Mai 2018 ist openSUSE Leap 15.0 verfügbar. Ein guter Grund mal ein paar Tipps zur Aktualiserung von openSUSE auf eine neue Version zu geben. Da ich für gewöhnlich mithilfe des Installationsmediums aktualisiere beziehen sich meine Tipps primär auf diese Methode. Aber gerade der Hinweis wie man verwaiste Pakete findet ist natürlich auch nach einem sogenannten Live-Upgrade hilfreich.

openSUSE Leap 15.0 ist jetzt verfügbar

Der NVIDIA-Treiber

Meiner Erfahrung nach empfiehlt es sich den NVIDIA-Treiber vor dem Update zu deinstallieren. Bei früheren Versionen von openSUSE habe ich es ansonsten schon erlebt, dass auch nach hinzufügen des NVIDIA-Repositories für die neue Version noch der alte Treiber installiert bleibt. Dieser funktioniert dann allerdings nicht. Linux, bzw. X.org, ist an dieser Stelle zwar hart im Nehmen und nutzt dann automatisch Nouveau, aber dieser kann dem proprietären Treiber von NVIDIA leider nicht annähernd das Wasser reichen.

Sollte das System bereits aktualisiert und Nouveau aktiv sein, so empfiehlt es sich den alten NVIDIA-Treiber mittels zypper remove nvidia* komplett zu deinstallieren und anschließen neu zu installieren. Eine Neuinstallation mittels zypper install --force hat bei mir in der Vergangenheit meißtens nicht den gewünschten Erfolg gebracht.

UEFI

Bei einem System welches sowohl im EFI-Modus als auch im Bios-Kompatibilitätsmodus starten kann ist es wichtig das Upgrade im selben Modus zu starten welchen das alte System nutzt. Bei openSUSE 42.2 endete ich dadurch, dass ich dies nicht getan habe, mit einem nicht bootfähigen System. Allerdings gibt es im Zweifelsfall einen einfachen Ausweg. Einfach auf dem bereits aktualisieren System das Update nochmal im richtigen Modus ausführen. Da alle Pakete schon aktualisiert sind und nur noch der Bootcode korrekt installiert werden muss, geht dies dann auch recht schnell.

Repositories

Bei einem Update mithilfe des Installationsmediums werden alle zusätzlichen Repositories aus dem System entfernt. Dies führt zu einem sauberen Update, kann aber zur Folge haben, dass man anschließend mühsam zusammensuchen muss woher man eine bestimmte Anwendung hatte. Hierzu empfiehlt es sich vor der Aktualisierung einen Überblick zu verschaffen welche Pakete man aus dritten Quellen installiert hat.

Die konfigurierten Repositories

Zypper kann einem mit repos -u die Liste der aktuell konfigurierten Repositories mit ihren URLs ausgeben. So ist es, falls das Repository auch nach dem Update noch benötigt wird, möglich, durch einfaches Ersetzen der Versionsnummer in der URL, an das passende Repository der neuen Version zu kommen. Auf meinem großen Rechner sieht dies dann zum Beispiel so aus:

> zypper repos -u
Die Repository-Prioritäten sind ohne Effekt. Alle aktivierten Repositorys teilen sich die gleiche Priorität.

#  | Alias                           | Name                                                    | Aktiviert | GPG-Überprüfung | Aktualisierung | URI
---+---------------------------------+---------------------------------------------------------+-----------+-----------------+----------------+-------------------------------------------------------------------------------------
1 | code                            | Visual Studio Code                                      | Ja        | (r ) Ja         | Ja             | https://packages.microsoft.com/yumrepos/vscode
2 | download.nvidia.com-leap        | nVidia Graphics Drivers                                 | Ja        | (r ) Ja         | Ja             | http://download.nvidia.com/opensuse/leap/42.3
3 | download.opensuse.org-non-oss   | Haupt-Repository (NON-OSS)                              | Ja        | (r ) Ja         | Ja             | http://download.opensuse.org/distribution/leap/42.3/repo/non-oss/
4 | download.opensuse.org-non-oss_1 | Aktualisierungs-Repository 

Mittwoch
09. Mai 2018


face

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.

Der Startbildschirm von Grid Autosport auf openSUSE

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


Dienstag
24. April 2018


face

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


Sonntag
21. Januar 2018


Pierre Böckmann: Du fehlst

00:21 UTCmember

face

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


Donnerstag
04. Januar 2018


face

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


Montag
01. Januar 2018


face

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 

Freitag
06. Oktober 2017


face

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

Sonntag
01. Oktober 2017


face

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


Samstag
23. September 2017


face

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


Samstag
16. September 2017


face

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


Mittwoch
06. September 2017


face

Eigentlich ist es ja gewünscht wenn das System einem regelmäßig die temporären Dateien wegräumt. Löscht es einem dabei aber auch Dateien welche man gerade erst dort abgelegt hatte, dann steht wohl irgendwas in der Konfiguration schief.

Ich nutze tatsächlich häufig das Verzeichnis /tmp. Gerade beim Schreiben kleiner Skripte ist es ganz angenehm sich im Fehlerfall einfach darauf zu verlassen, dass übrig gebliebene temporäre Dateien schon wieder verschwinden werden. Auch meine virtuellen Python-Umgebungen lege ich, seit mich Holger Peters mal auf diese Idee gebracht hat, stets dort ab. Seit einiger Zeit löschte mir meine openSUSE meine gerade angelegten Dateien aber immer kurz nach dem Systemstart unter der Nase weg.

Da das Problem immer kurz nach dem Systemstart auftrat war schnell klar, dass da wohl der Aufräumcronjob schuld sein muss. Auch wenn dies natürlich inzwischen gar kein Cronjob mehr ist sondern ein Systemd-Timer.

marix@eddie:~> systemctl list-timers
NEXT                         LEFT        LAST                         PASSED       UNIT                         ACTIVATES
Di 2017-09-05 21:10:12 CEST  22h left    Mo 2017-09-04 21:10:12 CEST  1h 9min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.serv
Mo 2017-09-11 00:00:00 CEST  6 days left Mo 2017-09-04 20:55:51 CEST  1h 23min ago fstrim.timer                 fstrim.service

Der alte Cronjob hatte eine Konfigurationsdatei in /etc/sysconfig in der man die Schonzeit für Dateien in /tmp und /var/tmp konfigurieren konnte. Beim Systemd-Job übernehmen die Konfigurationsdateien von systemd-tmpfiles diesen Job. Die dazugehörige Manpage ist tmpfiles.d (5).

Die Standardatei /usr/lib/tmpfiles.d/tmp.conf erklärt auch ganz brav diese Verzeichnisse in Ruhe zu lassen. Das ist zwar nicht ganz was ich möchte, aber auch nicht Grund meines Problemes.

# Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
q /tmp 1777 root root -
q /var/tmp 1777 root root -

Die schuldige Konfiguration fand sich in /etc/tmpfiles.d/tmp.conf. Hier muss, bei einem der vielen Versionsupgrades welche mein System hinter sich hat, ein kleiner Übertragungsfehler passiert sein.

d /tmp 1777 root root 0d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Mit dem Alter Null Tage wird systemd-tmpfiles angewiesen alle Dateien zu löschen, egal wann sie zuletzt modifiziert wurden. Auch wenn dies die meißten Anwendungen in meinem System klaglos hinnahmen sorgte es natürlich für einiges WTF was meine eigenen Skripte und die die virtuellen Python-Umgebungen anging. Die korrektur des Wertes auf einen Tag hat mein Problem erfolgreich gelöst.

d /tmp 1777 root root 1d
d /var/tmp 1777 root root -
x /tmp/* - - - - root

Und das schöne an Systemd ist, dass man so eine Änderung dann auch gleich sehr leicht testen kann.

sudo systemctl start systemd-tmpfiles-clean.service

Eine Anwendung welche mit dem agressiven Aufräumen der temporären Dateien gar nicht klar kommt ist übrigens meine früher so geliebter Browser Opera. Nachdem die temporären Dateien weggräumt wurden findet dieser seine bereits laufende Instanz nicht mehr und fliegt dann beim Versuch


Samstag
05. August 2017


face

Nachdem ich meine Workstation von openSUSE 13.1 auf openSUSE Leap 42.1 migriert hatte funktionierten lies sich die Grafikkarte nicht mehr zum Rechnen nutzen. Irgendwie hatte es einen Fehler bei der Installation des neuen Grafiktreibers gegeben. Seine Neuinstallation löste das Problem.

Das Problem

Nach dem Update fanden CUDA nutzende Anwendungen keine Grafikkarte. So meldete Boinc No usable GPUs found. Prinzipiell funktionierte die Grafikkarte aber. So hatte ich volle 3D-Beschleunigung, und auch nvidia-smi meldete die erwarteten Daten:

+------------------------------------------------------+
| NVIDIA-SMI 340.93     Driver Version: 340.93         |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 580     Off  | 0000:01:00.0     N/A |                  N/A |
| 43%   49C   P12    N/A /  N/A |    494MiB /  1535MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Compute processes:                                               GPU Memory |
|  GPU       PID  Process name                                     Usage      |
|=============================================================================|
|    0            Not Supported                                               |
+-----------------------------------------------------------------------------+

Die Analyse

NVIDIA bietet CUDA zwar für einige SUSE-Varianten zum Download, aber leider nicht für Leap 42.1. Es gibt zwar Pakete für das unterliegende SLE 12, aber diese verlangen einen Grafikttreiber welcher nicht zum Kernel von Leap 42.1 passt. Deshalb habe ich mich für die Analyse auf OpenCL-Beispiel-Code zurückgezogen. Denn für OpenCL benötigt man nur die Header, welche man einfach direkt zum Code legen kann, und einen C-Compiler.

Schon der erste Versuch mit einem Beispielprogramm welches nur die OpenCL-Runtime initialisiert zeigt das Problem:

> sudo ./platform
modprobe: FATAL: Module nvidia-uvm not found.
Failed to get platforms: -1001

Das sudo ist hier übrigens nur vorangestellt um es zu ermöglichen Kernel-Module nachzuladen. Ohne sudo erhält man den gleichen Fehler, aber ohne die essentielle Information zum Kernelmodul.

Schnell konnte ich herausfinden, dass eigentlich alle Kernelmodule installiert sind:

> rpm -ql nvidia-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko
/lib/modules/4.1.12-1-default/updates/nvidia.ko

> rpm -ql nvidia-uvm-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko
/lib/modules/4.1.12-1-default/updates/nvidia-uvm.ko

> ls /lib/modules/4.1.12-1-default/updates/
nvidia.ko  nvidia-uvm.ko

Allerdings war das nicht das Modulverzeichnis des aktuell laufenden Kernels:

> uname -a
Linux eddie 4.1.13-5-default #1 SMP PREEMPT Thu Nov 26 16:35:17 UTC 2015 (49475c3) x86_64 x86_64 x86_64 GNU/Linux

Wo liegen also dessen Module? /lib/modules/4.1.13-5-default/updates existiert nicht. Das NVIDIA-Modul ist aber schnell gefunden:

> ls /lib/modules/4.1.13-5-default/weak-updates/updates/
nvidia.ko

Nur fehlt in diesem Verzeichnis das nvidia-uvm.ko.

Die Lösung

Eine Neuinstallation des dazugehörigen Paketes lässt dann endlich auch OpenCL wieder richtig initialisieren:

> zypper in in -f nvidia-uvm-gfxG03-kmp-default

> ls /lib/modules/4.1.13-5-default/weak-updates/updates/
nvidia.ko  nvidia-uvm.ko

> modprobe nvidia-uvm

> ./platform
Failed to get platforms: -1001

> sudo ./platform
NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE

> ./platform
NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE

Um die Grafikkarte tatsächlich zu verwenden war dann allerdings noch ein Neustart notwendig.

Ältere Artikel ->