Project: Webportal - 04. Migration PHP-NUKE 7.6 Server to Server

AMBROSIA60-Portal  Webportal Project


Server to Server Migration von PHP-NUKE 7.6

Welche Fallstricke sich ergeben, wenn man nur "einfach" mal eine PHP-Nuke Installation, die über die Zeit entstanden ist, von einem zum nächsten Server transferieren möchte - davon erzählt hier diese Story:

Neben PHP-Nuke waren folgende Komponenten beteiligt:

  1. PHP-Nuke 7.6
  2. PHP 4.4.1 (Win32)
  3. MySQL 4.x (Win32)
  4. Apache 2.x (Win32)
  5. IIS 5
  6. Cygwin (Win32)

Unter PHP-Nuke habe ich installiert:

  1. phpBB2 2.0.19
  2. Gallery 1.5
  3. MS_Analysis 1.0
  4. Diverse Grafik Tools für Gallery Remote

Von den Anfängen des Projekts bis zum produktiven Einsatz hat es mich nur "7 Tage" Aufwand gekostet, den Transfer von einem Testserver zu einem Produktivserver umzusetzen.

Vorbereitungen:
Unter Vorbereitungen sind die Grundinstallationen zu verstehen, von Software, die benötigt wird, damit PHP-Nuke überhaupt laufen kann. Dazu zählen vor allem: PHP und MySQL.

  • PHP lief auf dem Testserver bereits komplett in einem dediziertem Verzeichnis C:\PHP. Aufgrund diverser Upgrades bin ich dazu übergegangen sämtliche EXE's und DLL's nur noch in einem Verzeichnis suchen zu müssen. Bei einem Upgrade kann ich so alle Dateien im Verzeichnis C:\PHP sichern und mit dem Upgrade Paket überschreiben. Wenn irgendetwas nicht funktioniert, kann ich den vorherigen Zustand wieder herstellen.
    Für die Migration war es so ein einfaches, einfach das komplette Verzeichnis C:\PHP auf den Produktivserver zu kopieren.
    Mit den mitgelieferten REG Files habe ich dann den entsprechenden Registry Eintrag in Windows vorgenommen. Zusätzlich habe ich unter HKLM\Software\PHP den Eintrag IniFilePath Typ: REG_SZ Value: C:\PHP vorgenommen um die Konfiguration auf das dedizierte Verzeichnis zeigen zu lassen.
  • MySQL musste ich auf dem Produktivserver komplett neu installieren. Dazu habe ich mir die entsprechende aktuelle 4er Version von der MySQL Website downgeloadet. Da auf dem Testsystem noch MySQL 4.x lief, es aktuell zwar eine Version 5 gibt, die aber in der Schnellübersicht darauf hindeutete, dass beim Upgrade eine Datenbank Konvertierung vorgenommen wird, habe ich den konventionellen, sicheren Weg gewählt und noch einmal eine 4er Version installiert.
    Die Installation selbst ist recht unspektakulär. Die Services unter Windows habe ich direkt einrichten lassen. Den Root Account und ein Passwort vergeben. Danach habe ich dann die Datenbank dann erst einmal gestoppt.
    Die PHP-Nuke Datenbank vom Testserver habe ich dann in das MySQL Data Verzeichnis auf dem Produktivserver kopiert. Anschliessend den MySQL Dienst wieder gestartet.
    Bei der Installation wurden leider nicht die Admin Tools mit eingerichtet, die ich bereits auf dem Testserver im Einsatz hatte: MySQL Control Center und MySQLAdministrator. Die habe ich dann ebenfalls vom Testserver in das MySQL BIN Verzeichnis kopiert.
    Mit MySQLAdministrator habe ich die Systemumgebung von MySQL auf dem Produktivsystem noch ein wenig angepasst. Mit MySQL Control Center habe ich entsprechende Accounts eingerichtet und Berechtigungen für die entsprechende Datenbank vergeben.
  • In Windows Systemsteuerung - System - Umgebungsvariablen habe ich C:\PHP und C:\MySQL\Bin zusätzlich unter Path hinzugefügt.

PHP-Nuke Transfer
PHP-Nuke habe ich dann das komplette PHP-Nuke Verzeichnis 1:1 auf den Produktivserver kopiert. Anpassung der phpnuke/config.php für den Datenbank Zugriff und den Sitekey ($dbhost, $dbuname, $dbpass, $dbname, $sitekey).
Danach habe ich versucht phpnuke/admin.php aufzurufen um die "interne" Konfiguration anzupassen. There seems to be a problem with the MySQL server ;-(

Rechtslagen überprüft - alles in Ordnung und gesetzt.
Also Debug Zeilen eingefügt. In phpnuke/mainfile.php habe ich dann echo Zeilen vor und nach dem Aufruf zu phpnuke/db/db.php => @require_once("db/db.php"); eingefügt. Davor wurde angezeigt. Danach nicht mehr. DB Typ von MySQL auf mysql4 umgestellt. Keine Veränderung. Timeout Problem? Also Schleife in mysql4 einprogrammiert. Keine Veränderung. Mit den Accounts herum experimentiert. Keine Veränderung.
Nach endlosen Versuchen, bin ich dazu übergegangen, die Commandline Scripte, die ich im DLIMP/DLTIC Projekt benutzt habe umzuschreiben um einmal an die Datenbank zu connecten, 2 Werte auszulesen und auszugeben und die Datenbank wieder zu schliessen. Und siehe da, ich bekam eine Ausgabe vom Datenbank Inhalt (Sitename). ???
Warum funktioniert es dann nicht unter PHP-Nuke?
Da ich auf dem Testserver die Datenbank mit Localhost verbinde und auf dem Produktivsystem die Webseite als eine unter vielen virtuellen Webservern läuft, dachte ich mir, dass vielleicht Localhost nur von der primären Addresse des Webservers funktioniert. Also habe ich unter MySQL Control Center einen zusätzlichen Account mit name@domain angelegt. Nach Anpassung der Rechtslagen konnte ich auch mit diesem Account von der Commandline die Datenbank connecten. Unter PHP-Nuke bekam ich jetzt zumindest die Debug-Line #2 nach dem DB-Connect. Die Anzeige blieb aber leer. Dafür war aber die Fehlermeldung verschwunden, dass es Probleme mit der Datenbank gäbe.

Wie sich jetzt herausstellte versuchte sich die produktive PHP-Nuke Installation an die Webseite des Testsystems zu verbinden. Da diese "intern" definierte Website aber im Internet nicht erreichbar ist, scheiterte der weitere Aufbau der Webseite.
Aufruf MySQL Control Center. Anpassung von nuke_config Eintrag der Webseite auf den aktuellen Wert.
Erstmals erhielt ich jetzt wenigstens eine Anzeige der Website.
Aufruf admin.php, Einstellungen, Anpassung der Einstellungen unter PHP-Nuke und unter Forum.
Bei der Kontrolle der Logfiles erhielt ich Fehlermeldungen, dass dass irgendwelche Datenbank Aufrufe zurückgesetzt wurden bzw. dass Aufrufe ungütig seien. Nach Zurücksetzen des Datenbank Typs auf MySQL verschwanden auch die Fehlermeldungen.


Erste Tests
Bei den ersten Tests schien wohl alles zu laufen. Ich konnte mich als Benutzer anmelden. Habe Bereiche gesehen die nur registrierten Benutzern zugänglich sind. Konnte Einträge vornehmen. Soweit alles gut.

Gallery 1.5 auf dem Produktivserver
Beim Aufruf des Gallery Moduls erschien unter PHP-Nuke eine Fehlermeldung dass der Pfad für die Userdatenbank nicht stimmen würde.
Also: Anpassung des Pfades für Gallery 1.5 auf dem neuen Server in der Datei phpnuke/modules/gallery/config.php

  • Alle Verweise auf die physikalischen Verzeichnisse an die neue Umgebung angepasst.

Beim Editieren der config.php fielen mir die Verweise auf das Cygwin/bin Verzeichnis auf. Da war doch noch was ....
  • Kopieren des Cygwin/bin Verzeichnisses vom Testserver auf den Produktivserver
  • Cygwin/bin in den Windows System Path hinzugefügt
Im wesentlichen ging es hierbei um die ganzen zusätzlichen Grafik- und Packertools die für Gallery 1.5 benötigt werden und die ich schon einmal als Bundle an anderer Stelle zu einem früheren Zeitpunkt zusammengestellt hatte: Gallery Addons (Utils)  Gallery Addons (Utils)

Mit Gallery Remote wollte ich dann sogleich den Versuch unternehmen, ob sich weiterhin Bilder und Alben auf den neuen Produktivserver transferieren liessen.
Anlegen neues Album. Rechtevergabe ... egal was ich an Rechtevergabe eingetragen habe, wurden die Änderungen nicht übernommen. Auch Änderungen an bestehenden Accounts liess das System nicht zu. Aus dem PHP Error Log war zu entnehmen, dass Permissions auf das Albums Verzeichnis fehlten. Rechte im Webserver und im Filesystem eingetragen. Jetzt konnte ich wieder Userrechte ändern, hinzufügen oder löschen.
Gallery Remote ...
Nachdem ich 3 Bilder hinzufügen wollte brach der Transfer auf den Server mit der Fehlermeldung ab. Error uploading to server ...
Aus den Webserver Logfiles war zu entnehmen, dass für das entsprechende Upload Verzeichnis noch die nötigen Rechte fehlten. Write Access für das Uploads Verzeichnis eingetragen. Erneuter Versuch. Und läuft immer noch nicht.
Bei der Google Suche nach der Fehlermeldung stiess ich auf einen Hinweis, dass der Filetransfer mit Gallery Remote mit PHP-Isapi nicht funktionieren würde und man auf die EXE ausweichen solle.
Also PHP Isapi gegen PHP.EXE Aufruf ausgetauscht.
Nun endlich funktioniert der Upload.

Nach all diesen Änderungen und Vorbereitungen verhielt sich Gallery 1.5 aber dennoch "irgendwie merkwürdig" auf dem neuen Server.
Für Gallery 1.5 habe ich ja selbst einen Fix eingebaut. Trotz diesen Fixes wurden die Useraccounts von PHP-Nuke nicht erkannt. Weder konnte ich als Admin noch als User zwischen PHP-Nuke und Gallery 1.5 eine Verbindung schaffen.
Beim direkten Gallery 1.5 Aufruf erschien dann ein Hinweis, dass die PHP Einstellung register_globals wohl nicht korrekt wäre.
Stimmt. In der Zwischenzeit habe ich auf dem Testserver ein anderes PHP Paket im Test. osCommerce. Das verlangt explizit eine Einstellung register_globals ON.
Ich entsinne mich, dass ich für Gallery seinerzeit diese Einstellung umgeändert hatte.
Bei der Google Suche bin ich auf einen Hinweis gestossen, dass man für Gallery auch eine Konfiguration (Eintrag unter phpnuke/modules/gallery/config.php) auf skipRegisterGlobals = YES stellen könnte, dass dies aber nicht empfehlenswert sei und ohne Garantie. Eine Änderung dieser Einstellung bewirkte nichts. Erst als ich den entsprechenden Programmcode in phpnuke/modules/gallery/init.php fand und auskommentierte ... die Stelle befindet sich nach dem folgenden Kommentar:
* We TRY to make sure that register_globals is disabled. If the user has not disabled
* register_globals in their php.ini, we try to emulate its functionality by unsetting all
* variables from $_REQUEST. Some *Nuke systems apparently do not function well with this
* emulation, so we have given users a method to opt-out.
*
* WE DO NOT OFFICIALLY SUPPORT THE USE OF skipRegisterGlobals BECAUSE IT COULD POTENTIALLY
* OPEN Gallery TO SECURITY RISKS! This is for advanced users only.
funktionierte die Verbindung PHP-Nuke zu Gallery 1.5 wieder wie erwartet.


MS_Analysis 1.0.65
Vor kurzem erst hatte ich unter PHP-Nuke das erweiterte Statistik Modul MS_Analysis von Maty Scripts Analysis http://www.matyscripts.com in PHP-Nuke integriert. Ein Aufruf dieses Moduls lieferte einen leeren Bildschirm. ;-(
Beim Durchforsten des Codes stiess ich auf allerhand List() Aufrufe, die mir beim Downloads Modul schon Schwierigkeiten bereiteten. Also sämtliche List() Aufrufe in manuelle Umsetzung umgewandelt. List(1,2,3,...) = durch $row# = und var1 = $row#['field#'] Aufrufe ersetzt.
Irgendwo habe ich auch mal die Begründung nachgelesen, weswegen das List() in der Win32 PHP Version nicht funktioniert. Steht wohl im Zusammenhang mit der Mixed Form von Strings und Integerwerten die nicht zusammen in einem List Aufruf übergeben und transferriert werden können:

$result = $db->sql_query( "select ID, Title from .... List( $id , $Title ) = $db->sql_fetchrow( $result ); ^ ^ Integer String Jetzt erhielt ich zumindest wieder eine Anzeige, aber sämtliche Einträge blieben leer obwohl in der Zwischenzeit Einträge in der Datenbank vorzufinden waren.
Bei der näheren Untersuchung des Codes stiess ich auf String Verarbeitungsfehler ohne Ende ... ;-(
Zeilen für den Datenbankzugriff in der Form:
$result = $db->sql_query( "select max_items, max_online from $prefix"._msanalysis_admin." where id='1'" ); ^ ^ ^^ ^^ ^ zeigten eine "eigenwillige" Anordnung von Quotes und Stringverbindungen. An sich sollte $prefix den Prefix aus der PHP-Nuke Config liefern und mit der Datenbank *_msanalysis_admin verknüpft werden. Ich weiss nicht was die Aufrufzeile zurücklieferte, jedenfalls nicht den String nuke_msanalysis_admin. Eine Korrektur der Zeile zu: $result = $db->sql_query( "select max_items, max_online from ".$prefix."_msanalysis_admin where id='1'" ); ^ ^^ ^^ ^^gelöscht ^ lieferte zumindest für die geänderten Einträge endlich einen regulären Inhalt.
Nachdem ich an, ich weiss nicht wievielen Stellen, die Strings korrigiert habe, war endlich ein einigermassen zufriedenstellendes Ergebnis aufzuweisen.
Bei der Google Suche nach den vorherigen Problemen stiess ich auf Fehlermeldungen, dass Flaggen nicht angezeigt werden.
Wenn ich den Code $flag = "modules/$module_name/images/flags/$domain".".gif"; sehe, wird mir auch klar, warum da keine Anzeige erscheint ....
Genau das gleiche String-Durcheinander wie beim Datenbankzugriff.
Hier eine korrigierte Zeile: $flag = "modules/ $module_name /images/flags/ $domain ".".gif"; $flag = "modules/".$module_name."/images/flags/".$domain.".gif"; ^^ ^^ ^^ ^^^ 2 Zeichen ." gelöscht Seltsamerweise haben die PHP Versionen bei 2 Installationen (sind die Win32 ISAPI PHP Aufrufe) keine Probleme mit den "merkwürdigen" String Aufrufen. Aber die dritte Installation hat dafür umso massivere Schwierigkeiten.
Dann liefern auch die &op= Aufrufe Browser Warning Meldungen. Bei der Gelegenheit auch gleich sämtliche & Aufrufe in HREF's gegen & Aufrufe ersetzt.
Da ich mit Firefox als Browser in der Entwicklungsphase arbeite, fiel mir sofort auf, dass MS_Analysis Firefox nicht unterstützt. Also gleich auch noch Firefox in die Browser Class als Erweiterung hinzugefügt.
Nachdem ich nun das Paket einmal komplett durchgenudelt und gefixt habe, fiel mir auf, dass zwar jetzt überall Einträge hinzugefügt und angezeigt wurden - alle bis auf die Statistik der aufgerufenen Module.
Hier stiess ich bei der Analyse auf das Modul mstrack.php und den Aufruf: // Get Module Name which is activated $moduleurl = substr( stristr( getenv( "REQUEST_URI" ), 'name='), 5 ); Mit PHPINFO() stellte ich fest, dass beim IIS 5.0 solch eine Umgebungsvariable nicht existierte. Nur unter Apache ist diese Variable zu finden.
Eine Variable, die für getenv("REQUEST_URI") sowohl unter Apache alsauch unter IIS 5.0 einen Inhalt liefert wäre $_SERVER["QUERY_STRING"]. Also auch diese Zeile korrigiert.
Nun werden auch die aufgerufenen Module aufgelistet, bis auf Home. Also noch eine Zeile eingefügt: if ($moduleurl=="") { $moduleurl="Home"; } und schon wird der Home-Aufruf statt mit einem leeren Eintrag als Home aufgeführt.
Puuh.


PHP-Nuke: "cannot login" bzw. "Userstatus: Offline"
Nach all den Änderungen und Fixes dachte ich schon, das wäre alles. Aber auf einmal bemerkte ich, dass was zuvor irgendwann einmal funktionierte, auf einmal nicht mehr funktioniert.
Nach einer Anmeldung an PHP-Nuke bekomme ich zwar die Meldung User: mein Name aber als Status wird zurückgeliefert, ich sei Offline.
Also wieder Google Suche.
Unter Login und trotzdem offline-Status??? fand ich einen Lösungsansatz. Allerdings brauchte ich ein Weilchen bis bei mir der Groschen fiel. Die angebotene Lösung:

Nehme einen Editor ( Ultra Edit , Word Pad etc. ) und suche in der Datei alle Einträge mit folgendem Code >> Header("Location: und ändere ihn auf folgende Zeile: Header("Refresh: 0;url= brachte mich irgendwie nicht wirklich weiter. Bis ich die Datei fand in der dieser Code zu finden sein soll.
Die Datei ist ein klein wenig "versteckt".
Hier dafür noch einmal der dezente Hinweis. In der Datei
phpnuke/modules/Your_Account/index.php

sind die angegebenen Änderungen durchzuführen.
Nun klappts auch mit dem Nachbarn ..... ;-)
Ich weiss jetzt nicht was der Auslöser für dieses Problem gewesen sein mag, aber ich vermute die IIS Einstellung für Enable Script Buffering hat bei PHP-Nuke ein anderes Verhalten ausgelöst.
Da dieses einer der vielen Schrauben war, an denen ich gedreht habe, und die möglicherweise solch ein Verhalten auslösen könnten, sehe ich dies als mögliche, naheliegende Ursache ...

Zusammenfassung:
Nach allerlei Hürden - welches Problem habe ich eigentlich nicht mitbekommen? - verlief der Servertransfer recht schmerzhaft. Nichts lief wie es laufen sollte und wie ich es erwartet hätte. Murphy hat voll zugeschlagen. Und wenn ich schon dachte, ich hätte es geschafft gab's immer noch wieder einen obendrauf.
Keines der Probleme war zentral in einem Logfile herauszulesen. Vielmehr habe ich immer wieder sämtliche möglichen Logfiles durchsuchen müssen und jedesmal fand ich einen Hinweis in wieder einem anderen Logfile. Daher hier noch einmal die Liste der Möglichen Debugging Optionen:

  • mysql/data/*.err
  • phperr.log, Eintrag in PHP.INI, error_reporting = E_ALL, log_errors = On, error_log = path\php.log
  • Apache: Eintrag in Httpd.conf ErrorLog path/error.log
  • IIS: Configuration Virt. Webserver - Properties - Tab: Web Site - Enable Logging - Properties - Logfile Directory + Logfile name W3SVC#
Wenn keines der Logfiles einen Hinweis auf einen Fehler meldete habe ich durch ECHO ... Zeilen in den entsprechenden PHP Sources versucht das Problem einzugrenzen (was nicht immer auf Anhieb gelang). Wenn auch das nicht zum Ziel führte, oder der Fehler eindeutig auf der Website nachlesbar war (i.e. PHP-Nuke User: Offline) so suchte ich über Google nach der entsprechenden Fehlermeldung und wurde auch immer wieder auf die eine oder andere Weise danach fündig.
Aber ..., keines der Probleme war jeweils so trivial, als dass es mich nicht eine schlaflose Nacht gekostet hätte.

Ulrich Schroeter, März 2006






Ein kleiner Nachtrag, der auch in die Rubrik Server Migration fallen könnte:
Ein phpNuke Projekt dass schon eine Weile problemlos lief, meldete beim Aufruf der phpNuke Seite sich auf einmal die Error Seite, die Probleme mit der Datenbank anzeigte. Da dies in der Zwischenzeit unabhängig voneinander bei zwei Webseiten passiert ist, möchte ich die simple Lösung hier nicht vorenthalten:
Die initiale Datenbank Verbindung wird mit dem eingestellten Account und Passwort hergestellt. Ab und an kann es vorkommen, dass das in der DB gespeicherte Passwort nicht mehr mit dem gelieferten Passwort übereinstimmt. Eine Antwort warum das passiert habe ich bislang hierzu nicht finden können. Nur die Lösung:
Passwort in MySQLadmin bzw. MySQL Control Center für den Connect Account erneut eingeben.
In zwei Fällen, in denen das Problem bei mir auftrat hatte diese simple Lösung letztendlich zum Erfolg geführt, nachdem ich schon ewig die Scripte und die Methoden versucht habe anzupassen (Connection Type: MySQL statt MySQL4 und umgekehrt, usw.).
Relates to: PHPNUKE v7.6, MySQL 4.xx, Apache 2.x
[23.11.06] Ulrich Schroeter
© 2003-2024 by Ulrich Schroeter   01038