Re: [Proftpd-user] Event handlers/listeners via http-urls?
Thomas L. Shinnick wrote:[color=blue]
> At what level of detail do you need 'events'? The key question would
> seem to be, is there anything you need to know that is _not_ presented
> in the logs?
In my case, no, though I might foresee needing more info someday (ssl
events, file-level events, etc). Right now I just need to know when
files are created modified renamed deleted etc.
> I've not used the mod_exec feature, so I am unsure about one rather
> important point: does an external execution via mod_exec cause _any_
> part of ProFTPD sessions to pause, waiting until the external program is
> finished? If so, you probably don't want to hook the vagaries of
> network/server connections into your session processing. Direct
> execution of wget could allow hiccups elsewhere to become roadblocks for
Agreed, I would rather having something that lets the server write the
event async into a dispatch queue that some other thread consumes. I
don't need a blocking or return, although that too seems potential very
useful, for example to let the app server decide whether an FTP action
may continue, for example with a URL-parametrized or XML response. I
also dont need before-events (only post-event), though before & after
event-fires could be useful.
> Hmm, looking TJ Saunders' source, it seems to fork and exec, which
> should be okay... ooo, waitpid()? Is that controlled by ExecOptions?
> Makes me nervous... TJ?
I could like with that, of course forking has overhead and someday to
have a dedicated/built-in URL invoker for events would be... really neat.
> Again, it is possible you need to know things that are only revealed via
> mod_exec hooks. But if your needs are such that passive monitoring of
> logs will work for you, I'd think that vastly preferable.
I thought about that, but it appear I'd have to track the session state
to determine the CWD. More complexity than I can deal with, especially
rolling my own (and having such talented at making mistakes). I noticed
that mod_exec appears to supply the full path of the file being acted
on, which was a plus for me.
> And the FIFO-logging linked to from the bottom of the mod_exec doc does
> give you a more dynamic 'live' view of the text logging. I can get by
> just monitoring text logs using 'tail' and the like. But if you want to
> execute programs given certain conditions the FIFO processing might be
> more 'immediate' (and controllable without impacting FTP sessions?).
> Consider this a vote for the least intrusive monitoring possible - log
> tailing or FIFO monitoring.
I second that vote but by using async dispatch, but also someday having
a provision for synchronous/return like to let an app server decide actions.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
ProFTPD Users List <firstname.lastname@example.org>