samba "uploaded-script"

[JAF]

hi,

weiss das jemand, gibt es bei samba auch die moeglichkeit, eine art von "uploaded"-script zu nutzen?

d.h. der client spielt eine datei rauf und sobald samba damit fertig ist, startet es eine bestimmtes script?

[cane]

Beschreibe genauer was Du damit bezwecken möchtest.

mfg
cane

[JAF]

nun, es gibt ja diese grossen multifunktions-lasergeraete.

diese unterstuetzen scannen (vom geraet direkt - ohne pc) als pdf in ein verzeichnis (samba freigabe, manche auch FTP).

ich moechte gerne scannen und dann diese datei - sobald empfangen am (samba-)server versenden mit einem script.

[mamue]

Prinzipiell sehe ich verschiedene Ansätze, diese Aufgabe zu erledigen:
1) Gar nicht - der Ansatz ist falsch. Die meisten Multifunktionslasergeräte bieten auch die Möglichkeit eines E-Mail Versandes. ;)
2) Am einfachsten per Cronjob. Wenn es reicht, jede Minute nachzuschauen, wäre das am einfachsten per shell-script zu erledigen.
3) Es gibt "File-Monitore" - ich kann mich da wage an "dazuko" entsinnen, ich glaube "fam" ist ein weiterer. Die wachen über Verzeichnisse oder Dateien und führen bei positivem Befund ein Skript aus.
4) Du könntest auch ein shell-script schreiben, das alle X Sekunden das Verzeichnis überprüft und das script in den Hintergrund legen (nohup ...)

Mit Samba geht das eher nicht so gut, es gibt zwar preexec/exec, aber das wird nur einmal beim Anmelden ausgeführt.

HTH,
mamue

[cane]

Immer and en gleichen user?

mfg
cane

[BedriddenTech]

Inotify hast du vergessen, mamue. :) Das läßt sich eigentlich sehr schön in einem Perl-Skript nutzen.

[JAF]

das ganze soll dann nicht gemailt werden, sondern per tcp-socket verschickt ;)

darum kommt email nicht in frage.
cronjob waere meine notloesung.

jedoch geht es darum: der client spielt die datei noch rauf (vielleicht einige megabyte) und ich will verhindern, dass es zu selben zeit schon verwendet wird zum versenden, erst wenn der upload fertig ist.

[mamue]

das ganze soll dann nicht gemailt werden, sondern per tcp-socket verschickt ;)
darum kommt email nicht in frage.

Naja, das ist kein echtes Argument, wenn man procmail auf dem Server laufen hat. Das wäre aber nicht mehr mein Favourit unter den potentiellen Lösungen.



cronjob waere meine notloesung.

jedoch geht es darum: der client spielt die datei noch rauf (vielleicht einige megabyte) und ich will verhindern, dass es zu selben zeit schon verwendet wird zum versenden, erst wenn der upload fertig ist.

Das ist ab hier nur mehr eine Frage der Geschicklichkeit bei der Shellscript-Programmierung. Ich bin mir sicher, dass man unter Unix feststellen kann, ob eine Datei gerade von einem anderen Prozess geöffnet ist. Als erste Näherung könnte man auch prüfen, ob eine Datei vorhanden ist und in dem Fall alle paar Sekunden testen, ob sie "geändert" wurde (last modified, größe).
Vielleicht bietet Inotify da ja auch schon etwas fertiges an.

HTH,
mamue

[JAF]

Naja, das ist kein echtes Argument, wenn man procmail auf dem Server laufen hat. Das wäre aber nicht mehr mein Favourit unter den potentiellen Lösungen.

denke da gleich


Ich bin mir sicher, dass man unter Unix feststellen kann, ob eine Datei gerade von einem anderen Prozess geöffnet ist. Als erste Näherung könnte man auch prüfen, ob eine Datei vorhanden ist und in dem Fall alle paar Sekunden testen, ob sie "geändert" wurde (last modified, größe).
Vielleicht bietet Inotify da ja auch schon etwas fertiges an.

nunja, tools wie inotify sind zwar toll, aber das geht halt immer mehr oder weniger auf die rechnerleistung. ich denke ich bleibe bei meiner loesung mit cronjob, aber das mit "(last modified, größe)" ist eine gute idee, das werde ich vermutlich noch einbauen. danke fuer den denkanstoss!

[cane]

nunja, tools wie inotify sind zwar toll, aber das geht halt immer mehr oder weniger auf die rechnerleistung.

Wenn inotify interessant ist empfehle ich diesen Artikel:

http://www.linux-magazin.de/heft_abo/ausgaben/2006/01/auferstanden_aus_archiven/(kategorie)/378

mfg
cane

[BedriddenTech]

Aber ein Cronjob mit periodischer Überprüfung von Dateigrößen geht nicht auf die Rechnerleistung?! Ich glaube Dnotify bzw. Inotify sind wesentlich ressourcenschonender. Aber ich lasse mich da gerne belehren...

[mamue]

Es spielt meiner Erfahrung nach wirklich keine Rolle, solange der Host nicht gerade auf "embedded" Hardware läuft. Bei einer Überprüfung jede Sekunde spielt die Startzeit eine große Rolle, da ist Perl etwas im Nachteil. Wenn man das Skript - egal in welcher Form - im Hintergrund laufen lässt, wird man es schwerlich in der Prozessliste bemerken.

mamue

[JAF]

Aber ein Cronjob mit periodischer Überprüfung von Dateigrößen geht nicht auf die Rechnerleistung?! Ich glaube Dnotify bzw. Inotify sind wesentlich ressourcenschonender.

nunja, ich denke schon.
cronjob muss in meinem fall immer laufen.
wen ich nun den cronjob starte, ich sehe eine neue datei, warte z.b. 3 sekunden - falls gefunden - ob eine gefunden wurde, und mache dementsprechend weiter...
ich denke das braucht weniger rechenleistung.

[BedriddenTech]

Nach der Lösung, die ich kenne (http://search.cpan.org/~mlehmann/Linux-Inotify2-1.1/), liefe das Perl-Skript sowieso mehr oder weniger dauerhaft. Entsprechende Aktionen werden aber nur ausgeführt, wenn der Kernel meldet, daß sich eine Datei geändert hat/erzeugt wurde/etc. Die Cronjob-Version läßt in regelmäßigen Abständen ein Shellskript anlaufen (SH-Parser wird jedes Mal gestartet), das dann alle paar Sekunden eine Datei überprüft.

Der Unterschied ist bei 50 Dateien bestimmt kaum festzustellen, aber ich bin immer noch der Meinung, daß die Version »startet bei Bedarf« wesentlich besser ist als »startet alle paar Sekunden etwas, das wieder alle paar Sekunden...«, noch zudem, wo die zweite, die Cron-Version, immer irgendwas startet, auch im Leerlauf. Da müßte Inotify schon sehr verschwenderisch mit den zur Verfügung stehenden Mitteln umgehen, um nicht effizienter zu sein. Vielleicht ist meine Logik ja verquer, aber m.E. ist der Vorteil von Inotify evident. Wie kommst du denn zu dem Gedanken, daß der Cronjob weniger Rechenleistung benötigt, JAF?