Debian Trixie

Hallo

okay danke für die Rückinfo.

Dann haben wir ja am Wochenende genug Zeit zum testen.

Mit freundlichen Grüßen

Martin Krüger

Upgrade vom letzten 3er Stable auf Test klappt bei mir nicht:

Aug 23 22:06:53 server liveconfig[2037109]: [2037109] [2025-08-23 22:06:53.680002] [INFO] LiveConfig starting...
Aug 23 22:06:53 server liveconfig[2037109]: [2037109] [2025-08-23 22:06:53.683305] [INFO] Database driver loaded: SQLite (3.50.3)
Aug 23 22:06:53 server liveconfig[2037109]: [2037109] [2025-08-23 22:06:53.685346] [INFO] Upgrading database schema (r218010 -> 2.18.4-0)
Aug 23 22:06:53 server liveconfig[2037109]: [2037109] [2025-08-23 22:06:53.685391] [INFO]  - migrating TSIGKEYS
Aug 23 22:06:53 server liveconfig[2037109]: [2037109] [2025-08-23 22:06:53.685752] [EMERG] index TSIGKEYS_IDX already exists
Aug 23 22:06:53 server systemd[1]: liveconfig.service: Control process exited, code=exited, status=74/IOERR

Edit: Beim Versuch von der 2er auf die 2er Test upzugraden bekomme ich die gleiche Fehlermeldung. Auf dem Server ist und war übrigens nie ein Nameserver aktiv.

Hallo

Upgrade von 3.0.2 auf 3.0.3 lief Problemlos.

Wir nutzen allerdings MariaDB statt SQLLite.

Mit freundlichen Grüßen

Martin Krüger

kk

Hatte ich es falsch verstanden, ich dacht 3.0.3 stellt die Ordnerstruktur wieder von /var/mail/user/1/Maildir auf /var/mail/user/1/ zurück?

Mit freundlichen Grüßen

Martin Krüger

Hallo

mit dem Update heute auf LiveConfig 3.0.3 (16481) wurde bislang nichts an der Dovecot Struktur unter /var/mail/ wieder zum Urzustand verändert.

Mit freundlichen Grüßen
Martin Krüger

Hallo

und was muss gemacht werden wenn dort bereits 60 drin steht?

Mit freundlichen Grüßen

Martin Krüger

Hallo

nein sind keine Einträge vorhanden nur

8] [2025-08-25 19:49:32.074741] [INFO] LiveConfig starting...

[2748368] [2025-08-25 19:49:32.078106] [INFO] Database driver loaded: MariaDB Connector/C (3.3.15)

[2748373] [2025-08-25 19:49:32.094027] [INFO] Database driver loaded: MariaDB Connector/C (3.3.15)

[2748375] [2025-08-25 19:49:32.096424] [INFO] Connected to dBus!

[2748375] [2025-08-25 19:49:32.832812] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

[2748375] [2025-08-25 19:49:32.838394] [INFO] [LUA] Detected 'Debian GNU/Linux 13 (trixie)'

[2748375] [2025-08-25 19:49:33.042848] [INFO] [LUA] setting PHP default version to 'php82'

[2748375] [2025-08-25 19:49:33.236669] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

[2748375] [2025-08-25 19:49:33.236769] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

[2748375] [2025-08-25 19:49:33.236862] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

Mit freundlichen Grüßen

Martin Krüger

Bei mir ist jetzt nach dem Upgrade auf Trixie nur noch eine Website von sechs erreichbar. Die Dienste lauen alle sauber und es gibt keinerlei Logeinträge, die auf Fehler hinweisen.

Hat da jemand eine Idee, oder das gleiche Problem auch gehabt?

Problem: bei Debian-Updates bleiben die Werte der bisherigen PHP-Versionen (eigenstellt durch Kunden) in der Datenbank erhalten. Das muss jedesmal manuell durch "Bastelarbeiten" nach dem Debian-Update korrigiert werden, indem man diese Werte manuell entfernt. Andernfalls sind die Webseiten nicht zu erreichen oder Apache startet nicht.

Schön wäre, wenn man das in Zukunft über die Oberfläche mit einem Klick regeln könnte. Es wäre zudem eine große Zeitersparnis. Aber das Thema "Massen-PHP-Änderung" wurde schon ja schon oft angesprochen.

Hallo

könnte man evtl. ja über die PHP Auswahl machen, dass die Konfigs von allen Kunden neugeschrieben wird.

Mit freundlichen Grüßen

Martin Krüger

Zitat von kk

Für "das gleiche Problem" müsste man wissen, um welches Problem genau es sich handelt.

Wie genau äußern sich die "nicht erreichbaren" Websites? Erscheint dort eine Fehlermeldung? Was wird bei Web-Zugriffen in den einschlägigen Logfiles (insbes. /var/log/apache2/errors.log) protokolliert? Welche LiveConfig-Version läuft? (2.18.5 oder 3.0.3?)

Sehr wahrscheinlich hat sich auch die PHP-Standardversion geändert (Debian 12 hatte 8.2.x, Debian 13 hat 8.4.x). Es könnte sein, dass die betroffenen Anwendungen/Websites damit vielleicht nicht zurecht kommen.

Das weiß ich ja auch nicht 😄

Ich bin jetzt soweit, dass es wahrscheinlich wieder an DNSSEC lag. Wir werden glaube ich keine Freunde mehr…

Im Apache error.log stand nichts, ausser Django Fehlermeldungen, die nichts mit dem eigentlichen Problem zu tun hatten. PHP wird auf den meisten Seiten ebenfalls nicht eingesetzt.

Über Mobilfunk konnte ich die Seiten dann teilweise zumindest öffnen, weshalb es scheinbar irgendein DNS Problem ist, welches ich aber noch nicht ganz durchblickt habe bisher. Zumindest die wichtigsten Seiten sind wieder erreichbar.

Was sagt denn dig meinedomain ANY @meinnameserver oder ein Test der Zone mit Zonemaster?

https://zonemaster.se/en/run-test

Damit müsste sich ein Fehler im DNSSEC bzw. mit den Nameservern finden lassen.
Aber insgesamt mehr Infos wäre schon ganz nett. Laufen alle Server Dienste korrekt, Logfiles, Was sagt das Logfile von den Nameservern, etc.

Einige (Sub-)Domains konnten nicht validiert werden. Ich habe jetzt mal wieder alle Domains auf externe Nameserver umgestellt, alles aus /var/lib/bin/keys gelöscht und wieder auf den eigenen Nameserver umgestellt. Jetzt läuft es so langsam wieder alles. Warum es solche Probleme nach dem OS Upgrade gab, verstehe ich allerdings nicht so wirklich.