Subject: RE: Trigger of an executable upon file send complete

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 1 Oct 1998 06:48:12 -0400 (EDT)

On Thu, 1 Oct 1998 [email-masked] wrote:

> Assume different applications on different platforms and servers. We
> have jobs that extract data from a multitude of databases into flat
> files and ftp them into other servers for their use. A lot of this
> ftp'g has been around and implemented into production for a long, long
> time. Cron jobs and polling mechanisms are currently in place to
> detect the files b4 uploading into another database for processing
> etc. I'd like to migrate the cron and polling jobs to an
> event-triggered mechanism (ie. triggered from the FTP server).
> 
> If only binary type executables are allowed to be triggered, I can
> live with that. Shell scripts are very flexible but I can understand
> and agree with your concerns on security which should take priority.

GET <filename>
GET <filename>.md5
if md5sum(<localfile>) == <checksum>
  DELE <filename> or SITE EXEC <postprocess>

The feature isn't required.  The addition of SITE CHECKSUM provides a
better means of determining you have a good copy of the file.

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: DJ <[email-masked]>
Date: Thu, 01 Oct 1998 23:07:37 -0700

Exactly.

Also I agree with you that this should not be part of the ftpd.
We build a separate daemon, called Agentd, that runs all these
jobs.  FTPDs connect to various agentds to make it happen.

DJ

At 03:15 PM 10/1/98 -0300, Cameron Lemon wrote:
>I guess I may as well offer my two cents worth on this.  An installation
that I
>am familiar with, runs a bunch of web servers.  Customers ftp their updated
>html pages, etc, to a staging server [drop off point ].  The web servers are
>cron'd to grab the new files for a particular site from the staging server.
>Checks are performed on the new pages, then are written out to that web
servers
>doc root.  The problem is that this is a polling model, which is
inefficient to
>say the least.  If an FTP Daemon existed that could act as an intelligent
>relay/proxy system, and perform actions per file or whatever, then the
polling
>system in place could then be event driven.  I think we can all agree that
>benefits are numerous when comparing the two models.  Personally, I don't
think
>that this functionality belongs in the ftpd either, however if it could be
>provided as a build option/module, then I'm all for it.  I would
definately use
>it though either way it was presented to me.  I can always choose to
disable or
>not to use it.
>
>Bob Luckin wrote:
>
>> > >Do you really have some processes where you want to connect to an
>> > >FTP server, _pull_ the file from the server to your local node, and then
>> > >execute a binary on the server from which you just pulled the file ?
>> > >
>> > ----------------------
>> >
>> > Many of our customers use this feature to trigger extended logging
>> > (eg log into a database, send a notification that the file has been
>> > downloaded from the server), or to delete or rename a file after it
>> > has been downloaded.  Also to do realtime tracking to see if a file
>> > has been downloaded.
>>
>> Well, you can delete and rename files using the relevant commands, without
>> the need to execute anything on the remote server.  And depending on how
>> things are set up, notification could perhaps be initiated from the client
>> end instead of the server.  The same might apply to the tracking as well,
>> depending on the mechanisms used...  But I'll accept that your clients find
>> the feature useful.
>>
>> I think Gregory asked his question originally to see how big the demand
>> for an "ondownload" equivalent to his proposed "onupload" was.  My guess
>> is there there may not be enough to warrant his effort to implement it.
>>
>> Of course, once he has written the code for the "onupload" command, it may
>> not take a lot of extra effort to add "ondownload" as well.  Assuming the
>> algorithms are similar much of the code may be calls to the functions
>> already written for "onupload"...  But since he's the one who is proposing
>> to implement either or both of these features, I'll certainly leave that
>> decision to him !
>>
>>   :-)
>>
>> Cheers, Bob
>> --
>> Bob Luckin      [email-masked]      "Temporarily sigged out"
>
>
>
>Attachment Converted: "c:\program files\eudora\attach\vcard56.vcf"
>