Post-Upload Hook für sftp

[daemotron]

Moin,

ich wurschtele momentan an folgendem Szenario: Per sftp können Dateien auf einen Server hochgeladen werden. Dank chroot landen diese auch in einem vorbestimmten Verzeichnis. Allerdings müssen diese hochgeladenen Dateien auf dem Zielserver weiterverarbeitet werden.

Wie bekomme ich es hin, nach einem abgeschlossenen sftp-Transfer ein Programm auszuführen, dem als Parameter der Pfad zur fertig hochgeladenen Datei übergeben wird?

Ich habe das "fertig hochgeladen" absichtlich hervorgehoben. Natürlich könnte ich per cron regelmäßig nachschauen, ob eine Datei in dem Verzeichnis liegt - jedoch kann ich aus der bloßen Existenz einer Datei noch nicht schließen, dass diese auch vollständig ist. Jemand eine Idee?

[daemotron]

Lädt der Dämon die Datei nicht erst in eine temporäre Datei und movt hinterher?

Nein, SCP/SFTP-Transfers sind direkt (FTP typischerweise eigentlich auch). Hab es eben noch mal verifiziert.

Das würde ich mal prüfen, ansonsten würde ich das Transfer log Serverseitig prüfen.
Alternativ, sofern man z.B. SFTP Transfers automatisch macht, eine Flagdatei anlegen.

<dateiname>.transfered

z.B. damit lässt sich erkennen ob ein transfer abgechlossen wurde.
Dürfte der einfachte weg sein.

Die hochladende Seite habe ich leider nicht unter Kontrolle, sonst wäre das mit der Flag-Datei natürlich die einfachste Methode gewesen :-k Mit dem Transferlog muss ich mir noch mal anschauen, ob internal-sftp überhaupt die Argumente -f und -l versteht. Falls nein, bekomme ich leider auch kein Transferlog...

[daemotron]

Dann kann ich auch gleich ProFTPd installieren - mit mod_exec / ExecOnCommand lässt sich so etwas scheinbar realisieren. Ich hatte halt die Hoffnung, bei OpenSSH bleiben zu können...

Mir ist noch eine weitere Idee gekommen, aber auch die gehört mehr in die Kategorie "von hinten durch die Brust ins Auge": Programm per cron losjagen, das für alle Dateien im Eingangsverzeichnis lstat() abfragt und speichert (in Datenbank, Pickle-Dump o. ä.). Wenn sich zwischen zwei Programmausführungen die stat-Informationen (Größe, atime, mtime, ctime) einer Datei nicht verändert haben, gilt sie als hochgeladen und wird verarbeitet.

[daemotron]

inotify scheidet aus - auf der Kiste ist kein Linux. Klar, ich kann mir jetzt mit gamin oder fam oder gleich kqueue irgend was wildes basteln - dann bin ich mit der Installation von ProFTPd aber allemal besser bedient (auch was die Qualität der eingesetzten Software angeht).

[Roger Wilco]

Gibt es nicht so etwas wie incron für FreeBSD? Also einfach ein fertiges Programm, das auf die Events von kqueue reagiert? Das würde doch passen.

[Joe User]

http://stackoverflow.com/questions/1165 ... -new-files

Eventuell bringt Dich das ja auf neue Ideen.

[daemotron]

Interessant - seit 2.6 hat Python's select-Modul Klassen für kqueue und kevent Objekte. Damit hätte man sowas wie incron als Nicht-Ganz-Dreizeiler schnell geschrieben. Es bleibt allerdings das Problem, dass Kevent unter EVFILT_VNODE nur melden kann, wenn in eine Datei geschrieben wurde. Ein Event, das signalisiert, dass alle anderen Handles auf eine Datei geschlossen wurden, gibt es leider nicht.

Das ganze führt mir mittlerweile ehrlich gesagt auch zu weit. Das ganze ist nicht so performance-kritisch, dass ich mit kevent arbeiten müsste. Ich denke, ich orientiere mich eher in Richtung einer "simplen" Lösung wie das von matzewe01 vorgeschlagene Vorgehen mit find.

[dotme]

Während ein SFTP-Client die mtime vermutlich auf die selbe Uhrzeit setzt wie auf der Quelle?!

Da Du ja internal-sftp machst, scheidet der Austausch des unter subsystem sftp angegebenen sftp-server durch ein wurschteliges Skript, das sftp-server aufruft und anschliessend das Verzeichnis gegen eine Schattenkopie vergleicht, wohl eher aus?

[daemotron]

So, habe jetzt eine (wenn auch nicht zur Nachahmung empfohlene ) Lösung:

Der Upload erfolgt wir ursprünglich geplant über SFTP in ein definiertes Upload-Verzeichnis. Das erzwinge ich durch folgenden Abschnitt in meiner sshd_config:

Code: Select all

AllowGroups sftp
Match Group sftp
	ChrootDirectory /home/transfer
	ForceCommand internal-sftp

/home/transfer gehört root und hat die Rechte 0755; ein sftp-User darf nur in dem darin liegenden Upload-Verzeichnis schreiben (/home/transfer/upload gehört root:sftp und hat die Berechtigung 0775).

Dazu habe ich mir ein kleines Skript gebaut, das ich einmal pro Minute per Cron starte. Das Skript sammelt alle Dateien aus dem Upload-Verzeichnis und verarbeitet sie gemäß vorgegebener Logik.

Die Verarbeitung per Cron wurde dabei durch zwei kleine Kunstgriffe ermöglicht:

• Das Skript legt zu Beginn eine PID-Datei an und löscht diese am Ende wieder. Existiert bereits eine PID-Datei, verweigert das Skript die Ausführung. Dadurch wird verhindert, dass es zu Überschneidungen kommt, wenn das Skript einmal länger als 60 Sekunden laufen sollte.
• Das Skript zieht nur Dateien in Betracht, bei denen die letzte Änderung mindestens 30 Sekunden her ist. Hierzu wird st_ctime aus stat herangezogen - die Manpage liefert eigentlich auch gleich die Begründung, warum ctime und nicht mtime.

[Joe User]

Statt dem PID-File würde ich eher ein Lock-File nehmen, falls der Prozess mal vor dem Löschen des PID-Files stirbt. Existiert das Lock-File beim nächsten Cron-Lauf noch, wird geprüft, ob die Verarbeitung noch läuft oder abgebrochen wurde.

[daemotron]

Die Dateien werden verschoben, wenn sie verarbeitet wurden - das verschieben ist Bestandteil der Verarbeitung. Ergo muss ich mir ohnehin nicht merken, welche Dateien noch verarbeitet werden müssen. Das mit dem PID-File ist ein reiner Schutzmechanismus, um eine Race Condition zu vermeiden. Das Skript besorgt sich eingangs ein Listing des Upload-Verzeichnisses und arbeitet danach alle Dateien aus diesem Listing ab. Würde eine zweite Instanz des Skripts gestartet, bevor die erste fertig ist, würde sie in dem Listing einen Teil der Dateien erwischen, die die erste Skript-Instanz aber noch verarbeiten will. Entweder die erste Instanz ist schneller, dann hat die zweite ein Problem oder umgekehrt.

Die Existenz-Prüfung für den Prozess kann ich natürlich auch anhand des PID-Files machen - ist ja egal, ob in dem File was drinsteht oder nicht (so wüsste ich immerhin gleich, nach welcher PID ich fahnden muss, wenn ich tatsächlich noch eine Prüfung einbaue).