UCO/Lick logo
UNIVERSITY OF CALIFORNIA OBSERVATORIES / LICK OBSERVATORY

Network, Information, and Computing Services

FTP (File Transfer Protocol), by itself, is a highly insecure protocol. When you log into an FTP server, your login and password are transmitted clear-text, without any encryption.

This is why we only allow anonymous FTP from outside the UCO/Lick network. While this can be inconvenient at times, it is a necessary step to try and maintain the security of our systems. If you want to use a direct transfer method, some operating systems allow you to use "scp," or secure copy, to transfer files. This is available by default on most modern UNIX systems, and can be downloaded for Windows + Mac machines. In addition, our UNIX hosts also allow "sftp," or (you guessed it) secure FTP connections. The behavior of sftp is exactly like ftp, except that the data connection and exchange of passwords are both encrypted.

If you are already on the UCO/Lick network, you can FTP to your heart's content to any other machine on the UCO/Lick network, as well as any external FTP sites that you could normally access.

FTP access for the outside world is a very different situation, as we've already stated; there are two situations that we have documented here: giving files to the outside world, and giving files to UCO/Lick from the outside world. As an added bonus, we've got a small blurb on how to retrieve files sent to you via our anonymous ftp service.

One caveat for Windows users: the ftp client included with most versions of Windows (the one you use on the command line interface) is a little too helpful for its own good. While most ftp clients have no problem creating new directories in the incoming directory to upload new files, the Windows ftp client feels that it does not have sufficient permissions. The only workaround is to use a different ftp client to create the first subdirectory, at which point you can use the Windows ftp client all you want.


Making files available to external users

For UNIX users, the process is quite simple. On your favorite managed UNIX machine, do the following:
cd /usr/local/ftp/outgoing
mkdir myusername                       (if it doesn't already exist)
cd myusername
cp /u/myusername/myfile ./
Your file is now availble for download via ftp.ucolick.org, in the directory /pub/outgoing/myusername. It is very critical that "myusername" is a valid UCO/Lick username; your files will be deleted on sight if it is not.

For any other users (Windows, Mac, etc.), you need to ftp into a managed UNIX machine; mambo, a public UNIX host, will do nicely for this purpose. The steps are the same as they are above, but the commands will vary depending on what FTP program you use. In the last step, instead of copying a file, you'll have to use your FTP program's "put" function. Make sure that you specify whether the file you're uploading is ascii or binary; binary files transferred as ascii files are borderline useless to your intended recipient(s).

Any files that you place in the outgoing area will eventually be deleted. Please read the README file for the specifics.


Uploading files to UCO/Lick as an external user

The steps for uploading files to ftp.ucolick.org are very similar to the steps outlined above. Fire up your favorite ftp program, point it at ftp.ucolick.org, and do the following:
ftp> cd /pub/incoming
ftp> mkdir myusername                  (if it doesn't already exist)
ftp> cd myusername
ftp> put myfile
ftp> quit
The exact syntax of the steps will vary depending on which FTP program you are using. It is very critical that "myusername" is a valid UCO/Lick username. If it is not, any files transferred will be deleted on sight. Also, please make sure that you transfer any binary files as binary files (as opposed to transferring them as ascii files); otherwise, the files will be almost useless to your intended recipient(s).

Any files placed in the incoming area will eventually be deleted. Please read the README file for more information on when and how your files will be deleted. Don't count on anything surviving longer than 24 hours; sometimes the machine gets bored, and doesn't want your file lying around dirtying things up.


Retrieving files sent to you, a UCO/Lick user

A collaborator of yours has uploaded one or more files into /pub/incoming/myusername as described above. How do you go about getting those files?

The most portable option is to use sftp to access these files. Using your favorite sftp client, log into the host ssh.ucolick.org with your normal UNIX username and password. You can then browse to the incoming ftp directory; here is a sample set of commands with the OpenSSH sftp client, which has a very similar command structure to the standard UNIX ftp client. 
sftp> cd /usr/local/ftp/incoming/myusername
sftp> get collaborator.data
sftp> get some.other.collaborator.data
sftp> quit

Another less secure way for you to retrieve our files is to use ftp. If you ftp to mambo.ucolick.org (or any managed UNIX host that accepts ftp logins and where you have a valid login) and log in using your UNIX login and password, you can retrieve the files directly. Note that this option is only available if you are on a machine within the UCO/Lick firewall, on the UCO/Lick network at UCSC.

Here's a synopsis of the ftp commands; these will take different forms depending on what kind of ftp client you're using.
ftp> cd /usr/local/ftp/incoming/myusername
ftp> get collaborator.data
ftp> get some.other.collaborator.data
ftp> quit
Here, I've downloaded the files "collaborator.data" and the accompanying "collaborator.data.description" to my local computer. Remeber to transfer binary files in binary mode, and flat text files in ASCII mode.


If you're using a managed UNIX host, you have an alternate, more direct method available to you.
cd /usr/local/ftp/incoming/myusername
ls -la
cp collaborator.data /u/myusername
cp some.other.collaborator.data /u/myusername
Here, I've copied the files "collaborator.data" and the accompanying "some.other.collaborator.data" directly without needing to go through another ftp session. I've placed the files in my "myusername" home directory on the machine I'm currently using.

You can go ahead and delete the files from your incoming directory, or you can let the automatic system delete the files for you. Read the README file to determine how long the files will remain in that directory. Don't count on anything remaining there for more than 24 hours (actual mileage may vary).

If you have any questions, please contact NICS.
Last modified on Friday, 21-Jul-2006 11:59:03 PDT