Post by Wolfgang KleinPost by Christian Weisgerberrsync ohne Ziel listet die verfügbaren Quelldateien auf.
Funktioniert soweit. :)
Ist dieses Auflisten der möglichen Dateien abhängig von der auf der
Gegenseite verwendeten Standard-Shell, oder muss ich mir darum keine
Gedanken machen?
Meines Wissens startet ssh auf der Gegenseite das Programm, das
als Shell in der Benutzerdatenbank für denjenigen Benutzer
eingetragen ist, wenn derjenige Benutzer für den ssh‐Zugang nichts
anderes („forced command“) konfiguriert hat.
Der ssh‐Aufrufer hat meines Wissens keine Möglichkeit, ssh zu
befehlen, was an der Gegenseite als Shell gestartet wird, noch
kann ssh erfragen, was an der Gegenseite als Shell gestartet wird.
=> rsync als ssh‐Aufrufer hat diese Möglichkeit ebenfalls nicht.
=> rsync kann nicht wissen, was derjenige Benutzer als Shell
konfiguriert hat.
=> rsync muss Annahmen über das richtige Zusammensetzen der an den
Shell der Gegenseite zu übermittelnden Kommandozeile machen, die
richtig oder falsch sein können.
=> Du als Eigentümer des Benutzeraccounts der Gegenseite musst den
ssh‐Zugang passend konfigurieren, damit rsync mit seinen Annahmen
nicht falsch liegt.
Post by Wolfgang KleinIst dieses Auflisten der möglichen Dateien abhängig von der auf der
Gegenseite verwendeten Standard-Shell, oder muss ich mir darum keine
Gedanken machen?
Du musst dir entsprechende Gedanken machen.
Ich habe rsync schon lange nicht mehr angesehen.
Vor Jahren hat rsync weder das notwendige Quoting für den Shell
der Gegenseite nicht durchgeführt (was es auch nicht kann, s. o.),
noch in der Dokumentation den Benutzer darauf hingewiesen, dass
der als Aufrufer dafür verantwortlich ist, die Dateinamen für die
Gegenseite passend shell‐quoted anzugeben.
Damit hat rsync also die Annahme gemacht, der Shell auf der
Gegenseite bekäme keine Kommandozeile sondern eine
execve‐Parameterliste.
Diese Annahme ist definitiv falsch: ssh übermittelt eine
Kommandozeile, keine Parameterliste.
Das stand im Widerspruch zur Dokumentation, die nichts davon
beschrieb, dass rsync notwendiges Quoting für den Shell der
Gegenseite unterlässt und es deshalb vom Aufrufer vorzunehmen ist.
Daraufhin habe ich von rsync die Finger gelassen, und ich habe
nicht weiter verfolgt, ob der Fehler (in der Dokumentation)
inzwischen behoben ist.
Beispiel: Angenommen, man wollte auf der Gegenseite im
HOME‐Verzeichnis das Unterverzeichnis „ein Verzeichnis“ (mit
Leerraum im Namen) anfassen. Dann scheiterte der rsync‐Aufruf
„rsync -e "ssh -i .ssh/backup" \
'***@server:/home/backup/ein Verzeichnis'“,
weil der Shell der Gegenseite als Teil der Kommandozeile den Text
„/home/backup/ein Verzeichnis“
anstelle von
„'/home/backup/ein Verzeichnis'“
übermittelt bekam.