Free FTP Access?
April 6, 2006 1:22 PM Subscribe
I am working with a vendor who needs FTP access to our servers. I can't give that and the ones who can, won't. So what are my options from here?
I'd like it to be (1) cheap, preferably free (2) secure, and (3) quick to implement. An automated system will be loading XML files to this server. Think news service without the feed.
I'd like it to be (1) cheap, preferably free (2) secure, and (3) quick to implement. An automated system will be loading XML files to this server. Think news service without the feed.
Well, the big question is, why do they need access? Are they placing the XML files somewhere so that an automated process does something with them? Is it possible that they could just put their files on their own webserver and then your process could consume them?
If you're looking for some way to set up an FTP server on your local network, that will be accessible from the outside, against your network admin's wishes, then you're setting yourself up for a heap o' trouble.
You need to either work it out with your network admin or get your boss's written authorization that what you're doing is, in fact, authorized. Most companies take a very dim view of employees screwing around with the network.
posted by bshort at 1:33 PM on April 6, 2006
If you're looking for some way to set up an FTP server on your local network, that will be accessible from the outside, against your network admin's wishes, then you're setting yourself up for a heap o' trouble.
You need to either work it out with your network admin or get your boss's written authorization that what you're doing is, in fact, authorized. Most companies take a very dim view of employees screwing around with the network.
posted by bshort at 1:33 PM on April 6, 2006
It's not clear even if they need to upload or download, unless I'm missing something.
And these FTP servers aren't connected to a web server?
They're just storage?
You could write a CGI script to handle uploading and downloading which only had access to certain specified directories.
posted by AmbroseChapel at 1:37 PM on April 6, 2006
And these FTP servers aren't connected to a web server?
They're just storage?
You could write a CGI script to handle uploading and downloading which only had access to certain specified directories.
posted by AmbroseChapel at 1:37 PM on April 6, 2006
Perhaps you should look into scp, or getting WinSCP (or other alternate scp client) setup to transfer files about. It's practically the same as FTP just much more secure.
posted by gaby at 1:49 PM on April 6, 2006
posted by gaby at 1:49 PM on April 6, 2006
Traditionally organizations keep a box in the 'dmz' (demilitarized zone) outside the firewall for vendor feeds such as this. The box is armored to the hilt, but assumed to be compromised and only trusted protocols are used to make connections.
Give the vendor sftp/scp access to the box. Have them upload their files periodically. Meanwhile, back on your side of the firewall, poll the box for the files and use whatever secure extraction mechanism you can to pull the data back through the firewall to the safety of your internal network.
With ftp, it can be helpful if the vendor drops a 'flag' file to indicate that the feed has completed -- the nature of ftp is such that it's not possible to detect when a file is done uploading unless you know its specific size in bytes in advance.
Generally these problems can be best solved with both the vendor and the network staff on the phone together with you. The vendor is there to try to keep your business and get you the data; the network staff works on your behalf and keeps the network secure; and you are there to champion a connection between the two.
posted by felix at 1:55 PM on April 6, 2006
Give the vendor sftp/scp access to the box. Have them upload their files periodically. Meanwhile, back on your side of the firewall, poll the box for the files and use whatever secure extraction mechanism you can to pull the data back through the firewall to the safety of your internal network.
With ftp, it can be helpful if the vendor drops a 'flag' file to indicate that the feed has completed -- the nature of ftp is such that it's not possible to detect when a file is done uploading unless you know its specific size in bytes in advance.
Generally these problems can be best solved with both the vendor and the network staff on the phone together with you. The vendor is there to try to keep your business and get you the data; the network staff works on your behalf and keeps the network secure; and you are there to champion a connection between the two.
posted by felix at 1:55 PM on April 6, 2006
Assuming there is some requirement to use ftp because of limitations on your or your vendors part, you could simply purchase an account with a hosting service such as 1and1.com and use it as an intermediary. They are fairly cheap (depending on your storage requirements). But the suggestions above are better ideas.
posted by Manjusri at 2:04 PM on April 6, 2006
posted by Manjusri at 2:04 PM on April 6, 2006
Echoing what b1tr0t and gaby said - use scp.
There is a reason that those who could give access won't. It is the same reason they probably wouldn't allow the use of telnet. FTP, especially from an outside source, is a very bad idea from a security standpoint.
Anonymous FTP is fine, but HTTP is just as easy for most tasks, and it looks like you want the vendor to actually send you files, not receive files from you.
Having dealt with outside vendors with requirements like this, I'd be wary if they can't implement scp or something similar. It is very easy to do, and not being able to do so reflects poorly upon the technical abilities of the company.
If it is something you can't live without, and they can only do FTP, then by all means set up FTP, but do it outside your network, using dreamhost, 1and1, or something similar. But you really, really shouldn't need to be doing it that way.
hint: rsync works fine over ssh, too, and will keep itself updated with a proper one line shell command
posted by bh at 2:17 PM on April 6, 2006
There is a reason that those who could give access won't. It is the same reason they probably wouldn't allow the use of telnet. FTP, especially from an outside source, is a very bad idea from a security standpoint.
Anonymous FTP is fine, but HTTP is just as easy for most tasks, and it looks like you want the vendor to actually send you files, not receive files from you.
Having dealt with outside vendors with requirements like this, I'd be wary if they can't implement scp or something similar. It is very easy to do, and not being able to do so reflects poorly upon the technical abilities of the company.
If it is something you can't live without, and they can only do FTP, then by all means set up FTP, but do it outside your network, using dreamhost, 1and1, or something similar. But you really, really shouldn't need to be doing it that way.
hint: rsync works fine over ssh, too, and will keep itself updated with a proper one line shell command
posted by bh at 2:17 PM on April 6, 2006
sftp looks like ftp but uses ssh - it might be an easier sell than scp and should work equally well. i'm pretty sure putty will do sftp.
posted by andrew cooke at 2:22 PM on April 6, 2006
posted by andrew cooke at 2:22 PM on April 6, 2006
(putty for the client; your side needs the ssh stuff everyone else is talking about).
posted by andrew cooke at 2:22 PM on April 6, 2006
posted by andrew cooke at 2:22 PM on April 6, 2006
Response by poster: File size unknown, which is why I ruled out email. There is no box for my company in the dmz. Don't ask me why, I don't make these decisions. I have no control or influence over the IT department policies, let alone authorization to install ANY software on the server.
Here's what I need to do:
We have an internal Filemaker database. It was here before I got here, it's not the best solution, it's not on my long list of things to change (I just started at this job in Dec.). It tracks our news clips. We are buying an outside service that uses a Web browser interface to deliver our clips to us. We like that service, however the clips fall off after 60 days and we like to have them longer than that. From what I can tell, each clip is an xml file and then that is parsed through a perl script to give us the page we see when we login. The vendor has told us it will give us the xml files, but it can only do that if they have FTP access.
I've tried to scrape the HTML page so I don't have to do all this. There doesn't seem to be any way to get it from their finished file into our database AND have the information we want.
Does this give anyone any different ideas than FTP?
posted by nramsey at 2:29 PM on April 6, 2006
Here's what I need to do:
We have an internal Filemaker database. It was here before I got here, it's not the best solution, it's not on my long list of things to change (I just started at this job in Dec.). It tracks our news clips. We are buying an outside service that uses a Web browser interface to deliver our clips to us. We like that service, however the clips fall off after 60 days and we like to have them longer than that. From what I can tell, each clip is an xml file and then that is parsed through a perl script to give us the page we see when we login. The vendor has told us it will give us the xml files, but it can only do that if they have FTP access.
I've tried to scrape the HTML page so I don't have to do all this. There doesn't seem to be any way to get it from their finished file into our database AND have the information we want.
Does this give anyone any different ideas than FTP?
posted by nramsey at 2:29 PM on April 6, 2006
nramsey, I work in a library and we are currently changing our enews munging software, so I've gotten a look into that kind of thing. An added bonus is that I work in an agency where data privacy is incredibly important, so we have an "interesting" network setup. I've had to deal with a lot of similar issues, although I do have more say in what we can/can't do than you might have.
I am quite curious, though - I haven't heard of an enews provider that FTPs _in_ to the site they feed. The usual setup seems to be that the provider will have their clips on their FTP server, and the clients will setup automated tasks to fetch whatever feeds they are subscribed to (controlled by their username/password, of course). That could happen either through an in-house FTP fetching solution or as part of the provider's delivered software for handling enews services.
I would personally have real reservations about allowing any vendor FTP in to our servers on the internal network, and I doubt I would ever get the authorization to do that. That's why sites that are intent on being secure in that way setup a DMZ to compromise and communicate with the external world.
I guess if the provider is crafty and willing to customize, they could write scripts to zip up the xml files and email them off, but as you said there might be a size issue. Perhaps as has been suggested SFTP would be a possibility if your IT department is concerned about password exposure.
I don't really think there's a way around it; as far as enews delivery is concerned, timeliness is usually an issue, and that implies that network transfers are pretty much necessary. FTP is the reccommended app for large file transfers. If your IT department wants a secure network, they either have to work out DMZ issues for communicating with the outside while having a secure network, or else they and the company have to be willing to work with the limitations not having a DMZ creates.
posted by splice at 3:23 PM on April 6, 2006
I am quite curious, though - I haven't heard of an enews provider that FTPs _in_ to the site they feed. The usual setup seems to be that the provider will have their clips on their FTP server, and the clients will setup automated tasks to fetch whatever feeds they are subscribed to (controlled by their username/password, of course). That could happen either through an in-house FTP fetching solution or as part of the provider's delivered software for handling enews services.
I would personally have real reservations about allowing any vendor FTP in to our servers on the internal network, and I doubt I would ever get the authorization to do that. That's why sites that are intent on being secure in that way setup a DMZ to compromise and communicate with the external world.
I guess if the provider is crafty and willing to customize, they could write scripts to zip up the xml files and email them off, but as you said there might be a size issue. Perhaps as has been suggested SFTP would be a possibility if your IT department is concerned about password exposure.
I don't really think there's a way around it; as far as enews delivery is concerned, timeliness is usually an issue, and that implies that network transfers are pretty much necessary. FTP is the reccommended app for large file transfers. If your IT department wants a secure network, they either have to work out DMZ issues for communicating with the outside while having a secure network, or else they and the company have to be willing to work with the limitations not having a DMZ creates.
posted by splice at 3:23 PM on April 6, 2006
You might be able to rig up some sort of web-browser based Java or html upload applet.
posted by fvox13 at 3:32 PM on April 6, 2006
posted by fvox13 at 3:32 PM on April 6, 2006
I really think you should just get third-party storage, as a number of other people have said.
You can get hosting services so cheaply nowadays you could pay for it out of your own pocket and hardly notice it. You can get these accounts from as little as $20 a year.
So just get a cheap web hosting service -- FTP traffic doesn't even count toward your total traffic anyway.
If you really want to scrape their site on the other hand, I'll write a script for you, cheap!
posted by AmbroseChapel at 3:47 PM on April 6, 2006
You can get hosting services so cheaply nowadays you could pay for it out of your own pocket and hardly notice it. You can get these accounts from as little as $20 a year.
So just get a cheap web hosting service -- FTP traffic doesn't even count toward your total traffic anyway.
If you really want to scrape their site on the other hand, I'll write a script for you, cheap!
posted by AmbroseChapel at 3:47 PM on April 6, 2006
Funny, most questions would involve finding a web host who wasn't so insane as to still offer FTP :)
1and1.com's accounts have FTP and I think they have something as cheap as $8 a month and with no setup or cancellation fees. Make sure you get FTP with anything you sign up with - many providers refuse to offer it. Most external storage sellers a la Strongspace.com don't allow it either.
posted by phearlez at 4:25 PM on April 6, 2006
1and1.com's accounts have FTP and I think they have something as cheap as $8 a month and with no setup or cancellation fees. Make sure you get FTP with anything you sign up with - many providers refuse to offer it. Most external storage sellers a la Strongspace.com don't allow it either.
posted by phearlez at 4:25 PM on April 6, 2006
many providers refuse to offer it
Really? Have you got a list of companies which refuse to allow FTP? I'm not challenging you, I'm just surprised. Web hosting companies, particularly cheap ones, offer the technologies that their customers are familiar with and aren't too worried if they're insecure, as far as I know.
posted by AmbroseChapel at 6:06 PM on April 6, 2006
Really? Have you got a list of companies which refuse to allow FTP? I'm not challenging you, I'm just surprised. Web hosting companies, particularly cheap ones, offer the technologies that their customers are familiar with and aren't too worried if they're insecure, as far as I know.
posted by AmbroseChapel at 6:06 PM on April 6, 2006
This thread is closed to new comments.
posted by inigo2 at 1:32 PM on April 6, 2006