Beiträge von kk

  • Problem nach Update auf 2.15.1

    Wie bereits vermutet: die Tabelle PERMISSIONS ist kaputt. War der Server vielleicht mal irgendwann (rand)voll?
    Da liegen jedenfalls zwei Fehler vor:
    - der AUTO_INCREMENT-Wert für PERMISSIONS steht auf "2", der sollte aber bei "42" stehen
    - da fehlen etwa 16 Einträge. Die Tabelle PERMISSIONS muss vor dem Update 41 Zeilen enthalten.


    Sie können einfach von irgendeinem beliebigen anderen LiveConfig-Server (mit Version <= 2.15.0 !) einen Dump der Tabelle PERMISSIONS importieren.


    Wenn diese Tabelle aber schon fehlerhaft ist, kann es sein, dass auch woanders Probleme bestehen...

  • Problem nach Update auf 2.15.1

    Nein, das hilft leider nicht - der o.g. SQL-Output wäre hilfreich.
    Dieser Fehler deutet auf eine korrupte Datenbanktabelle (PERMISSIONS) hin; jeder Eintrag darin muss einen eindeutigen Wert für P_ID haben. Während des Schema-Upgrades wird ein Eintrag hinzugefügt; wenn MySQL dabei einen "duplicate key" meldet, dann müssen bereits irgendwelche "falschen" Daten in der Tabelle stehen.

  • LiveConfig 2.15.1

    Hallo,


    ab sofort steht LiveConfig v2.15.1 zum Download bereit.


    Bei den Änderungen handelt es sich in erster Linie um Bugfixes und Verbesserungen.
    Hervorzuheben sind dabei:

    • in seltenen Fällen schlug die DNS-Prüfung bei Let's-Encrypt-Zertifikaten fehl, weil statt einer erwarteten IPv4-Adresse vom Resolver eine IPv4-mapped IPv6-Adresse zurückgegeben wurde. Das wird nun korrekt erkannt und behandelt.
    • alle PHP-FPM-Konfigurationen erhalten nun automatisch in die php.ini-Einstellung "disable_functions" die Funktion "opcache_get_status" hinzugefügt. Dieses Verhalten ist (aus Sicherheitsgründen) nicht deaktivierbar.
      FastCGI-Konfigurationen sind davon nicht betroffen.
    • pro Domain kann nun der Empfang von externen E-Mails mit diesem Domainnamen als Absender deaktiviert werden. Das soll die Scam/Phishing-Gefahr etwas reduzieren, da nur noch E-Mails lokaler (authentifizierter) Absender mit dieser Domain akzeptiert werden.


    Das Update kann wie immer völlig reibungslos über die Repositories installiert werden.


    Viele Grüße


    -Klaus Keppler

  • externe E-Mails mit lokaler Absenderdomain können nun abgelehnt werden

    Nehmen wir an, Sie hosten die Domain example.org.
    Wenn diese Einstellung aktiviert ist, dann lehnt der Server eingehende E-Mails (also von extern) ab, welche als Envelope-From diese Domain (example.org) enthalten.
    Der Sinn ist, dass Scam/Phishing erschwert wird, indem Mails mit dieser Domain nur über lokale (authentifizierte) Benutzer eingereicht werden dürfen.

  • Problem nach Update auf 2.15.1

    Diese Fehlermeldung deutet auf ein lokales Datenbankproblem hin (das betroffene Schema-Upgrade hier ist ziemlich primitiv).
    Bitte schicken Sie die Ausgabe folgendes SQL-Befehls (ausgeführt auf der LiveConfig-Datenbank) an support@liveconfig.com, damit wir sehen was da drin eventuell falsch ist:

    Code
    select P_ID, P_IDLEFT, P_IDRIGHT, P_IDLEVEL, P_PERMISSIONID, P_KEY from PERMISSIONS order by P_IDLEFT;

  • AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" Fehler

    Zitat von ñull

    Bedeutet dies, dass ich diese Frage von apt dist-upgrade mit Y hätte beantworten sollen?

    Code
    *** named.conf.options (Y/I/N/O/D/Z) [default=N] ?


    Diese Antwort ist eigentlich genau richtig.


    Zitat von ñull


    Gibt es auf Ihrem Testsystem etwas in /etc/apparmor.d/local/usr.sbin.named? Bei mir war es leer.


    Ja, diese Datei gibt es bei uns, und die ist recht gut gefüllt, und wurde vom Paket "bind9" mit installiert.


    Was liefert denn der Befehl "dpkg -l | grep bind9" ?

  • AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" Fehler

    Wir haben hier in unserer Testumgebung den BIND9 unter Debian 11 problemlos mit AppArmor am laufen.
    Die Log-Meldung deutet darauf hin, dass BIND ein Socket in einem Verzeichnis erzeugen möchte, wofür er keine Erlaubnis hat.
    Vermutlich wurde die bisherige BIND-Konfiguration vom Ubuntu migriert, und hatte da irgendwas drin was so unter Debian nicht klappt?


    Eventuell taucht in /var/log/named/messages eine Meldung auf, welche Aktion genau fehlschlägt (also welches Socket nicht erstellt werden kann).
    LiveConfig sollte den BIND unabhängig von AppArmor aber dennoch erkennen können.
    Was liefert die Ausgabe von "liveconfig --diag" (Abschnitt "Checking for DNS server software:") ?

  • Fehler nach Serverwechsel

    Verwenden Sie die Preview-Version (2.15.1)?
    Dann sollte es genügen, wenn Sie in der php.ini-Verwaltung (im LiveConfig als "admin" anmelden, Hosting -> PHP-Einstellungen) einen Eintrag für "disable_functions" anlegen, der Inhalt darf dabei leer sein.
    Wir werden das Problem kurzfristig auch in der Preview beheben.

  • Überlauf php_errors.log

    Naja, wenn das irgendeine Wordpress-Extension ist, die eigenständig per ini_set() das "log_errors=on" setzt, dann kann LiveConfig da beim besten Willen nichts machen.
    Einzige Lösung wäre, hier die Log-Datei (error_log) auf /dev/null zu setzen. :-/

  • Überlauf php_errors.log

    Am besten zuerst mal prüfen ob die Einstellung "log_errors = off" auch in der php.ini korrekt drin steht:

    Code
    grep log_errors /var/www/<Vertrag>/conf/php*/php.ini


    Wenn das der Fall ist, dann hat wohl die PHP-Anwendung selbst irgendwo das Logging aktiviert (Funktion "ini_set()") - da hat LiveConfig natürlich keinen Einfluss darauf. Meines Wissens sollte die php-Errorlog-Datei aber rotiert werden. Wie "alt" ist die denn? (also von wann ist da der erste Eintrag)

  • Wann erfolgt Letsencrypt Zertifikate-Verlängerung

    Hallo!


    LiveConfig beginnt (wie empfohlen) 30 Tage vor Ablauf mit der Verlängerung (außer man hat die Checkbox zur automatischen Verlängerung bei den Zertifikatseinstellungen ausdrücklich deaktiviert). Sollte es Probleme geben und ein Zertifikat droht abzulaufen, versendet LiveConfig zudem 14 und 7 Tage vor Ablauf eine entsprechende Hinweis-E-Mail.

  • PHP 7.2.30, 7.3.17 und 7.4.5

    Zusätzliche PHP-Interpreter müssen immer im LiveConfig registriert werden (via Lua).


    Die von uns bereitgestellten PHP-Pakete liefern ein Lua-Script zur Registrierung mit (/etc/liveconfig/lua.d/php##.lua). Man kann aber genauso auch die Pakete von deb.sury.org verwenden, dann muss man eine solche Datei eben manuell anlegen (Format ist hier beschrieben).


    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.

  • Einstellung Fehlerseiten

    LiveConfig stellt eigene Fehlerseiten nur für dem Fall bereit, dass noch keine Inhalte hochgeladen wurden (Beispiel: https://www.apachedemo.de)


    Was z.B. 404 (Not Found) betrifft, installiert LiveConfig ganz bewusst keine eigene globale Fehlerseite. Das lässt sich aber sehr einfach einrichten - unter Debian/Ubuntu z.B. so:


    1. erstellen Sie die gewünschte Fehlerseite unter /usr/share/liveconfig/html (z.B. "not-found.html")
    2. legen Sie eine Datei namens /etc/apache2/conf-available/errors.conf an, mit folgendem Inhalt:

      Code
      ErrorDocument 404 /.errorFiles/not-found.html


    3. führen Sie den Befehl "a2enconf errors" aus
    4. führen Sie den Befehl "systemctl reload apache2" aus


    (der URL-Pfad "/.errorFiles/" wird durch LiveConfig auf "/usr/share/liveconfig/html/" gemapped)

  • PHP 7.4 - End Of Life

    Hallo,


    zur Information: PHP 7.4 hat nun offiziell den "End of life"-Status erreicht. Eine Übersicht über die aktiv gepflegten PHP-Versionen finden Sie auf der PHP-Website.


    Unsere PHP 7.4-Pakete für Debian/Ubuntu werden daher auch nur noch kritische "Backports" erhalten, welche wir i.d.R. aus dem php-src-security-Repository von Remi Collet beziehen. Wir empfehlen daher auch dringend, auf PHP 8 umzusteigen.


    PHP 8.0 bekommt übrigens auch nur noch Updates für kritische Fehler, als "aktive" Versionen gelten PHP 8.1 und 8.2.


    VIele Grüße


    -Klaus Keppler

  • Passwort änderung MySQL/MariaDB, Login nicht möglich

    Zitat von informant

    Mit dem Strukturfehler schlichen sich in einige User DBs fehler ein, so dass diese nicht mehr auffindbar sind aber in der liveconfig DBS Tabelle noch enthalten waren.


    Das genannte Problem während des Schema-Upgrades hat nichts mit dem von Ihnen gesendeten MySQL-Fehler zu tun. In diesem konkreten Fall ging es um das in Beitrag #17 beschriebene Problem (wo die Erhöhung des table_definition_cache empfohlen wird).
    Einen "Strukturfehler" gab und gibt es seitens LiveConfig nicht. Das Upgrade schlug fehl, wenn auf einem Server mehrere verschiedene MySQL-Versionen erkannt worden waren (möglicherweise durch Updates oder manuell installierte MySQL-/MariaDB-Versionen).