IP und Hostname ändern [GELÖST]

[Ralph]

Ich habe für den Umzug zu Keyhelp mein neues Produktivsystem vorab auf einem anderen Server installiert und vorbereitet (Dauer für nötige Anpassungen System, Anwendungen, Webs ca. 1 Woche) ich möchte dieses morgen per Snapshot (image) auf den bisherigen Server übertragen (überschreiben) und somit die offiziellen IPs und den Hostname übernehmen.
Ich müsste also dort Hostname, IPv4 und IPv6 ändern, ich habe das bisher noch nicht gemacht um Fehler zu vermeiden frage ich deshalb nochmal nach ...

Keyhelp Datenbank (PHPmyadmin):
keyhelp > settings ändern:
- IPv4 und IPv6 Adresse
- hostname
- nav_url
- name_servers
- panelurl
- nav_url (pma, webmail)

ausführen:
keyhelp-toolbox
- Rewrite user configuration files

ausführen:
php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php --force-update

reboot

Ist der Vorgang so korrekt - kann ich loslegen oder habe ich noch etwas übersehen?

[Tobi]

Du hast übersehen, dass Du den Hostnamen und die IP Adressen direkt über das Panel ändern kannst.

Das ist die einzig wahre & empfohlene Methode.

[Ralph]

Du hast übersehen, dass Du den Hostnamen und die IP Adressen direkt über das Panel ändern kannst.

Das ist die einzig wahre & empfohlene Methode.

Hi Tobi!
schon, es ist aber hier ein komplettes fertiges system image und die Änderungen in der DB mache ich besser gleich auf dem Vorab System bevor ich das Image rüberziehe damit ich auf dem neuen Hostsystem gleich Zugriff aufs Panel habe.
Ist halt abgeleitet von der restore Prozedur und ich muss die Ausfallzeit so gering wie möglich halten, da laufen 2 Billing Systeme drauf und eine Menge Cronjobs & API prozesse nach extern.

[Ralph]

Du hast übersehen, dass Du den Hostnamen und die IP Adressen direkt über das Panel ändern kannst.

Das ist die einzig wahre & empfohlene Methode.

Hast Recht ich mache das so, der v-host ist ja nicht an eine feste IP gebunden
<VirtualHost *:443>

Ich muss mich noch an die neuen Configs gewöhnen

[Ralph]

Das hat alles geklappt ... Website läuft, Email etc.
Es gibt nur ein Problem:
WHMCS läuft nicht richtig bzw. PHP7.3 hängt sich weg mit 100% CPU Load, die Loginseite wird angezeigt Lizenz wurde auf den neuen Pfad geändert, die WHMCS configs angepasst ...
Sobald ich mich einloggen möchte hängt sich PHP7.3 auf:

top:
100.0 0.8 4:01.20 keyhelp-php73-f

Code: Select all

[Sun Dec 04 20:03:54.700702 2022] [proxy_fcgi:error] [pid 195659:tid 140230394214144] [client xxx.xxx.xxx.xxx:35240] AH01067: Failed to read FastCGI header
[Sun Dec 04 20:04:21.878193 2022] [proxy_fcgi:error] [pid 195660:tid 140230385821440] [client xxx.xxx.xxx.xxx:32796] AH01067: Failed to read FastCGI header
[Sun Dec 04 20:06:19.381375 2022] [proxy_fcgi:error] [pid 198593:tid 140637258086144] [client xxx.xxx.xxx.xxx:49086] AH01067: Failed to read FastCGI header
[Sun Dec 04 20:08:48.402248 2022] [proxy_fcgi:error] [pid 198593:tid 140637107017472] [client xxx.xxx.xxx.xxx:58522] AH01067: Failed to read FastCGI header

Die abhängigen PHP Erweiterungen sind alle vorhanden (aktiv) also per default.
Das alte System läuft ebenfalls mit PHP7.3 fpm allerdings auf Buster ...
Könnte es an der MariaDB Version liegen oder an den Ioncube loader für PHP 7.3?

Das ist eine WHMCS v7.10.3

Hat jemand diese Version auf Keyhelp im Einsatz?

[Ralph]

an mariadb liegt es wohl eher nicht:
https://docs.whmcs.com/MySQL_Version_Support_Matrix

WHMCS 7.10 läuft auf MySQL v8.0 und PHP 7.3
Ist auf Bullseye mariadb-server-10.5 nicht equivalent zu MySQL v8.0?
IonCube Problem?

[Alexander]

Um es erstmal wieder ans Laufen zu bringen, hilft bei einem "Failed to read FastCGI header" i.d.R. immer ganz gut, den PHP-FPM einmal neu zu starten.

[Ralph]

Um es erstmal wieder ans Laufen zu bringen, hilft bei einem "Failed to read FastCGI header" i.d.R. immer ganz gut, den PHP-FPM einmal neu zu starten.

Danke Alex!
PHP73 restart ist kein Problem, danach ist die Load auch wieder OK, sobald ich Username und PW in WHMCS eingebe und auf Login klicke hängt PHP7.3 wieder.
Ich habe erstmal abgebrochen und den altenSystem snapshot wieder hergestellt, ich versuche mal meine Dev Lizenz auf einen Testserver zu switchen und über das Setup einen whmcs requirement check zu starten.
Ich vermute es könnte an der IonCube loader version für PHP7.3 liegen ... die PHP Erweiterungen sind ja vorhanden.

Whmcs Pfad:
/home/users/website/www/domain.tld/htdocs
wobei die geschützten Ordner cron, uploads etc oberhalb von htdocs liegen
/home/users/website/www/domain.tld/cron (etc)
Die Pfade sind in der config alle richtig angepasst

Gibt es WHMCS (7.10) User hier im Forum die etwas dazu sagen könnten?

[Alexander]

Warum denkst du der ioncube loader könnte dafür verantwortlich sein?

Schonmal probiert, WHMCS mit einer anderen PHP-Version laufen zu lassen? Laut WHMCS empfehlen sie ja 7.4 oder 8.1.

[Ralph]

Warum denkst du der ioncube loader könnte dafür verantwortlich sein?

Schonmal probiert, WHMCS mit einer anderen PHP-Version laufen zu lassen? Laut WHMCS empfehlen sie ja 7.4 oder 8.1.

bezgl. Ioncube habe ich das hier gefunden - bin mir allerdings nicht 100% sicher ob es tatsächlich daran liegt:
https://whmcs.community/topic/304579-50 ... mitticket/


Die neue 8.x läuft unter PHP 7.4, die v 7.10 max. bis PHP 7.3.
Nächstes Jahr werde ich auf Wisecp wechseln, da arbeite ich dran (Module fertigstellen & Migrations Vorbereitungen).
Mein Plan war zuerst das aktuelle i-mscp (Buster) durch Keyhelp auf Bullseye zu ersetzen, da hängen auch bei Wisecp und einigen Modulen Lizenz Änderungen dran (Pfad Änderung), wenn ich alles auf Keyhelp am laufen habe, kann ich nachdem die Module fertig sind auf problemlos Wisecp migrieren (da hängt sehr viel manuelle Nacharbeit dran nach Import von whmcs) deswegen sollte der Server bereits soweit sein das beide Billingsysteme paralell darauf laufen können.
Wisecp läuft auf PHP 7.4 ... ich weiß das passt jetzt nicht genau hier in den Thread aber ich habe es angehenegn damit die Prozedur wie ich migriert habe ersichtlich bleibt.
Ich teste später mal mit der Dev Lizenz auf einem Test System und erstelle dazu einen neuen Thread falls erforderlich.

P.s. Kann ich die IonCube loader für die compiled PHP 7.3 selbst ersetzen?

[Ralph]

Auf dem alten System verwende ich für PHP-fpm (packaged) die SURY.ORG .deb sourcen und ioncube loader manuell eingebunden ...
Ich schätze mal das wäre hier keine gute Idee, wird vermutlich das Keyhelp unbrauchbar machen - oder?

[Jolinar]

wird vermutlich das Keyhelp unbrauchbar machen

Davon kannst du ausgehen...

[Ralph]

wird vermutlich das Keyhelp unbrauchbar machen

Davon kannst du ausgehen...

Ja, ich denke auch nicht das es mit der compiled PHP 7.3 etwas zu tun hat, der requirements check (im install package) zeigt alles grün an, also keine Probleme gefunden im output des kompletten checks ...
Ich lasse gerade meine Dev Lizenz ändern auf das Test System und lasse mal die komplette Installation durchlaufen, danach müsste sich die Ursache feststellen lassen.

[Ralph]

Habe jetzt eine Test Installation mit WHMCS 7.10 auf Keyhelp PHP7.3 durchgeführt.
Der Installer läuft ohne Probleme bis zum Ende durch, keine Fehler ...
Das gleiche Problem wie mit der vorigen Migration tritt auch bei einer Neu Installation auf, sobald ich user und pw eingegeben habe und den Login Button klicke hängt sich alles auf bis der Timeout greift.

Code: Select all

[Tue Dec 06 09:51:34.129318 2022] [proxy_fcgi:error] [pid 137124:tid 140503660279552] (70007)The timeout specified has expired: [client xx.xxx.xxx.xx:56944] AH01075: Error dispatching request to : (polling), referer: https://test.mydomain.tld/admin/login.php?redirect=%2Fadmin%2F

PHP Ioncube Loader Versionen sind auf dem alten und auf dem Keyhelp System gleich:
ionCube24 v11.0.1

Fehlermeldungen sind hier sonst keine zu finden, irgendwo wird etwas blockiert ...
In der .htaccess von WHMCS wird zwar kein FollowSymlinks verwendet, es könnte aber irgendwo intern in den ioncubed WHMCS files integriert sein, mehr fällt mir momentan dazu nicht ein.

Gibt es denn hier wirklich niemanden der WHMCS verwendet?

[Tobi]

Also ich hatte mir gestern mal die WHMCS Systemanforderungen durchgelesen.
Von MariaDB steht dort leider gar nix.
Auch in Foren etc. habe ich keine weiterführenden Hinweise auf die Verwendung von MariaDB gefunden.
Lediglich der lapidare Hinweis, dass MariaDB, solange es binärkompatibel ist, wohl funktionieren sollte.

MariaDB hat aber seit Version 10.5 ziemlich viele Neuerungen welche vorher so nicht on Board waren und auch der Unterschied zu MySql wird immer größer. Meine Vermutung wäre, dass du den Strict Mode bei MariaDB explizit deaktivieren musst.

Füge mal bitte testweise folgende Zeile am Ende der Datei "/etc/mysql/mariadb.conf.d/90-tuning.cnf" ein.
Nach dem Eintrag sollte auf jeden Fall noch ein Zeilenumbruch kommen.
Die letzte Zeile muss stets eine leere Zeile sein.
Dann noch MariaDB neu starten und gucken was passiert.

Code: Select all

sql_mode                = NO_ENGINE_SUBSTITUTION