Image von Strato V-Server ziehen?

[Uhu U. (uhu)]

Kann man von einem Strato V-Sever ein Disk-Image ziehen, das sich auf 
einer virtuellen Maschine installieren läßt? Wenn ja: wie?

[unix (Gast)]

Wenn da Unix läuft via dd lokal erstellen (so genug Platz ist) und dann 
umgekehrt.
Nur warum nicht alles via FTP ziehen und dann manuell kopieren ?

[TestX (Gast)]

Kurze Antwort: So wie du es dir vorstellst nein.

[Uhu U. (uhu)]

TestX schrieb:
> Kurze Antwort: So wie du es dir vorstellst nein.

/boot ist auf dem Ubuntu-V-Server komplett leer - keine gute 
Voraussetzung...

[unix (Gast)]

Uhu U. schrieb:
> TestX schrieb:
>> Kurze Antwort: So wie du es dir vorstellst nein.
>
> /boot ist auf dem Ubuntu-V-Server komplett leer - keine gute
> Voraussetzung...

Natürlich ist das leer, Du mußt den Webserver (Apache z.B.) erstmal 
selber installieren und zwar mit allem was der V-Server hat.
Danach kannst Du in Deinem V-Server entweder das dd image installieren 
oder die Kopie vom FTP.
Du hast das Prinzip von V-Servern nicht verstanden.
Eine Server-Instanz mit fixer IP hat mehrere Inhalte die über die URL 
aufgelöst werden aber die gleiche IP haben.
Wenn Du lokal Deine Website testen und aktualisieren willst bevor Du sie 
auf den Host bringst solltest Du Dir ansehen welcher WWW-Server samt 
Erweiterungen auf Deinem öffentlichen Hoster installiert ist und nachdem 
Du die gleiche Konfiguration hast Deine Daten via FTP in Deinen eigenen 
Server packen und testen.

[Planlos (Gast)]

unix schrieb:
> Du hast das Prinzip von V-Servern nicht verstanden.

Es geht hier um "V-Server", Marketing-Speak für Linux-Installationen auf 
virtuellen Maschinen, die man bei Strato mieten kann.

Du meinst HTTP-(Name based) Virtual hosts.

Uhu U. schrieb:
> Kann man von einem Strato V-Sever ein Disk-Image ziehen, das sich auf
> einer virtuellen Maschine installieren läßt? Wenn ja: wie?

Rechtlich: Evtl. eine Raubkopie, je nachdem was Strato da vorinstalliert 
hat.

Technisch: Im Prinzip Ja.


Bevor du das mit einem echten Image vom Dateisystem probierst: Es geht 
evtl. auch einfach mit einer Datei-basierten Kopie.

Uhu U. schrieb:
> /boot ist auf dem Ubuntu-V-Server komplett leer - keine gute
> Voraussetzung...

Bei paravirtualiserten Systemen durchaus normal, dass der Kernel 
"außerhalb" der VM vorgehalten wird.

Vorteile:
 - Host muss das Dateisystem auf den Gast-Plattenimages nicht lesen 
können
 - Gastsystem kann den Kernel nicht durch eine eigene Version ersetzen 
(die ggfs. für den paravirtualisierten Betrieb nicht geeignet ist)
 - Host muss kein BIOS emulieren, damit der Gast mit GRUB o.Ä. seinen 
eigenen Kernel laden kann.

Du wirst bei dir zuhause vmtl. eh eine andere Virtualisierungs-Software 
einsetzen als Strato. ==> du brauchst sowieso einen eigenen Kernel, der 
mit deiner VM harmoniert. ==> das leere Boot-Verzeichnis ist kein 
Problem.


Wenn du zuhause mit einer Voll-Virtualisierung (z.B. VMWare/VirtualBox) 
arbeiten willst, dann kannst du einen normalen x86/amd64-Kernel 
verwenden.


ABER: Wäre es nicht viel einfacher, du installierst bei dir einfach 
lokal dieselbe Linux-Version die auch dein V-Server fährt, und kopierst 
dir nur die Konfiguration, Daten-Files etc?

[Uhu U. (uhu)]

Planlos schrieb:
> Rechtlich: Evtl. eine Raubkopie, je nachdem was Strato da vorinstalliert
> hat.

Es läuft z.Zt. Ubuntu 10.04, auf Plesk u.ä. Wunderdinger habe ich 
absichtlich verzichtet - wie man die raubmordkopieren soll, erschließt 
sich mir nicht.

> ABER: Wäre es nicht viel einfacher, du installierst bei dir einfach
> lokal dieselbe Linux-Version die auch dein V-Server fährt, und kopierst
> dir nur die Konfiguration, Daten-Files etc?

In "einfach" liegt der Hund begraben... Das riecht eher nach Chaos ohne 
Ende.

Dann doch eher eine Komplettkopie und damit das Dateisystem der 
heimischen VM ersetzt, mit Ausnahme des /boot-Verzeichnisses natürlich, 
in der das lokale 10.04 vorinstalliert ist.

Dafür würde sich rdiff-backup anbieten - einen Versuch wäre es wert. Um 
das lokale System zu konfigurieren, mountet man die virtuelle 
Systemplatte in eine andere VM.

[Dirk D. (dicky_d)]

unix schrieb:
> Wenn da Unix läuft via dd lokal erstellen (so genug Platz ist) und dann
> umgekehrt.
> Nur warum nicht alles via FTP ziehen und dann manuell kopieren ?

Ein dd von einen rw gemountetem device ist eine eher schlechte Idee.

Zum Problem:
Nein, SO einfach geht das nicht.
Das was meiner Meinung nach an ehesten dran kommt:
Installiere das selbe Betriebssystem mit der selben arch in deiner vm.
Mach, wenn du da fertig bist am besten nen clone von, falls du das 
nochmal brauchst.

Mach auf dem Vserver mit dpkg --get-selections [1] eine Liste aller 
Installierten Pakete.
Übertrage die Liste in die VM, und Installier alle Pakete aus der Liste 
mit dpkg --set-selections (auch [1]).
ggf. musst du, wenn du zusätzliche Paketquellen eingebunden hast alles 
aus /etc/apt/ vorher von vserver in deine vm kopieren.

mach jetzt eine kopie von etc, die wirst du später brauchen.

Jetzt Fährst du deine vm runter und Bootest eine Live-CD, deine ubuntu 
installation-cd eignet sich super dafür.

Jetzt kannst per rsync via ssh alles was du vom vserver brauchst in 
deine vm kopieren, mounte dafür in deiner vm die platte in dein 
live-system.
Dann kopierst du aus denem vserver alles was du brauchst. wenn du das 
nicht weiß sind folgende Ordner ein guter Rat:
/bin
/etc
/home
/lib
/lib32
/lib64
(je nach arch gibts bei den /lib* unterschiede, nim alle mit)
/opt
/root
/run
/sbin
/srv
/usr
/var


Wenn du das gemacht hat hast du alle Dateien in deiner VM, manche werden 
aber ggf in einem schlechten zustand sein, weil Dienste im Vserver die 
Datei beschrieben haben während du sie kopiert hast, oder 2 Dateien 
passen aus dem selben Grund nicht mehr zusammen.
Wenn du nur "Spielen" willst kannst du das ignorieren oder Du kannst 
weitermachen und Testen, und wenns klemmt kommst du wieder hier hin. 
Wenn du auf Nummer sicher gehen willst:

Remounte dein Dateisystem auf dem Vserver readonly

mount -lo remount,ro /

Die meisten deiner Dienste auf dem Vserver werden dann aber ihren dienst 
verweigern.
Starte den rsync-Vorgang nochmal.
Das wird diesmal Deutlich schneller gehen, da nur die Änderungen 
Übertragen werden.
Wenn das Fertig ist kannst du dein Root-Dateisystem wieder rw mounten, 
das machst du wie oben nur mit rw statt ro.

Jetzt hast du eine vm die Ihren Kernel booten kann und sich ansonsten 
verhält wie dein Vserver.
Auch wenn sich das gut anhört ist das nicht das was du willst.
Dein vserver weiß nichts von Festplatten.
Deswegen musst du aus deinem Backup von etc die fstab wieder 
zurückhohlen.
auch hat dein vserver andere Netzwerkeinstellungen aus deine vm, die 
musst du auch zurückhohlen, sie liegen unter /etc/network

Danach sollte deine VM Durchbooten.
Es kann gut sein das einige Dienste trotzdem ihren Dienst verweigern, 
z.b. weil du sie an die IP-Adresse des Vservers gebunden hast, oder sie 
Certifikate haben die auf die ip oder eine Domain des Vservers 
ausgestellt sind, aber das wirst du errausfinden und im Einzelfall lösen 
(oder hier nachfragen) müssen.
Viel Spaß
Dirk



[1] https://wiki.ubuntuusers.de/Paketverwaltung/Tipps

[Uhu U. (uhu)]

Dirk D. schrieb:
> mount -lo remount,ro /

Das Herunterladen rsync ging erfreulich schnell, nur der ro-Remount geht 
nicht: auch root bekommt ein "permission denied".

[Dirk D. (dicky_d)]

Uhu U. schrieb:
> Dirk D. schrieb:
>> mount -lo remount,ro /
>
> Das Herunterladen rsync ging erfreulich schnell, nur der ro-Remount geht
> nicht: auch root bekommt ein "permission denied".

Hmm, das muss an der art liegen wie strato vserver macht.
Du kannst, um sicher zu gehen das keine nutzdaten kaputt sind 
(datenbank-files oder so) einfach alle Dienste (ausser ssh natürlich) 
anhalten und dann nochmal rsyncen

[c.m. (Gast)]

Uhu U. schrieb:
> Dirk D. schrieb:
>> mount -lo remount,ro /
>
> Das Herunterladen rsync ging erfreulich schnell, nur der ro-Remount geht
> nicht: auch root bekommt ein "permission denied".

das wäre nur wichtig bei dateien die sich während des rsync ändern 
(/var/log/* vor allem).
die wichtigen sachen, einstellungen unter /etc oder ggf daten unter 
/var/www oder /home sind nicht betroffen - vor allem wenn keine 
programme schreibend zugreifen (was auch bedeutet das man vor/während 
dem rsync unnötige dienste beenden sollte: apache, munin, ftp server, 
mysql… bla).

[Uhu U. (uhu)]

Dirk D. schrieb:
> Hmm, das muss an der art liegen wie strato vserver macht.

Das vermute ich auch. Ich denke, das ist alles nicht so schlimm, denn 
die Applikation, die dort läuft, wird est ab Mitte September wieder 
schreibend genutzt und falls die kopierte DB einen Knoten hat, kann ich 
sie von eigenen Backups auf dem Clon wieder laden.

Ein zweiter rsync-Lauf brachte auch nur Änderungen in Logs, einigen 
temp-Files des Serverpaketes und der .bash_history.

Jetzt kommt das Wiederaufsetzen... heute Abend.

-----
Nachtrag: rsync muss unter lokalen root-Rechten laufen, sonst gehören 
hinterher alle Verzeichnisse und Files dem User, unter dem kopiert 
wurde.

[Dirk D. (dicky_d)]

Uhu U. schrieb:

> Nachtrag: rsync muss unter lokalen root-Rechten laufen, sonst gehören
> hinterher alle Verzeichnisse und Files dem User, unter dem kopiert
> wurde.

Jo klar, wie soll er das auch anders anlegen.
Du brauchst das aber nicht Löschen und nochmal machen, ruf das selbe 
kommando nochmal als root auf, dann biegt er das schon grade.

[Uhu U. (uhu)]

Dirk D. schrieb:
> Jo klar, wie soll er das auch anders anlegen.

Ich hätte eine Fehlermeldung erwartet, aber rsync bringt keine.

[unix (Gast)]

Planlos schrieb:
> unix schrieb:
>> Du hast das Prinzip von V-Servern nicht verstanden.
>
> Es geht hier um "V-Server", Marketing-Speak für Linux-Installationen auf
> virtuellen Maschinen, die man bei Strato mieten kann.

Oh, dann ist das von mir falsch verstanden worden.

>
> Du meinst HTTP-(Name based) Virtual hosts.
>

Ja das meinte ich.

Wenn Strato selber eine Backupoption anbietet würde ich da mal 
nachsehen.
Um die eigene Umgebung in Deiner VM kommt man aber immer noch nicht 
herum.

[Uhu U. (uhu)]

unix schrieb:
> Wenn Strato selber eine Backupoption anbietet würde ich da mal
> nachsehen.

Die Backups bekommt man nicht, man kann sie nur zurücksichern.

[oszi40 (Gast)]

Uhu U. schrieb:
> Die Backups bekommt man nicht, man kann sie nur zurücksichern.

Dann ist die Frage, WOHIN sie zurücksichern. Entweder überschreiben sie 
ALLES alte ODER schieben die letzten Backupdaten in einen Ordner z.B. 
"OLDuhu" für Dich? Frag mal.

[unix (Gast)]

Uhu U. schrieb:
> unix schrieb:
>> Wenn Strato selber eine Backupoption anbietet würde ich da mal
>> nachsehen.
>
> Die Backups bekommt man nicht, man kann sie nur zurücksichern.

Und wie sichern sie ?
Via externem cronjob oder läuft da ein deamon (z.B. TSM) ?
Wenn lokal sollte da eine config sein wo drin steht was wann läuft.
Stellt sich mir aber immer noch die Frage warum nicht via FTP und 
SQLDumper sichern ?

[Uhu U. (uhu)]

oszi40 schrieb:
> Dann ist die Frage, WOHIN sie zurücksichern.

Die Sache ist ganz einfach: alles, oder nichts. Und "alles" heißt, dass 
der komplette Server auf den Backup-Stand gesetzt wird.

Bewegungsdaten sichere ich per cron job in ein spezielles Verzeichnis, 
das von der Rücksicherung oder dem kompletten Neuaufsetzen des Severs 
mit einem neuen OS unberührt bleibt.

unix schrieb:
> Und wie sichern sie ?

Das geht einmal täglich automatisch. 10 Stände werden gehalten.

[unix (Gast)]

Uhu U. schrieb:
> Das geht einmal täglich automatisch. 10 Stände werden gehalten.

Und was für ein Interface gibt's dafür, kann man da eine lokale Kopie 
speichern ?
Mach doch einfach ein Ticket für ein Backup auf.
Wie gesagt via FTP und SQLDumper kannst Du alles selber holen.

[Uhu U. (uhu)]

Es sieht schon ganz gut aus, aber der Boot bleibt irgendwann hängen - 
kein Wunder, ich habe nichts gemacht, um den auf meiner VM zu beginn 
eingerichteten User in das Abbild des Strato-Servers zu übernehmen.

Reicht es, die /etc/passwd zu kopieren, oder muss ich da noch mehr 
machen?

Sehe ich das richtig, dass er im init hängen geblieben ist und die 
Ursache das /etc/init.d von Strato ist? Ich kopier mal das 
init.d-Verzeichnis


Nachtrag: auch mit dem "richtigen" /etc/init.d kommt er nicht weiter, 
allerdings mit anderen Meldungen - siehe screenshot-2

[Uhu U. (uhu)]

Ich habe nochmal einen Anlauf genommen:

1. Ubuntu Server 10.04.4 in einer VM aufgesetzt
2. Paketliste vom Strato-Server mit dpkg --get-selections geholt und
   auf dem VM-Server mit dpkg --set-selections importiert und mit
   apt-get dselect-upgrade installiert.
3. das home-Verzeichnis, in dem die Anwendung liegt, mit rsync geholt
4. /etc des Strato-Servers in ein anderes Verzeichnis in der VM kopiert
5. Auf dem Strato-Server mit gem list die Liste der geladenen gems
   geholt und per Editor in ein Ladeskript für die VM umgebaut.
6. Ubuntu 10.04-spezifisch: gem install rubygems-update und
   ./update_rubygems.
7. /etc/network der VM angepasst
8. /etc/apache2 der VM angepasst.

Wenn ich jetzt noch den Apachen dazu kriege, das Rails-Paket auch noch 
auszuführen, sollte der Clon des Strato-Servers komplett sein.