staging.inyokaproject.org

2026 Woche 35

30. August 2026

Kurz notiert: Das Debian-Projekt hat sich in einer Abstimmung mit dem Einsatz von generativer KI im Projekt beschäftigt. Zur Debatte stand, ob und wie die Regeln angepasst werden sollen, ob ein Verbot kommen soll oder der Einsatz begrüßt wird. Das betrifft nicht nur Code, sondern auch Kommunikation wie Bug Reports oder Beiträge auf Mailinglisten.

Acht Vorschläge für den Umgang mit Gen AI standen zur Abstimmung, diese reichten von "No LLM contributions to Debian via Social Contract", also ein nachdrückliches Verbot, bis hin zu "Allow AI-Assisted Contributions with conditions". Darüber hinaus waren auch moderate Optionen vertreten.

Die durchaus moderate Option "Responsible Use of Generative AI" hat sich schließlich in der Präferenzwahl durchgesetzt.

Kurz zum Wahlverfahren, da gibt es nämlich einen spannenden Einblick. Da bei Debian-Abstimmungen die Wähler mit einer Rangfolge inkl. der Sonderoption "Keine der genannten Optionen" (also Ablehnung aller Wahloptionen) abstimmen, lässt sich ablesen, dass ein AI-Ban extrem schlecht ankam. Die beiden kritischen ablehnenden Optionen 1 und 3 landeten sogar hinter "Keine der genannten Optionen".

Die damit einhergehende Diskussion wurde - trotz des moderaten Ergebnisses - durchaus kontrovers geführt. Einerseits ist das Debian-Projekt, das sich traditionell stark für freie Software einsetzt, mit den lizenzrechtlichen Auswirkungen konfrontiert. Denn die LLMs nutzen die Quelltexte von Debian und anderen Projekten fürs Training und es bleibt weiterhin die rechtliche Frage offen, inwieweit Urheberrechte auf LLM-Erzeugnisse geltend gemacht werden können. Andererseits ist Debian auf die Upstream-Projekte angewiesen, die weitaus mehr KI-Einsatz zulassen können, als man selber verantworten möchte.

Und zu guter Letzt bleibt natürlich die Frage der Nachweisbarkeit von KI-Nutzung, auch wenn Anbieter wie Anthrophic zunehmend Wasserzeichen in ihre Erzeugnisse integrieren.

Daher liest sich der angenommene Vorschlag wie ein pragmatischer Versuch, mit einer Entwicklung umzugehen, die nun einfach da ist und im besten Fall den Maintainern erlaubt, in der gleichen kostbaren Zeit mehr Beiträge für das Projekt zu stemmen. Ob GenAI den Output sinnvoll multipliziert oder durch Slop und massenhafte Bug Reports die kostbare Zeit auffrisst, wird sich in den nächsten Monaten und Jahren zeigen. Aber aufzuhalten wäre es trotzdem nicht.

Am Ende stellt der Vorschlag auf etwas ab, das sowieso schon im Projekt gilt. Hinter jedem automatisierten (KI-)System steht ein Mensch, der die Arbeit von diesem verantwortet. Und dieser Umgang ist schon ausreichend geregelt. Ob nun ein LLM die halbe Codebase umschreiben will oder ein kontroverser Maintainer, läuft inhaltlich auf die gleiche Diskussion hinaus. Offen bleibt nur, ob sich die Sorge vor dem Spam weiterhin bewahrheitet.

29. August 2026

Hugo Konfiguration

In deiner hugo.yaml muss der Parameter ShowShareButtons unter params: auf true gesetzt sein:

params:
  ...
  ShowShareButtons: true
  ...

Template vorbereiten

  1. Kopiere die Datei themes/PaperMod/layouts/partials/share_icons.html
  2. in dein Projektverzeichnis: layouts/partials/share_icons.html.

So überschreibst du die Theme-Datei, ohne sie direkt zu verändern.

Copy Button

Dieser Button kopiert einen Post in den Zwischenspeicher, der so aussieht:

# Die Populismusfalle: Warum Logik gegen Populismus versagt

https://hyperblog.de/hoergen/posts/2026/2026-08-09-die-populismusfalle/ 
#demhoergen #hyperblog #Linux #hugo #Fedivers #blog #Friendica #Mastodon

Die Bestätigung eines Populisten zu suchen, ist die höchste Form der Dummheit. Ansätze wie man mit Populisten umgehen kann.

Im Kopf der Definition können noch eigene Hashtags hinzugefügt werden. Dort wo hier im Beispiel “#demhoergen #hyperblog” steht.

Der Code muss genau so am Anfang positioniert werden.

<li>
{{- if (cond ($custom) (in $ShareButtons "copy") (true)) }}
{{- $hashtags := "#demhoergen #hyperblog" -}}
{{- with .Params.tags -}}
    {{- range $index, $tag := . -}}
        {{- $hashtags = printf "%s #%s" $hashtags $tag -}}
    {{- end -}}
{{- end -}}

<button onclick="copyToClipboard()"
        aria-label="Link kopieren"
        style="background:none;border:none;cursor:pointer;">
    <svg viewBox="0 0 24 24" width="24" height="24" fill="currentColor">
        <path d="M16 1H4c-1.1 0-2 .9-2 2v14h2V3h12V1zm3 4H8c-1.1 0-2 .9-2 2v14c0 1.1.9 2 2 2h11c1.1 0 2-.9 2-2V7c0-1.1-.9-2-2-2zm0 16H8V7h11v14z"/>
    svg>
button>

<script>
function copyToClipboard() {
    const title = "{{ $title | plainify }}";
    const url = "{{ $pageurl | absURL }}";
    const description = "{{ .Params.description | plainify }}";
    const tags = "{{ $hashtags }}";

    const text = `\# ${title}\n\n${url} \n${tags}\n\n${description}`;

    navigator.clipboard.writeText(text).then(() => {
        alert('Artikel-Infos in die Zwischenablage kopiert!');
    }).catch(err => {
        console.error('Fehler beim Kopieren: ', err);
    });
}
script>
{{- end }}
li>

Hugo Konfiguration

In deiner hugo.yaml muss der Parameter ShowShareButtons unter params: auf true gesetzt sein:

params:
  ...
  ShowShareButtons: true
  ...

Template vorbereiten

  1. Kopiere die Datei themes/PaperMod/layouts/partials/share_icons.html
  2. in dein Projektverzeichnis: layouts/partials/share_icons.html.

So überschreibst du die Theme-Datei, ohne sie direkt zu verändern.

Copy Button

Dieser Button kopiert einen Post in den Zwischenspeicher, der so aussieht:

# Die Populismusfalle: Warum Logik gegen Populismus versagt

https://hyperblog.de/hoergen/posts/2026/2026-08-09-die-populismusfalle/ 
#demhoergen #hyperblog #Linux #hugo #Fedivers #blog #Friendica #Mastodon

Die Bestätigung eines Populisten zu suchen, ist die höchste Form der Dummheit. Ansätze wie man mit Populisten umgehen kann.

Im Kopf der Definition können noch eigene Hashtags hinzugefügt werden. Dort wo hier im Beispiel “#demhoergen #hyperblog” steht.

Der Code muss genau so am Anfang positioniert werden.

<li>
{{- if (cond ($custom) (in $ShareButtons "copy") (true)) }}
{{- $hashtags := "#demhoergen #hyperblog" -}}
{{- with .Params.tags -}}
    {{- range $index, $tag := . -}}
        {{- $hashtags = printf "%s #%s" $hashtags $tag -}}
    {{- end -}}
{{- end -}}

<button onclick="copyToClipboard()"
        aria-label="Link kopieren"
        style="background:none;border:none;cursor:pointer;">
    <svg viewBox="0 0 24 24" width="24" height="24" fill="currentColor">
        <path d="M16 1H4c-1.1 0-2 .9-2 2v14h2V3h12V1zm3 4H8c-1.1 0-2 .9-2 2v14c0 1.1.9 2 2 2h11c1.1 0 2-.9 2-2V7c0-1.1-.9-2-2-2zm0 16H8V7h11v14z"/>
    svg>
button>

<script>
function copyToClipboard() {
    const title = "{{ $title | plainify }}";
    const url = "{{ $pageurl | absURL }}";
    const description = "{{ .Params.description | plainify }}";
    const tags = "{{ $hashtags }}";

    const text = `\# ${title}\n\n${url} \n${tags}\n\n${description}`;

    navigator.clipboard.writeText(text).then(() => {
        alert('Artikel-Infos in die Zwischenablage kopiert!');
    }).catch(err => {
        console.error('Fehler beim Kopieren: ', err);
    });
}
script>
{{- end }}
li>

28. August 2026

Wenn ich unterwegs bin, möchte oder muss ich ab und zu Notizen erstellen. Da mir in solch einem Fall teilweise nur ein Browser und ein Internetzugang zur Verfügung stehen, habe ich seit längerem HedgeDoc verwendet. So ganz zufrieden war ich damit aber nie.

HedgeDoc hat für mich vor allem zwei Nachteile. Zum einen ist das Programm ein ziemlicher Brocken (Node.js, Datenbank usw.). Und zum anderen verwendet HedgeDoc zwar Markdown für die Notizen, speichert diese aber in der Datenbank und nicht in einzelnen Markdown-Dateien. Was einen Export umständlicher macht.

Die Alternativen, die ich bisher angesehen habe, haben mir alle nicht zugesagt. Oft war es die Bedienung. Oder es wird eine Technik vorausgesetzt, die mein Webspace nicht anbietet. Docker zum Beispiel. Oder die Entwicklung ist eingeschlafen, obwohl es noch genug offene Probleme gibt. Oder oder oder. Irgendwas war immer.

Gestern bin ich zufällig auf LeafWiki gestoßen. Und auch wenn es nicht perfekt ist, bin ich erstaunt, wie gut es meinen Wünschen entspricht. Wie wenn ich es selbst programmiert hätte, wenn ich programmieren könnte.

Fangen wir mal mit der Installation an. LeafWiki besteht im Grunde nur aus einer, mit Golang erstellten, Datei. Grob gesagt, reicht es also fast schon, die Datei herunterzuladen und auszuführen. Bei Uberspace.de habe ich für die Installation (inkl. dem Anlegen eines Web-Backends, eines Services und der Subdomain) geschätzt keine 5 Minuten benötigt. Für die reine Installation von HedgeDoc brauche ich merklich länger.

Was den Funktionsumfang betrifft, kann LeafWiki nicht mit HedgeDoc mithalten, bietet aber eigentlich alles, was ich will.

  • Tags
  • Organisation in einer Baumansicht
  • Suchfunktion
  • Verlinkung
  • Metadaten
  • WYSIWYG-Ansicht

Mehr brauche ich eigentlich nicht, sodass HedgeDoc eigentlich schon immer zu überladen war. LeafWiki bietet aber aktuell noch weitere Funktionen wie Drag and Drop oder auf TOTP basierende 2FA. Andere Funktionen sind zudem geplant. Wie zum Beispiel die Lokalisierung der Oberfläche. Die nächste Version wird somit voraussichtlich auch in Deutsch und nicht nur in Englisch angeboten werden.

25. August 2026

Um in Hugo und dem Theme PaperMod einen dedizierten RSS-Feed nur für das Tag “Linux” zu erstellen, der den vollständigen Artikelinhalt enthält, musst du eine Kombination aus Hugo-Konfiguration und einem spezifischen Template anlegen. Hier ist die dafür notwendige Schritt-für-Schritt-Anleitung in 3 Schritten

1. RSS-Feed für Tags aktivieren

Zuerst muss sichergestellt sein, dass Hugo überhaupt RSS-Feeds für einzelne Tags (Term-Seiten) generiert. Dies wird über die outputs-Einstellung in deiner hugo.yaml gesteuert . Stelle sicher, dass term (für einzelne Begriffe wie Tags) die Ausgabe rss enthält:

outputs:
  home: ["html", "rss"]
  section: ["html", "rss"]
  taxonomy: ["html", "rss"]
  term: ["html", "rss"] # Wichtig für einzelne Tags

Mit dieser Konfiguration erstellt Hugo für jedes Tag, z.B. “linux”, einen Feed unter einer Standard-URL wie /tags/linux/index.xml . Dies ist eine wichtige Grundvoraussetzung.

2. Workaround Datei _index.md für das Tag “Linux” erstellen

Es muss im Verzeichnis content/tags/linux/ der layout-Parameter in der Datei _index.md gesetzt werden.

  1. Erstelle die Inhaltsdatei für das Tag: Lege die Datei content/tags/linux/_index.md an.
  2. Setze den layout-Parameter: Füge in die Frontmatter dieser Datei den Befehl layout = 'linux-tag' ein.

Der Inhalt der Datei könnte so aussehen:

---
title: "Linux"
layout: "linux-tag"
---

Willkommen auf der Seite für alle Artikel zum Thema Linux.

3. Das RSS-Template linux-tag.rss.xml für den Volltext anpassen

Nun erstellst du das Template mit dem Namen layouts/tags/linux-tag.rss.xml. Dieses Template wird dann exklusiv für die Tag-Seite “Linux” verwendet, da du den layout-Parameter entsprechend gesetzt hast .

In deiner neu erstellten Datei layouts/tags/linux-tag.rss.xml kannst du nun den Inhalt anpassen, um den vollständigen Artikel auszugeben.

Der entscheidende Unterschied ist die Verwendung von .Content anstelle von .Summary im -Tag - ganz unten. Dies stellt sicher, dass der gesamte Artikel im Feed erscheint. Die anderen Tags verwenden weiterhin das Standard-Template (z.B. layouts/taxonomy/tag.rss.xml) und bleiben unverändert.

Die Datei kann so aussehen:

{{- $pctx := . -}}
{{- if .IsHome -}}{{ $pctx = .Site }}{{- end -}}
{{- $pages := slice -}}
{{- if or $.IsHome $.IsSection -}}
{{- $pages = $pctx.RegularPages -}}
{{- else -}}
{{- $pages = $pctx.Pages -}}
{{- end -}}
{{- $limit := .Site.Config.Services.RSS.Limit -}}
{{- if ge $limit 1 -}}
{{- $pages = $pages | first $limit -}}
{{- end -}}
{{- printf "" | safeHTML }}
 version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  
    </span>{{ if eq .Title .Site.Title }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{.}} on {{ end }}{{ .Site.Title }}{{ end }}<span>
    {{ .Permalink }}
    Recent content {{ if ne .Title .Site.Title }}{{ with .Title }}in {{.}} {{ end }}{{ end }}on {{ .Site.Title }}
    {{- with .Site.Params.images }}
    
      </span>{{ $.Site.Title }}<span>
      {{ index . 0 | absURL }}
      {{ index . 0 | absURL }}
    
    {{- end }}
    Hugo -- gohugo.io
    {{ with .Site.LanguageCode }}
    {{.}}
    {{ end }}
    {{ with .Site.Copyright }}
    {{.}}
    {{ end }}
    {{ if not .Date.IsZero }}
    {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
    {{ end }}
    {{- with .OutputFormats.Get "RSS" -}}
    {{ printf " href=%q rel=\"self\" type=%q />" .Permalink .MediaType | safeHTML }}
    {{- end -}}
    {{ range $pages }}
    
      </span>{{ .Title }}<span>
      {{ .Permalink }}
      {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
      {{ .Permalink }}
      
      
      
      {{ .Content | html }}
      {{ .Content | html }}
    
    {{ end }}
  

Zusammenfassung der Lösung

Um nur für das Tag “Linux” einen Volltext-Feed zu erstellen, musst du also die outputs-Konfiguration anpassen, eine _index.md-Datei für das Tag mit einem spezifischen layout-Parameter anlegen und dann ein entsprechendes RSS-Template mit .Content erstellen. So erhältst du einen dedizierten Feed unter der URL https://DEINEWEBSEITE.DE/tags/linux/index.xml (oder einer ähnlichen, von dir konfigurierten URL), der alle Artikel des Tags “Linux” im Volltext enthält.

Bonus URL Umleitung mit Apache und .htaccess

Wenn du eine alte URL auf die neue URL umleiten musst, wie ich das musste, dann muss noch im root Verzeichnisses deines Webspaces die .htaccess Datei verändert und der Apache Webserver neu gestartet werden

Trage folgenden Redirect ein. Das Format lautet mit relativen Pfadangaben

Redirect 301 /alter/pfad/ /neuer/pfad/

Das könnte z.B. so aussehen:

Redirect 301 /hoergen/tag/linux/feed/ /hoergen/categories/linux/index.xml

Nicht vergessen!

systemctl restart apache2.service

Um in Hugo und dem Theme PaperMod einen dedizierten RSS-Feed nur für das Tag “Linux” zu erstellen, der den vollständigen Artikelinhalt enthält, musst du eine Kombination aus Hugo-Konfiguration und einem spezifischen Template anlegen. Hier ist die dafür notwendige Schritt-für-Schritt-Anleitung in 3 Schritten

1. RSS-Feed für Tags aktivieren

Zuerst muss sichergestellt sein, dass Hugo überhaupt RSS-Feeds für einzelne Tags (Term-Seiten) generiert. Dies wird über die outputs-Einstellung in deiner hugo.yaml gesteuert . Stelle sicher, dass term (für einzelne Begriffe wie Tags) die Ausgabe rss enthält:

outputs:
  home: ["html", "rss"]
  section: ["html", "rss"]
  taxonomy: ["html", "rss"]
  term: ["html", "rss"] # Wichtig für einzelne Tags

Mit dieser Konfiguration erstellt Hugo für jedes Tag, z.B. “linux”, einen Feed unter einer Standard-URL wie /tags/linux/index.xml . Dies ist eine wichtige Grundvoraussetzung.

2. Workaround Datei _index.md für das Tag “Linux” erstellen

Es muss im Verzeichnis content/tags/linux/ der layout-Parameter in der Datei _index.md gesetzt werden.

  1. Erstelle die Inhaltsdatei für das Tag: Lege die Datei content/tags/linux/_index.md an.
  2. Setze den layout-Parameter: Füge in die Frontmatter dieser Datei den Befehl layout = 'linux-tag' ein.

Der Inhalt der Datei könnte so aussehen:

---
title: "Linux"
layout: "linux-tag"
---

Willkommen auf der Seite für alle Artikel zum Thema Linux.

3. Das RSS-Template linux-tag.rss.xml für den Volltext anpassen

Nun erstellst du das Template mit dem Namen layouts/tags/linux-tag.rss.xml. Dieses Template wird dann exklusiv für die Tag-Seite “Linux” verwendet, da du den layout-Parameter entsprechend gesetzt hast .

In deiner neu erstellten Datei layouts/tags/linux-tag.rss.xml kannst du nun den Inhalt anpassen, um den vollständigen Artikel auszugeben.

Der entscheidende Unterschied ist die Verwendung von .Content anstelle von .Summary im -Tag - ganz unten. Dies stellt sicher, dass der gesamte Artikel im Feed erscheint. Die anderen Tags verwenden weiterhin das Standard-Template (z.B. layouts/taxonomy/tag.rss.xml) und bleiben unverändert.

Die Datei kann so aussehen:

{{- $pctx := . -}}
{{- if .IsHome -}}{{ $pctx = .Site }}{{- end -}}
{{- $pages := slice -}}
{{- if or $.IsHome $.IsSection -}}
{{- $pages = $pctx.RegularPages -}}
{{- else -}}
{{- $pages = $pctx.Pages -}}
{{- end -}}
{{- $limit := .Site.Config.Services.RSS.Limit -}}
{{- if ge $limit 1 -}}
{{- $pages = $pages | first $limit -}}
{{- end -}}
{{- printf "" | safeHTML }}
 version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  
    </span>{{ if eq .Title .Site.Title }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{.}} on {{ end }}{{ .Site.Title }}{{ end }}<span>
    {{ .Permalink }}
    Recent content {{ if ne .Title .Site.Title }}{{ with .Title }}in {{.}} {{ end }}{{ end }}on {{ .Site.Title }}
    {{- with .Site.Params.images }}
    
      </span>{{ $.Site.Title }}<span>
      {{ index . 0 | absURL }}
      {{ index . 0 | absURL }}
    
    {{- end }}
    Hugo -- gohugo.io
    {{ with .Site.LanguageCode }}
    {{.}}
    {{ end }}
    {{ with .Site.Copyright }}
    {{.}}
    {{ end }}
    {{ if not .Date.IsZero }}
    {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
    {{ end }}
    {{- with .OutputFormats.Get "RSS" -}}
    {{ printf " href=%q rel=\"self\" type=%q />" .Permalink .MediaType | safeHTML }}
    {{- end -}}
    {{ range $pages }}
    
      </span>{{ .Title }}<span>
      {{ .Permalink }}
      {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
      {{ .Permalink }}
      
      
      
      {{ .Content | html }}
      {{ .Content | html }}
    
    {{ end }}
  

Zusammenfassung der Lösung

Um nur für das Tag “Linux” einen Volltext-Feed zu erstellen, musst du also die outputs-Konfiguration anpassen, eine _index.md-Datei für das Tag mit einem spezifischen layout-Parameter anlegen und dann ein entsprechendes RSS-Template mit .Content erstellen. So erhältst du einen dedizierten Feed unter der URL https://DEINEWEBSEITE.DE/tags/linux/index.xml (oder einer ähnlichen, von dir konfigurierten URL), der alle Artikel des Tags “Linux” im Volltext enthält.

Bonus URL Umleitung mit Apache und .htaccess

Wenn du eine alte URL auf die neue URL umleiten musst, wie ich das musste, dann muss noch im root Verzeichnisses deines Webspaces die .htaccess Datei verändert und der Apache Webserver neu gestartet werden

Trage folgenden Redirect ein. Das Format lautet mit relativen Pfadangaben

Redirect 301 /alter/pfad/ /neuer/pfad/

Das könnte z.B. so aussehen:

Redirect 301 /hoergen/tag/linux/feed/ /hoergen/categories/linux/index.xml

Nicht vergessen!

systemctl restart apache2.service

Mozilla hat mit Firefox 154.0.1 sein wöchentliches Korrektur-Update veröffentlicht. Dieser Artikel beschreibt die Änderungen des neuesten Updates.

Download Mozilla Firefox 154.0.1

Firefox 154 aktivierte einen in Rust geschriebenen Speicher für Zugangsdaten, was zu verschiedenen Problemen für einen Teil der Nutzer führte, darunter unerwartete Aufforderungen beim Start von Firefox auf Windows oder Öffnen von PDF-Dateien, das Hauptpasswort einzugeben, sowie ein langsamerer Zugriff auf gespeicherte Zugangsdaten. Aus diesem Grund wurde die Änderung temporär rückgängig gemacht und in der Zwischenzeit neu gespeicherte Zugangsdaten in den alten Speicher zurück migriert.

Für Windows-Nutzer, die Firefox aus dem Startmenü entfernt haben, hatte sich Firefox ungewollt von alleine wieder hinzugefügt.

Das automatische Ausfüllen von Adress-Formularen konnte fehlschlagen.

Ein Kontrastproblem in Zusammenhang mit Tab-Gruppen bei Verwendung eines dunklen Themes wurde behoben. Unter Windows konnten die Titel von Tabs am Anfang abgeschnitten dargestellt werden, wenn MS UI Gothic als Systemschrift festgelegt ist. Außerdem wurde ein Darstellungsproblem im Lesezeichen-Menü korrigiert, wenn Namen von Lesezeichen in einer Sprache waren, in der von rechts nach links geschrieben wird.

Im Entwicklerwerkzeug Stilbearbeitung zeigte Firefox bei jedem Speichern einer lokalen CSS-Datei den Dialog zur Auswahl des Speicherorts an. Außerdem konnte das Lineal auf der Seite sichtbar bleiben, nachdem die Entwicklerwerkzeuge geschlossen wurden.

Es wurde ein Problem behoben, bei dem auf einigen über HTTP geladenen Websites Verbindungen zu lokalen Netzwerkgeräten fehlschlugen, ohne dass eine Berechtigungsabfrage angezeigt wurde.

Experimente konnten unter Umständen erst nach einem Neustart des Browsers starten.

In Snap-Builds auf Linux konnte das Anwendungsmenü verlangsamt öffnen.

KI-Funktionen konnten unter Umständen bei Verwendung einer 32-Bit-Version unter Windows fehlschlagen. Darüber hinaus gab es diverse Anpassungen für die sogenannten intelligenten Fenster, einem KI-Feature, welches derzeit schrittweise ausgerollt wird.

Zwei potenzielle Absturzursachen wurden behoben.

Der Beitrag Mozilla veröffentlicht Firefox 154.0.1 erschien zuerst auf soeren-hentzschel.at.

24. August 2026

Mit dem Befehl sudo BEFEHL werden Befehle mit den Rechten eines anderen Benutzers (meist root) ausgeführt. Das ist praktisch, wenn du administrative Aufgaben erledigen musst, aber nicht dauerhaft als root angemeldet sein willst. Der Name steht für “superuser do” – also “als Superuser ausführen”.

Grundlegende Verwendung

## Als root ausführen
sudo apt update
## Als anderer Benutzer ausführen
sudo -u benutzer BEFEHL
## Vorherigen Befehl mit sudo wiederholen
sudo !!

Bei der ersten Nutzung in einer Sitzung wirst du nach deinem eigenen Passwort gefragt. Das ist nicht das root-Passwort, sondern dein Benutzerpasswort.

Wer darf sudo nutzen?

Die Berechtigung wird in der Datei /etc/sudoers festgelegt. Diese Datei wird nicht direkt editiert, sondern mit dem Befehl visudo.

sudo visudo

Warum visudo?

  • Syntaxprüfung - Prüft die Datei vor dem Speichern auf Fehler – sonst könnte sudo komplett ausfallen
  • Sperrmechanismus - Verhindert, dass zwei Administratoren gleichzeitig die Datei ändern
  • Editor-Auswahl - Öffnet standardmäßig nano oder vi (je nach System)

Typische Einträge in der sudoers-Datei

## Ein einzelner Benutzer darf alles
hoergen  ALL=(ALL:ALL) ALL

## Eine Gruppe darf alles
%admin   ALL=(ALL:ALL) ALL

## Benutzer darf nur bestimmte Befehle
hoergen  ALL=(ALL) /usr/bin/systemctl restart nginx

## Ohne Passwortabfrage (vorsichtig verwenden!)
hoergen  ALL=(ALL) NOPASSWD: /usr/bin/apt update

Aufbau eines Eintrags in sudoers

BENUTZER  HOST=(BENUTZER:GRUPPE)  BEFEHLE
Feld Bedeutung
BENUTZER Wer darf sudo nutzen? (oder %gruppe)
HOST Auf welchem Rechner? (ALL für alle)
(BENUTZER:GRUPPE) Als welcher Benutzer/Gruppe? (ALL für alle)
BEFEHLE Welche Befehle? (ALL für alle)

Wichtige Parameter

Option Bedeutung
-u benutzer Als anderer Benutzer ausführen (default: root)
-i Als root einloggen (Login-Shell)
-s Shell als root starten
-l Eigene sudo-Berechtigungen anzeigen
-k Sudo-Cache zurücksetzen (Passwort neu abfragen)
-v Sudo-Zeit verlängern (ohne Befehl)

Praktische Beispiele

## System aktualisieren
sudo apt update && sudo apt upgrade -y

## Datei bearbeiten, die root gehört
sudo nano /etc/hosts

## Als Benutzer "www-data" einen Befehl ausführen
sudo -u www-data php artisan cache:clear

## Dienst neu starten
sudo systemctl restart nginx

## Eigene Rechte anzeigen
sudo -l

Unterschied: sudo vs su

Befehl Bedeutung
sudo BEFEHL Führt einen Befehl mit root-Rechten aus (benötigt eigenes Passwort)
su - Wechselt dauerhaft zu root (benötigt root-Passwort)
sudo -i Wechselt zu root (benötigt eigenes Passwort)

Vorteil von sudo:

  • Kein root-Passwort nötig
  • Genaue Kontrolle über erlaubte Befehle
  • Jeder Befehl wird protokolliert
  • Zeitlich begrenzte Rechte (Standard: 15 Minuten)

Sicherheitsaspekte

Protokollierung

Alle sudo-Befehle werden in /var/log/auth.log (Debian/Ubuntu) oder /var/log/secure (RHEL) protokolliert.

## Letzte sudo-Befehle anzeigen
sudo tail -f /var/log/auth.log | grep sudo

Best Practices

# NICHT machen – zu viel Rechte
hoergen  ALL=(ALL:ALL) NOPASSWD: ALL

# BESSER – gezielt einschränken
hoergen  ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

## NOCH BESSER – nur was wirklich nötig ist
hoergen  ALL=(ALL) /usr/bin/apt update, /usr/bin/apt upgrade -y

Wichtige Sicherheitshinweise

  • Niemals NOPASSWD: ALL verwenden – das ist ein Sicherheitsrisiko.
  • Regelmäßig prüfen, wer sudo-Rechte hat: sudo -l -U benutzer
  • Bei Fehlern: visudo prüft die Syntax vor dem Speichern.
  • Standard-Sudo-Zeit (15 Minuten) kann mit -k zurückgesetzt werden.

Häufige Fehler und Lösungen

## Fehler: "user is not in the sudoers file"
## Lösung: Benutzer zur Gruppe sudo hinzufügen
usermod -aG sudo benutzername

## Fehler: "command not found"
## Lösung: vollen Pfad angeben oder sudo mit PATH nutzen
sudo -E env "PATH=$PATH" befehl

## Fehler: "sorry, try again"
## Lösung: Passwort prüfen oder sudo-Cache zurücksetzen
sudo -k

Tipp für Fortgeschrittene

## Aliase in sudoers für bessere Übersicht
User_Alias  ADMIN = hoergen, anna, sarah
Cmnd_Alias  SYSTEM = /usr/bin/systemctl, /usr/bin/apt
ADMIN       ALL=(ALL) SYSTEM

## Befehle ohne Passwort für bestimmte Aktionen
hoergen     ALL=(ALL) NOPASSWD: /usr/bin/apt update
hoergen     ALL=(ALL) /usr/bin/apt upgrade -y

Zusammenfassung

  • sudo erlaubt kontrollierte Ausführung mit root-Rechten.
  • Die Berechtigungen werden in /etc/sudoers festgelegt.
  • visudo ist der sichere Weg, diese Datei zu bearbeiten.
  • Immer so wenig Rechte wie möglich vergeben.
  • Alle Aktionen werden protokolliert.

Mit dem Befehl sudo BEFEHL werden Befehle mit den Rechten eines anderen Benutzers (meist root) ausgeführt. Das ist praktisch, wenn du administrative Aufgaben erledigen musst, aber nicht dauerhaft als root angemeldet sein willst. Der Name steht für “superuser do” – also “als Superuser ausführen”.

Grundlegende Verwendung

## Als root ausführen
sudo apt update
## Als anderer Benutzer ausführen
sudo -u benutzer BEFEHL
## Vorherigen Befehl mit sudo wiederholen
sudo !!

Bei der ersten Nutzung in einer Sitzung wirst du nach deinem eigenen Passwort gefragt. Das ist nicht das root-Passwort, sondern dein Benutzerpasswort.

Wer darf sudo nutzen?

Die Berechtigung wird in der Datei /etc/sudoers festgelegt. Diese Datei wird nicht direkt editiert, sondern mit dem Befehl visudo.

sudo visudo

Warum visudo?

  • Syntaxprüfung - Prüft die Datei vor dem Speichern auf Fehler – sonst könnte sudo komplett ausfallen
  • Sperrmechanismus - Verhindert, dass zwei Administratoren gleichzeitig die Datei ändern
  • Editor-Auswahl - Öffnet standardmäßig nano oder vi (je nach System)

Typische Einträge in der sudoers-Datei

## Ein einzelner Benutzer darf alles
hoergen  ALL=(ALL:ALL) ALL

## Eine Gruppe darf alles
%admin   ALL=(ALL:ALL) ALL

## Benutzer darf nur bestimmte Befehle
hoergen  ALL=(ALL) /usr/bin/systemctl restart nginx

## Ohne Passwortabfrage (vorsichtig verwenden!)
hoergen  ALL=(ALL) NOPASSWD: /usr/bin/apt update

Aufbau eines Eintrags in sudoers

BENUTZER  HOST=(BENUTZER:GRUPPE)  BEFEHLE
Feld Bedeutung
BENUTZER Wer darf sudo nutzen? (oder %gruppe)
HOST Auf welchem Rechner? (ALL für alle)
(BENUTZER:GRUPPE) Als welcher Benutzer/Gruppe? (ALL für alle)
BEFEHLE Welche Befehle? (ALL für alle)

Wichtige Parameter

Option Bedeutung
-u benutzer Als anderer Benutzer ausführen (default: root)
-i Als root einloggen (Login-Shell)
-s Shell als root starten
-l Eigene sudo-Berechtigungen anzeigen
-k Sudo-Cache zurücksetzen (Passwort neu abfragen)
-v Sudo-Zeit verlängern (ohne Befehl)

Praktische Beispiele

## System aktualisieren
sudo apt update && sudo apt upgrade -y

## Datei bearbeiten, die root gehört
sudo nano /etc/hosts

## Als Benutzer "www-data" einen Befehl ausführen
sudo -u www-data php artisan cache:clear

## Dienst neu starten
sudo systemctl restart nginx

## Eigene Rechte anzeigen
sudo -l

Unterschied: sudo vs su

Befehl Bedeutung
sudo BEFEHL Führt einen Befehl mit root-Rechten aus (benötigt eigenes Passwort)
su - Wechselt dauerhaft zu root (benötigt root-Passwort)
sudo -i Wechselt zu root (benötigt eigenes Passwort)

Vorteil von sudo:

  • Kein root-Passwort nötig
  • Genaue Kontrolle über erlaubte Befehle
  • Jeder Befehl wird protokolliert
  • Zeitlich begrenzte Rechte (Standard: 15 Minuten)

Sicherheitsaspekte

Protokollierung

Alle sudo-Befehle werden in /var/log/auth.log (Debian/Ubuntu) oder /var/log/secure (RHEL) protokolliert.

## Letzte sudo-Befehle anzeigen
sudo tail -f /var/log/auth.log | grep sudo

Best Practices

# NICHT machen – zu viel Rechte
hoergen  ALL=(ALL:ALL) NOPASSWD: ALL

# BESSER – gezielt einschränken
hoergen  ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

## NOCH BESSER – nur was wirklich nötig ist
hoergen  ALL=(ALL) /usr/bin/apt update, /usr/bin/apt upgrade -y

Wichtige Sicherheitshinweise

  • Niemals NOPASSWD: ALL verwenden – das ist ein Sicherheitsrisiko.
  • Regelmäßig prüfen, wer sudo-Rechte hat: sudo -l -U benutzer
  • Bei Fehlern: visudo prüft die Syntax vor dem Speichern.
  • Standard-Sudo-Zeit (15 Minuten) kann mit -k zurückgesetzt werden.

Häufige Fehler und Lösungen

## Fehler: "user is not in the sudoers file"
## Lösung: Benutzer zur Gruppe sudo hinzufügen
usermod -aG sudo benutzername

## Fehler: "command not found"
## Lösung: vollen Pfad angeben oder sudo mit PATH nutzen
sudo -E env "PATH=$PATH" befehl

## Fehler: "sorry, try again"
## Lösung: Passwort prüfen oder sudo-Cache zurücksetzen
sudo -k

Tipp für Fortgeschrittene

## Aliase in sudoers für bessere Übersicht
User_Alias  ADMIN = hoergen, anna, sarah
Cmnd_Alias  SYSTEM = /usr/bin/systemctl, /usr/bin/apt
ADMIN       ALL=(ALL) SYSTEM

## Befehle ohne Passwort für bestimmte Aktionen
hoergen     ALL=(ALL) NOPASSWD: /usr/bin/apt update
hoergen     ALL=(ALL) /usr/bin/apt upgrade -y

Zusammenfassung

  • sudo erlaubt kontrollierte Ausführung mit root-Rechten.
  • Die Berechtigungen werden in /etc/sudoers festgelegt.
  • visudo ist der sichere Weg, diese Datei zu bearbeiten.
  • Immer so wenig Rechte wie möglich vergeben.
  • Alle Aktionen werden protokolliert.