FTP or SFTP?

mpmcleod

Could someone (preferably a SM employee) explain why SM doesn't offer FTP or SFTP uploads?

It seems like it would be much more efficient than these hacks for bulk uploads.

If there is a web page or FAQ I would be happy to read that.

thanks!

mpmcleod

mpmcleod wrote:

Could someone (preferably a SM employee) explain why SM doesn't offer FTP or SFTP uploads?

It seems like it would be much more efficient than these hacks for bulk uploads.

If there is a web page or FAQ I would be happy to read that.

thanks!

anyone?
bump

Andy

What would you like me to say?

rutt

I had the same frustration and it led me to write this: http://dgrin.com/showthread.php?t=3853

Might not be what you are looking for, but it works for me.

mpmcleod

I was wondering if someone could answer the overall question of why FTP (or sFTP) was not allowed?

I seem to recall reading somewhere a comment from a SM person along the lines of "for certain reasons we don't allow FTP" -

I was wondering why not? or what those reasons might be?

Security reasons are easily addressable these days.

I was curious what the other reasons might be?

bandwidth, file checking/ processing, limiting the amount of data each non-programmer person uploads?

I have a hack working that lets me upload files but felt that FTP might be more efficient for people like myself uploading large amounts of data

If this is a question we are not supposed to ask I will drop it.
If this is a feature in the pipeline then that would be nice to know as well.

Thanks,

mlougee

FTP (and SFTP) advantages, maybe... synching and "watched folders"
I'm also interested in SFTP upload/download, esp with the new version of WinSCP's capability to do more with "synchronization" of folders, seemingly via automatically-watched folders.

If I understand it correctly, WinSCP can automagically synch folders in two locations, via names/filedates. IF Smug allowed SFTP, then perhaps just the simple act of placing photos into a folder on my desktop would get them auto-uploaded to the right place on Smug, maybe??

WinSCP is open-source (GPL Lic) so maybe that would make any coding somewhat easier?

If there are potential problems with use of bandwidth for exchange, or directory-size problems, or anything else, maybe these could be overcome with "limits" on various parameters?

cmason

my suspicion is that it has to do with loadbalancing,clustering and other such design elements. It is entirely likely that your photos do not reside on a single server to FTP to. In fact, I suspect they do not reside on a server at all, but on a virtualized SAN.

By going thru the API, your photos can be tagged with your acct info, and be dynamically assembled into what you know as your galleries.

While FTP can transport files, and is simple and fast since it is really just copying files from one directory on one machine, to a directory on another, I don't think FTP provides what they need. There is no 'directory" to FTP to in the traditional sense.

Just a WAG on my part, but I suspect the API is doing far more than simply transferring your files.

mpmcleod

cmason wrote:

my suspicion is that it has to do with loadbalancing,clustering and other such design elements. It is entirely likely that your photos do not reside on a single server to FTP to. In fact, I suspect they do not reside on a server at all, but on a virtualized SAN.

By going thru the API, your photos can be tagged with your acct info, and be dynamically assembled into what you know as your galleries.

While FTP can transport files, and is simple and fast since it is really just copying files from one directory on one machine, to a directory on another, I don't think FTP provides what they need. There is no 'directory" to FTP to in the traditional sense.

Just a WAG on my part, but I suspect the API is doing far more than simply transferring your files.

It would still be faster for SM to have a temp directory to receive photos which are then processed.

For my part I have a workaround in which I use my Linux system where a copy of the photos are stored, sm_tool.py to create the galleries, and a Perl program to interface with the HTML uploader (not the API). This process appears to be much faster and more robust than any of the API software I have tried. I currently have 30,000+ photos uploaded.

For daily loading I am using send-to-smugmug. It is very slow but I generally only upload 100-200 photos at a time so it seems to work ok for that. Now I wish I could download a text file with my catalog of photos, including all the EXIF information and the checksum for each photo but perhaps I should start a new thread about that.

devbobo

Mike,

I suggest one of the other issues with FTP of any kind is that its requires a physical user account per smugmug user on the system.

This in it self brings a whole lot of new concerns, password strength, etc. When a user select a weak password, it's a potential foothold into a system with which they could use other exploits to increase their priviledges.

Cheers,

David

mpmcleod

devbobo wrote:

Mike,

I suggest one of the other issues with FTP of any kind is that its requires a physical user account per smugmug user on the system.

This in it self brings a whole lot of new concerns, password strength, etc. When a user select a weak password, it's a potential foothold into a system with which they could use other exploits to increase their priviledges.

Cheers,

David

The FTP server doesn't have to be setup that way (it is not on systems that I run), but that is how most people chose to do it. I don't really think security is the reason for SM not allowing FTP/SFTP. Then again if one considers the general trend of SM security with private not really private, images and galleries assigned sequential numbers, default settings on gallery creation to unsecure settings, etc. All of which makes it more difficult to secure ones photos and easy pickings for someone to steal or use in a nefarious manner (e.g. pics of the kids). Perhaps it is better for SM to simply disallow it rather than dealing with setting it up in a secure manner.

It is easier to deal with one point of contact and one piece of software (e.g. the web server software) rather than have to deal with different daemons for each type of protocol. Personally, I do the same thing with my software. I design everything to go through the web server. I could open our database to direct outside queries, add FTP capabilities, etc. But I choose to force everyone through the web server so I only have to configure, log and secure one port and one point of access. Uploads happen through the web, database access is through cgi wrappers, etc.

I am one-man show in an academic environment. I had assumed that a company like SM with a full-time highly trained and very compentent IT staff and positive cash flow could offer other options. That said, while FTP upload would be nice I would greatly prefer dealing with security as a priority. At least let the user set a default template and remove the unsecure "smugmug default" template from my list of options during gallery creation.

SamirD

There's a good thread on some faster ways to upload here: http://www.digitalgrin.com/showthread.php?t=30847