Fehler bei server.sh nach automated setup

[etron770]

Server frisch installiert: Bookworm (IPV6 only)
apt update & apt upgrade

apt update apt upgrade
wget -O - https://get.ispconfig.org | sh -s -- --use-nginx --use-ftp-ports=40110-40210 --unattended-upgrades --interactive --no-roundcube --no-mailman --no-quota --no-ntp --ssh-port=2xxxx

Das Setup lief problemlos im Expertmodus mit Anschluss an den Master durch.

Auf dem Master Webinterface stehen 1310 Tasks die Jobwarteschlange zeigt keine.
Die Tasks werden gelöscht, wenn man den Server wieder vom Master löscht.
Auf dem Client führt /usr/local/ispconfig/server/server.sh zu folgender Fehlermeldung:

/usr/local/ispconfig/server/server.sh
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)
18.01.2025-11:04 - WARNING - There is already a lockfile set, but no process running with this pid (773). Continuing.
PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, bool given in /usr/local/ispconfig/server/lib/classes/modules.inc.php:148
Stack trace:
#0 /usr/local/ispconfig/server/server.php(187): modules->processDatalog()
#1 {main}
thrown in /usr/local/ispconfig/server/lib/classes/modules.inc.php on line 148

der cannot change locale Fehler ist nur der Vollständigkeit mit aufgeführt - den kann ich natürlich selbst lösen.
Zweimal neu aufgesetzt - immer dasselbe Problem.

 

[Till]

Das ist kein Problem mit der Installation auf dem neuen Server, daher kann da eine Neuinstallation auch nicht helfen. Da ist scheinbar etwas an Daten in Deinem datalog auf dem master dass es so nicht geben dürfte und daher steigt der Server aus. Ändere mal auf dem neuen Server in der datei /usr/local/ispconfig/server/lib/classes/modules.inc.php Zeile 148

if(count($data['new']) > 0) {

in

if(!empty($data) && !empty($data['new']) && count($data['new']) > 0) {

dann sollte er die defekten Daten überspringen. Ältere PHP Versionen waren da resistenter, daher hast Du es bisher nicht bemerkt dass da Daten defekt sind, die hatten dann halt nur eine Warnung ausgegeben wenn der Datentyp nicht zählbar ist und haben einfach weiter funktioniert.

 

[etron770]

Da ist scheinbar etwas an Daten in Deinem datalog auf dem master dass es so nicht geben dürfte und daher steigt der Server aus.

Ja das habe ich schon lange vermutet, aber nicht gefunden...

 

[etron770]

Auf Master und Client ist die neueste IspConfig Version
Die 1310 Tasks waren verschwunden.
Der Block von chown bis zum nächsten chown kommt sehr oft. Was davor kam sehe ich auf der Konsole nicht mehr

[...]
chown: cannot access '': No such file or directory
PHP Warning: Undefined array key "forward_in_lda" in /usr/local/ispconfig/server/plugins-available/maildeliver_plugin.inc.php on line 96
PHP Warning: Undefined array key "forward_in_lda" in /usr/local/ispconfig/server/plugins-available/maildeliver_plugin.inc.php on line 96
PHP Warning: Undefined array key "greylisting" in /usr/local/ispconfig/server/plugins-available/rspamd_plugin.inc.php on line 278
PHP Warning: Undefined array key "maildir_format" in /usr/local/ispconfig/server/plugins-available/mail_plugin.inc.php on line 281
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
PHP Warning: Undefined variable $chown_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1766
PHP Warning: Undefined variable $chgrp_mdsub in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 1767
chown: cannot access '': No such file or directory
PHP Warning: Undefined array key "forward_in_lda" in /usr/local/ispconfig/server/plugins-available/maildeliver_plugin.inc.php on line 96
PHP Warning: Undefined array key "forward_in_lda" in /usr/local/ispconfig/server/plugins-available/maildeliver_plugin.inc.php on line 96
PHP Warning: Undefined array key "greylisting" in /usr/local/ispconfig/server/plugins-available/rspamd_plugin.inc.php on line 278
18.01.2025-15:58 - ERROR - Replication of datalog_id: 6741 failed. Error: (web_domain) in MySQL server: (localhost) Unknown column 'fastcgi_php_version' in 'field list' # SQL: REPLACE INTO ?? (??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??
,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
?,?,?,?,?,?)
18.01.2025-15:58 - ERROR - Error in Replication, changes were not processed.
finished server.php.

Jetzt sind wieder 1077 Task vorhanden:
Fehlermeldung:

18.01.2025-16:13 - ERROR - Replication of datalog_id: 6741 failed. Error: (web_domain) in MySQL server: (localhost) Unknown column 'fastcgi_php_version' in 'field list' # SQL: REPLACE INTO ?? (??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??
,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??,??) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
?,?,?,?,?,?)
18.01.2025-16:13 - ERROR - Error in Replication, changes were not processed.
finished server.php.

 

[etron770]

Die ersten Einträge in sys_datalog sind von 2012.
In den 2010er Jahren ist mir mal ein Server abgestürzt.
Es kann auch sein, dass das damals passiert ist, als ich den einzigen Server zum Master Server gemacht und Mailserver und Webserver "irgendwie" aufgeteilt habe. Das könnte inkorrekt gewesen sein.

Auf jedem neuen Server wird ein Verzeichnis /var/www/clients/client1/web1/web/xxx/yyy/ anglegt.
Web1 gibt es schon lange nicht mehr, das war auf dem abgestürzten Server oder auf dem ersten Server mit ISPconfig der inzwischen nur noch die Masterdienste macht.

Wie ich Dinge nachvollziehen soll, die mehr als 10 Jahre zurückliegen, weiß ich nicht ....

 

[Till]

An sich dürften im sys_datalog keine Einträge für server_id = 0 drins ein die älter als 30 tage sind und Einträge für Tabelle web_domain) sind nie server_id = 0, daher muss da irgend was von Deinen vorherigen manuellen Änderungen im argen liegen. Schau einfach ob der neue Server funktioniert wenn Du jetzt etwas neu anlegst und dann ignorier die Meldungen.

 

[etron770]

Alle Server die ich bisher angelegt habe funktionieren. Der neueste weiß ich noch nicht, der ist wie vom Script installiert.
Im datalog sind 1365 Einträge mit server_id = 0 drin der älteste eben von 2012
Auch sind ein viele Einträge von Server_Ids drin, die es nicht mehr gibt.
Kann man z.B alle mit Server Id = 0 löschen, die älter als sechs Monate sind und alle mit Ids von Servern, die es nicht mehr gibt?
Z.B sind die neuesten drin, bei denen die oben genannten Fehler aufgetreten sind und ich den Server gelöscht habe.
Da habe ich aber garantiert erst den Server vom ISP Config gelöscht und dann den Server selbst.

 

[etron770]

Ein "reverese restore" des Masters von den Daten der Clients gibt es nicht, oder?

 

[Till]

Der neueste weiß ich noch nicht, der ist wie vom Script installiert.

Wie ich oben schon gesagt habe, Du hast kein installationsproblem sondern ein problem mit der Replikation von Altdaten aus dem sys_datalog. Aber das kannst Du vermutlich ignorieren, daher prüf einfach ob der neue geht wenn Du was auf ihm anlegst.

Kann man z.B alle mit Server Id = 0 löschen, die älter als sechs Monate sind und alle mit Ids von Servern, die es nicht mehr gibt?

Ja, kannst Du machen.

Ein neuer Server bekommt ja immer eine neue ID, ees werden keine ID's nochmal verwendet, auch wenn Du Server löschst. Von daher ist es an sich auch egal falls es noch einen alten Eintrag geben sollte für eine andere ID, denn der neue Server zeiht sich ausschließlich records mit server_id = 0 plus records für seine eigene ID, und da seine ID ja vorher nicht verwendet worden ist, kann es nur server_id = 0 für ihn geben. Außer natürlich Du hast ihm gesagt dass er ein Mirror eines anderen servers sein soll, aber auch dann kann er ja kein Mirror eines nicht mehr existenten Servers sein und Mirrors kann man auch nur anlegen wenn der master des mirrors (nicht zu verwechseln mit master server) zusammen mit seinem mirror angelegt wird.

 

[etron770]

denn der neue Server zeiht sich ausschließlich records mit server_id = 0 plus records für seine eigene ID,

Dann ist ja klar wo die über 1300 records auf jedem neuen Server herkommen - von den alten Server ID=0

 

[Till]

denn der neue Server zeiht sich ausschließlich records mit server_id = 0 plus records für seine eigene ID,

Dann ist ja klar wo die über 1300 records auf jedem neuen Server herkommen - von den alten Server ID=0

Dass er sich die records zieht und dass es die gibt ist ja auch richtig und nicht Dein Problem. Du hast Fehler mit der web_domain Tabelle und es gibt in der Tabelle keine Records mit server_id = 0. server_id = 0 records sind broadcasts an alle Server, daher werden die auch nicht gelöscht denn sonst könnten sich neu eingefügte Server nicht mit den bestehenden synchronisieren. server_id = 0 sind im Grunde nur so Sachen wie die client Tabelle und ein paar andere globale config Sachen, aber eben nichts in der web_domain Tabelle da es keine Websites gibt die gleichzeitig auf allden Nodes liegen.

 

[etron770]

Hallo Till, danke für Deine Antworten.
Ja, das mag sein, dass es trotzdem mein Problem ist. Probleme treten oft aus, wenn man einen anderen Weg geht wie der Programmierer vorgesehen hat, oder woran er nicht gedacht hat. Das ist ja ein gängiges Problem in der IT-Welt. Das soll kein Vorwurf sein, dein System ist seit Jahren wirklich sehr gut.

Was aber derzeit bei ISP-Config (meines Wissens nach) unmöglich ist, wenn man mit Vservern, arbeitet:
Vserver haben den Vorteil, dass man sie zurücksetzen kann, das aber bekommt ISPConfig nicht mit und dann stimmt der Status des Vservers nicht mit den Daten auf dem Master überein. Eine Möglichkeit den Zustand vom Client zum Master zu resetten, kenne ich nicht.
Da wären gespeicherte "snapshots" hilfreich, die passenderweise auf den clients gespeichert sind und vom Master eingelesen werden können. Der Snapschot wäre dann der Zustand des Vservers beim Backup. Analog zu btrfs Dateisystem mit Snapper/Rollback


Zumindest, wenn man Vserver über die Konsole managed und nicht über IspConfig (das habe ich nicht eingerichtet.)
Es kann immer mal passieren, dass ein Upgrade oder eine Installation durchgeführt wird, die man dann mit einem Backup zurücksetzen möchte. Ein Vorteil eines Vservers,

Und warum im Datalog Server IDs verbleiben, die ich ordnungsgemäß aus ISP-Config gelöscht habe, verstehe ich aber nicht.

 

[Till]

Was aber derzeit bei ISP-Config (meines Wissens nach) unmöglich ist, wenn man mit Vservern, arbeitet:
Vserver haben den Vorteil, dass man sie zurücksetzen kann, das aber bekommt ISPConfig nicht mit und dann stimmt der Status des Vservers nicht mit den Daten auf dem Master überein. Eine Möglichkeit den Zustand vom Client zum Master zu resetten, kenne ich nicht.

Das geht in ISPConfig absolut problemlos und auch seit vielen Jahren, habe ich schon sehr oft gemacht auf eigenen und Kunden Systemen. Solange der Reset auf einen Zustand ist der nicht älter als 30 Tage ist, musst Du garnichts machen, dann regelt ISPConfig alles alleine und synchronisiert sich wieder. Ist der Zustand auf demn Du zurücksetzt älter als 30 Tage, nutzt Du Tools > resync in ISPConfig. Und ein Sync ist immer vom master zum client, anders herum macht überhaupt keinen Sinn und ist daher auch nicht implementiert. Der master ist ja auch nur eine einzige Datenbank, die sichert man auf einzelystemen täglich, sobald man mehrere Systeme hat stündlich und ab ein paar dutzend Nodes hat man ja normalerweise immer ein realtime backup mit Replikation. Beim Master geht bei Upgrades im Grunde auch nie etwas schief, da dort ja meist nur MariaDB, Nginx/Apache und PHP läuft. Das heißt im worst case falls dieses simple setup kaputt geht müsstest Du nur die dbispconfig datenbank im letzten Zustand zurückspielen, der Rest spielt da keine Rolle.

Und warum im Datalog Server IDs verbleiben, die ich ordnungsgemäß aus ISP-Config gelöscht habe, verstehe ich aber nicht.

Lies nochmal meine obien Beiträge zu server_id = 0 und web_domain Tabelle.

 

[etron770]

Hallo Till, das mit Resync zurückzusetzen hatten wir schon einmal besprochen:
Das Szenario beim Rücksetzen eines Client Servers ist doch, dass der Client ältere IspConfig Daten haben kann, die aber funktionieren. Der Master neuere IspConfig Daten des Clients haben kann, die fehlerhaft sind.
Mit dem Tool-> Resync stelle ich den fehlerhaften Zustand des Clients wieder her.

 

[Till]

Das Szenario beim Rücksetzen eines Client Servers ist doch, dass der Client ältere IspConfig Daten haben kann, die aber funktionieren. Der Master neuere IspConfig Daten des Clients haben kann, die fehlerhaft sind.
Mit dem Tool-> Resync stelle ich den fehlerhaften Zustand des Clients wieder her.

Siehe Post #13:

Und ein Sync ist immer vom master zum client, anders herum macht überhaupt keinen Sinn und ist daher auch nicht implementiert. Der master ist ja auch nur eine einzige Datenbank, die sichert man auf einzelystemen täglich, sobald man mehrere Systeme hat stündlich und ab ein paar dutzend Nodes hat man ja normalerweise immer ein realtime backup mit Replikation. Beim Master geht bei Upgrades im Grunde auch nie etwas schief, da dort ja meist nur MariaDB, Nginx/Apache und PHP läuft. Das heißt im worst case falls dieses simple setup kaputt geht müsstest Du nur die dbispconfig datenbank im letzten Zustand zurückspielen, der Rest spielt da keine Rolle.

 

[etron770]

Und ein Sync ist immer vom master zum client, anders herum macht überhaupt keinen Sinn
Sorry doch das würde Sinn machen (oder habe ich dich immer noch nicht verstanden?):

Jemand löscht einen kompletten Webspace über IspConfig (Master) aus dem Client (Server1)
/var/web/clients/client1/web123, Letsencrypt Zertifikate, Apache/nginx Einträge sind physikalisch auf dem Client und in der Datenbank des Masters gelöscht.

Auf einem anderen Client (Server2) werden andere Dinge durchgeführt.
Die Master Datenbank kann ich also wegen den Änderungen auf Server 2 nicht zurücksetzen.

Man restauriert den Server 1 aus dem Backup und der resync löscht den Webspace auf dem Client wieder
Oder wenn er nicht physikalisch gelöscht wird, ist der Webspace nicht mehr in der Master DB vorhanden.

Dasselbe würde mit anderen Einstellungen so sein, z.B Änderungen auf einem Mailserver passieren.

 

[Till]

Und es macht nich immer keinen Sinn, denn so ein zurückspielen inkonsistenter Daten würde ggf. auch Daten auf anderen Systemen löschen und verändern. Denn damit würdest Du ein System mit unvollständigen Daten (den zurückgesetzten Slave) zum master aller Systeme machen und da würde dann ggf. eine menge aufgeräumt, gelöscht und geändert. Denn nur der master hat einen vollständigen Satz aller Daten, die slaves haben das nicht. Wenn Du jetzt also sagst dass ein system mit unvollständigen daten die Referenz ist und sich der Rest danach anpassen soll, dann verlierst Du ggf. eine menge Dtane im ganzen multiserver setup.

Und Änderungen die Du z.B. in webs gemacht hast kannst Du auch über den datalog viewer rückgängig machen, Backups der Seite und datenbank sind je nachdem was Du eingestellt hast dann ja auch noch da. Für sowas würde man also nie einen vm reset machen, VM resets macht man nur wenn z.B. etwas bei einem dist upgrade komplett schief gelaufen ist oder ähnliches.