Frage, physisches Linux virtualisieren

D

Domi

Member
Ein hallo in die Runde,

ich habe ende vergangenes Jahr den Arbeitgeber gewechselt und vor ein paar Wochen hatte man mich gebeten, ob ich mal gucken könnte, ob (oder wie) man unseren alten Intranet Server virtualisieren kann. Aktuell läuft unser Intranet auf einem älteren Lenovo System, der Kern des Systems ist ein SLES 10 mit PHP4!

Nun hab ich ein Debian 11 virtualisiert und alles "ready" gemacht, aber wir haben Systeme die nie wirklich aktualisiert wurden und man bekommt von der einen oder anderen Webanwendung nichts mehr für z.B. PHP 5.6! Somit gibt es hier die ober A-Karte... mit einem VMware Converter wollte ich via SSH das Teil convertieren, dass ging schon schief, weil er irgendwie die Datenträgerabbilder nicht korrekt übernommen hat, somit startet das System nicht.

Eine weitere Möglichkeit wäre ein Veeam Agent für SLES 10, aber da finde ich nichts... sonst könnten wir schon mal ein ordentliches Backup machen.

Nun wären diverse Fragen und vielleicht hat da jemand Ideen...

a.) Bekommt man für Debian Bullseye noch irgendwo ein PHP 4.x her, welches ich relativ einfach implementieren kann um alles zu verschieben um es auf einem neueren Linux gangbar zu bekommen?

b.) Bekommt man für das SLES 10 eventuell auch noch irgendwo ein Veeam Agent zum installieren?

c.) oder gibt es einen anderen guten Weg wie man eventuell via SSH ein Image vom System machen kann um dieses zu virtualisieren?

Ich weiß, der eine oder andere wird jetzt sagen "mach das nicht weil...", aber das ist zum jetzigen Zeitpunkt keine Option, da uns das System (da es ein physikalischer Rechner ist) jeden Tag um die Ohren fliegen kann und dann geht hier nichts mehr.

Ich kann sagen, PHP 4.x für Debian Bullseye hab ich keins gefunden... Veeam Agent für SLES 10 hab ich keinen gefunden, die Web Anwendungen die noch auf PHP 4 laufen, habe ich nicht in einer aktuelleren Version gefunden, zumal hier auch das eine oder andere selbst gebaut ist. Mittels VMware Converter über SSH hab ich schon ein Abbild versucht, der kommt aber nicht hoch weil er scheinbar die Laufwerke nicht findet / einbinden kann, die Daten wären aber scheinbar da.

Die VM hab ich nämlich mal mit einem Knoppix gestartet, "mount /dev/sda3 /mnt" sowie "mount /dev/sda1 /mnt/boot" hab ich schon gemacht, die Inhalte sehen gut aus, via chroot kann ich auch in das System rein, hab die "/etc/fstab" schon mal angepasst, hab auch schon geschaut ob es hilft wenn ich die menu.lst im Grub Ordner anpasse, aber leider bekomme ich das nicht gestartet. Auch da wäre die Option es gangbar zu bekommen, aber da ich keine Einträge im /var/log sehe vom Bootvorgang der virtuellen Maschine, vermute ich mal dass er die Laufwerke gar nicht erst korrekt eingehängt bekommt.

Es sind viele Fragen, viele Ansätze, zumal ja viele Wege nach Rom führen, aber vielleicht hat hier ja jemand einen coolen Tipp / Ansatz für mich :)

Schon mal vielen Dank im Voraus, ich bin auf die Ideen / Tipps gespannt. Ja, ich weiß... irgendwann müssen wir eventuell mal die Applikationen aktualisieren, aber wie gesagt... Zeit ist das Problem, die Prioritäten lege ich nicht fest, aber mit dem aktuellen System muss es doch dennoch möglich sein, dieses zu virtualisieren...

Gruß, Domi
 
a.) Bekommt man für Debian Bullseye noch irgendwo ein PHP 4.x her, welches ich relativ einfach implementieren kann um alles zu verschieben um es auf einem neueren Linux gangbar zu bekommen?
Click to expand...
Sehr unwahrscheinlich.

b.) Bekommt man für das SLES 10 eventuell auch noch irgendwo ein Veeam Agent zum installieren?
Click to expand...
Ich habe keine Ahnung von Veeam. Aber für ein OS, das vermutlich ~10 Jahre EOL ist? Sehr unwahrscheinlich.

c.) oder gibt es einen anderen guten Weg wie man eventuell via SSH ein Image vom System machen kann um dieses zu virtualisieren?
Click to expand...
Ich habe bis vor kurzem für eine paar Jahre ein SLES 9 virtualisiert gehabt. Das war sehr problematisch. Die VM hatte einen eigenen Host gebraucht, weil sie Lastempfindlich war und bei zu viel Last auf dem Server ist, die einfach nur abgeschmiert.

Ich weiß, der eine oder andere wird jetzt sagen "mach das nicht weil...", aber das ist zum jetzigen Zeitpunkt keine Option, da uns das System (da es ein physikalischer Rechner ist) jeden Tag um die Ohren fliegen kann und dann geht hier nichts mehr.
Click to expand...
Wieso? Was ist kaputt bzw. am kaputt gehen? Platten könnte man vermutlich austauschen.

Ich kann sagen, PHP 4.x für Debian Bullseye hab ich keins gefunden...
Click to expand...
Du könntest ein Debian 5 (Lenny, oder Debian 4? 6?) installieren. Das liefert PHP 4 mit. Das wäre IMO eine der realistischeren Optionen PHP 4 ans laufen zu bekommen.
 
greystone said:
Wieso? Was ist kaputt bzw. am kaputt gehen? Platten könnte man vermutlich austauschen.
Click to expand...
Aktuell nein... aber dass muss ja in der EDV Welt nichts heißen, darum wollen wir von dem physischen System weg. Wir haben schon Server im dreistelligen Bereich virtualisiert und da läuft die Datensicherung auch sehr gut und zuverlässig. Und um die eine oder andere physische Maschine los zu werden, ist der Plan das Teil zu virtualisieren. Vielleicht gab es mit dem System schon mal Probleme, aber seit dem ich da bin, noch nicht :D

greystone said:
Du könntest ein Debian 5 (Lenny, oder Debian 4? 6?) installieren. Das liefert PHP 4 mit.
Click to expand...
Das wäre noch mal ein Ansatz... das probiere ich erst einmal bei mir in einer virtuellen Maschine aus, spreche mit meinem Kollegen darüber und ich denke mal, dass wird er so abnicken, wenn das klappt. So könnte ich dann zumindest mit meiner vertrauten Umgebung (Debian) weiter machen, erst einmal alles versuchen mittels PHP4 von SLES auf Debian zu migrieren und dann anschließend (wenn es virtualisiert ist) daran weiter zu arbeiten.

Hier sind dann leider mehrere Instanzen gefragt mit denen geklärt werden muss ob eine Web Applikation noch gebraucht wird, ob sie weg kann etc. und das Problem ist halt, es lief die Jahre über immer ohne Probleme, somit wurde an dem System nie etwas gemacht. Ich denke mal, im Intranet sieht man halt weniger Probleme und gefahren, was ja auch stimmt... aber existent wären sie dennoch :)

Aber schon mal vielen Dank für die Ansätze... das probiere ich aus.
 
Domi said:
Aktuell nein... aber dass muss ja in der EDV Welt nichts heißen, darum wollen wir von dem physischen System weg. Wir haben schon Server im dreistelligen Bereich virtualisiert und da läuft die Datensicherung auch sehr gut und zuverlässig. Und um die eine oder andere physische Maschine los zu werden, ist der Plan das Teil zu virtualisieren. Vielleicht gab es mit dem System schon mal Probleme, aber seit dem ich da bin, noch nicht :D
Click to expand...
Ah. Ok. Das "kann uns jederzeit um die Ohren fliegen" in Deinem Anliegen schien mir etwas Panik auszudrücken. Deshalb frug ich nach, ob hier besondere Eile geboten ist.

Ansonsten zum Backup: Vielleicht einmal ein Image erstellen und ansonsten regelmässiges Dateibackup. Falls man das FS wieder neu erstellen muss, muss man vermutlich die Inode-Size auf 128 Bytes begrenzen(-I bei mkfs). Am besten auch Partitionstabelle sichern(sfdisk -d) und vielleicht mal ein tune2fs -l von den Dateisystemen aufheben, wenn's ext2/3/4 ist. Das hilft für den Fall eines notwendigen Restores schon sehr.
 
ggf. bleibt dir die Option im PHP Archiv php4 zu laden und ggf. manuell zu kompilieren. Aber ob das alles ohne Probleme gut geht, da php ja auch einige Abhängigkeiten hat.
 
Wäre evtl ein (uralter) Docker Container ( z.B. https://hub.docker.com/r/nouphet/docker-php4/ , nur mal nach schneller Suche gefunden) als Basis etwas? Damit könnte das OS aktuell, die Anwendungsumgebung im Container aber uralt sein. Und man könnte das alte System hinter einen Reverse Proxy packen, um nicht alle Systemschwachstellen einer Uraltdistro (auch wenns intern ist) zu exposen. Die PHP Schwachstellen wird man allerdings trotzdem haben.
 
Alternativ hatte ich bei dem gleichen Problem mal ein altes Ubuntu installiert: http://old-releases.ubuntu.com/releases

Ubuntu 9.10 hat zum Beispiel PHP 5.2.

Die Idee mit dem Docker Container wäre natürlich auch okay.
Und am besten wäre es schlicht die PHP Anwendung upzudaten. Im Regelfall hat sich da von Version zu Version jetzt nicht soooo viel schlimmes geändert. Von wievielen LOC reden wir denn?
 
Moin, die Gedanken einer älteren Version (ob nun Debian oder Ubuntu wäre mir da sogar egal) werde ich nachher mal durch gehen. Vielleicht werde ich das auch erst zuhause in einer VM ausprobieren und dann auf der Arbeit einspielen, mein Kollege wird aber mit Sicherheit nichts dagegen haben.

Auch der Gedanke mit einem Docker Container und PHP4 klingt cool, so könnte man dann als Basis sogar das aktuelle Debian behalten, damit werde ich eventuell nachher sogar mal anfangen und es ausprobieren.

Thunderbyte said:
Und man könnte das alte System hinter einen Reverse Proxy packen, um nicht alle Systemschwachstellen einer Uraltdistro (auch wenns intern ist) zu exposen. Die PHP Schwachstellen wird man allerdings trotzdem haben.
Click to expand...
Vollkommen verständlich, da das Teil aber zum Glück "nur" im Intranet ist, ist die Gefahr nicht ganz so groß wie ein Webserver in irgend einem Rechenzentrum und somit vollkommen öffentlich erreichbar über das Internet :) Das eine macht das andere jetzt nicht besser, aber ich hoffe wir verstehen uns da.

ThomasChr said:
Von wievielen LOC reden wir denn?
Click to expand...
... eine Abkürzung die ich nicht kenne, denke aber du meinst "Line of Code" und dass ist schwer zu sagen... das eine oder andere konnte ich selbst anpassen, so dass es mit PHP 5.6 oder neuer funktionieren würde. Dann ist da noch ne ganz ganz alte xt-Commerce installiert (Version müsste ich gucken), dann ist da so ein kleines Newsfeed Tool, welches aber signifikant Wichtig ist da die Kolleginnen und Kollegen aus der einen oder anderen Abteilung rein schreiben. Das dritte fällt mir gerade nicht ein, da müsste ich selbst noch mal durch gucken... vielleicht waren es aber doch nur die zwei Anwendungen.

Das ganze läuft sogar über einen LAMPP Stack... als ich den Dienst für Port 80 neu starten wollte, war das schon ein Akt. So Befehle wie "service apache2 start" etc. kenne ich, auch über init.d die Dienste starten kenne ich, aber dieser "Apache" Dienst läuft irgendwie über /opt/lampp/ und der Dienst war nur für ca. 5 Sekunden weg, da kam sofort E-Mails von einem IT Kollegen und einem anderen Mitarbeiter dass das Intranet weg wäre. Bei knapp 1.000 Mitarbeiter scheint da also auch gut was los zu sein :D
 
Klingt ein bisschen so als wärst du in der Legacy Hölle gelandet :)

Ich wäre immer noch für Updaten der Programmcodes. Mit neueren PHP Versionen wirds dann schließlich auch schneller.

Aber ja, die Zeit muss man erstmal haben und auch bekommen. Die Realität ist da leider oft anders (die Firmen die in der Fertigung an Maschine XY immer noch einen Windows XP Rechner haben können da ein Liedchen von singen).

Berichte mal welche Lösung du dann letztendlich genommen hast!
 
Ansonsten würde ich irgendwann auch mal sagen: "lieber ein Ende mit Schrecken als Schrecken ohne Ende". ;)

Also irgendwann muss eh was neues her.
 
Ich sag es mal so, mit dem Betriebswechsel hab ich alles richtig gemacht, man lernt viele neue Dinge etc., es macht auch Spaß... das gute ist, wir sind alles "nur" Menschen. Das Thema "Intranet Server" hatte man mir aufgrund der Linux Erfahrungen auf das Auge gedrückt und ich meinte "ist bestimmt easy", hatte mir auch schon gedacht dass es mit PHP 8.x nicht geht, darum PHP 5.6 aus den repository von "sury??" besorgt und dann ging ja schon das meiste.

Das First-Level Team hat geprüft, wir aus dem Infrastruktur Team haben geschaut, sieht gut aus, dann hat ein anderer Teil nach seinen Masken geschaut und dann kam das große "ohhh"... xt-Commerce wollte ich gucken ob es dafür ein Update gibt, ja es gibt welche aber solche Versionssprünge dürften kritisch werden und vermutlich geht dann auch deren Template nicht mehr oder irgend etwas anderes.

Daher war dann der Gedanke, das System erst einmal virtualisieren und darüber in Sicherheit bringen. Auf Dateisystem-Ebene gibt es einen Cronjob der die Daten weg sichert, ein Cronjob für die SQL Datenbank hab ich dann noch gebaut, weil man nur die FTP Daten weg gesichert hatte, aber wenn einem das System natürlich um die Ohren fliegt und man solche alten PHP Versionen nicht mehr gangbar bekommt, wird es echt eng.

Und Projekte hab ich schon einige... Admin Tiering ist sehr spannend. Hab sonst immer nur in bis zu 15 Personen Domänen durch meinen ehemaligen Arbeitgeber oder meine Selbstständigkeit im Nebenerwerb gearbeitet, aber das bei uns ist schon was anderes :)
 
Einmal ein Nachtrag zu dem ganzen Thema... ich hab vorhin mal ein wenig in einer VMware ausprobiert und bin zu dem Entschluss gekommen, ich nehme ein aktuelles Debian (oder Ubuntu) und haue mir dort ein PHP4 innerhalb eines Docker drauf. Hier gibt es sogar ein Paket :)

Nun muss ich nur erst einmal ein paar Docker Skills rein bekommen... hatte mich vor ein paar Jahren schon mal damit befasst und brauchte es dann nicht wieder :D

Gibt es da eventuell lesbares Material für "Basics", welches man empfehlen kann?
 
Thumbs up. Die Beschäftigung mit Docker lohnt sich, glaub mir. Am Schluß wirst Du alles so machen. ;)

Docker selbst bietet ja alle mögliche Doku.

https://docs.docker.com/get-started/overview/ , https://docs.docker.com/engine/ , Du willst Dich auch mit https://docs.docker.com/compose/ beschäftigen, da Du damit Deine Umgebungen zusammenbauen kannst.

Ansonsten würde ich sagen: einfach anfangen und beim Machen lernen, idealerweise natürlich nicht direkt im Internet sondern z.B. auf ner Linux VM / nem Testrechner.

Mein Tip (der mir auch so gegeben wurde und der sehr praktisch ist): mach Dir ein privates Github Repo und pushe Deine docker-compose Files da rein. Damit haste ein Backup Deiner Konfig und kannst Dir die compose Files überall hin pullen.

Ansonsten lege ich immer noch vor jeglicher Benutzung eine /etc/docker/daemon.json an ( https://docs.docker.com/engine/reference/commandline/dockerd/ ):

Diff: 
{
"data-root": "/docker/",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

die mir das Docker Data Root höher zieht (wäre sonst in /var/lib/docker ). Siehe hierzu auch https://www.ibm.com/docs/en/z-logdata-analytics/5.1.0?topic=compose-relocating-docker-root-directory

Dann noch drei Ordner:
- docker (als Root Folder für den Daemon)
- docker_build (für die Compose Files)
- docker_data (für die herausgelegten Dateien, die man via "-v" aus dem Container herauslegt, damit sie nicht überschrieben werden)

Der letzte Punkt ist auch noch der wichtigste Teil: Docker Container sind keine VMs und sollten jederzeit gelöscht / neu gebaut werden können. Damit die Nutzdaten nicht verloren gehen, werden sie via "-v" als Volumes herausgelegt. Das geht entweder mittels Angabe eines absoluten Pfades oder als Docker Volume, dann kümmert sich Docker um die Anlage und legt es ins Docker root Dir (siehe daemon.json).

Empfehlenswerte Youtube Kanäle / Playlists:

Falls Du weitere Fragen hast, gibts ja auch https://serversupportforum.de/forums/containerisierung.94/
Wer mal damit anfängt, wird alles damit machen...
 
Joa, dass ist mal eine ausführliche Auflistung :)

Ich musste mal überlegen warum ich damit vor ein paar Jahren herum experimentiert hatte... mein Gedanke war, Bitwarden und meinen Ubiquiti Controller auf eine Maschine zu bringen. Docker Compose Beispiele hatte ich dafür auch gesehen und ich muss sagen, dass sah echt cool aus. Man kann damit schön übersichtlich die Pakete zusammen schnüren.

Vor allem wenn man z.B. einen Webserver und MySQL Datenbank aufbauen möchte.

Aktuell ist mein Debian auf dem ich im Container herum experimentiere in einer VMware, aber vielleicht baue ich mir auch eine VM (kein Container) auf meinem Proxmox Server auf, den ich im Keller habe und experimentiere damit herum.

Ich bedanke mich schon mal vielmals und wünsche ein charmantes Wochenende.
 
Ich hatte so ein "Reverse Proxy" Paket gesehen... und wo ich das gerade erwähne, fällt mir auch ein dass es "Elements" für das Matrix Netz war, warum ich mich mal mit Docker befasst hatte. Neben Bitwarden und Unifi (Ubiquiti) Controller parallel auf einem System.

Was Docker angeht, ich hab mir ein php4 Paket sowie ein pure-ftpd Paket besorgt und erst einmal geschaut wie ich es hin bekomme, dass ich durch pufeftpd in das php / Apache Verzeichnis schreiben kann. War aber relativ simple und logisch. Vielleicht gibt es da noch sinnvollere Wege und Möglichkeiten, aber ich nutze weiterhin das /var/www/ Verzeichnis und das klappt.

Mir gefällt auch, dass ich mehrere SQL Instanzen parallel via Ports auf einem System laufen lassen kann, wobei das mit einem für docker eigenes Netzwerk vermutlich noch cooler geht, aber es tut was ich möchte. Hab zum testen einen Docker mit MySQL 5.x genommen, aber für diese eine "xt-commerce" Version scheint es wirklich auf MySQL 4.x anzukommen.

ABER ich kann somit schon mal die eine oder andere Lösung mit etwas aktuellerer MySQL Datenbank laufen lassen und das andere dann wieder über ältere Lösungen.

Es gibt auf jeden Fall schon schicke Möglichkeiten und Spielereien die man damit realisieren kann.
 
Ich wollte mal ein kleines Zwischenfazit da lassen...

Thunderbyte said:
ich lege die Ports überhaupt nicht auf den Host raus, sondern spreche die Container nur durch den Reverse Proxy an
Click to expand...
Darüber haben Kollege und ich vorhin auch gesprochen... ich hatte schon mal mit diesem Nginx Teil gearbeitet, irgendwas ging da aber nicht. Vielleicht bringe ich den sogar wieder in das Spiel und lasse ihn die Abfragen abarbeiten. Hab nämlich aktuell folgendes Szenario realisiert...

- http://ServerIP/ (PHP5 Dienst)
- http://ServerIP:81/ (PHP4 Dienst)

Eingebunden habe ich die Volumes beide in "/var/www/html", was sogar sehr gut funktioniert. Ich muss nur eine Datei anpassen und kann diese via PHP4 oder PHP5 testen. Und da sogar einiges PHP5 kann, könnte ich es sogar schon mal umbauen und Objektorientierte Programmierung anwenden, was mir sehr gut gefällt :)

Volumes sind noch minimal rätselhaft... wenn ich das Prinzip richtig verstehe, sind die Daten immer in "volumes/name/_data/" drin, da gibt es aber auch mal Ausnahmen und ich hab beim starten meiner Container ein Volume mit einem Random Wert... ich muss noch herausfinden welcher Container dieses erstellt. Genauso muss ich noch verstehen, welche Pfade ich immer via "volume" einbinden muss. Irgend ein Docker Container nutzt z.B. "/var/www/html/" und ein anderer hatte was mit "/opt/apache2/htdocs/" verwendet...

Aber da komme ich noch hinter... hoffe ich. Zumindest ist das eine sehr coole Angelegenheit und gefällt mir sehr gut.
 
Wenn Du das auf 2 Ports hast, könntest Du hinter einem Reverse Proxy (Nginx) auch zwei unterschiedliche Domains verwenden, die dann PHP4 oder 5 ansprechen. Z.B. php4.meinedomain.de -> http://ServerIP:81/ und php5.meinedomain.de -> http://ServerIP/ . Das kann natürlich auch jede beliebige andere Subdomain sein, z.B. intra-old.meinedomain.de und intra.meinedomain.de. Die Domains zeigen dann auf die IP des Host Servers und der Proxy leitet weiter.

Hinweis: ein Reverse Proxy ist in erster Linie für HTTP(S) Verkehr geeignet. Wenn Du z.B. einen Mailserver im Container betreiben willst, kann die Weboberfläche z.B. durch den Proxy gehen, die SMTP, POP, IMAP etc Ports müssen aber rausgelegt werden und gehen nicht durch den Proxy.


Bei Volumes hast Du im Wesentlichen zwei Möglichkeiten:
1. Du matchst einen Ordner im Hostfilesystem mit einem Ordner im Container
2. Du sagst Docker, leg mir ein Volume (eine Speichermöglichkeit auf dem Host) an, dann legt Docker an seinem Standardort ( /var/lib/docker/volumes/ ) einen entsprechenden Ordner an.

Siehe hierzu https://docs.docker.com/storage/volumes/ :
Beispiel für 1.:
Code: 
    volumes:
      - "/meinordner/unterordner/myapp:/home/node/app"

Hier wird der Ordner "myapp" im Filesystem (dieser Ordner liegt im Ordner /meinordner/unterordner auf dem Host) auf den Ordner /home/node/app im Container gemappt. D.h. was im Ordner /meinordner/unterordner/myapp auf dem Host ist, ist im Container in /home/node/app. Da dieser Ordner "herausgelegt" ist, bleibt er bei einem Neubau des Containers erhalten.

Beispiel für 2.:
Code: 
    volumes:
      - "myapp:/home/node/app"

Hier weist man Docker an, das Volume "myapp" auf dem Host zu erstellen (standardmäßig in /var/lib/docker/volumes/ , wenn mans nicht verlegt hat) und den Inhalt mit dem Ordner home/node/app im Container zu mappen.

Beide Arten haben so ihre Vor- und Nachteile.
 
Moin... alles klar, die "Volumes" Seite von docker.com hatte ich mir auch schon angeschaut, weil ich mich gefragt hatte wo dieses Volume mit der kryptischen Bezeichnung her kommt und ob man das irgendwie herausfinden kann.

Aktuell hab ich es wie folgt gemacht, die Container für "ftpd", "php4" und "php5" sind via "Ordner" gemappt und landen direkt beim Host im "/var/www/html", dass funktioniert gut und tut was es soll. Via FTP können die Leute aus dem Netzwerk darauf zugreifen und ihren Plunder dort hoch laden, anschließend können beide Web Dienste darauf zugreifen. Präferiert ist aber der "php5" Container auf Port 80 und die alte XT Commerce wird dann über Port 81 abgerufen. Für die restlichen Pfade die es so in den Containern gibt, hab ich dann wieder Volumes genutzt, so dass ich Apache oder PHP der unterschiedlichen Instanzen anpassen kann.

Wenn ich das Prinzip des Reverse Proxy korrekt verstanden habe (hab mir den nochmal angeschaut) muss der mit Domains und / oder Subdomains arbeiten, der kann nicht via "Pfad" gesteuert werden. Beispiel,
- http://intranet/ -> php5 Container auf Port 80
- http://intranet/xt/ -> php4 Container auf Port 81

Soll aber auch kein Abbruch sein, dann hinterlege ich einfach A-Records im DNS und schon würde das auch gehen.

Dass natürlich der Reverse Proxy bevorzugt für SSL Verschlüsselungen da ist, hab ich auch schon gesehen... aber bei uns im Intranet ist das eher obsolet. Zumal die xtCommerce jetzt auch nicht so dargestellt ist, dass man sagen könnte "ohh, so etwas sollte aber verschlüsselt sein" etc., denn das System ist nur dazu da, dass ein Mitarbeiter Visitenkarten beim Marketing Team ordern kann.

Das schöne ist, es funktioniert... somit können wir nach meinem Urlaub noch einmal die MySQL Daten transferieren und anschließend einen Schwenk von der physischen Maschine auf eine virtuelle Maschine mit Containern machen. Dann kann die physische Maschine sogar weg :)
 
You must log in or register to reply here.
Back
Top