Beiträge von kk

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.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)

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.

Zitat von aho546745

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:

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)

Zitat von kroerig

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

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).

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() then

Offenbar bringt 8.7 nun auch eine Datei namens /etc/os-release mit, was bislang nur bei OpenSUSE der Fall war.

Zitat von ap24

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.