Subject: RE: WU-FTP Hooks and file uploads

From: "Callaway, John" <[email-masked]>
Date: Thu, 8 Apr 1999 17:16:42 -0400

What M. Lundberg is suggesting is exactly how our company does this.  We
have a Linux box running wu_ftpd outside the firewall.  Customers are given
guest accounts under the group ftponly.  Jobs inside the firewall utilize a
real user and use 'cd ~username' to get to the appropriate directories.

This has been very effective and in use for two years, with over 200 users
using the system.  We can move users around and add disk drives very easily,
since all references to get files use '~user', and all users are guests.

The only problem we have is knowing 'when' files arrive.  We have to run
jobs every hour or so to go look for new files and download them.

-----Original Message-----
From: Gregory A Lundberg [mailto:[email-masked]]
Sent: Thursday, April 08, 1999 4:54 PM
To: Perry Edward (tsp2emp)
Cc: Wu-Ftpd (E-mail)
Subject: Re: WU-FTP Hooks and file uploads

On Thu, 8 Apr 1999, Perry Edward  (tsp2emp) wrote:

> If someone could tell me if this is a good idea or bad idea. It would
> also be helpful if you would me some of the functions that would help
> me to implement this.
> 
> I am looking to add the ability to upload a file from one FTP server
> to another FTP server (I guess build a basic FTP client in the
> server). The idea is that a customer would FTP to ftp server A. and
> upload a file. Then ftp server A. would open an intranet connection to
> ftp server B and login is using the user id and password that was used
> by the user to login on to system A. At this point Server A would
> transfer the file to ftp system B. When the transfer from A to B was
> finished it would then return control to the customer terminal or it
> could release the terminal and do the transfer in the background. Then
> files would exist on both system right away. I know something like
> this could be done by a script (like Mirror) but then passwords would
> be listed in an unencrypted state or I would have to make the script
> to run as setuid on the target system.

Sounds like you need to look at 'mirror' or an FTP proxy.

Don't know what you're trying to do but the way I read it, it looks
perillous.  If you're trying to allow outside customers to drop off files
for inside users, leave them on the outsode server and have the insiders
come get them.  I would NEVER allow ANYTHING from the outside world past a
firewall/proxy without someone on the inside coming to pick it up.

Think of it like a letter-bomb .. should the mail room deliver it to the
board room, or make the CFO come pick it up?  Damage will be bad either
way.  It may mean the CFO has to walk a bit, and he may make life hard on
your for making him do it, but at least there's _something_ left of the
executive board after the smoke clears.  You question, though, sounds even
worse .. you want to let the bomber have the keys to the board room so
it's easier for him to drop off the letter where it will do the most
damage.  What you should be doing is bomb-proofing the mail room.

-- 

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

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 8 Apr 1999 17:27:29 -0400 (EDT)

On Thu, 8 Apr 1999, Callaway, John wrote:

> The only problem we have is knowing 'when' files arrive.  We have to
> run jobs every hour or so to go look for new files and download them.

BeroFTPD has an email extension which will mail you automagically when a
file arrives.

I've got something similar in my TODO list, but I'll allow you to run a
given program instead of simply emailing.  My plan is to offer an email
program as an example so my version has a feature similar to BeroFTPD's (I
could, I suppose, even use Bernhard's syntax to run that program).

--