OT: WEB Server Umzug Solaris -> Linux - CGI Problem
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 -- 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
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
Danke Joerg, Am 01/27/2016 um 11:33 AM schrieb EXT Joerg Thuemmler:
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.
[...]
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.
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.
Sicherheit ist da nicht das Thema. Das läuft alles ausschließlich im Intranet. Alles in mein cgi-bin kopieren will ich aus mehreren Gründen nicht. 1) dann hätte alles ich an der Backe und dass darf nicht sein ;-) 2) die cgi-bin scripte werden über verschiedene Pfade benutzt http://solaris.xxxx.de/cgi-bin/dir1/script.pl http://solaris.xxxx.de/cgi-bin/dir2/script5.pl http://solaris.xxxx.de/cgi-bin/dir3/script7.pl Und es wird bestimmt ein file1 in der einen Dir geben und ein file1 mit einem anderen Inhalt in dir2. Und was weiss ich noch für Schweinereien. Aber ich habe schon von Thomas den Hinwies auf "Reverse-Proxy" bekommen. Muss ich mir ansehen. Gruss Werner -- 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
Am 27.01.2016 um 12:40 schrieb Werner Franke:
Danke Joerg,
Am 01/27/2016 um 11:33 AM schrieb EXT Joerg Thuemmler:
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.
[...]
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.
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.
Sicherheit ist da nicht das Thema. Das läuft alles ausschließlich im Intranet.
Alles in mein cgi-bin kopieren will ich aus mehreren Gründen nicht. 1) dann hätte alles ich an der Backe und dass darf nicht sein ;-) 2) die cgi-bin scripte werden über verschiedene Pfade benutzt
http://solaris.xxxx.de/cgi-bin/dir1/script.pl http://solaris.xxxx.de/cgi-bin/dir2/script5.pl http://solaris.xxxx.de/cgi-bin/dir3/script7.pl
Und es wird bestimmt ein file1 in der einen Dir geben und ein file1 mit einem anderen Inhalt in dir2. Und was weiss ich noch für Schweinereien.
Aber ich habe schon von Thomas den Hinwies auf "Reverse-Proxy" bekommen. Muss ich mir ansehen.
Gruss Werner
OK, dann ist es natürlich einfacher. Was hindert Dich daran, die Dinger alle samt ihren Verzeichnissen in ein Verzeichnis unterhalb Deines aktuellen cgi-bin zu kopieren und das in der Apache-Konfig so freizugeben? Dann stören weder gleiche Namen noch hast Du Ärger mit Deinem normalen cgi-bin. Du kannst die sogar ganz woanders hinpacken und Softlinks anlegen und im Apachen erlauben, wenn es Intranet ist. Klingt mir alle mal einfacher und zukunftssicherer als so ein reverse-proxy-Ding auf einen "sterbenden" Server... An der Backe hast Du sie wohl so oder so... Und Du kannst/musst evt. noch vorhandenen Besitzern ja Zugriff drauf geben, da bieten sich Softlinks natürlich auch an, der Besitzer hat dann Zugriff auf das target und der Apache sieht den link... 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
Am 01/27/2016 um 04:03 PM schrieb EXT Joerg Thuemmler:
Am 27.01.2016 um 12:40 schrieb Werner Franke:
Danke Joerg,
Am 01/27/2016 um 11:33 AM schrieb EXT Joerg Thuemmler:
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.
[...]
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.
Sicherheit ist da nicht das Thema. Das läuft alles ausschließlich im Intranet.
Alles in mein cgi-bin kopieren will ich aus mehreren Gründen nicht. 1) dann hätte alles ich an der Backe und dass darf nicht sein ;-) 2) die cgi-bin scripte werden über verschiedene Pfade benutzt
http://solaris.xxxx.de/cgi-bin/dir1/script.pl http://solaris.xxxx.de/cgi-bin/dir2/script5.pl http://solaris.xxxx.de/cgi-bin/dir3/script7.pl
Und es wird bestimmt ein file1 in der einen Dir geben und ein file1 mit einem anderen Inhalt in dir2. Und was weiss ich noch für Schweinereien.
Aber ich habe schon von Thomas den Hinwies auf "Reverse-Proxy" bekommen. Muss ich mir ansehen.
Gruss Werner
OK, dann ist es natürlich einfacher.
Was hindert Dich daran, die Dinger alle samt ihren Verzeichnissen in ein Verzeichnis unterhalb Deines aktuellen cgi-bin zu kopieren und das in der Apache-Konfig so freizugeben? Dann stören weder gleiche Namen noch hast Du Ärger mit Deinem normalen cgi-bin. Du kannst die sogar ganz woanders hinpacken und Softlinks anlegen und im Apachen erlauben, wenn es Intranet ist. Klingt mir alle mal einfacher und zukunftssicherer als so ein reverse-proxy-Ding auf einen "sterbenden" Server...
An der Backe hast Du sie wohl so oder so... Und Du kannst/musst evt. noch vorhandenen Besitzern ja Zugriff drauf geben, da bieten sich Softlinks natürlich auch an, der Besitzer hat dann Zugriff auf das target und der Apache sieht den link...
Hi Joerg, nein, an der Backe haben werde ich nicht alles. Es spielen da natürlich - wie so oft - politische Dinge eine Rolle. Es ist ein wichtiger Web Server und einige CGI Tools werden für den Arbeitsbetrieb unbedingt benötigt. Etliche aber sind auch alt und können entsorgt werden. Da in den letzten Jahren immer nur Personal abgebaut wurde, sind dabei auch einige Owner von solchen Tools auf der Strecke geblieben. Entweder sie haben die Firma verlassen oder machen jetzt etwas anderes. Den Umzug wollen wir nutzen um einigen wichtigen Tools wieder Owner zu verschaffen und die nicht mehr benutzten zu entsorgen. Aber so lange es nicht sehr dringend ist, wird der aktuelle Projektdruck verhindern, dass neue Owner bestimmt werden und auch Zeit dafür bekommen. Das Tool funktioniert ja. Mit Hilfe des "Reverse-Proxy" oder einem anderen Mechanismus könnten wir dafür sorgen, dass solche Tools weiterhin über den Solaris Server laufen. Aber spätestens wenn der kaputt ist oder von IT abgeschaltet wird, wird es dringend. Dann entscheidet sich ob das Tool wirklich wichtig ist oder doch nicht. Ich bin seit 1984 an dem Standort, dessen Firmenname sich inzwischen zum sechsten Mal geändert hat. Manchmal muss man Spielchen spielen... Gruss Werner -- 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
Am 28.01.2016 um 09:11 schrieb Werner Franke:
Am 01/27/2016 um 04:03 PM schrieb EXT Joerg Thuemmler:
Am 27.01.2016 um 12:40 schrieb Werner Franke:
Danke Joerg,
Am 01/27/2016 um 11:33 AM schrieb EXT Joerg Thuemmler:
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.
[...]
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.
Sicherheit ist da nicht das Thema. Das läuft alles ausschließlich im Intranet.
Alles in mein cgi-bin kopieren will ich aus mehreren Gründen nicht. 1) dann hätte alles ich an der Backe und dass darf nicht sein ;-) 2) die cgi-bin scripte werden über verschiedene Pfade benutzt
http://solaris.xxxx.de/cgi-bin/dir1/script.pl http://solaris.xxxx.de/cgi-bin/dir2/script5.pl http://solaris.xxxx.de/cgi-bin/dir3/script7.pl
Und es wird bestimmt ein file1 in der einen Dir geben und ein file1 mit einem anderen Inhalt in dir2. Und was weiss ich noch für Schweinereien.
Aber ich habe schon von Thomas den Hinwies auf "Reverse-Proxy" bekommen. Muss ich mir ansehen.
Gruss Werner
OK, dann ist es natürlich einfacher.
Was hindert Dich daran, die Dinger alle samt ihren Verzeichnissen in ein Verzeichnis unterhalb Deines aktuellen cgi-bin zu kopieren und das in der Apache-Konfig so freizugeben? Dann stören weder gleiche Namen noch hast Du Ärger mit Deinem normalen cgi-bin. Du kannst die sogar ganz woanders hinpacken und Softlinks anlegen und im Apachen erlauben, wenn es Intranet ist. Klingt mir alle mal einfacher und zukunftssicherer als so ein reverse-proxy-Ding auf einen "sterbenden" Server...
An der Backe hast Du sie wohl so oder so... Und Du kannst/musst evt. noch vorhandenen Besitzern ja Zugriff drauf geben, da bieten sich Softlinks natürlich auch an, der Besitzer hat dann Zugriff auf das target und der Apache sieht den link...
Hi Joerg,
nein, an der Backe haben werde ich nicht alles. Es spielen da natürlich - wie so oft - politische Dinge eine Rolle. Es ist ein wichtiger Web Server und einige CGI Tools werden für den Arbeitsbetrieb unbedingt benötigt. Etliche aber sind auch alt und können entsorgt werden. Da in den letzten Jahren immer nur Personal abgebaut wurde, sind dabei auch einige Owner von solchen Tools auf der Strecke geblieben. Entweder sie haben die Firma verlassen oder machen jetzt etwas anderes.
Den Umzug wollen wir nutzen um einigen wichtigen Tools wieder Owner zu verschaffen und die nicht mehr benutzten zu entsorgen.
Aber so lange es nicht sehr dringend ist, wird der aktuelle Projektdruck verhindern, dass neue Owner bestimmt werden und auch Zeit dafür bekommen. Das Tool funktioniert ja.
Mit Hilfe des "Reverse-Proxy" oder einem anderen Mechanismus könnten wir dafür sorgen, dass solche Tools weiterhin über den Solaris Server laufen. Aber spätestens wenn der kaputt ist oder von IT abgeschaltet wird, wird es dringend.
Dann entscheidet sich ob das Tool wirklich wichtig ist oder doch nicht.
Ich bin seit 1984 an dem Standort, dessen Firmenname sich inzwischen zum sechsten Mal geändert hat. Manchmal muss man Spielchen spielen...
Gruss Werner
Hi, ja so ist das leider oft. Würde mich allerdings gerade dazu "verleiten", den Kram physisch auf den neuen Server zu migrieren... naja, ein weites Feld. Kannst ja mal posten, ob die reverse-proxy-Methode funzt... good luck! 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
Hallo, Werner Franke schrieb:
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.
Wenn die Scripte in verschiedenen Verzeichnissen liegen, könntest Du einen Reverse-Proxy (kann man mit Apache machen) davor schalten. In dessen Konfiguration kannst Du dann für jede URL festlegen, ob sie intern auf den Linux- oder den Solaris-Host weitergeleitet wird. Den DNS-Eintrag, der jetzt auf den Solaris-Host zeigt, biegst Du auf den Reverse-proxy um, sodaß dieser nun unter der "alten" URL angesprochen wird. So könntest Du nach und nach jede Applikation einzeln umziehen und die Benutzer "sehen" nur eine URL... -- Mit freundlichen Grüßen Thomas Voigt -- 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
Danke Thomas, Am 01/27/2016 um 11:34 AM schrieb EXT Voigt, Thomas:
Hallo,
Werner Franke schrieb:
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.
Wenn die Scripte in verschiedenen Verzeichnissen liegen, könntest Du einen Reverse-Proxy (kann man mit Apache machen) davor schalten. In dessen Konfiguration kannst Du dann für jede URL festlegen, ob sie intern auf den Linux- oder den Solaris-Host weitergeleitet wird. Den DNS-Eintrag, der jetzt auf den Solaris-Host zeigt, biegst Du auf den Reverse-proxy um, sodaß dieser nun unter der "alten" URL angesprochen wird. So könntest Du nach und nach jede Applikation einzeln umziehen und die Benutzer "sehen" nur eine URL...
-- Muss ich mir ansehen. Reverse-Proxy sagt mir erst mal nichts, was aber kein Wunder ist, da ich mich mit dem Thema erst wieder seit kurzen beschäftige (darf).
Gruss Werner -- 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
Werner Franke schrieb am 27.01.2016 um 10:36:
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.
Oder du legst Links an die entsprechenden Stellen, damit die Skripte ihren Interpreter finden.
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.
Vielleicht ließe sich das automatisieren. Beste Grüße, der Marco. -- 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
Am 01/27/2016 um 10:36 AM schrieb EXT 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 ?
[...] Hallo zusammen, aufgrund der Anregungen hier habe ich eine einfache und für uns vollkommen ausreichende Lösung gefunden. Vielleicht sollte ich noch erwähnen, dass wir auf dem Solaris Web Server insgesammt 5 virtuelle Server laufen haben, die alle unter unterschiedlichen Usern laufen und jeder ein eigenes CGI-BIN Directory hat... Ich habe es mit ErrorDocument 500 /cgi-bin/errors.pl gelöst. Wobei es das Perl File "errors.pl" natürlich auf allen unterschiedlichen CGI-BIN Directories der virtuellen WEB Servers (unter Linux) geben muss. Softlinks machen's möglich. In dem Perl Script, gebe ich eine HTML Meldung aus, dass ein Internal Server Error aufgetreten ist und dass auf den Solaris Server weitergeleitet wird. Aus den ENV Variablen $ENV{'HTTPS'} $ENV{'HTTP_HOST'}; $ENV{'REQUEST_URI'}; baue ich die URL zusammen und ersetze den Namen (XXX.de.lucent.com:8004) durch den Namen des Solaris Servers ($hostname.de.lucent.com:8004) und leite dann an den weiter. "<meta http-equiv="refresh" content="0, url=$forwardUrl"> Eventuell kann ich auch den Orginal Namen (XXX.de.lucent.com:8004) weiter verwenden, aber wir wissen noch nicht, wie der neue Linux Server heißen soll. Unser Firmennamen hat sich ja gerade wieder mal geändert. In dem Script kann ich dann auch mitschreiben, was noch an den Solaris Server geht um dann ermitteln zu können, was ev. noch gebraucht wird. Danke an alle die mir Tipps gegeben haben. schönes Wochende Werner -- 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
participants (4)
-
Joerg Thuemmler -
Marco Bakera -
Voigt, Thomas -
Werner Franke