Posts by ñull

    Derzeit werden die Repository-Schlüssel auf die gleiche Weise aktualisiert wie in der Installationsanleitung beschrieben wird:

    Code
    wget -O /root/liveconfig-keyring.deb https://www.liveconfig.com/liveconfig-keyring.deb
    dpkg -i /root/liveconfig-keyring.deb

    In der Demo sehe ich die Sprachen Arabisch, Deutsch, Englisch und Niederländisch. Arabisch und Niederländisch sind vorhanden, aber vieles ist dort noch Englisch.


    Wann wird Ihre Pootle-Seite auch Liveconfig 3 enthalten? Wäre es nicht schöner, wenn die Übersetzungen vor der Veröffentlichung weitgehend fertig sind?

    Ich habe einen alten Server, den ich vorübergehend deaktiviert, aber als Snapshot behalten habe. Aus vorübergehend wurde dauerhaft. Jahre später habe ich versucht, ihn wiederherzustellen, aber irgendwie funktioniert die Vernetzung nicht mehr. In diesem Offline-Zustand ist es unmöglich, ihn aus der Serververwaltung von Liveconfig zu entfernen.


    Wie kann man den Servereintrag trotzdem entfernen, ohne dass er online ist? Gibt es eine (My)SQL-Abfrage, um dies sicher zu tun, ohne die Datenbankintegrität von Liveconfig zu beeinträchtigen?

    Mistake: Debian 11 still has php 7.4.33 as default. 8.x can only be installed with an additional PHP repository.


    I removed all php to avoid confusion between standard and Sury php. Then I reinstalled from Sury php 8. 0.x and php 8.1.x. I run and see:

    Code: bash shell
    systemctl restart liveconfig; liveconfig --diag
    
    Running OS diagnostics... (LiveConfig 2.16.0-release)
    ....
    
    Running Lua diagnostics...
    [WARNING] addPHP: incomplete FPM configuration for '/usr/sbin/php-fpm8.0' - skipping...
    [WARNING] addPHP: incomplete FPM configuration for '/usr/sbin/php-fpm8.1' - skipping...

    The warnings were for the missing ['fpm']['reload'] which I had commented out. I included it and corrected eol year:



    After Switching to FPM the affected site shows me this message when I access the site with my browser:


    Quote from php page with <?php phpinfo() ?>

    Service Unavailable

    The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

    In apache's configuration I see:


    Code: /etc/apache2/sites-available/contract-name.conf
        <IfModule mod_proxy_fcgi.c>
            <FilesMatch ".+\.ph(p[3457]?|t|tml|ps)$">
                SetHandler "proxy:unix:/run/php80-fpm/<subscription-name>.sock|fcgi://localhost"
                SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
            </FilesMatch>
        </IfModule>

    The run folder however does not exist, only /run/php. I finally made the socket folder common for all and in /run/php :

    I am not sure if that will again cause conflicts when switching versions. I experienced these when after switching php version the FPM service complained that a socket (of the previous PHP version) already existed. The old socket under the other PHP version remained active and was apparently not closed when the version change took place. I tried changing from 8.0.x to 8.1.x and sure enough I see it again after restarting:

    Quote from systemctl restart php8.0-fpm; systemctl status php8.0-fpm

    sep 06 11:58:00 hostname php-fpm8.0[767720]: [06-Sep-2023 11:58:00] ERROR: Another FPM instance seems to already listen on /run/php/<subscription-name>.sock

    sep 06 11:58:00 hostname php-fpm8.0[767720]: [06-Sep-2023 11:58:00] ERROR: FPM initialization failed

    After some time it restored itself although I doubt that 8.0.x was still working because initialization failed. This is however a client with their own dedicated server with limited damage when you are aroud to solve it. Aparently a restart like this seems to solve the issue:



    Code: bash shell
    systemctl restart php8.{0,1}-fpm.service apache2 mariadb
    systemctl status php8.{0,1}-fpm.service apache2 mariadb

    Some more instruction is helpful for external repositories to avoid wrong recognition of Lc internals. Apparently Lc looks at the Debian version and the expected default version (in my case Debian 11 with php 8.0). The ID used here is php8. To distinguish sury from the LC provided repos in /opt, I used a different IDs namely php80sury. This causes a confusion that created and additional php8 version with mixed erroneous paths . I did not try it but I guess that the default will then fail to work correctly.

    The only workaround I found is to follow the undocumented convention:


    1. remove all default /opt based luas; when you use external repos they are simply not needed.
    2. make your own luas and let the php 8 version have 'id' php8 . Only then the internal default recognition code is overridden. It recognises the 'id' not the PHP version.

    Here I post the still untested pattern for php8:


    This is how far I got but I see more errors. FPM seems to have become fully disconfigured. I have given up on it for lack of time. Any hints are appreciated how to get this working with fpm and sury repository. I don't mind answers in German.

    Fehlermeldung:

    Quote

    An error occured while processing your request: mysql_stmt_execute: (1451) Cannot delete or update a parent row: a foreign key constraint fails (`LIVECONFIG`.`USERS`, CONSTRAINT `USERS_ibfk_2` FOREIGN KEY (`U_CONTACTID`) REFERENCES `CONTACTS` (`CON_ID`))

    LC 2.16.0 Die Datenbank wurde von Anfang an auf MySQL umgestellt. Der Vertrag des Kunden wurde bereits gelöscht. Wie sollte ich dieses Problem umgehen oder lösen?

    Ich habe disable_functions als Benutzer admin in PHP Einstellungen geändert. Nach der Änderung sehe ich, dass bei meinen Kunden diese Einstellung nicht übernommen wurde. Dies erscheint mir nicht sehr sicher, auch weil nach der Änderung keine Warnung darüber erscheint. Im Moment ist es aber wichtiger zu wissen, wie ich dies manuell erreichen soll?

    In spätere Debian/Ubuntu Versionen sieht man:

    Code
    Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8))


    ... und geht es dann doch mit:

    Code
    wget -O - https://www.liveconfig.com/liveconfig.key | gpg --dearmor - >/etc/apt/trusted.gpg.d/liveconfig.gpg

    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.