gelöst: Test einer Website bei Serverumzug VOR Domaintransfer

H

haegar

New Member
Hallo zusammen,
ich habe folgendes Problem:
eine alte Joomla-Installation (Joomla 2.5) soll von einem Server auf einen anderen Server umziehen. Das genze erfolgte per Plesk Backup/Restore. Auf dem neuen Server wurde für die alte Seite noch ein PHP 5.6 installiert. Soweit sieht (fast) alles gut aus.
Auf dem neuen Server kann ich die Vorschau nutzen, die Seite wird mit Ausnahme eines problems vollständig und korrekt angezeigt. Dort gibt es aber ein Funktionsproblem: ein als Popup über dem Seiteninhalt anzuzeigendes Bild wird in der Vorschau einfach nur in einem neuen Tab geöffnet.
  • siehe Orginalseite Bild als Popup -> dort auf ein Bild klicken: es wird als PopUp über den Seiteninhalt eingeblendet
  • in der Vorschau: Bild in neuem Tab -> dort auf Bild klicken: es wird als ganz normaler Link in einem neuen Tab geöffnet
Leider funktioniert in der Vorschau auch das Joomla-Backend nicht, so dass ich auch nicht testen kann, ob man in Joomla etwas umstellen kann/muss. Das scheint aber ein bekanntes Problem zu sein und soll hier nicht weiter verfolgt werden.

Meine Frage:
Es ist leider für mich nicht erkennbar, ob die falsche Darstellung nur durch die Plesk-Site-Vorschau verursacht ist oder ob auf dem neuen Server noch irgendeine Konfiguration (PHP, Berechtigungen, ...) fehlt, um die gewollte Darstellung als PopUp zu erreichen.

Dann habe ich alternativ versucht, einfach den kompletten Ordner der Site unter einer anderen (momentan ungenutzten) Domain einzustellen, um darüber eine Art von Vorschau zu ermöglichen. Dazu habe ich einfach über cp -R /var/www/vhosts/[echte domain] /var/www/vhosts/[ungenutzte domain] die Dateien kopiert. Datenbank etc. bleibt ja alles identisch.
Dort funktionieren aber die Links nicht. Für einen Test muss man etwa 1-2 Seiten scrollen, dann kommt im rechten Bereich eine Box mit der Überschrift "alp 200" und darin der Menüeintrag/Link "Experte gesucht". Die aufzurufende Unterseite ist https://bilderbrennerei.de/fachleute-gesucht. Das führt dann aber nur zu "Seite nicht gefunden".
Im Log steht leider auch nur :
Error404GET /fachleute-gesucht HTTP/1.0

Hat jemand noch einen guten Tipp für mich, wie ich vor dem Domaintransfer prüfen kann, ob die Seite auf dem neuen Server wie gewünscht funktioniert? Entweder wie man in der Vorschau in Logs genauer herausfinden kann, warum statt eines Popups nur ein neuer tab geöffnet wird oder wie ich unter einer anderen Domain die Links lauffähig bekomme.
So lange die Seite noch auf dem alten Server läuft, habe ich damit keinen zeitlichen Stress. Wenn ich die Domain aber transferiere und es geht dann nicht, muss ich ganz schnell eine Lösung finden. Daher versuche ich das vorher zu klären und hoffe auf einen hilfreichen Tipp :).

Viele Grüße,
Siegbert
 
Ich verwende in solchen Fällen eine lokale "hosts"-Datei, in der mal die eine und mal die andere IP eingetragen wird.
Diese übersteuert den DNS und man kann alles (bis hin zum SSL-Zertifikat) entspannt testen.
 
  • Like
Reactions: .A.
haegar said:
Auf dem neuen Server wurde für die alte Seite noch ein PHP 5.6 installiert. Soweit sieht (fast) alles gut aus.
Click to expand...

Bitte verwende PHP 5.6 und alles gut niemals in einem Satz.

Das Popup wird durch JS erzeugt. Es gibt hierbei sowohl auf der Originalseite als auch der Vorschau im Browser Fehler. Vermutlich kommt daher das verschiedene Verhalten, du hast nicht alle Fehler korrekt übernommen. Vielleicht solltest du aber auch die Fehler mal beheben?

Whistler said:
Ich verwende in solchen Fällen eine lokale "hosts"-Datei, in der mal die eine und mal die andere IP eingetragen wird.
Diese übersteuert den DNS und man kann alles (bis hin zum SSL-Zertifikat) entspannt testen.
Click to expand...
Genau so.

--
.A.
 
Vielen Dank, das hat das Problem gelöst.
Die Seite funktioniert fehlerfrei :-). Da die Kopie auf dem neuen Server nicht die aktuellen Daten im Forum enthält, kann ich sicher sehen, dass der Aufruf auch tatsächlich die Kopie anzeigt.

Dass PHP 5.6 längst veraltet ist, weiß ich auch, ebenso Joomla 2.5. Aber was will man machen, wenn der Schwager sich nicht an ein Update Joomla herantraut und Joomla 2.5 mit aktuelen PHP-Versionen nicht läuft. Ich helfe ja mal beim Serverumzug, so ist wenigstens Linux (Ubuntu 24.04) aktuell. Aber ein Joomla-Update mit x Komponenten/Plugins/Themes übersteigt die Zeit, die ich in der Famile "mal eben nebebei" investieren kann.
 
haegar said:
Aber was will man machen, wenn der Schwager sich nicht an ein Update Joomla herantraut und Joomla 2.5 mit aktuelen PHP-Versionen nicht läuft.
Click to expand...
Der Welt einen Gefallen tun und die Seite so lange offline nehmen, bis der Schwager die Migration angeht.

haegar said:
Aber ein Joomla-Update mit x Komponenten/Plugins/Themes übersteigt die Zeit, die ich in der Famile "mal eben nebebei" investieren kann.
Click to expand...
Natürlich geht das nicht mal eben nebenbei, genauso wie die Administration eines Servers. Aber weil die Seite ohnehin Code von einem EDV-Dienstleister einbindet, sollte dieser auch seine Arbeit machen (übrigens auch auf der eigenen Seite mal ;)).

--
.A.
 
haegar said:
Aber was will man machen, wenn der Schwager sich nicht an ein Update Joomla herantraut und Joomla 2.5 mit aktuelen PHP-Versionen nicht läuft.
Click to expand...
Dann beißt man in den sauren Apfel, nimmt etwas Geld in die Hand und beauftragt einen Profi damit. Das ist am Ende günstiger, als wenn der Server kompromittiert und z.B. als Spamschleuder mißbraucht wird.
Der Admin des Servers ist erstmal für alles verantwortlich, was auf der Kiste läuft...
 
nexus said:
Das ist am Ende günstiger, als wenn der Server kompromittiert und z.B. als Spamschleuder mißbraucht wird.
Click to expand...
Ich nehme einmal an, TE hat mit geeigneten Maßnahmen (z.B. SELinux) das Szenario Spamschleuder bereits abgesichert, daher sehe ich diese Gefahr eher nicht. Deshalb sagte ich ja auch, der Schwager sollte die Migration angehen (und nicht bereits abschließen).

Wenn der Server kompromittiert wird, sind erst einmal die Daten der eigenen Nutzer gefährdet. Und dann besteht eher das Risiko der Verwendung des Servers als "Cloud" für alles mögliche, was man lieber nicht mit der Marke in Verbindung gebracht sehen möchte.

Das ist so ein Erfahrungswert aus vergangenen Migration von CMS vergleichbaren Alters: Als Erste Hilfe genügt oft, ein Paar grobe Schnitzer zu schließen und der Upgrade der PHP-Version. Der Aufwand dafür ist zumeist recht überschaubar. Das verschafft Zeit, um in Ruhe die Seite auf neue, dauerhaft stabile Füße zu stellen.

--
.A.
 
Joomla 2.5 LTS ist seit 31.12.2014 EOL, wird also seit über zehn Jahren (!) nicht mehr mit Sicherheitsupdates versorgt.
Dementsprechend viele Angriffsvektoren dürfte es geben, um nicht nur Daten aus der laufenden Joomla Instanz zu gefährden, sondern den ganzen Server zu 'übernehmen', um beispielsweise eine bösartige Webshell o.ä. Schadsoftware zu installieren und den Server für weitergehende Angriffe auf andere Systeme zu mißbrauchen.
Und da reicht es eben nicht aus, nur "ein paar grobe Schnitze" zu schließen.

Eventuell wäre es hilfreich zu wissen, welcher Unterbau auf dem Server läuft (verwendetes OS, verwendete Version des Adminpanels, etc.), um dem TE weitergehende Hinweise geben zu können, wie er sein System absichern könnte...
 
nexus said:
Joomla 2.5 LTS ist seit 31.12.2014 EOL, wird also seit über zehn Jahren (!) nicht mehr mit Sicherheitsupdates versorgt.
Click to expand...

Ja, das ist leider normal bei derartigen alten CMS. Mein beobachteter Rekord ließ sich zwar nicht mehr genau datieren enthielt aber Dependencies mit letztem Update 2008.

nexus said:
Dementsprechend viele Angriffsvektoren dürfte es geben, um nicht nur Daten aus der laufenden Joomla Instanz zu gefährden, sondern den ganzen Server zu 'übernehmen', um beispielsweise eine bösartige Webshell o.ä. Schadsoftware zu installieren und den Server für weitergehende Angriffe auf andere Systeme zu mißbrauchen.
Click to expand...

Beim Beispiel SELinux läuft die Webshell dann im Kontext des Webservers, kann also nur genau das tun, wozu der Webserver auch berechtigt ist. Und damit verhindere ich erst einmal aktive Zugriffe/Angriffe auf andere Systeme.

Also kein Grund unmittelbar in Panik zu verfallen, aber durchaus ein Grund für einige Sofortmaßnahmen und einen Plan für die Zukunft der Seite.

--
.A.
 
You must log in or register to reply here.
Back
Top