Beiträge von Nolz

    Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/

    (das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.


    Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.

    Genau das hatte ich bei zwei Domains. Gute Erklärung, habe ich es mir also doch nicht eingebildet 😄


    Ist das auch der Grund dafür, dass KSKs mit Algo 13/14 gar nicht erst gepublished werden?

    Bei mir wurde in jedem Fall von Bind immer ein neuer KSK mit Algo 7 erzeugt und die Policy lc-nsec3rsasha1-2048 angewandt.

    Ich habe jetzt über die GUI neue Algo 7 Keys erzeugt, beim zweiten Versuch werden jetzt die verwendet, da die erwähnte Bedingung mit den Key-Tags wohl nicht mehr zutrifft.

    Ich habe mich mal etwas mit den lc* Diensten beschäftigt, da keine Mails mehr kamen. Vielleicht hat ja noch jemand das Problem.

    Das Maillog war voll mit:

    Aug 03 17:04:55 hashtag postfix/smtpd[1335974]: warning: connect to private/lcpolicyd: No such file or directory

    Aug 03 17:04:55 hashtag postfix/smtpd[1335974]: warning: problem talking to server private/lcpolicyd: No such file or directory


    - Für den lcpolicyd hatte ich nur eine lcpolicd.conf-dist unter /etc/liveconfig liegen. Daher wollte der Dienst nicht so wirklich seine Arbeit aufnehmen. Nach lcpolicd.conf kopieren und Neustarten hat geholfen.

    - Der lclogparse Dienst ließ sich gar nicht starten, da er die lclogparse.service nicht finden konnte:


    [465647] [2025-08-03 17:24:23.929248] [ERR] Failed to start service unit lclogparse: Unit lclogparse.service not found.

    [465646] [2025-08-03 17:24:23.929551] [ERR] Error while handling request: Unit lclogparse.service not found.


    habe sie dann aus /usr/lib/liveconfignach /lib/systemd/system kopiert, aktiviert und dann wurde der Dienst auch sofort in der UI als laufend angezeigt.

    - unter /etc/systemd/system/multi-user.target.wants/ sind die Links zu lclogsplit.service und lcsam.service broken. Die Dienste laufen aber, da sie scheinbar über /etc/init.d/ gestartet werden.


    Mails funktionieren jetzt wieder. Mir scheint als wurde der Installationsprozess hier nicht komplett zu Ende ausgeführt. Das Log gibt dazu leider nichts her.

    Jetzt habe ich aber scheinbar wirklich einen Fehler gefunden, der durch das Upgrade entstanden ist. Ich habe phpMyAdmin und Roundcube als Anwendung installiert. beide sind aber im Status error. Im findet man dazu:


    [3855806] [2025-08-01 19:13:04.814518] [ERR] Error while creating Database: Username already exists!

    [3855806] [2025-08-01 19:13:04.814740] [ERR] Error while creating Database: Username already exists!

    [3855805] [2025-08-01 19:13:05.337996] [ERR] App installation failed for app 1: Username already exists!

    [3855805] [2025-08-01 19:13:05.615638] [ERR] App installation failed for app 2: Username already exists!


    Die ganze Zeit standen auch keine Statistiken in der Datenbank Übersicht bei den beiden Datenbanken. Bei der für Roundcube steht jetzt seit ein paar Minuten "2 Tabellen". Allerdings habe ich nichts an den Datenbanken verändert, ausser mich einmal in PMA anzumelden auf einer anderen Datenbank.


    Edith: die Datenbanken wurden bei der Aktion gelöscht. Also vorher schön Backup machen 🙂


    Edith v2: Wenn ich eine neue App installieren möchte, habe ich im Log folgenden Fehler und die Seite wo ich eine App auswählen soll bleibt leer. Vielleicht gab es den auch bei der Migration:

    [465646] [2025-08-02 19:55:51.413975] [EMERG] Uncaught exception: [json.exception.type_error.316] invalid UTF-8 byte at index 142: 0x75

    [465646] [2025-08-02 19:55:51.414013] [EMERG] METHOD: GET; URL: /liveconfig/api/v1/apps

    [465646] [2025-08-02 19:55:51.414024] [EMERG] Got exception: nlohmann::json_abi_v3_11_3::detail::type_error

      [ 0] 0x271ea5   

      [ 1] 0x273b86   

      [ 2] 0x27422b   

      [ 3] 0x274086   

      [ 4] 0x27422b   

      [ 5] 0x123b44   /usr/lib/liveconfig/libk.so.0.9

      [ 6] 0x123c92   /usr/lib/liveconfig/libk.so.0.9

      [ 7] 0x7ef415   

      [ 8] 0xf7a35    /usr/lib/liveconfig/libk.so.0.9

      [ 9] 0x125c4a   /usr/lib/liveconfig/libk.so.0.9

      [10] 0x3a6240   

      [11] 0xd44a3    /lib/x86_64-linux-gnu/libstdc++.so.6

      [12] 0x891f5    /lib/x86_64-linux-gnu/libc.so.6

      [13] 0x10989c   /lib/x86_64-linux-gnu/libc.so.6

    Alle lc* Dienste waren bei mir nach dem Upgrade masked. Ich habe sie unmasked und dann lief es.

    Also die Migration hat ohne weitere Probleme geklappt. Die Keys wurden erfolgreich verschoben. In der named.conf.options steht allerdings noch

    dnssec-secure-to-insecure   yes;, laut dem Wiki Artikel sollte das aber entfernt werden?


    Das prüfen des DNSSEC Status mit rndc dnssec -status <zone> hatte aber auch nach etwas Wartezeit nie omnipresent angezeigt. Da fing es dann langsam an, dass sämtliche Zonen (alle DNSSEC signiert) teilweise nicht mehr erreichbar waren. Im LiveConfig Log hab ich dann gesehen, dass er immer Fehler bei Domain Aktualisierungen geschmissen hat, bzgl. des DNS Templates. Beim erneuten Speichern des Templates wurde mir ein externer Nameserver als fehlerhaft markiert. In dem Servernamen stand etwas in Klammern, scheinbar mag LiveConfig 3 an dieser Stelle keine Sonderzeichen (mehr). Unter LC2 war das kein Problem. Bearbeiten konnte ich den Eintrag aber nicht mehr. Also Downgrade auf LC2 gemacht (Danke, dass das so einfach geht!!), Template/externen Server editiert und von sämtlichen Sonderzeichen befreit, Upgrade auf LC3 gemacht, noch mal gespeichert, hat funktioniert. Somit konnte ich zumindest die Domains wieder bearbeiten. Ich habe zwar immer noch den Fehler [ERR] Can't add domain to object log: invalid domain or DNS template immer mal wieder im Log, aber es scheint soweit alles zu funktionieren.


    Danach gabs jede Menge Hickhack mit den Keys (durch mich verschuldet, nicht durch LiveConfig). Scheinbar hat sich an der Art wie man DNSSEC einrichtet in den letzten Jahren etwas geändert. Ich hatte beim Registrar immer den DNSKEY und den DS, welcher mir in LC2 angezeigt wurde, hinterlegt (musste man das nicht früher so machen?). Scheinbar macht man das nicht mehr, und der DNSKEY reicht. War ne lange Nacht 🙃 Jetzt scheint es sich aber langsam etwas zu beruhigen. Interessanterweise wird scheinbar immer noch ein Key mit Algo 7 genutzt, obwohl ich jetzt nur noch einen Key mit Algo 14 hinterlegt habe.


    Eine Sache die ich aber noch nicht ganz verstanden habe: über rndc dnssec -status wird manchmal die policy "insecure" angezeigt und keine der in der Config definierten Policies. Hab ich da was kaputt gemacht, oder gibt es dafür einen anderen Grund? Das Log sagt dazu nichts.


    Edit: das passiert, wenn man bei einer Zone DNSSEC deaktiviert, etwas wartet, dann wieder aktiviert und den Status mit rndc dnssec -status <zone> prüft. Da steht dann bei allen Keys Key has been removed from the zone und auch nach längerer Wartezeit ändert sich an dem zustand nichts. Auch wenn man einen neuen Key erstellt, wird der nicht sofort (nach dem speichern) unter /var/lib/bind/keys/ geschrieben. Mit einem stop von named und LC und einem starten von LC, wodurch named wieder mutgestartet wird, geht es dann wieder.


    Nicht DNSSEC bezogen: Sämtliche lc* Dienste waren nach dem Upgrade im masked state. Sollte das so sein?


    Fazit: Ich dachte Anfangs bei dem Upgrade sei etwas schiefgelaufen, aber ich war zu ungeduldig und hätte vielleicht bis Dienstag warten sollen, wenn der Upgrade Guide kommt 😅 Da ich aber nie Probleme bei LC Updates hatte, hatte ich erwartet/gehofft, dass es einfach durchläuft, so wie immer. Ich hatte aber nicht mit meinem fehlenden Wissen über DNSSEC gerechnet. Zu meiner Verteidigung: ich mache das nicht Professionell, eher als Hobby für das man wenig Zeit hat. Daher schätze ich LC so, da es für gewöhnlich ohne Probleme läuft. 😄

    So ähnlich mache ich es auch. Habe eine Domain mit LE Zertifikat die Proxy für :8443 spielt und schiebe das LE Zertifikat regelmäßig in das sslcert. So hat man noch die Möglichkeit über :8443 zuzugreifen, falls der Apache mal nicht will.

    Hallo,


    mir ist aufgefallen, dass wenn man 2FA per FIDO2 und OTP aktiviert, zumindest in Safari immer die Abfrage nach FIDO2 kommt. Wenn man dort auf abbrechen klickt, um den OTP Code (das Fenster für die Eingabe erscheint im Hintergrund) einzugeben - weil man vielleicht den FIDO Stick nicht dabei hat - wird der Login Vorgang ebenfalls abgebrochen mit der Fehlermeldung

    Code
    Unexpected server answer. Login not possible: NotAllowedError: This request has been cancelled by the user.


    Lässt sich das durch LiveConfig ändern, oder ist das etwas Browser bedingtes, was sich nicht abfangen lässt?


    Viele Grüße

    Hallo,
    ich habe genau das gleiche Problem bei einem neuinstalliertem Debian 11.


    OpenDKIM 2.11.0beta2-4 ist installiert, läuft und ist auch in LC aktiviert.


    /etc/postfix/main.cf:

    Code
    [COLOR=#000000][FONT=Menlo]smtpd_milters = unix:/var/run/clamav/clamav-milter.ctl, unix:/var/run/lcsam.sock, unix:/var/spool/postfix/opendkim/opendkim.sock[/FONT][/COLOR]


    Bei mir wurde der Eintrag durch LC hinzugefügt und verschwindet, wenn ich OpenDKIM deaktiviere.


    Beim versenden einer Mail werden keinerlei OpenDKIM spezifische Einträge im Log geschrieben.


    Würde mich über Hilfe freuen.



    Edit: scheint doch zu klappen. Habe mich auf den MXToolbox Report verlassen, aber der scheint nicht zuverlässig zu sein.

    Hallo in die Runde,


    ist es beabsichtigt, dass die <Domainname>.httpd.conf nicht eingebunden wird, wenn man als Weiterleitungsmethode Proxy auswählt?


    Ich wollte dem Dienst Basic Auth vorschalten, da der selber keinen Login Mechanismus anbietet. Dies könnte ich ja theoretisch über die <Domainname>.httpd.conf machen, oder habe ich da irgendwo noch einen Knoten im Hirn? .htaccess im Web Verzeichnis des Dienstes (außerhalb von /var/www) hilft leider nicht.


    Oder ginge das noch anders?


    Vielen Dank schon mal und viele Grüße :)

    Guten morgen,


    ich grabe das Thema nochmal aus. Ich habe eine komplett neue Umgebung mit zwei Servern hochgezogen. beide Server werden mit LC verwaltet. Ich habe alles nur über die GUI konfiguriert und nirgendwo in der Datenbank oder Configfiles rumgedoktort.
    Folgendes Verhalten:


    Server 1 keys.liveconfig:

    Code
    [FONT=Monaco]key "LC-f09fXXXX"key "LC-0390XXXX"key "LiveConfig"[/FONT]


    Server 2 keys.liveconfig:

    Code
    [FONT=Monaco]key "LC-f09fXXXX"key "LC-0390XXXX"key "LiveConfig"[/FONT]


    Soweit so gut.


    Bei Server 1 stehen die IP's von Server 2 und bei Server 2 die IP's von Server 1.
    Bei jeder IP auf jedem Server steht aber der Key "LC-f09fXXXX".
    In der zones.liveconfig auf Server 1 steht bei jeder Domain für die Server 1 der Master ist

    Code
    [FONT=Monaco]allow-transfer { key LC-0390XXXX.; };[/FONT]


    Auf Server 2 steht bei jeder Domain für die dieser Server der Master ist

    Code
    [FONT=Monaco]allow-transfer { key LC-f09fXXXX.; };[/FONT]


    Im Log von Server 1 steht

    Code
    [FONT=Monaco]X.X.X.X#43927/key lc-f09fXXXX (example.org): zone transfer 'example.org/IXFR/IN' denied[/FONT]


    Weil er da offensichtlich den falschen Key für nimmt. Ein Transfer von Server 2 zu Server 1 funktioniert aber problemlos.


    Verstehe ich hier was falsch, oder ist das wirklich ein Fehler?