Re: Rootserver Umzug. Was beachten?
Am Montag, 3. April 2006 23:15 schrieb Andreas Pakulat:
> On 03.04.06 21:55:26, Markus Schulz wrote:
[...]
> > Ja, war als Synonym für eine remote Copy-Session zu verstehen, z.B.
> > mit rsync oder scp ...
> > Problematisch bleibt dabei aber die Rechte/Owner Erhaltung. Daran
> > hatte ich erst garnicht gedacht. Wird wohl via tar (z.B. wie Sven
> > Bröckling schilderte) passieren müssen.
>
> cp koennte das auch, allerdings nicht remote. scp scheint nur die
> Rechte zu behalten, aber nicht den Besitzer.
es geht aber leider nicht ohne remote. Sonst hätte ich die Platte
einfach in den neuen Rechner hängen lassen und alles wäre gut.
> > Die erste Variante hätte eventuell auch das Problem, das einige
> > Pakete jetzt in anderer Reihenfolge eingespielt werden und damit
> > andere SysUserIDs bekommen. Damit wäre ein kopieren von /var
> > eventuell gefährlich, obwohl Tar per default glaube ich den
> > Usernamen mit einpackt, anstatt der ID.
>
> Das sollte eigentlich nicht passieren. Die verwendeten ID's sind
> innerhalb von stable immer diesselben (z.B. 33 == www-data, 102 ==
ok, die postinst Scripte von z.B. Apache geben die ID mit an, ich weiss
aber nicht ob das in der Policy auch gefordert wird. Wahrscheinlich
wird es aber so sein. *mal nachlesen*
> Debian-exim, news == 9). Ein Kopieren von tar ohne vorher genau zu
> pruefen welche der Verzeichnisse du kopieren _kannst_ ist auf jeden
> Fall ein Risiko.
Wieso kann ich irgendein Verzeichnis nicht kopieren? Die Paketliste ist
100% identisch. An den Quelldaten zum Zeitpunkt des kopierens wird
nichts verändert (remount ro und kein Dienst ausser ssh läuft).
Ausser in /etc und /var wird im Betrieb nie etwas geschrieben
(Paket-Install/Upgrade aussen vor). Man sollte doch also davon ausgehen
können, das ich auch mit meiner Variante 1 das System zu 100%
duplizieren kann.
> > > in dieser Form durchfuehren, in /etc koenntest du evtl. noch mehr
> > > ueberschreiben als nur die Netzwerkkonfig. /var enthaelt die
> > > Paketdatenbank und noch einiges mehr, da solltest du definitiv
> > > nur _selektiv_ deine Datenbank, Mailspool usw. kopieren.
> >
> > Hmm, versteh ich jetzt nicht, wieso empfiehlst du mir dann in
> > deiner dritten Version exakt dies?
>
> Es gibt einen wichtigen Unterschied: Meine Variante kopiert _alles_
> rueber, deine Variante installiert erstmal die Pakete. Wenn du dann
> /etc einfach direkt kopierst sind alle Dateien in /etc geaendert und
> du kriegst bei jedem Upgrade die Meldungen ob du deine Konfig-Version
> oder die aus dem Paket installieren willst, bei jeder Konfig-Datei.
Warum sind die Configs nach dem kopieren geändert? Wenn ich sie auf der
Quellmaschine nie angefaßt habe entspricht die MD5 exakt der, die auch
auf dem Zielsystem vor dem Überschreiben vorhanden war.
Deine "dritte" Variante entspricht im übrigen exakt meiner zweiten
Variante.
> Weiterhin finde ich es nicht gut (und hatte auch selbst schon
> negative Erfahrungen) /etc blind zu ueberschreiben.
>
> > An Configs sollte eigentlich alles überschrieben werden, der
> > Rechner nimmt schliesslich exakt den Platz des alten ein. Später
> > sogar mit gleicher IP (nach reboot test).
>
> Siehe oben. Man sollte bei einem Server eine Liste der geaenderten
> Configs haben und nur diese geaenderten uebernehmen, oder gleich eine
> 1:1 Kopie des Sytems anlegen.
Ich habe aber keine solche Liste, und prüfbar sind die configs in /etc
auf Veränderung zum Original eh kaum noch, da oft via debconf gestellte
Fragen bzw. deren Antworten in eine Template Config übernommen werden.
Damit sind die md5sums des Pakete nicht mehr als Prüfsumme
heranzuziehen. Bleibt also nur auf dem Quellsystem von Hand erzeugen
und mit denen auf dem neu installiertem Ziel vergleichen.
> > > > Variante 2:
> > > > rsync Abgleich aller Verzeichnisse (ausser /boot)
> > >
> > > rsync macht fuer einmalige Kopieraktionen IMHO nicht soo viel
> > > Sinn.
> >
> > Hatte ich nur angedacht, da es sicher kopieren kann
>
> Was meinst du damit? Verschluesselte Uebertragung? Mag mich ja irren,
> aber plain-rsync verschluesselt nichts. Erst in Verbindung mit einer
> ssh-Verbindung wird das verschluesselt und dann kannst du auch gleich
> ssh+tar nehmen.
>
> > und Files iirc auch prüft (Prüfsumme).
>
> Das geht auch "zu Fuss" und vor allem: Das dauert ewig und 3 Tage,
> schonmal ne MD5 Summe von ner Datei erstellt? Jetzt ueberleg dir mal
> wieviel du Kopieren willst... Das wuerde ich nicht bei der
> Uebertragung machen wollen.
Zuviel Aufwand sowas zu Fuss zu machen und md5 generieren ist mehr als
Schnell genug. Wir haben hier schon mit Gigabyte großen Dateien und
deren Prüfsummen hantiert, kein Problem. Ob die Übertragung einige
Stunden dauert interessiert mich im übrigen auch nicht, es muss nur
100% korrekt auf der Ziel-HDD ankommen.
> > > Ich moechte aber eine 3 Variante darbieten:
> > >
> > > Sichern der notwendigsten Konfigurationen des neuen Systems
> > > (Netzkonfig und aehnliches) oder gleich auf dem alten die
> > > Konfigurationen anpassen Alles loeschen
> > > cp -a altesSystem:/ neuesSystem:/
> > >
> > > Fertig. Hab ich hier (allerdings nur HDD-Wechsel) schon haeufiger
> > > gemacht, funktioniert problemlos.
> >
> > Verstehe nicht ganz den Unterschied zu meiner Copy-Session? Zumal
> > ich ja auch hier ein Remote-fähiges Copy nehmen muss.
>
> Copy-Session? Du hast auf dem Zielsystem erstmal Pakete installiert,
Das war meine Variante eins, deine Variante entsprichte exakt meiner
zweiten Variante.
> danach solltest du die Paketdatenbank tunlichst nicht ueberschreiben.
Und genau hier würde ich gern wissen warum? Schliesslich sind exakt die
gleichen Pakete installiert, alle Dateien sind in gleicher Form
vorhanden.
Mein Resume lautet aber wohl doch die komplette Copy-Orgie zu
veranstalten. Auch wenn die Probleme bei der Variante 1. mir nicht
einleuchten wollen. Vielleicht versuch ich das ja mal privat mit einer
Kiste.
--
Markus Schulz
UNIX is user friendly, it's just picky about who its friends are
Reply to: