Tar-Bruecke eingebaut

schmutzige_tricks.tex

@@ -24,10 +24,66 @@ haben.
 
 \section{Die Tar-Br<42>cke}
 
-TODO!!! tar-Br<42>cke
+Eine sogenannte Tar-Br<42>cke benutzt man, wenn eine oder mehrere Dateien zwischen
+Rechnern <20>bertragen werden sollen, aber kein Dienst wie SCP oder FTP zur
+Verf<EFBFBD>gung steht. Au<41>erdem hat die Methode den Vorteil, da<64> Benutzerrechte und
+andere Dateiattribute bei der <20>bertragung erhalten
+bleiben\footnote{Vorausgesetzt nat<61>rlich, da<64> der Benutzer auf der entfernten
+Seite <20>ber die n<>tigen Rechte verf<72>gt.}.
 
-%ssh 192.168.2.1 tar clf - / | (cd /mnt; tar xf - )
-%tar cf - $j | rsh $i "(mkdir -p $PWD ;cd $PWD; tar xf -)"
+Der Trick besteht darin, auf einer Seite der Verbindung etwas mit \texttt{tar}
+einzupacken, dies durch eine Pipe auf die andere Seite der Verbindung zu
+bringen und dort wieder zu entpacken.
+
+Wenn dem Kommando \texttt{tar} an Stelle eines Dateinamens ein Minus-Zeichen
+als Archiv gegeben wird, benutzt es~---~je nach der gew<65>hlten Aktion~---~die
+Standard-Ein- bzw. -Ausgabe. Diese kann an ein weiteres \texttt{tar} <20>bergeben
+werden um wieder entpackt zu werden.
+
+Ein Beispiel verdeutlicht diese Kopier-F<>higkeit:
+
+\texttt{tar cf - . | ( cd /tmp/backup; tar xf - )}
+
+Hier wird zun<75>chst der Inhalt des aktuellen Verzeichnisses `verpackt'. Das
+Resultat wird an die Standard-Ausgabe geschrieben. Auf der Empf<70>ngerseite der
+Pipe wird eine Subshell ge<67>ffnet. Das ist notwendig, da das empfangende
+\texttt{tar} in einem anderen Verzeichnis laufen soll. In der Subshell wird
+zun<EFBFBD>chst das Verzeichnis gewechselt. Dann liest ein \texttt{tar} von der
+Standard-Eingabe und entpackt alles was er findet. Sobald keine Eingaben mehr
+kommen, beendet sich der Proze<7A> mitsamt der Subshell.
+
+Am Ziel-Ort finden sich jetzt die gleichen Dateien wie am Quell-Ort.
+
+Das lie<69>e sich lokal nat<61>rlich auch anders l<>sen. Man k<>nnte erst ein Archiv
+erstellen, das dann an anderer Stelle wieder auspacken. Nachteil: Es mu<6D>
+gen<EFBFBD>gend Platz f<>r das Archiv vorhanden sein. Denkbar w<>re auch ein in den Raum
+gestelltes \texttt{cp -Rp * /tmp/backup}. Allerdings fehlen einem dabei
+mitunter n<>tzliche \texttt{tar}-Optionen\footnote{Mit \texttt{-l} verl<72><6C>t
+\texttt{tar} beispielsweise nicht das File-System. N<>tzlich wenn eine Partition
+gesichert werden soll.}, und die oben erw<72>hnte Br<42>cke w<>re mit einem reinen
+\texttt{cp} nicht m<>glich.
+
+Eine Seite der Pipe kann n<>mlich auch ohne Probleme auf einem entfernten
+Rechner `stattfinden'. Kommandos wie \texttt{ssh} oder \texttt{rsh} (letzteres
+nur unter Vorsicht einsetzen!) schlagen die Br<42>cke zu einem anderen System,
+dort wird entweder gepackt und versendet oder quasi die Subshell gestartet und
+gelesen. Das sieht wie folgt aus:
+
+\texttt{ssh 192.168.2.1 tar clf - / | (cd /mnt/backup; tar xf - )}
+
+Hier wird auf einem entfernten Rechner die Root-Partition verpackt, per SSH in
+das lokale System geholt und lokal im Backup-Verzeichnis entpackt.
+
+Der Weg in die andere Richtung ist ganz <20>hnlich:
+
+\texttt{tar cf - datei.txt | ssh 192.168.2.1 \dq(mkdir -p \$PWD ;cd \$PWD; tar xf -)\dq}
+
+Hier wird die Datei verpackt und versendet. Eine Besonderheit gegen<65>ber dem
+vorigen Beispiel bestehtdarin, da<64> das Zielverzeichnis bei Bedarf erstellt
+wird, bevor die Datei dort entpackt wird. Zur Erkl<6B>rung: Die Variable
+\texttt{\$PWD} wird, da sie nicht von Ticks `gesichert' wird, schon lokal durch
+die Shell expandiert. An dieser Stelle erscheint also auf dem entfernten System
+der Name des aktuellen Verzeichnisses auf dem lokalen System.
 
 
 \section{Binaries inside}