FTP im Batchbetrieb

Automatisieren der FTP-Übertragung

Nach vielem Blabla jetzt also die Frage, wie man (frau) denn eine FTP-Übertragung automatisieren kann.

Folgende Varianten sind möglich:

• .netrc
  Man kann FTP durch eine Datei ~/.netrc fernsteuern. Dazu muss dann in ~/.netrc User und Passwort drinstehen und die Aktion (put Dateiname, get Dateiname,...). Einzelheiten stehen in der Man-Page netrc(5).
  Man legt sich für jedes Zielsystem eine netrc-Datei an und schreibt ein Shellscript, dass die netrc.<zielsystem>-Datei nach ~/.netrc kopiert und die Rechte richtig setzt (da ist ftp pingelig. Gruppen- und "Other"-Rechte müssen auf 0 stehen). Beachten muss man dabei, dass man einige Vorkehrungen treffen muss, falls man damit rechnet, dass mehrere FTP-Übertragungen (ggf. mit unterschiedlichen Zielsystemen) gleichzeitig anlaufen. Sonst überschreiben sich nämlich die ~/.netrc-Dateien gegenseitig und das wäre unschön.
• Here-Dokument
  Meiner Meinung nach die eleganteste Art, FTP fernzusteuern. Man hat kein Rechte-Problem, man kann viele FTP-Sessions gleichzeitig aufmachen und man hat Script und FTP-Kommandos am Stück und muß zum Debuggen nicht in mehreren Dateien nachschauen. Ausserdem ist diese Syntax auf jedem mir bekannten Unix-System portabel.
  Ein Here-Dokument ist ein mehrzeiliger Text, der von der Shell an STDIN eines Kommandos geleitet wird. Dabei ist auch Variablensubstitution möglich.
  Hier ein Beispiel:
  

    #!/bin/bash
    # autoftp.sh
    lokal_file=/tmp/test1
    remote_file=/var/tmp/remote_test1
    # ... /tmp/test1 erzeugen
    ftp -n <<EOFTP
      open zielhost
      user uid4711 null8fuenf10
      bin
      put $lokal_file $remote_file
      quit
    EOFTP
    # Und jetzt wieder aufraeumen...
  

  Die UserID auf dem Zielrechner ist hier im Beispiel "uid4711", das zugehörige Passwort ist "null8fuenf10".
  Das Beispiel ist übrigens keineswegs auf die bash festgelegt. Das funktioniert auch mit der ksh und der Bourne-Shell (vermutlich auch mit der csh, aber da ist vielleicht die Syntax für das HERE-Dokument anders).
• FTP-Command-Datei
  Ähnlich der Variante mit .netrc ist es auch möglich, eine beliebige Datei mit den nötigen FTP-Kommandos zu füllen und dann mit

    cat FTPCMD.TXT | ftp -n zielhost
  

  bzw unter Windows mit

    ftp -s:FTPCMD.TXT zielhost
  

  die Übertragung zu starten. Hier entfällt auch die Gefahr des Überschreibens der .netrc und das Rumfriemeln mit den Rechten. Nachteil ist, dass das Passwort in einer Datei steht, die evtl. nur ungenügend gegen neugierige Augen geschützt ist.
• ncftp
  Der (IMHO) hervorragende FTP-Client ncftp bringt zwei Tools ncftpget und ncftpput mit, mit denen Dateien direkt übertragen werden können:

    ncftpput -u uid4711 -p null8fuenf10 zielhost /tmp /tmp/test1
  

  macht im wesentlichen das gleiche wie das obige Shell-Script.
  Für Einzelheiten: siehe ncftpput(1) und ncftpget(1).
  Nachteil dieser Lösung: Es muss auf den Client-Rechnern ncftp installiert sein. Für Linux-Rechner ist das kein Problem, bei anderen Unix-Derivaten ist es eher nicht im Standardumfang enthalten.

Folgejobverarbeitung mit FTP

Das klassische Problem bei Batchübertragungen mit FTP ist die Frage, wie die Folgeverarbeitung auf dem Zielsystem gestartet wird.

Natürlich kann man da einen Cronjob einrichten, der ein Script startet, dass die Folgeverarbeitung anschiebt.
Was ist wenn die Datei noch gar nicht da ist ? Kein Problem, das kann man ja im Script überprüfen und ggf. mit sleep warten.
Und was ist, wenn die Datei noch nicht vollständig übertragen wurde (egal, ob das so ist, weil die Datei so groß ist oder das Netzwerk mal wieder so langsam) ? Das Script kann das erstmal nicht so ohne weiteres erkennen. Gut, man kann nach der eigentlichen Nutzdatei eine sehr kleine Merker-Datei schicken. Das Verarbeitungsscript weiss dann, dass die eigentlichen Daten komplett sind, wenn die Merker-Datei da ist.

Warum schickt denn dann überhaupt der Absender ? Wenn der Empfänger die Daten abholt, weiss er ja, wann sie komplett übertragen sind und kann dann zwanglos mit der Verarbeitung beginnen.
Stimmt. Aber woher weiss der Absender, wann die Erstellung der Daten abgeschlossen ist ? Hier können jetzt auch wieder ähnliche Mechanismen wie oben geschildert eingesetzt werden (Merkerdateien). Einfacher ist das nicht.

Man erkennt also, dass sich zwar das Problem der Folgejobverarbeitung mit FTP in den Griff bekommen läßt. Aber wirklich elegant (und einfach) ist das nicht, zumal man es im Prinzip jedesmal neu programmieren muss. Kennt jemand dafür eine Shell- oder Perl-Bibliothek ?

Einhalten der Reihenfolge mit FTP

Muß man sicherstellen, dass Daten in einer bestimmten Reihenfolge weiterverarbeitet werden, kann man z.B. mit Generationsnummern arbeiten, d.h. die Senderseite hängt an jede zu übertragende Datei eine laufende Nummer an. Die Empfänger-Seite muss sich dann die zuletzt verarbeitete Nummer merken und darf erst dann weiterverarbeiten, wenn die Folgenummer ankommt.

Und schon wird es spannend: Was passiert, wenn aufgrund irgendwelcher Störungen nicht die Nummer 101 sondern 103 - 108 zuerst versandt wurde und dann auf dem Empfänger-System nicht mehr genug Platz für Datei Nummer 101 ist ?
Es ist schwer, dafür einen Automatismus zu entwerfen. Solche Aufgaben mit FTP zu lösen schreit geradezu nach Handarbeit.

Verschlüsselung/Komprimierung mit FTP

Die Frage nach Verschlüsselung und Komprimierung von Dateien mit FTP beantwortet sich schnell: FTP tut da nix. Wer so was will, muss es vor der Übertragung gesondert durchführen.
Das heisst aber auch, dass bei FTP die Daten unverschlüsselt übers Netz gehen (und übrigens auch User und Passworte. Versucht einfach mal, mit tcpdump oder ethereal eine FTP-Übertragung zu belauschen und ihr werdet feststellen, dass Passworte sogar noch extra mit "PASSWORD" gekennzeichnet werden).
Für die Komprimierung bietet sich da natürlich compress, gzip und bzip2 an (ggf. auch zip für den Austausch mit Windows-Systemen). Für die Verschlüsselung kann man ja auf Tools wie pgp oder gpg oder ähnliches zurückgreifen.