hdd durch ssh pipen

A

atzplzw

Active Member
Hi!

Wie kann ich eine spezielle Anzahl von Sektoren durch ssh pipen?

Also ich steige bei einem Hoster auf einen anderen Server um. Nun wäre es ja am einfachsten den ersten slice einfach mit ssh auf den anderen Server zu bringen, da die Hardware ja nahezu gleich ist. Da ich beide Server im Rescue Mode habe sollte das kein Problem darstellen.
In Linux rescue ist der freebsd slice /dev/sda1 und startet bei sektor 1. Da ich natürlich auch den bootsektor brauche muss ich wohl sda nehmen. Und dann will ich ja nur bis Sektor 652, das ist das Ende des slices.

Es gab schon mal ne Diskussion darüber, wie man ohne Konsole so was macht: http://www.bsdforen.de/showthread.php?t=14574
Aber ich brauch das ja mit dd. Deshalb bin ich etwas verwirrt wie das jetzt genau aussehen soll. Wer kann helfen?

Danke!
 
Kurze Antwort: Was Du da vor hast funktioniert nicht.

Längere Antwort: Was Du da vor hast funktioniert nicht, da Du im Prinzip ein Abbild der Festplatte machst (sektorenweise), und zwar im laufenden Betrieb. Niemand ausser dem Betriebssystem bzw. dem Dateisystem kann sicherstellen, dass Dein Abbild konsistent ist. Im einfachsten Fall werden Dateien verändert während Du Dein Abbild ziehst, so dass nur einzelne, möglicherweise unwichtige Dateien fehlerhaft übertragen werden. Im schlimmsten Fall finden Änderungen an den Meta-Daten des Dateisystems statt, so dass Du mit einem unbrauchbaren Dateisystem auf dem Zielhost da stehst.

Einfachere und sauberere Methode ist es, das Basissystem auf dem Zielhost identisch zu konfigurieren, d.h. ersteinmal die selbe Software zu installieren und dann Konfigurationsdateien und Daten zu übertragen.
 
Das Linux Rescue System wird übers Netzwerk gebootet. Also sind beide Platten vom Zugriff befreit, da sich alles in der RAMdisk abspielt. Wie ich das sehe bringt Linux nicht mal UFS2 Unterstützung mit.
Soweit also kein Problem...
 
Zuletzt bearbeitet:
Dann könnte's klappen, Probleme mit Disk-Layout/MBR etc. aussen vor.

Da Du binäre Daten über's Netz schiebst, ist's vermutlich einfacher/sicherer mit SSH+nc zu arbeiten. Du baust einen SSH Tunnel von Urspung zu Remote Host, dann netcattest (man nc) Du Deine Daten über diesen Tunnel. Man Pages lesen nicht vergessen, aber die ungetestete Kurzform geht in etwa so:

Von Ursprung nach Remote Host: ssh -L 1234:127.0.0.1:4321 user@remote.host
Auf dem Remote Host: nc -l -p 4321 | dev of=/dev/disk...
Auf dem Ursprungs-Host: dd if=/dev/... ... | nc 127.0.0.1 1234
 
Danke für den Tip. Ich hatte mir das hier zusammengebastelt:

dd if=/dev/sda count=?? | ssh root@ip "dd of=/dev/sda"
Zum Vergrößern anklicken....


Wie finde ich den count raus? Wenn bei dd ein block 512 bytes sind muss ich das wohl irgendwie auf die Sektorgröße umrechnen.


Das schlimmst was passieren kann ist das er nicht bootet. Dann muss man halt mal bis morgen warten und in die Konsole schauen.
 
lass den count weg. er ist fertig wenn er fertig ist.
aber mal was anderes... ueberhaupt schon probiert ob das alles so klappt? sshd und nc sind nicht unbedingt auf allen rettungssystemen zu finden.
 
Habs grade laufen lassen und nach 5 GB abgebrochen. In cfdisk sieht alles normal aus also 1. FreeBSD slice is da. Leider rührt sich nach einem Neustart nix. Muss man wohl mal die Konsole bemühen.
 
Zuletzt bearbeitet:
Super hat voll funktioniert! Hab nur vergessen, die ListenAddress in der sshd_config zu ändern.
Hat jemand einen Tip wie ich das im Single User Mode ändern kann? Das Dateisystem is ja readonly und es gibt nich mal vi.
 
Kannst Du das Dateisystem nicht als R/W mounten? "mount -uw /" sollte genügen.

Ganz ohne Editor wird's schwierig werden eine Datei zu ändern, aber ich vermute, dass Du irgend einen Editor zur Verügung hast, wenn auch nicht vi.
 
mount -o rw / müsste das sein...
und vi muesste sich irgendwo auf /usr oder so befinden.

Müssen solche Stunts eigentlich immer von Leuten gemacht werden, welche sich in Ihren Systemen nicht auskennen? :confused:
 
mount -uw / ist schon richtig. Und wenn man /usr nicht mounten kann, findet man den auch unter /rescue/vi.
 
Danke für all die Tipps! Ich hab einfach das ganze nochmal gemacht und vorher sshd config geändert.

Eine letzte Frage bleibt noch: Wie kann ich das Ganze mit einem Verzeichnis machen?
tar habe ich schon probiert, doch der mag wohl kein pipes.
nc -l -p 4321 | tar xv
tar: Failed to open '/dev/sa0': Operation not supported
Zum Vergrößern anklicken....
 
1. Gewöhn Dir an, die Manpage zu einem Tool zu lesen, bevor Du's verwendest.
2. Man lernt erstmal ohne Stützräder Fahrrad zu fahren, bevor man einen Hochseilakt wagt.
3. "tar cf -" bzw. "tar -xf -" ist vermutlich, was Du suchst.
 
Vincent Vega schrieb:
1. Gewöhn Dir an, die Manpage zu einem Tool zu lesen, bevor Du's verwendest.
2. Man lernt erstmal ohne Stützräder Fahrrad zu fahren, bevor man einen Hochseilakt wagt.
3. "tar cf -" bzw. "tar -xf -" ist vermutlich, was Du suchst.
Zum Vergrößern anklicken....

Zu 1 und 2.

welch wahre Worte

Zu 3.
Stimmt wahrscheinlich das er das gesucht hat. Aber damit er auch was sieht und nicht wieder, ohne nachzudenken einen Kopiervorgang abbricht, sollte er 'tar cvf -' bzw. 'tar xvf -'
Nachdem Netzlasten scheinbar keine Rolle spielen, sollte es so am einfachsten sein.
 
Zuletzt bearbeitet:
v in Verbindung mit - scheint mir riskannt, schließlich wird die Ausgabe dann mit in die Pipe gegeben und ich kann mir nicht vorstellen, dass hinten noch was sinnvolles rauskommt.
 
Kamikaze schrieb:
v in Verbindung mit - scheint mir riskannt, schließlich wird die Ausgabe dann mit in die Pipe gegeben und ich kann mir nicht vorstellen, dass hinten noch was sinnvolles rauskommt.
Zum Vergrößern anklicken....

ok. bei tar cf - gebe ich dir recht. Hätte nicht gedacht, das es so eine witzige Wirkung hat. Aber tar xvf - funktioniert tadellos
 
Die -v Ausgabe geht auf stderr und kann deshalb sowohl bei -c als auch bei -x verwendet werden. (doppelt macht aber wirklich wenig Sinn)
 
Sobald die Validierung fehl schlägt, sind alle "Vorteile" des Multicast dahin, denn Du musst das gesamte Image nochmal übertragen. Und auch dann ist nicht sichergestellt, dass das Image vollständig und richtig übertragen wurde.
 
Warum reicht es nicht einzelne Pakete neu zu übertragen? Das kann man doch entsprechend lösen.
 
Es gibt FEC und Geschichten wie Network Coding, womit man auch per Multicast das Zeug sicher&gut uebertragen kann. Alles eine Frage der Implementierung.
 
Klar reicht es, einzelne Pakete neu zu übertragen. TCP ist ein Protokoll, welches das macht. Bei Multicast ist das erkennen und behandeln einer solchen Situation aber nicht so leicht. Beispiel mit einem Quell- und zwei Zielhosts:

Host A empfängt Block #1234 korrekt
Host B empfängt Block #1234 nicht korrekt.
Host B muss jetzt den Block neu anfordern, was dazu führt, dass Host A den Block doppelt erhält.

Anderer Sonderfall der behandelt werden muss:

Host A empfängt nacheinander Block #7, #8, #9
Host B empfängt nacheinander Block #7, #9 und erst dann Block #8

Alle "Lösungen" laufen darauf hinaus, dass man irgendwie ein sicheres Protokoll über ein unsicheres Protokoll abbilden muss. Man hätte auch gleich ein sicheres Protokoll nehmen können. So wie ich das einschätze wäre z.B. SCTP für den selben Zweck besser geeignet.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben