Beiträge von Jim

Kann es sein das die Datei cron.deny von Liveconfig bei einem Upgrade auf Version 3 angelegt wurde?
Ich hatte vor kurzem Version 3 installiert, bin dann aber wieder zurück auf die Version 2.

Wird die Datei cron.deny auch bei der Version 2 benötigt?

Zitat von antondollmaier

LiveConfig macht hier nichts anderes, als "/usr/bin/crontab -u web25" aufzurufen.

Gibt es da ggf. eine cron.allow/cron.deny?

Ja es gibt eine Datei cron.deny in dieser stehen auf einmal alles Liveconfig Benutzer (Verträge).

Aber bereits vorhandene Cronjobs in Liveconfig werden nach wie vor ausgeführt.

Zitat von pkambach

hi!

Welches Betriebssystem?

VG

Debian Bookworm (12)

Ich habe das Problem das ich bei Liveconfig Version 2.19.1 die Kunden keine neuen Crontabs anlegen können. Obwohl dies im Vertrag freigeschaltet ist.

Die Meldung im liveconfig.log ist folgende:

[LUA] Updating crontab for 'webXX'

[LUA] CRON[web25]: 'The user webXX cannot use this program (crontab)'

[LUA] crontab(web25) returned with exit code 1

LC.cron.update() failed: crontab(webXX) returned with exit code 1

Zitat von kk

Sind hier mehrere Let's-Encrypt-Accounts vorhanden? (z.B. einer beim "admin" und einer beim Kunden?)

Ja. Das ist ein Upgrade von Liveconfig 2 auf Version 3. Da sind Let's-Encrypt-Accounts beim Admin genauso wie beim Kunden (und auch Reseller) vorhanden.

Habe jetzt mit der aktuellen Version 3.0.3 unter Debian bookworm folgendes Problem mit den Zertifikaten.

Die automatische Verlängerung von Liveconfig hat nun bei den zu verlängernden Zertifikaten den Job doppelt angelegt.

Das führt zu dem Fehler das die Verlängerung nicht ausgeführt wird und in der liveconfig.log folgender Fehler protokoliert wird.

 [3519098] [2025-08-26 12:36:54.077276] [INFO] [LUA] Detected 'Debian GNU/Linux 12 (bookworm)'
[3519097] [2025-08-26 12:37:52.503274] [EMERG] Uncaught exception in ChildManager: tlsjob already exists
[3519097] [2025-08-26 12:37:52.503314] [EMERG] Got exception: WebSession::AuthRequiredException
  [ 0] 0x177fab   
  [ 1] 0x274d48   
  [ 2] 0xf7d05    /usr/lib/liveconfig/libk.so.0.9
  [ 3] 0x125eca   /usr/lib/liveconfig/libk.so.0.9
  [ 4] 0x3b0ac0   
  [ 5] 0xd44a3    /lib/x86_64-linux-gnu/libstdc++.so.6
  [ 6] 0x891f5    /lib/x86_64-linux-gnu/libc.so.6
  [ 7] 0x10989c   /lib/x86_64-linux-gnu/libc.so.6

Zitat von kk

Wir beheben das eben, Update kommt gleich...

Bis wann ist mit dem Update ca. zu rechnen?

Zitat von hchristo

Um Wieviel von was hast du die table_definition_cache erhöht?
Freue mich auf Infos

Ich habe dazu das Tool "mysqltuner" benutzt. Das zeigt einem an wie viele Tables benutzt werden.
Somit kann man dann seinen eigenen benötigten Wert für den table_definition_cache ermitteln.

z.B. Auszug aus mysqltuner bei mir (jetzt nach der Anpassung des table_definition_cache auf 7000"

[OK] table_definition_cache(7000) is upper than number of tables(6864)

LG Jim

Zitat von kk

Laut einer Antwort bei StackOverflow könnte es helfen, den table_definition_cache zu vergrößern. Versuchen Sie das bitte einmal.

Das Vergrößern des table_definition_cache hat tatsächlich geholfen. Der Fehler tritt nun nicht mehr auf und das Ändern des Passwortes einer Datenbank über Liveconfig funktioniert wieder einwandfrei.

Vielen Dank.

"SET PASSWORD FOR 'user'@'localhost' = PASSWORD('StReNgGeHeIm');"
funktioniert als root-Benutzer einwandfrei zum ändern des Passworts.
Ebenfalls kann man natürlich ohne Probleme das Passwort auch mit PhpMyAdmin ändern.

Externer Datenbankenzugriff ist nicht aktiviert.
Auch das deaktivieren von Single Sign-On unter "Serververwaltung" in Liveconfig ändert nichts.

Mysql (MariaDB) funktioniert über die Shell einwandfrei, als root genauso wie als user.

liveconfig --diag erkennt die MariaDB richtig:
---
Checking for database server software:
- Found 'mysql' database server
Version: '10.5.12'
Package version: '1:10.5.12-0+deb11u1'
---

Wie bereits geschrieben funktioniert über Liveconfig auch das neue erstellen sowie auch das löschen einer Datenbank ohne Fehler und Probleme. Nur leider das ändern des Passworts einer Datenbank funktioniert nicht über Liveconfig.
Die Fehlermeldung in der liveconfig.log ist bei jedem Versuch das Passwort einer Datenbank zu ändern immer die gleiche:

[2022/02/13 16:00:01.559982] [702313|702318] Prepared statements invalidated - trying to recover...
[2022/02/13 16:00:13.572035] [702313|702318] (last message repeated 6 times)
[2022/02/13 16:00:13.572086] [702313|702318] Error while updating database: Re-preparation of MySQL statement failed (7 attempts, waited 63 seconds)

Auch ein "mysql_upgrade --force" konnte das Problem nicht lösen.
Alle anderen Logfiles (z.B. von mysql) zeigen keine Fehler oder Hinweise auf das Problem.

mysql_upgrade:
This installation of MariaDB is already upgraded to 10.5.12-MariaDB, use --force if you still need to run mysql_upgrade

Mysql ist verbunden. Auch kann man problemlos neue Datenbanken anlegen oder löschen.
Das Problem tritt leider wirklich nur beim Passwort ändern auf.

Fehler in der Liveconfig Logfile:

[2022/01/21 15:52:57.525050] [2809|2810] Prepared statements invalidated - trying to recover...
[2022/01/21 15:53:09.538462] [2809|2810] (last message repeated 6 times)
[2022/01/21 15:53:09.538497] [2809|2810] Error while updating database: Re-preparation of MySQL statement failed (7 attempts, waited 63 seconds)

Ja ist mariadb Ver 15.1 Distrib 10.5.12-MariaDB.
Also die Standard Version von MariaDB unter Debian 11.

Wegen der Fehlermeldungen werde ich gleich mal im Log von Liveconfig schauen.

Zitat von BMK-Media

Hi,

auch mit dem neuen Update ist die Passwort Änderung von MySQL/MariaDB Datenbanken nicht richtig möglich, Änderung erfolgt, aber Login funktioniert nicht. Wenn ich das Passwort dann per PHPMySQL ändere, ist der Login wieder möglich, nur wenn dies über die Liveconfig geändert wird, funktioniert dies nicht richtig.

Betriebsystem: CentOS 7
Server-Version: 10.4.14-MariaDB - MariaDB Server
Liveconfig-Version: 2.10.1 (release)

Habe leider nun genau das gleiche Problem, seit dem Upgrade von Debian 10 auf Debian 11. Liveconfig Version ist die aktuelle 2.13.0
Hatte das auch schon mal einer von auch nach einem Upgrade von Debian 10 auf Debian 11?

Ich kann hier denn Fehler z.B. bei einer Nextcloud (Version 21.0.2 und auch 21.0.3) unter Debian 10 nachvollziehen.
Vor dem Update ohne Probleme mit PHP 7.4 (FastCGI). Nach dem Update open_basedir Probleme. (Gerade nochmals mit Backup getestet.)

z.B. :

Zitat

Error: file_exists(): open_basedir restriction in effect. File(/templates/) is not within the allowed path(s): (/var/www/cloud/htdocs/:/var/www/cloud/apps/:/var/www/cloud/priv/:/var/www/cloud/tmp/:/usr/share/pear/:/usr/share/php/:/tmp/) at /var/www/cloud/htdocs/nextcloud/lib/private/Template/Base.php#68

Mit aktuellem PHP 7.3 funktionert es ohne Probleme.

Kann das Problem auch bestätigen. Auch bei mir mit php 7.4 (FastCGI) der gleiche Fehler mit open_basedir seit dem Update.
System: Debian 10

Zitat von Jens122

Gibt es hierfür eig. Mittlerweile eine Lösung Seitens LiveConfig?

Würde mich auch interessieren. Ob es da von Liveconfig eine Lösung gibt bzw. geplant ist.

kk Gibt es eigentlich einen Grund das Liveconfig SpamAssassin als User spamd haben will und nicht wie unter Debian üblich als debian-spamd.
Bei einer Debian 9 Neuinstallation mit Liveconfig und SpamAssassin wird ja auch das Verzeichnis für SpamAssassin mit debian-spamd angelegt. z.B.

/var/lib ls -la
drwxr-xr-x  5 debian-spamd debian-spamd 4096 Aug 21 17:26 spamassassin


/var/lib/spamassassin ls -la
drwxr-xr-x  5 debian-spamd debian-spamd 4096 Aug 21 17:26 .
drwxr-xr-x 41 root         root         4096 Aug 21 17:25 ..
drwxr-xr-x  3 debian-spamd debian-spamd 4096 Aug 21 17:26 compiled
drwx------  3 debian-spamd debian-spamd 4096 Aug 21 17:26 sa-update-keys
drwx------  3 debian-spamd debian-spamd 4096 Aug 21 17:26 .spamassassin

Und in dem Script /etc/cron.daily/spamassassin wird ja auch der Debian Standard debian-spamd verwendet.