Planet openSUSE Planet openSUSE /images/icon.svg /images/logo.svg 2021-01-20T15:05:12+00:00 https://planet.opensuse.org/de Pluto tag:marix.org,2021-01-04:/cd-roms-von-klett-unter-linux-nutzen.html Matthias Bach https://marix.org 2021-01-03T23:00:00+00:00 2021-01-03T23:00:00+00:00 CD-ROMs von Klett unter Linux nutzen <p>Der <a href="https://www.klett.de">Klett Verlag</a> bietet zu vielen seiner Lehrwerke auch Begleitmaterialien auf CD ROM an. Die Anwendung auf diesen CDs öffnet tatsächlich nur HTML-Datei, so dass sich die CDs durch direktes Öffnen der Datei <code>index.html</code> Datei auch wunderbar auf nicht-Windows-Systemen nutzen ließen. Häufig wird dann aber eine kaputte Seite dargestellt, und die Fehlerkonsole des Browsers beschwert sich über fehlende Dateien, z.B. für die Schriftarten. Des Rätsels Lösung ist, dass diese Dateien auf der Ebene des Joliet-Dateisystems als versteckt markiert sind und für Anwendungen so normalerweise nicht sichtbar sind. Unter Windows kümmert sich die Klett-Anwendung darum diese vor dem Öffnen der <code>index.hml</code> sichtbar zu schalten.</p> <p>Mit dem Wissen darum, dass die Dateien auf Dateisystemebene versteckt sind, kann man die CDs auch unter Linux wunderbar nutzen. Die Lösung findet sich dann beispielsweise <a href="https://askubuntu.com/questions/370906/unable-to-see-files-in-dvd-hidden-using-windows-7">auf askubuntu.com</a>: Die CD muss mit der Option <code>unhide</code> eingebunden werden.</p> <p>Während normalerweise auch Nutzer CDs mounten können, muss dies in diesem Fall allerdings durch Root gemacht werden, da Nutzer keine Optionen beim Mounten angeben dürfen. Auf meinem openSUSE-System führe ich also folgende Schritte aus:</p> <pre><code>mkdir /tmp/klett sudo mount -o unhide -t iso9660 /dev/sr0 /tmp/klett </code></pre> <p>Danach ist die CD mit allen Dateien in <code>/tmp/klett</code> verfügbar und ich kann z.B. mit einem <code>xdg-open /tmp/klett/index.html</code> den Inhalt öffnen.</p> <p>Zur Erklärung der obigen Kommandozeile:</p> <ul> <li>Mit <code>mkdir /tmp/klett</code> lege ich ein temporäres Verzeichnis an. Es in <code>/tmp</code> anzulegen erspart es mir hinterher aufräumen zu müssen.</li> <li> <code>sudo</code> ist Notwendig, da ein normaler Nutzer keine Optionen angeben kann.</li> <li> <code>-o unhide</code> macht die normalerweise versteckten Dateien sichtbar.</li> <li> <code>-t iso9660</code> gibt explizit an welches Dateisystem verwendet wird. <code>mount</code> kann dies normalerweise auch automatisch erkennen.</li> <li> <code>/dev/sr0</code> ist mein optisches Laufwerk.</li> </ul> https://crowbyte.org/de/running-for-the-opensuse-board-ad-hoc-board-elections-2020 Pierre Böckmann https://crowbyte.org/de/ 2020-08-21T13:20:00+00:00 2020-08-21T13:20:00+00:00 Ich kandidiere für das openSUSE board - ad-hoc board elections 2020 <p>Für den Fall, dass Ihr der Mailingliste oder den openSUSE Gruppen in Social Media folgt, könntet ihr mitbekommen haben, dass die openSUSE Community ad-hoc board elections abhält, um einen offenen Platz im openSUSE Board zu füllen.</p><p>Solltet ihr das noch nicht gewusste haben, oder sogar wenn ihr das wusstet, könnte es dennoch sein, dass ihr verpasst habt, dass ich die Ehre habe von Gerald als Kandidat für die Wahl vorgeschlagen worden zu sein - und dass ich diese Nominierung angenommen habe.</p><p>Ic...</p> tag:marix.org,2020-06-21:/den-aktualisierungsstand-von-opensuse-mit-prometheus-uberwachen.html Matthias Bach https://marix.org 2020-06-20T22:00:00+00:00 2020-06-20T22:00:00+00:00 Den Aktualisierungsstand von openSUSE mit Prometheus überwachen <p>Letzte Woche habe ich Version 0.2.1 des <a href="https://gitlab.com/Marix/zypper-patch-status-collector">Zypper-Patch-Status-Collectors</a> veröffentlicht. Mit diesem kleinen, in Python geschriebenen, Helfer lässt sich der Aktualisierungsstand eines openSUSE-Systems durch Prometheus überwachen. Prometheus kann so nicht nur Alarme generieren wenn Sicherheitsaktualisierungen noch nicht angewandt sind, sondern auch wenn einzelne Dienste nach Aktualisierungen noch nicht neu gestartet wurden oder das System neu gestartet werden müsste.</p> <p>Der Collector nutzt Zypper um nach ausstehen Patches und Service- oder Systemneustartbedarf zu schauen und gibt diese Information im Format von Prometheus-Metriken aus. Dies sieht dann so aus wie in der README beschrieben:</p> <pre><code># HELP zypper_applicable_patches The current count of applicable patches # TYPE zypper_applicable_patches gauge zypper_applicable_patches&#123;category="security",severity="critical"} 0 zypper_applicable_patches&#123;category="security",severity="important"} 2 zypper_applicable_patches&#123;category="security",severity="moderate"} 0 zypper_applicable_patches&#123;category="security",severity="low"} 0 zypper_applicable_patches&#123;category="security",severity="unspecified"} 0 zypper_applicable_patches&#123;category="recommended",severity="critical"} 0 zypper_applicable_patches&#123;category="recommended",severity="important"} 0 zypper_applicable_patches&#123;category="recommended",severity="moderate"} 0 zypper_applicable_patches&#123;category="recommended",severity="low"} 0 zypper_applicable_patches&#123;category="recommended",severity="unspecified"} 0 zypper_applicable_patches&#123;category="optional",severity="critical"} 0 zypper_applicable_patches&#123;category="optional",severity="important"} 0 zypper_applicable_patches&#123;category="optional",severity="moderate"} 0 zypper_applicable_patches&#123;category="optional",severity="low"} 0 zypper_applicable_patches&#123;category="optional",severity="unspecified"} 0 zypper_applicable_patches&#123;category="feature",severity="critical"} 0 zypper_applicable_patches&#123;category="feature",severity="important"} 0 zypper_applicable_patches&#123;category="feature",severity="moderate"} 0 zypper_applicable_patches&#123;category="feature",severity="low"} 0 zypper_applicable_patches&#123;category="feature",severity="unspecified"} 0 zypper_applicable_patches&#123;category="document",severity="critical"} 0 zypper_applicable_patches&#123;category="document",severity="important"} 0 zypper_applicable_patches&#123;category="document",severity="moderate"} 0 zypper_applicable_patches&#123;category="document",severity="low"} 0 zypper_applicable_patches&#123;category="document",severity="unspecified"} 0 zypper_applicable_patches&#123;category="yast",severity="critical"} 0 zypper_applicable_patches&#123;category="yast",severity="important"} 0 zypper_applicable_patches&#123;category="yast",severity="moderate"} 0 zypper_applicable_patches&#123;category="yast",severity="low"} 0 zypper_applicable_patches&#123;category="yast",severity="unspecified"} 0 # HELP zypper_service_needs_restart Set to 1 if service requires a restart due to using no-longer-existing libraries. # TYPE zypper_service_needs_restart gauge zypper_service_needs_restart&#123;service="nscd"} 1 zypper_service_needs_restart&#123;service="dbus"} 1 zypper_service_needs_restart&#123;service="cups"} 1 zypper_service_needs_restart&#123;service="sshd"} 1 zypper_service_needs_restart&#123;service="cron"} 1 # HELP zypper_product_end_of_life Unix timestamp on when support for the product will end. # TYPE zypper_product_end_of_life gauge zypper_product_end_of_life&#123;product="openSUSE"} 1606694400 zypper_product_end_of_life&#123;product="openSUSE_Addon_NonOss"} 1000000000000001 # HELP zypper_needs_rebooting Whether the system requires a reboot as core libraries or services have been updated. # TYPE zypper_needs_rebooting gauge zypper_needs_rebooting 0 # HELP zypper_scrape_success Whether the last scrape for zypper data was successful. # TYPE zypper_scrape_success gauge zypper_scrape_success 1 </code></pre> <p>In diesem Beispiel stehen zwei Sicherheitspatches aus und mehrere Services, unter anderem der SSH Daemon, bräuchten einen Neustart weil sie noch mit bereits gelöschten, also durch ein Update ersetzten, Bibliotheken arbeiten.</p> <p>Durch Umleiten der Ausgabe in eine <code>prom</code> Datei ins Textfile-Collector-Verzeichnis des Node-Exporters von Prometheus kommen die Metriken dann ins Monitoring. Wurde der Node-Exporter wie folgt aufgerufen:</p> <pre><code>node_exporter --collector.textfile.directory /var/lib/node_exporter/collector </code></pre> <p>Dann lassen sie die Metriken wie folgt in Prometheus abladen:</p> <pre><code>zypper-patch-status-collector &gt; /var/lib/node_exporter/collector/zypper.prom </code></pre> <p>Stündlich per Systemd Timer aufgerufen hat Prometheus dann eine gute Übersicht über den Aktualisierungszustand der beobachteten openSUSE-Systeme.</p> <p>Sind alle Metriken in Prometheus lassen sich dann auch verschiedene nützliche Alarme definieren. Das folgende ist die Liste der auf dem Collector basierenden Alarme die ich momentan in meinem Alertmanager definiert habe:</p> <pre><code>- alert: 'ZypperPatchesPending' expr: 'sum(zypper_applicable_patches) by (instance) &gt; 0' for: '5m' labels: alert_severity: 'warning' annotations: summary: 'There are new patches available for &#123;&#123; $labels.instance }}.' description: 'Run `zypper patch --with-update` on &#123;&#123; $labels.instance }}.' - alert: 'ZypperCriticalPatchesPending' expr: 'sum(zypper_applicable_patches&#123;category="security"}) by (instance) + sum(zypper_applicable_patches&#123;severity="critical"}) by (instance) &gt; 0' for: '5m' labels: alert_severity: 'page' annotations: summary: 'There are security patches pending on &#123;&#123; $labels.instance }}.' description: 'Run `zypper patch --with-update` on &#123;&#123; $labels.instance }}.' - alert: 'ZypperSuggestsServiceRestart' expr: 'zypper_service_needs_restart' for: '5m' labels: alert_severity: 'warning' annotations: summary: 'Zypper suggest to restart &#123;&#123; $labels.service }} on &#123;&#123; $labels.instance }}.' description: 'Run `systemctl restart &#123;&#123; $labels.service }}` on &#123;&#123; $labels.instance }}.' - alert: 'ZypperSuggestsReboot' expr: 'zypper_needs_rebooting != 0' for: '5m' labels: alert_severity: 'warning' annotations: summary: 'Zypper suggest to reboot &#123;&#123; $labels.instance }}.' description: 'Run `systemctl reboot` on &#123;&#123; $labels.instance }}.' - alert: 'ProductEndOfLifeNear' expr: 'zypper_product_end_of_life &lt; time() + 4 * 7 * 24 * 3600' for: '5m' labels: alert_severity: 'warning' annotations: summary: '&#123;&#123; $labels.product }} on &#123;&#123; $labels.instance }} reaches end of life within four weeks.' description: 'Upgrade &#123;&#123; $labels.product }} on &#123;&#123; $labels.instance }} to the next version.' - alert: 'ProductEndOfLifeReached' expr: 'zypper_product_end_of_life &lt; time()' for: '5m' labels: alert_severity: 'page' annotations: summary: '&#123;&#123; $labels.product }} on &#123;&#123; $labels.instance }} reached end of life.' description: 'Upgrade &#123;&#123; $labels.product }} on &#123;&#123; $labels.instance }} to the next version.' - alert: 'ZypperPatchDataOutdated' expr: 'time() - node_textfile_mtime&#123;file="zypper.prom"} &gt; 24 * 3600' for: '5m' labels: alert_severity: 'page' annotations: summary: 'Patch status has not been updated for 24 hours.' description: | The patch status of &#123;&#123; $labels.instance }} has not been updated for 24 hours. Check the status of the timer and the service: systemctl status zypper-patch-status-collector.timer systemctl status zypper-patch-status-collector.service - alert: 'ZypperScrapeFailed' expr: 'zypper_scrape_success == 0' for: '24h' labels: alert_severity: 'page' annotations: summary: 'Failed to successfully query patch status for 24 hours now.' description: | Querying zypper for the current patch status has not been successful for 24 hours. Check the status of the service: systemctl status zypper-patch-status-collector.service </code></pre> <p>Die Installation des Collectors erfolgt am einfachsten über <a href="https://software.opensuse.org/package/python3-zypper-patch-status-collector">mein Community-Paket auf software.opensuse.org</a>. Ich veröffentliche das Paket zwar auch <a href="https://pypi.org/project/zypper-patch-status-collector/">auf pypi.org</a>, aber ein Werkzeug mit Bezug zu Zypper am System vorbei zu installieren wäre dann doch etwas sehr verquer.</p> tag:marix.org,2020-05-11:/der-schusselige-wlan-client.html Matthias Bach https://marix.org 2020-05-10T22:00:00+00:00 2020-05-10T22:00:00+00:00 Der schusselige WLAN-Client <p>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.</p> <p><img alt="KDE fragt per Dialog nach einem Passwort fürs WLAN" src="//marix.org/Bilder/WLAN-Passwortabfrage.png"></p> <p>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.</p> <p><a href="https://lists.opensuse.org/opensuse/2020-04/msg00581.html">Eine Nachfrage auf der Mailingliste von openSUSE</a> brachte mich dann mit einem Verweis auf <a href="https://lists.opensuse.org/opensuse-de/2019-10/msg00099.html">eine Diskussion auf der deutschsprachigen Liste</a> auf die Lösung des Problems: Anscheinend verursacht die <em>MAC address randomization</em> das Problem. Seit jene abgeschaltet ist trat das Problem nicht mehr auf.</p> <p>Ein einfacher weg die <em>MAC address randomization</em> abzuschalten findet sich auf <a href="https://blog.muench-johannes.de/networkmanager-disable-mac-randomization-314">https://blog.muench-johannes.de/networkmanager-disable-mac-randomization-314</a>. Es ist lediglich die Datei <code>/etc/NetworkManager/conf.d/100-disable-wifi-mac-randomization.conf</code> mit folgendem Inhalt anzulegen:</p> <pre><code>[connection] wifi.mac-address-randomization=1 [device] wifi.scan-rand-mac-address=no </code></pre> <p>Wieso dieses Vorgehen in einem Netzwerk ohne MAC-Adressen-Filter notwendig sein sollte ist mir zwar schleierhaft, aber solange es hilft…</p> <p>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.</p> https://vinzv.de/?p=922104581 Vinzenz Vietzke https://vinzv.de/tag/opensuse/ 2020-01-26T22:59:47+00:00 2020-01-26T22:59:47+00:00 Kandidatur für das openSUSE Board #2: Neue Leute an Bord holen <p>Anknüpfend an die Fragen von Gerald stellte Ariez J. Vachha nun <a href="https://lists.opensuse.org/opensuse-project/2020-01/msg00038.html" target="_blank" rel="noopener noreferrer">eine weitere Frage</a> an die Kandidaten.</p> <p><em>Ein Hinweis: Fragen und Antworten sind <a href="https://vinzv.de/en/running-for-opensuse-board-2-getting-new-people-aboard">ursprünglich auf Englisch</a>. Dies ist nur eine Übersetzung.</em></p> <blockquote><p>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.</p></blockquote> <p>Danke, dass du diese Frage stellst, denn sie berührt ein (wenn nicht gar <strong>das</strong>) entscheidende Thema für openSUSE als Gemeinschaft in der nahen Zukunft.</p> <p>Ich möchte meine Ansicht dazu an einem einfachen Beispiel veranschaulichen:<br> 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.</p> <p>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.</p> <p>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]</p> <p>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]<br> 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.</p> <p>Du hast weitere Fragen? <a href="https://vinzv.de/kontakt/">Schreib mir</a>!</p> <p>[1] <a href="https://lists.opensuse.org/opensuse-project/2019-06/msg00195.html" target="_blank" rel="noopener noreferrer">https://lists.opensuse.org/opensuse-project/2019-06/msg00195.html</a><br> [2] <a href="https://en.opensuse.org/openSUSE:Marketing_meeting:2020-01-08#1.3_Leap_15.2_Beta:_Promote_beta_testing" target="_blank" rel="noopener noreferrer">https://en.opensuse.org/openSUSE:Marketing_meeting:2020-01-08#1.3_Leap_15.2_Beta:_Promote_beta_testing</a></p> https://vinzv.de/?p=922104570 Vinzenz Vietzke https://vinzv.de/tag/opensuse/ 2020-01-16T22:23:58+00:00 2020-01-16T22:23:58+00:00 Kandidatur für das openSUSE Board #2: Fragen und Antworten <p>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.</p> <p>Einen allgemeinen Überblick über meine Vorstellungen und Ziele <a href="https://vinzv.de/kandidatur-fuer-das-opensuse-board/">gibt es hier</a>.</p> <p>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.</p> <p><em>Ein Hinweis: Fragen und Antworten sind <a href="https://vinzv.de/en/running-for-opensuse-board-2-questions-and-answers">ursprünglich auf Englisch</a>. Dies ist nur eine Übersetzung.</em></p> <blockquote><p>1. Was sind deiner Meinung nach die drei, vier Stärken von openSUSE, die wir kultivieren und auf denen wir aufbauen sollten?</p></blockquote> <p>1) Vielfalt der Features<br> 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.</p> <p>2) „Erbe“<br> 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.</p> <p>3) Genehmigungsfreie Gemeinschaft<br> 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.</p> <blockquote><p>2. Was sind die drei größten Risiken, die du für openSUSE siehst? (Und vielleicht Ideen, wie man sie angehen kann?)</p></blockquote> <p>1) Vergessen werden<br> 2) Teilweise unbekannt bleiben<br> 3) Im eigenen Saft schmoren</p> <p>Es könnte auch andere Risiken geben, aber diese drei passen alle zu einem großen Thema: Kommunikation – oder eher dem Fehlen einer solchen.</p> <p>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.</p> <p>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.</p> <p>Das Hauptziel ist es, einen konstanten Fluss interessanter Inhalte für den Rest der Gemeinschaft und für jeden außerhalb von openSUSE aufrechtzuerhalten.</p> <p>Die Antwort auf die folgende Frage erweitert diesen Punkt noch ein wenig.</p> <blockquote><p>3. Was sollte der Vorstand anders / mehr tun?</p></blockquote> <p>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.<br> 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.</p> <p>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.</p> <blockquote><p>4. Wenn du einen Blanko-Gutschein vom SUSE-CEO für einen Wunsch hättest, welcher wäre das?</p></blockquote> <p>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.</p> <blockquote><p>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?)</p></blockquote> <p>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.</p> <p>Du hast weitere Fragen? <a href="https://vinzv.de/kontakt/">Schreib mir</a>!</p> <p><small>(Quelle der Fragen ist <a href="https://lists.opensuse.org/opensuse-project/2020-01/msg00019.html" target="_blank" rel="noopener noreferrer">hier</a>.)</small></p> https://vinzv.de/?p=922104560 Vinzenz Vietzke https://vinzv.de/tag/opensuse/ 2019-11-07T21:34:58+00:00 2019-11-07T21:34:58+00:00 Hotels und Betriebssysteme <blockquote><p>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.</p></blockquote> <p><a href="https://kvz.io/tobuntu.html" target="_blank" rel="noopener noreferrer">Going from macOS to Ubuntu</a> | kvz.io</p> https://crowbyte.org/de/opensuse-project-vote-on-name-change Pierre Böckmann https://crowbyte.org/de/ 2019-10-23T12:10:00+00:00 2019-10-23T12:10:00+00:00 openSUSE Projekt: Abstimmung über Namenänderung <p>Das <a href="https://www.opensuse.org/">openSUSE-Projekt</a> 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 <a href="https://en.opensuse.org/openSUSE:Project_name_change_vote">Wiki-Artikel</a> haben das openSUSE-Board und das Election Committee zudem eine Zusammenfassung der Argumente für und wider einer Namensänderung den Mitgliedern bereit gestellt.</p><h3>Die Hintergründe</h3><p><a href="https://heise.de">Heise</a> berichtet bereits am 12.06.2019 in <a href="https://www.heise.de/newsticker/meldung/openSUSE-Projekt-will-eigene-Foundation-und-erwaegt-Namens-und-Logo-Aenderung-4444959.html">einem Artikel</a> darüber, dass das openSUSE-Projekt...</p> https://vinzv.de/?p=922104546 Vinzenz Vietzke https://vinzv.de/tag/opensuse/ 2019-10-13T21:25:11+00:00 2019-10-13T21:25:11+00:00 Highlights vom openSUSE Asia Summit 2019 <p>Der <a href="https://opensuse.id/osas2019/" target="_blank" rel="noopener noreferrer">openSUSE.Asia Summit</a> 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.</p> <h3>Highlight-Videos Tag 1 und 2</h3> <p><iframe title="Highlight openSUSE Asia Summit 2019 - Day 1" width="640" height="360" src="//www.youtube.com/embed/B-XJ5BgebR4?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p> <p><iframe title="Highlight openSUSE Asia Summit 2019 - Day 2" width="640" height="360" src="//www.youtube.com/embed/YW_u09VuWEA?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p> <p>Weitere Videos mit Vorträgen und Workshops sind <a href="https://www.youtube.com/channel/UCFGB0Tsqn45oBfJyfi-tJVg/featured" target="_blank" rel="noopener noreferrer">auf YouTube</a> verfügbar.</p> tag:marix.org,2019-08-22:/opensuse-leap-151-mit-usb-stick-als-schlussel-fur-die-festplattenverschlusselung.html Matthias Bach https://marix.org 2019-08-21T22:00:00+00:00 2020-07-13T22:00:00+00:00 openSUSE Leap 15.1 mit USB-Stick als Schlüssel für die Festplattenverschlüsselung <p>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 <a href="https://marix.org/usb-stick-als-schl%C3%BCssel-f%C3%BCr-die-festplattenverschl%C3%BCsselung.html">schon damals hier im Blog dokumentiert</a>. 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.</p> <p>Auch auf dem inzwischen erschienenen openSUSE Leap 15.2 funktioniert diese Methode unverändert.</p> <h2 id="festplattenverschlusselung">Festplattenverschlüsselung</h2> <p>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 <code>/boot</code> 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.</p> <p>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.</p> <h2 id="usb-stick-als-schlussel">USB-Stick als Schlüssel</h2> <p>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 <code>/dev/sdb</code> im System zu sehen, kann er wie folgt passend formatiert werden.</p> <pre><code>mkfs.ext2 -L keystick /dev/sdb </code></pre> <p>Das Label <code>keystick</code> 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.</p> <p>Anschließend sollte ein Schlüssel generiert und auf dem USB-Stick hinterlegen werden. Dies kann mit <code>pwgen</code> gemacht werden:</p> <pre><code>pwgen -s 1024 1 &gt; /media/keystick/keyfile </code></pre> <p>Und schließlich muss der Schlüssel der verschlüsselten Partition hinzugefügt werden.</p> <pre><code>cryptsetup luksAddKey /dev/sda2 /media/keystick/keyfile </code></pre> <p>In diesem Beispiel befindet sich die verschlüsselte Partition auf <code>/dev/sda2</code>.</p> <h2 id="usb-stick-beim-booten-nutzen">USB-Stick beim Booten nutzen</h2> <p>Um den Schlüssel beim Booten vom USB-Stick zu lesen muss der Kernelparameter <code>rd.luks.key</code> auf die Schlüsseldatei zeigen.</p> <pre><code>rd.luks.key=/keyfile:LABEL=keystick </code></pre> <p>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.</p> <p>Damit der Parameter <code>rd.luks.key</code> 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 <code>/etc/dracut.conf.d/50-keystick.conf</code> mit folgendem Inhalt anzulegen:</p> <pre><code>omit_dracutmodules+="systemd" </code></pre> <p>Ein anschließendes <code>mkinitrd</code> erzeugt eine Initrd ohne Systemd und das System kann zukünftig bei eingestecktem USB-Stick ohne Passworteingabe gestartet werden.</p> <h2 id="vorteile-gegenuber-der-alten-methode">Vorteile gegenüber der alten Methode</h2> <p><a href="https://marix.org/usb-stick-als-schl%C3%BCssel-f%C3%BCr-die-festplattenverschl%C3%BCsselung.html">Bei der alten Methode</a> 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.</p>