home *** CD-ROM | disk | FTP | other *** search
- In this distribution is a simple and relatively (ha!) readable
- Perl script called g2ftpd. The script implements an internet
- Gopher to FTP gateway. The gopher client connects to the g2ftpd
- daemon and tells it what the name of the ftp site is, (and perhaps
- what file it wishes to retrieve from there). The daemon connects
- to the remote host, retrieves a directory listing (or file) via
- anonymous ftp, and returns it to the gopher client. Of course
- all this happens without any new knowledge by the gopher client.
-
- Running the script on a UNIX box gives folks running gopher clients
- access to all that good stuff available out there for anonymous ftp.
- The script assumes a nice healthy unixy ftp server at the ftp end...
- that is to say it is probably not going to work with funky IBM or
- TOPS-20 ftp implementations. This is left as an exercise for the
- hacker... er... reader.
-
- The script is designed to be run by inetd as a TCP daemon.
- The easiest way to explain how to set it up and how it works
- is to use an example.
-
- Let us assume that we want to run a gopher to FTP gateway on
- a machine called hell.micro.umn.edu.
-
- 1. You need to have Perl available on the machine. If you don't you
- can ftp the sources from a variety of anonymous ftp sites including
-
- uunet.uu.net
- jpl-devvax.jpl.nasa.gov
- tut.cis.ohio-state.edu
-
- 2. Edit the first few, (marked) lines of the g2ftpd file for your
- local configuration; in this case change the marked lines as follows:
-
- #----Stuff here must be customized for your machine----
- $myName = "hell.micro.umn.edu"; #host full domain name
- $myPort = "7997"; #port at which inetd will listen
- $ftp = "/usr/ucb/ftp"; #whereever on your box this lives
- #----end local customizations-------
-
- 3. Become root and place the gtoftpd file someplace nice (like
- /usr/local/bin or /usr/etc or wherever you place stuff like this);
- assume we put it in /usr/local/bin. Make it owned by root and
- executable:
-
- chown root g2ftpd
- chmod 755 g2ftpd
-
- 4. Update /etc/services by adding the following line to the
- /etc/services file (note it's tab between g2ftpd and 7997):
-
- g2ftpd 7997/tcp
-
- Nothing sacred about 7997. Run it at 6666 if you like...
- For SUNs running yp, you'll also want to do a make services:
- cd /var/yp
- make services
-
- 5. Now update /etc/inetd.conf (for BSD-ish systems) or
- /etc/servers (on Ultrix or A/UX or others) depending on what you
- have.
- For /etc/inetd.conf, add a line:
-
- g2ftpd stream tcp nowait root /usr/local/bin/g2ftpd g2ftpd
-
- For /etc/servers, add a line:
-
- g2ftpd tcp /usr/local/bin/g2ftpd
-
- Note tabs between fields.
-
- 6. Kill and restart the inetd daemon whatever the prescribed way
- to do that on your machine.
-
- 7. You can confirm that g2ftpd is running now at port 7997 by
- telneting to hell.micro.umn.edu at port 7997. Type a hostname at
- it (eg: boombox.micro.umn.edu), and it should respond by returning
- the anonymous ftp directories available at boombox.micro.umn.edu.
-
- 8. Now make some links from a regular gopher server to the g2ftpd
- service. On a unix server, the links could look like this (on a
- Mac server, do the functional equivalent using Gopher's Helper):
-
- Name=Sumex-aim: Large collection of public domain Mac software.
- Type=1
- Port=7997
- Path=sumex-aim.stanford.edu@info-mac/
- Host=hell.micro.umn.edu
-
- Name=boombox: Home of POPmail and Gopher Central.
- Type=1
- Port=7997
- Path=boombox.micro.umn.edu@pub/
- Host=hell.micro.umn.edu
-
- And you're all set.
-
- What happens is that the user sees the full Name (as always), say
- "boombox: Home of POPmail and Gopher Central". It would appear as
- a directory (or folder icon on a Mac). If selected (double-clicked
- on a Mac), the client would open a connection to hell.micro.umn.edu
- at port 7997. The gtoftpd daemon would accept. The client would
- then send it the selector string "boombox.micro.umn.edu@pub/". The
- daemon would interpret this as "Go out to boombox.micro.umn.edu
- via anonymous ftp and get a listing of the pub directory." The
- daemon would return this listing to the client in nice gopher
- format. And everything else happens by magic as you would expect.
-
- To the client it looks just like any other gopher-type directory.
- The script does assume that files ending in .hqx are BinHex files
- and gives them the type 4. It also makes rash assumptions about the
- plethora of DOS binary files (.zip et. al.), and maps them all
- to a type 5. Type 5 used to be "IBM BinHex" in the protocol notes,
- but since nobody really uses that, we've decided to map all these
- pesky binaries into type 5. The client can decide what to do with
- them based on the .xxx extension that most seem to carry. Finally,
- it gives tar and Z files a filetype of 9. And 9 is a new gopher
- item type (actually the only one we've allocated since we set up
- standards for the protocol. All other files are given normal
- type 0: that is text.
-
- If your client is capable of handling binary types then it can
- allow type 5 and/or type 9 in directory listings. It should be
- prepared to do things based just on the extensions (.xxx) of the
- files that the user requests. In particular, it will need to
- just read from the connection until the server closes the connection
- when sending a binary file. So there will be no concluding period,
- and obviously lines are meaningless.
-
- WATCH OUT: The script has no way of knowing for sure that a file at an
- ftp site is binary (other than educated guesses based on the suffix of
- the filename), so when it presents gopherized listings, it must show
- these files too. When a client attempts to retrieve a file, the script
- can peek into the file and make a much more educated guess as to
- whether it contains text. So it should prevent a client from
- transferring totally gonzo binary. I can hear the unix folks, the GIF
- folks, the PICT and TIFF folks and all the other special interest
- binary folks screaming.... :-) Yes, we need to do add some types... but
- we'd like to keep them as few as possible.
-
- It would probably be wise to place caution ReadMe files out there for
- the users. Also, if possible good gopher administrators would place
- the link all the way inside the "pub" or whatever directory at the
- server end. We really don't want users fumbling around inside the bin
- or etc directories and attempting to suck down binary files.
-
- Once more: the binary question is still open and we need to resolve
- that one yet.
-
- All credit for this great and simple idea should go to Craig Rice
- (cdr@stolaf.edu). Thanks Craig.
-
- FXA.
-
-