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.
MariaDB wurde direkt von mariadb.com installiert.
Das ist bisweilen dann etwas schwierig, da unsere Tests "nur" mit den jeweiligen Distributions-Paketen laufen. Aber wir nehmen das mit auf.
Zitat
Die Änderung unter /usr/lib/liveconfig/lua/mysql.lua hat leider keinen Erfolg gebracht, die Datenbank wird immer noch nicht erkannt.
Hmm, in dem Fall glaubt LC ja unter OpenSUSE zu laufen.
Passen Sie bitte Zeile 87 an - dort "mariadb-server-10.6" mit aufnehmen:
pkg, v = LC.distribution.hasPackage('mysql-community-server', 'mariadb', 'mysql', 'mariadb-server-10.6')Stammt MariaDB aus dem Rocky-Repository, oder von extern (z.B. direkt von mariadb.com)?
"Normalerweise" sollte das generische Paket "mariadb-server" installiert sein - und dann auch gefunden werden.
Um auch Version 10.6 explizit zu unterstützen, gibt es kurzfristig folgenden Workaround: bearbeiten Sie die Datei /usr/lib/liveconfig/lua/mysql.lua und ändern in Zeile 84 den Eintrag "mariadb-server-10.5" in "mariadb-server-10.6". Danach LiveConfig neu starten, und alles sollte wieder laufen. Wir nehmen diese Änderung (und auch die falsche Erkennung als OpenSUSE) ins kommende Update (2.15.1) mit auf.
Starten Sie LiveConfig bitte mal neu (die DB-Erkennung wird nur beim Start durchgeführt, bei ungünstiger Update-Reihenfolge könnte das ein Problem sein).
Ansonsten: was liefert "rpm -qa | grep -i maria"?
Ich bin schon immer im Stable-Pfad. Was ich noch ergänzen kann, der o.g. Fehler war ein Folgefehler von
Vielen Dank für die Info, das erklärt einiges.
Hintergrund: LiveConfig wird mittelfristig verschiedene MySQL-Instanzen auf einem Server unterstützen können, und dieses Update bereitet das Datenbankschema dafür vor. Beim Anpassen der vorhandenen Daten scheint es da vereinzelt zu einem Fehler zu kommen. Wir werden das prüfen und den Update-Vorgang entsprechend umbauen.
Bei diesem (und wirklich nur diesem) Fehler, bitte folgenden SQL ausführen:
UPDATE LIVECONFIG SET LC_VALUE='0214042' WHERE LC_KEY='dbschema' AND LC_VALUE= '0214041';Danach läuft das Update durch.
Nach derzeitigem Kenntnisstand wurde bei manchen Update-Vorgängen bei einer v2.14.4-Preview die Schema-Version nicht korrekt aktualisiert (=bei Installationen der normalen Stable-Serie sollte das nicht auftreten).