Am 27.01.2016 um 10:36 schrieb Werner Franke:
Hallo zusammen,
wir müssen einen Apache Web Server der seit über 15 Jahren unter Solaris läuft auf Linux umziehen. Das muss jedoch jetzt nicht sofort sein.
Das größte Problem hierbei sind die vielen CGI Perl Scripte, die sich in den 15 Jahren angesammelt haben. Da es auf dem Solaris Server kein Perl an /usr/bin gab, werden in den Scripten sehr viele verschiedene Solaris-Perls an verschiedenen Pathes verwende. Die Scripte müssen also alle angepasst werden. Erschwerend kommt noch hinzu, dass viele Owner der Scripte die Firma inzwischen verlassen haben.
Hat jemand von Euch schon mal so etwas gemacht und hat einen Tipp wie man den Umzug möglichst Problemlos gestalten kann ?
Ich habe schon das access log durchsucht und die CGI's der letzten Jahre ermittelt, aber die anzupassen und zu testen würde Monate dauern.
Uns schwebt etwas in der folgenden Art vor:
Die Haupt CGI Anwendungen anpassen, dann auf den neuen Linux Web Server umschalten. Wenn dann ein nicht angepasstes CGI benutzt wird und ein "Server Error" kommt auf den alten Solaris Server mir der fast gleichen URL umschalten. Also eine Art Redirekt on Error.
Der Linux Server und der Solaris Server werden natürlich einen unterschiedlichen Namen haben (linux.xxxx.de - solaris.xxxx.de)
Beispiel: http://linux.xxxx.de/cgi-bin/script.pl -> http://solaris.xxxx.de/cgi-bin/script.pl
Geht so etwas überhaupt ? Hat jemand ein Beispiel dazu ? Danke für einen Tipp.
Werner Franke
Hi, würde ich nicht versuchen. Das würde bedeuten, dass Du dem Apachen erlaubst, scripte eines anderen Hosts auszuführen, mal abgesehen davon, dass ich nicht weiß, ob das geht, wäre es eine ziemliche Sicherheitslücke, denke ich. Kannst Du nicht sämtliche scripte oder den alten Server nach den verwendeten/vorhandenen Perls durchsuchen und die alle in Dein cgi-Verzeichnis kopieren? Die dürften doch nicht von ihrer lokalen Position abhängig sein, oder? Bedeutet immer noch, wenigstens zu checken, ob die überhaupt genutzt werden und wenn ja, wo. Geht aber vielleicht mit grep und Konsorten. Vorher würde ich die Kandidaten einfach mal mit /usr/bin/perl <kandidat> in einer chroot starten und gucken, ob die laufen. Dass ein oberveraltetes script out of the box läuft, aber was anderes tut, als es soll, ist doch vielleicht selten. Im Allg. bekommst Du doch eher Meldungen, das Funktionen deprecated sind oder Module fehlen. cu jth -- www.teddylinx.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org