Darknight Coffee Netzwerk

Carrabelloy ' Meine Hobbys sind so vielseitig

Politik & Persönliches

Open Source & KI

Schlagwort: admin

  • Was bei Hetzner, DNS und YunoHost wirklich passiert ist

    Was bei Hetzner, DNS und YunoHost wirklich passiert ist

    In den letzten Tagen hatte ich massive Probleme mit meinem YunoHost-Server bei Hetzner.
    Das Admin-Panel war teilweise erreichbar, teilweise nicht. Zertifikate liefen aus, Firefox blockierte Zugriffe wegen HSTS, und Dienste wie Mastodon, WordPress, Matrix, Diaspora,Screensa verhielten sich instabil oder sehr träge. Oder waren nicht aufrufbar. Wie E-Mail-Verkehr.

    Das Entscheidende vorweg:
    Das Problem lag nicht bei YunHost, nicht bei Firefox und nicht bei meinem Server.
    Die Ursache ist die laufende DNS-Migration bei Hetzner.

    1. Die Ausgangslage

    Mein Setup:

    Hetzner VPS

    YunHost

    mehrere Domains (example.org, .eu, Subdomains wie srv, cloud, netz, treff, mastodon ,wp,dia,)

    automatische Let’s-Encrypt-Zertifikate

    DNS bisher über die alte Hetzner DNS-Konsole

    Hetzner hat angekündigt:

    Die alte DNS-Konsole (dns.hetzner.com) wird abgeschaltet.
    Bestehende Zonen müssen in die neue Hetzner Console migriert werden.

    👉 Klingt harmlos – ist es aber nicht, wenn man Server betreibt.

    2. Das sichtbare Problem (Symptome)

    Folgende Dinge traten gleichzeitig auf:

    Firefox zeigt bei https://example.org/yunhost/sso: dns dmg

    HSTS-Fehler

    keine Möglichkeit, eine Ausnahme hinzuzufügen

    Server YunHost meldet:

    „DNS records are different to this server’s IP“

    Zertifikate lassen sich nicht erneuern

    Mastodon:

    Föderation instabil

    Verbindungsprobleme

    dig zeigt:

    intern: 1000.0.0.1

    extern: andere IPs als erwartet

    👉 Klassisches Zeichen für inkonsistente DNS-Quellen.

    3. Warum das so kritisch ist (HSTS erklärt)

    example.org nutzt HTTP Strict Transport Security (HSTS).

    Das bedeutet:

    Browser dürfen nur HTTPS

    abgelaufene oder falsche Zertifikate = kompletter Zugriff gesperrt

    kein „Ich vertraue trotzdem“-Button

    💡 Das ist kein Bug – das ist Sicherheit.

    Wenn DNS → falsche IP
    dann Zertifikat → falsch
    dann Browser → blockiert

    Kette geschlossen. Ende.

    4. Der entscheidende Hinweis: Zwei DNS-Welten gleichzeitig

    Was wirklich passiert ist:

    Alte Hetzner DNS-Konsole existiert noch

    Neue Hetzner Console existiert schon

    Domains sind teilweise migriert

    Teilweise zeigen Records noch auf alte IPs

    Teilweise schon auf neue IPs

    Ergebnis:

    Je nach Resolver (Server intern, Cloudflare, ISP, Browser)
    bekommst du unterschiedliche Antworten.

    Das ist der Worst Case für:

    Zertifikate

    Mail

    Föderation (Mastodon und weitere Anwendungen)

    Admin-Portale

    5. Warum Hetzner-Support mir nicht helfen konnte

    Ich habe:

    ein Ticket eröffnet

    telefonisch nachgefragt

    Antwort (ehrlich & wichtig):

    Der aktuelle Telefonsupport ist nur für Hardware & Rechenzentrum zuständig.
    DNS-Migration = anderes Team.
    Konkrete Hilfe zur neuen DNS-Console: aktuell kaum möglich.

    👉 Das ist keine böse Absicht – die Migration läuft noch.

    6. Warum der „Workaround“ keine Lösung ist

    Ja, man kann:
    yunhost domain cert renew DOMAIN –no-checks

    Das funktioniert kurzfristig.

    ❌ Aber:

    DNS bleibt falsch

    Zertifikate brechen beim nächsten Renew

    Mail bleibt fehleranfällig

    Mastodon und weitere Programme bleiben instabil.

    Das ist Flickschusterei – keine Lösung.

    7. Die saubere Lösung (kein Workaround) ✅
    Schritt 1: Eine einzige DNS-Quelle

    👉 Entscheiden:

    Entweder neue Hetzner Console

    oder externer DNS (z. B. deSEC, Cloudflare)

    ❌ Nicht beides gleichzeitig

    Da bei mir Cloudflare genauso vorhanden ist, bin ich erst spät darauf gekommen.

    Schritt 2: Alle A / AAAA Records korrekt setzen

    Für jede Domain & Subdomain:

    A → 1000.200.100.10

    AAAA → 2e001:4a9:122:39001::3

    Keine alten IPs mehr (987.201.222.100, …259d::3).

    Schritt 3: Wildcards & Mail sauber nachziehen

    * A / AAAA setzen

    MX setzen

    SPF / DKIM / DMARC aktualisieren

    CAA für Let’s Encrypt setzen

    (YunHost sagt dir exakt, was fehlt – das ist Gold wert.)

    Schritt 4: Warten (leider ja)

    DNS braucht:

    Minuten bis Stunden

    manchmal 24–48 Stunden

    Erst danach:

    Zertifikate erneuern

    Dienste testen

    Mastodon stabilisieren

    8. Warum jetzt plötzlich wieder manches geht

    Du hast es selbst beobachtet:

    Zertifikat für example.org geht wieder

    Admin-Panel über ddd.example.org funktioniert

    Probleme treten nur über das Portal / SSO auf

    👉 Das bestätigt:
    DNS-Inkonsistenz, nicht Serverfehler.
    Per Terminal kommt man weiter partiell

    9. Fazit

    Das hier ist wichtig – für alle mit Servern:

    DNS-Migrationen sind kein Detail.
    Sie sind kritisch für alles darüber.

    YunoHost funktioniert korrekt.
    Firefox reagiert korrekt.
    HSTS schützt korrekt.

    Nur DNS muss einmal sauber, vollständig und einheitlich gemacht werden.
    Und danach sollte Ihr Server wieder sauber laufen.

  • Titel: Warum kann ich trotz bekanntem Passwort keine Befehle mit sudo ausführen?

    Titel: Warum kann ich trotz bekanntem Passwort keine Befehle mit sudo ausführen?

    In diesem Blogbeitrag möchte ich über ein häufiges Problem sprechen, das beim Versuch auftreten kann, Befehle mit erhöhten Rechten auf einem Linux-System auszuführen, obwohl das Passwort bekannt ist. Dieses Problem kann besonders verwirrend sein, insbesondere für Anfänger. Ich werde erklären, warum dies passieren kann und wie es behoben werden kann.

    Das Problem:

    Kürzlich wollte ich meinen Laptop neu einrichten und einige Updates durchführen. Ich versuchte, Befehle mit sudo auszuführen, aber jedes Mal, wenn ich mein Passwort eingab, erhielt ich eine Fehlermeldung, die besagte, dass mein Benutzerkonto nicht in der sudoers-Datei aufgeführt war. Obwohl ich sicher war, dass ich mein Passwort richtig eingegeben hatte, konnte ich immer noch keine Befehle mit erhöhten Rechten ausführen.

    Die Lösung:

    Nach einiger Recherche fand ich heraus, dass mein Benutzerkonto nicht zur sudoers-Datei hinzugefügt wurde, was bedeutet, dass ich keine Berechtigung hatte, Befehle mit sudo auszuführen. Die sudoers-Datei ist eine Konfigurationsdatei auf Linux-Systemen, die steuert, welche Benutzer oder Gruppen Befehle mit erhöhten Rechten ausführen dürfen.

    Um dieses Problem zu lösen, musste ich mein Benutzerkonto zur sudoers-Datei hinzufügen. Dies konnte durch Bearbeiten der sudoers-Datei erreicht werden. Dabei musste ich einige Vorsichtsmaßnahmen beachten, um sicherzustellen, dass ich keine versehentlichen Änderungen vornahm, die das System beeinträchtigen könnten.

    Die Lösung in Aktion:

    Ich öffnete ein Terminal und wechselte in den Root-Modus, um die sudoers-Datei zu bearbeiten:

    bash
    Copy code
    sudo su –
    Anschließend öffnete ich die sudoers-Datei mit einem Texteditor:

    bash
    Copy code
    visudo
    In der sudoers-Datei fügte ich eine Zeile hinzu, um mein Benutzerkonto zur Liste der Benutzer mit sudo-Berechtigungen hinzuzufügen:

    plaintext
    Copy code
    carrabelloy ALL=(ALL:ALL) ALL
    Dadurch erhielt mein Benutzerkonto carrabelloy die Berechtigung, Befehle mit sudo auszuführen.

    Nachdem ich die Änderungen gespeichert und die sudoers-Datei geschlossen hatte, konnte ich Befehle mit sudo erfolgreich ausführen, ohne dass ich erneut nach meinem Passwort gefragt wurde.

    Schlussfolgerung:

    Es ist wichtig zu verstehen, wie die sudoers-Datei funktioniert und wie Benutzerkonten korrekt hinzugefügt oder entfernt werden können, um Probleme wie dieses zu vermeiden. Durch das Hinzufügen meines Benutzerkontos zur sudoers-Datei konnte ich das Problem erfolgreich lösen und meine gewünschten Befehle mit erhöhten Rechten ausführen.

    Ich hoffe, dieser Blogbeitrag war hilfreich und hat dazu beigetragen, dieses häufige Problem zu verstehen. Bei weiteren Fragen können Sie gerne einen Kommentar hinterlassen.