Ubuntu 14 Desktop als OVA oder OVF virtualisieren
Hallo,
am Institut haben wir noch eine alte Ubuntu Desktop mit einer selbst entwickelten Anwendung, die aus Sicherheitsgründen ins RZ muss.
Die Anwendung benötigt eine angepasste PHP / DB Umgebung. Eine Neuinstallation wäre also etwas mühsam.
Wir würden also gerne das komplette System in einen OVF / OVA Container "schieben" und im RZ als solche importieren.
Ist das Vorhaben umsetzbar / sinnvoll? Wenn ja, wie geht man am besten vor?
Vielen Dank für eure Empfehlung.
LG
I.
am Institut haben wir noch eine alte Ubuntu Desktop mit einer selbst entwickelten Anwendung, die aus Sicherheitsgründen ins RZ muss.
Die Anwendung benötigt eine angepasste PHP / DB Umgebung. Eine Neuinstallation wäre also etwas mühsam.
Wir würden also gerne das komplette System in einen OVF / OVA Container "schieben" und im RZ als solche importieren.
Ist das Vorhaben umsetzbar / sinnvoll? Wenn ja, wie geht man am besten vor?
Vielen Dank für eure Empfehlung.
LG
I.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 601912
Url: https://administrator.de/forum/ubuntu-14-desktop-als-ova-oder-ovf-virtualisieren-601912.html
Ausgedruckt am: 04.04.2025 um 18:04 Uhr
3 Kommentare
Neuester Kommentar
3 Sekunden bei Dr. Google... 
https://askubuntu.com/questions/308897/convert-ubuntu-physical-machine-t ...
https://www.howtogeek.com/213145/how-to%C2%A0convert-a-physical-windows- ...
Alternativ:
https://askubuntu.com/questions/308897/convert-ubuntu-physical-machine-t ...
https://www.howtogeek.com/213145/how-to%C2%A0convert-a-physical-windows- ...
Alternativ:
- Mit USB/DVD/PXE ein Live Linux booten
- Mit ddrescue ein Image auf USB-HDD oder Netzwerk ziehen.
- mit qemu-img nach vmdk konvertieren siehe https://possiblelossofprecision.net/?p=2293
- vmdk in eSXI einbinden.
Ihr habt also Anpassungen im Quellcode von PHP (und der DB auch?!) vorgenommen und selbst kompiliert? Oder was soll das bedeuten?
Umsetzbar sicherlich, für sinnvoll halte ich das nicht. Sicherheitskritische Sachen selbst zu hostent ist gut. Aber dann auf uralte Software setzen, die wohl nicht mehr gewartet wird und bei der auch die Plattform darunter (OS, PHP, Webserver etc) wohl schon ewig kein Update mehr gesehen hat? Merkst du selbst, wo der Widerspruch ist?
Die sinnvollste Lösung wäre, sich Zeit für eine Analyse zu nehmen, was da genau angepasst ist/wurde. Im besten Falle ist das dokumentiert. Wenn damals geschlampt wurde, muss man eben jetzt die technischen Schulden bezahlen und das nachholen. Mit den Infos kann man dann schauen, wie das auf aktuellen unterstützten Plattformen umgesetzt werden kann.
Da muss man sich jetzt halt entscheiden: Ist die Anwendung wirklich sicherheitskritisch, dann darf so was nicht zu "mühsam" sein. Im Gegenteil, es wird höchste Zeit das nachzuholen, was bisher wohl vernachlässigt wurde. Oder sie ist halt doch nicht so kritisch, dass es einem der Aufwand wert ist - und man fährt weiterhin dieses Gebastel in der Hoffnung, dass es einem nicht um die Ohren fliegt.
Gerade in deiner Situation gibt es dafür aber keine gute Ausrede: Du hast das Glück, lauter offene Technologien und Systeme einzusetzen. Das heißt du KANNST das mit halbwegs moderatem Aufwand beheben. Im Gegenzug zu jemand der sich damals für proprietäre/Drittanbieter Systeme (Windows, altes .NET etc) entschieden hat: Der hat gar nicht die Möglichkeit, das so gut es geht abzusichern. Dem bleibt wirklich nur die Isolation der gesamten Maschine und zu beten, dass kein ernster Angriff kommt, der das Ding so richtig schön auseinander nimmt. Solche Legacy-Systeme gibt es viele, weil damals Open Source noch eine Nische war. Das ist dann mal ein richtig lustiges Damokles-Schwert. Von dem her bist du vergleichsweise in einer sehr guten Position, das überhaupt fixen zu können.