Joseph Mack NA3T wrote:
On Tue, 14 Nov 2006, Joseph Mack NA3T wrote:
On Tue, 14 Nov 2006, Joseph Mack NA3T wrote:
I don't have any good ideas - here's a suggestion -
o does your ftp demon create the files with different owner,
permissions, date while it's downloading, than wind up on the file
after its been closed?
when I download a file with ncftp I can see with lsof that the file
is open and ncftp has it open, but after the download I don't see it
open. Can you do something similar with the files in your upload
directory or look for files opened by your ftpd?
if someone is doing an upload to the ftpd machine and you have
/etc/services with all the correct strings and look with
`netstat -ap | grep ftp`
you'll see something like
ftpd_machine:ftp other_machine:high_port ESTABLISHED
ftpd_machine:ftp-data other_machine:another_high_port
ESTABLISHED||TIME_WAIT
when the upload is over, the ftp-data connection will disapear. When
the client disconnects the ftp connection will go.
You could look for an inactive ftpd, then possibly block||kill the
ftpd, do your transfer and then restart the ftpd
Joe
Joe's working down the direction I would suggest that you look first.
It's the simplest thing to accomplish with out modifying the FTP server
directly, which frankly is a tricky business. I would suggest it only
as a last resort, as the last thing you want to do is inadvertently
introduce a security bug into your FTPd, as typically they're
notoriously bad for them (hence why anyone would name their product,
"very secure ftp daemon", and presumably why you (or your distribution
packager) would chose that one).
A better approach than monitoring the TCP side of the problem would be
to grab a list of files, then run lsof looking for those files as open
filehandles of running processes. If they are, something is still
potentially writing to said file. If not, it's reasonably safe to
consider that upload to have completed. Something akin to lsof | grep
'<fullpath/to/filename>' in your scripting language of choice, would
serve as a good start. Depending on your scripting skills, this should
be reasonably easy to implement, or you can for probably very limited
outlay of fundage, beer, or pizza acquire assistance from someone on the
list to work up a full solution.
Philip's suggestion of hooking into the FTP daemon is technically
superior, in that it's a notification system that doesn't involve
polling. For this reason alone it bears mentioning. Still, I'd submit
that the implementation challenges and technical hurdles in making it
work right are at least an order of magnitude greater, as it would
probably take at least twice as competent staff five times as long to do
it maybe half as well.
Aaron S. Joyner
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
