Beiträge von ñull

    Ich habe gerade entdeckt, dass in der Anleitung eine für mich sehr wichtige Zeile im Abschnitt Konfigurationsdateien umziehen fehlt. Es hat zu lange gedauert, bis ich die Ursache herausgefunden habe, deshalb berichte ich hier darüber. Es scheint mir wünschenswert, dass auch /usr/lib/liveconfig/lua/custom.lua als Konfiguration gesehen oder zumindest irgendwo erwähnt wird:




    rsync -avR --delete /etc/apache2 /etc/nginx /etc/proftpd \
    /etc/awstats /etc/webalizer \
    /etc/ssl/certs/*.crt /etc/ssl/private \
    /etc/postfix /etc/dovecot /etc/opendkim \
    /etc/liveconfig /var/lib/liveconfig \
    /usr/lib/liveconfig/lua/custom.lua \
    /etc/default/opendkim /etc/default/spamassassin \
    root@destination.example.org:/

    Da ich 2 Tage nach meiner Fehlermeldung feststellte, dass es wieder einwandfrei funktionierte, nahm ich einfach an, dass meine Fehlermeldung vom Administrator des Lizenzportals gelesen und behoben wurde. Wie das Problem behoben wurde, hat mich nicht interessiert, da ich bereits zufrieden war, dass alles wieder funktionierte. Dies dann kurz zu melden, schien mir angemessen und ausreichend.

    Anscheinend haben sie etwas unternommen, um das Problem zu lösen. Ich habe es gerade mit einer neuen Lizenz versucht und es hat wieder funktioniert.


    liveconfig --activate
    _ _ ___ __ _ (R)
    | | (_)_ _____ / __|___ _ _ / _(_)__ _
    | |__| \ V / -_) (__/ _ \ ' \| _| / _` |
    |____|_|\_/\___|\___\___/_||_|_| |_\__, |_____________________________________
    |___/
    Welcome to the LiveConfig license activation.
    License key file: '/etc/liveconfig/liveconfig.key'
    Please enter your license key: XXXX:YYYY:ZZZZ
    Generating license activation request, please wait... ok.
    ok.
    Sending license request... ok.
    => License successfully activated.

    Code
    Using license key from environment variable LCLICENSEKEY
    Generating license activation request, please wait... ok.
     - /usr/sbin/liveconfig: SSL peer certificate validation failed: certificate has expired
     error!
    SSL peer verification failed


    Wenn man die anderen Forenbeiträge liest, sollte dies bei einer Neuinstallation eigentlich nicht passieren. In meinem Fall kann ich Liveconfig natürlich nicht einfach aktualisieren, da es bereits die neueste Version sein sollte. Im Protokoll steht "LiveConfig 2.15.1-release starting...".

    Problem war leider noch nicht gelöst. Nach Neustart ist Bind wieder inaktiv. Doch dann las ich Folgendes:


    Das erklärt einiges. Da ich immer noch auf Bullseye aktualisieren werde, denke ich, dass das Entfernen von Apparmor im Moment gerechtfertigt ist.

    Ich habe die Lösung gefunden! Einige Dienste waren nicht aktiviert und daher konnte bind9 nicht richtig installiert werden. Zuerst habe ich dies versucht:

    Code
    $ dpkg-reconfigure bind9
    /usr/sbin/dpkg-reconfigure: bind9 is broken or not fully installed
    $ apt install bind9
    bind9 is already the newest version (1:9.11.5.P4+dfsg-5.1+deb10u8).
    0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
    1 not fully installed or removed.
    After this operation, 0 B of additional disk space will be used.
    Do you want to continue? [Y/n]


    Ich habe die Fragen mit den Standardoptionen beantwortet (die vorherige Frage kam allerdings nicht zurück). Dann sehe ich wieder diese Meldungen:


    Code
    bind9-pkcs11.service is a disabled or a static unit not running, not starting it.
    bind9-resolvconf.service is a disabled or a static unit not running, not starting it.


    Ich habe sie vorher ignoriert, aber anscheinend versucht bind, diese beiden Unterdienste zu starten und schlägt fehl, weil sie nicht aktiviert sind. Also tat ich folgendes:


    Code
    $ systemctl enable bind9-pkcs11.service
    Created symlink /etc/systemd/system/multi-user.target.wants/bind9-pkcs11.service → /lib/systemd/system/bind9-pkcs11.service.
    $ systemctl enable bind9-resolvconf.service
    Created symlink /etc/systemd/system/bind9.service.wants/bind9-resolvconf.service → /lib/systemd/system/bind9-resolvconf.service.


    Dann habe ich versucht, die Installation erneut durchzuführen:


    Code
    $ apt install bind9
    $ liveconfig --diag
    ...
    Checking for DNS server software:
     - Found 'bind' DNS server
       Version: '9.11.5'
       Package version: '1:9.11.5.P4+dfsg-5.1+deb10u8'
       DNSSEC support: yes
    Done.


    Nach einem Neustart von liveconfig erschien bind auch im Web-Frontend. Nach dem Entfernen des Symlinks und dem Neustart von bind schien auch das erste Problem behoben zu sein:


    Code
    $ rm /etc/apparmor.d/disable/usr.sbin.named
    $ apparmor_parser -R /etc/apparmor.d/usr.sbin.named
    $ systemctl restart bind9
    $ systemctl status bind9
    ● bind9.service - BIND Domain Name Server
       Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
       Active: active (running) since Tue 2023-02-07 19:28:50 CET; 2s ago


    Übrigens, ich habe meine Migration nach den Anweisungen dieses Beitrags durchgeführt: https://unix.stackexchange.com/a/718220/247520

    Ich habe den Apparmor vorübergehend nur für named deaktiviert:

    Code
    ln -s /etc/apparmor.d/usr.sbin.named /etc/apparmor.d/disable/
    apparmor_parser -R /etc/apparmor.d/disable/usr.sbin.named


    Named/bind9 ist jetzt aktiv, wird aber immer noch nicht von Liveconfig erkannt: Keine unterstützten Dienste gefunden.


    All dies gibt mir wenig Vertrauen, dass ich meinen Produktionsserver auf diese Weise aktualisieren kann. Das Funktionieren des DNS ist halt unerlässlich.

    Ich schaffe es nicht, bind9/named nach einer Migration von Ubuntu zu Debian zum Laufen zu bringen. In der Protokolldatei finde ich die folgende Ursache (Wiederholungen weggelassen):

    Code
    Feb 07 11:34:51 hostname audit[13400]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none
    Feb 07 11:34:51 hostname audit[13400]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
    Feb 07 11:34:51 hostname kernel: audit: type=1400 audit(1675766091.081:193): apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none
    Feb 07 11:34:51 hostname kernel: audit: type=1400 audit(1675766091.081:194): apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
    Feb 07 11:34:51 hostname audit[13413]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13413 comm="isc-worker0000" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"
    Feb 07 11:34:51 hostname audit[13413]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13413 comm="isc-worker0000" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none



    Ich habe keine Ahnung von Apparmor und Google scheint nicht sehr hilfreich zu sein. Soll ich apparmor einfach abschalten oder kann das mit einigen Regeln in /etc/apparmor.d/local/usr.sbin.named behoben werden?

    Zusätzliche PHP-Interpreter müssen immer im LiveConfig registriert werden (via Lua).
    Ich nehme das aber gerne mal als Feature Request mit auf, die Pakete von deb.sury.org längerfristig auch direkt (ohne manuelle Registrierung) erkennen zu können.


    Das PS. des ursprünglichen Beitrags gab mir den Eindruck, dass die Funktion bereits Teil Ihrer Roadmap war, aber ich danke Ihnen, dass sie es jetzt ist.

    Beim Hinzufügen einer Subdomain zu einer bestehenden Domain wurden die A/AAAA-Einträge nicht automatisch hinzugefügt. Ich dachte, dass es vielleicht damit zusammenhängt, dass die Subdomain umgeleitet wurde. Also habe ich sie so geändert, dass sie auf einen Ordner verweist. Da sich nichts änderte, versuchte ich es mit "Eigene DNS-Einträge", wodurch sie sofort hinzugefügt wurden.


    Ist dies ein Fehler oder eine Funktion? Bitte erklären Sie das.

    Ich verwende Liveconfig auf Spanisch, und ja, ich habe es in Pootle übersetzt, aber diese Schaltfläche erscheint immer noch auf Spanisch. Auch der Titel "SSL/TLS Certificate Providers" direkt darüber bleibt unübersetzt. Weder die Tabellenüberschrift "Provider" noch "Please choose you SSL provider" und die Beschreibung von Let's Encrypt oder irgendetwas, das beim Erstellen erscheint, ist übersetzt. Würden Sie diesen Fehler bitte überprüfen und beheben? Meine Kunden werden Ihnen dafür dankbar sein.

    Im Änderungsverlauf habe ich dies gesehen:

    Zitat


    Änderungen in Version 2.12.0 (29.07.2021):


    Konfiguration von PHP FPM-Pool-Einstellungen (z.B. pm.max_children) ist nun über die php.ini-Verwaltung möglich


    Ich habe es ausprobiert und pm.max_children hinzugefügt und einen anderen Wert angegeben. Jetzt erscheint es schon in der php.ini des Hosting-Accounts, aber ich sehe nicht, dass es in der /etc/php/7.x/fpm/pool.d/ geändert wurde; es bleibt der Standardwert 8. Was mache ich falsch?