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.
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" ?
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:") ?
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.
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. :-/
Am besten zuerst mal prüfen ob die Einstellung "log_errors = off" auch in der php.ini korrekt drin steht:
grep log_errors /var/www/<Vertrag>/conf/php*/php.iniWenn 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)
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.
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.
Edit: Gelöst durch Neustart des Postfix.
Das würde dann aber bedeuten, dass eine (völlig) andere Postfix-Konfiguration als die von LiveConfig aktiv war (ggf. durch manuelle Eingriffe). Im normalen Betrieb hat ein Postfix-Neustart hier keinen Einfluss.
Die Greylisting-Adressen werden in /etc/postfix/greylist_addrs verwaltet (plus zugehöriger .db-Datei).
Änderungen werden nach dem Speichern unmittelbar in diese übernommen.
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:
ErrorDocument 404 /.errorFiles/not-found.html(der URL-Pfad "/.errorFiles/" wird durch LiveConfig auf "/usr/share/liveconfig/html/" gemapped)
Bei mir wird die PHP Version in den Webeinstellungen doppelt angezeigt.
Welche LiveConfig-Version nutzen Sie? (bitte immer dazu schreiben)
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
Hallo,
letzte Woche ist PHP 8.2 erschienen. Unsere PHP-Pakete für Debian/Ubuntu stehen ab sofort ebenfalls in Version 8.2 zum Download bereit.
Viele Grüße
-Klaus Keppler
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).
Die Werte lassen sich alle in die my.ini eintragen... (auf den richtigen Abschnitt achten).
Mit LiveConfig hat das nichts zu tun, es fällt möglicherweise nur dort auf, weil LiveConfig sehr langlebige Verbindungen mit Prepared Statements nutzt (Web-Anwendungen sind da wesentlich "kurzlebiger").
Welche Distribution+Version?
Üblicherweise sollte es genügen, das Debian/Ubuntu-Paket libmagickcore-6.q16-6-extra zu installieren (je nach Distributions-Version kann der Name auch geringfügig anders lauten).
PHP-FPM muss danach ggf. neu gestartet werden (z.B. systemctl restart php80-fpm), damit die laufenden PHP-Instanzen die aktualisierten ImageMagick-Module finden und laden.
Viele Grüße
-Klaus Keppler
Alles klar. Unter Debian 11 gab's beim Build der memcached-Pakete einen Fehler, deshalb waren die noch nicht im Repository.
Wir haben das eben gelöst, die memcached-Extensions für PHP 7.3 und 7.4 sind nun auch für Debian 11 verfügbar. Für PHP 5.6, 8.0 und 8.1 waren die Pakete bereits vorhanden.
Sie müssten also apt update && apt upgrade ausführend, anschließend apt install php-7.3-opt-memcached
Die Extension muss zudem ausdrücklich aktiviert werden, indem Sie die Datei /opt/php-7.3/etc/conf.d/memcached.ini bearbeiten und gleich am Anfang die Anweisung "extension=memcached.so" aktivieren.
Welche Distribution+Version nutzen Sie?
Wo genau soll ein anderer Name statt der Host-ID angezeigt werden?
(eigentlich ist die Host-ID ein eher interner Wert, der den Endkunden gar nicht mehr angezeigt werden sollte)
Viele Grüße
-Klaus Keppler
Vertauschen Sie bitte in der Datei /usr/lib/liveconfig/lua/distribution.lua in Zeile 310 die Aufrufe von "detect_suse()" und "detect_centos()":
if detect_lsb() or detect_debian() or detect_centos() or detect_suse() or detect_gentoo() thenOffenbar bringt 8.7 nun auch eine Datei namens /etc/os-release mit, was bislang nur bei OpenSUSE der Fall war.