home *** CD-ROM | disk | FTP | other *** search
/ ftp.muug.mb.ca / 2014.06.ftp.muug.mb.ca.tar / ftp.muug.mb.ca / pub / src / gopher / gopher1.01 / misc / gopher2ftp / ReadMe < prev    next >
Text File  |  1992-06-10  |  7KB  |  159 lines
  1. Note: The ftp gateway functionality has been incorporated into the
  2. gopherd server in versions 1.0 and above.  You probably won't need
  3. this code.
  4.  
  5.  
  6. In this distribution is a simple and relatively (ha!) readable
  7. Perl script called g2ftpd.  The script implements an internet
  8. Gopher to FTP gateway. The gopher client connects to the g2ftpd
  9. daemon and tells it what the name of the ftp site is, (and perhaps
  10. what file it wishes to retrieve from there).  The daemon connects
  11. to the remote host, retrieves a directory listing (or file) via
  12. anonymous ftp, and returns it to the gopher client.  Of course
  13. all this happens without any new knowledge by the gopher client.
  14.  
  15. Running the script on a UNIX box gives folks running gopher clients
  16. access to all that good stuff available out there for anonymous ftp.
  17. The script assumes a nice healthy unixy ftp server at the ftp end...
  18. that is to say it is probably not going to work with funky IBM or
  19. TOPS-20 ftp implementations.  This is left as an exercise for the
  20. hacker...  er... reader.
  21.  
  22. The script is designed to be run by inetd as a TCP daemon.
  23. The easiest way to explain how to set it up and how it works
  24. is to use an example.
  25.  
  26. Let us assume that we want to run a gopher to FTP gateway on
  27. a machine called hell.micro.umn.edu. 
  28.  
  29. 1.  You need to have Perl available on the machine.  If you don't you
  30. can ftp the sources from a variety of anonymous ftp sites including
  31.  
  32.     uunet.uu.net
  33.     jpl-devvax.jpl.nasa.gov
  34.     tut.cis.ohio-state.edu
  35.  
  36. 2.  Edit the first few, (marked) lines of the g2ftpd file for your
  37. local configuration; in this case change the marked lines as follows:
  38.  
  39. #----Stuff here must be customized for your machine----
  40. $myName = "hell.micro.umn.edu";     #host full domain name
  41. $myPort = "7997";                   #port at which inetd will listen
  42. $ftp = "/usr/ucb/ftp";              #whereever on your box this lives
  43. #----end local customizations-------
  44.  
  45. 3.  Become root and place the gtoftpd file someplace nice (like
  46. /usr/local/bin or /usr/etc or wherever you place stuff like this);
  47. assume we put it in /usr/local/bin.  Make it owned by root and
  48. executable:
  49.  
  50.     chown root g2ftpd
  51.     chmod 755 g2ftpd
  52.  
  53. 4.  Update /etc/services by adding the following line to the
  54. /etc/services file (note it's tab between g2ftpd and 7997):
  55.  
  56.     g2ftpd    7997/tcp
  57.  
  58. Nothing sacred about 7997.  Run it at 6666 if you like...
  59. For SUNs running yp, you'll also want to do a make services:
  60.     cd /var/yp
  61.     make services
  62.  
  63. 5. Now update /etc/inetd.conf (for BSD-ish systems) or
  64. /etc/servers (on Ultrix or A/UX or others) depending on what you
  65. have.
  66. For /etc/inetd.conf, add a line:
  67.  
  68. g2ftpd    stream    tcp    nowait    root    /usr/local/bin/g2ftpd    g2ftpd
  69.  
  70. For /etc/servers, add a line:
  71.  
  72. g2ftpd    tcp    /usr/local/bin/g2ftpd
  73.  
  74. Note tabs between fields.
  75.  
  76. 6.  Kill and restart the inetd daemon whatever the prescribed way
  77. to do that on your machine.
  78.  
  79. 7.  You can confirm that g2ftpd is running now at port 7997 by
  80. telneting to hell.micro.umn.edu at port 7997. Type a hostname at 
  81. it (eg: boombox.micro.umn.edu), and it should respond by returning
  82. the anonymous ftp directories available at boombox.micro.umn.edu.
  83.  
  84. 8.  Now make some links from a regular gopher server to the g2ftpd
  85. service.  On a unix server, the links could look like this (on a 
  86. Mac server, do the functional equivalent using Gopher's Helper):
  87.  
  88.     Name=Sumex-aim:  Large collection of public domain Mac software.
  89.     Type=1
  90.     Port=7997
  91.     Path=sumex-aim.stanford.edu@info-mac/
  92.     Host=hell.micro.umn.edu
  93.  
  94.     Name=boombox:  Home of POPmail and Gopher Central.
  95.     Type=1
  96.     Port=7997
  97.     Path=boombox.micro.umn.edu@pub/
  98.     Host=hell.micro.umn.edu
  99.  
  100. And you're all set.
  101.  
  102. What happens is that the user sees the full Name (as always), say
  103. "boombox: Home of POPmail and Gopher Central".  It would appear as
  104. a directory (or folder icon on a Mac).  If selected (double-clicked
  105. on a Mac), the client would open a connection to hell.micro.umn.edu
  106. at port 7997.  The gtoftpd daemon would accept.  The client would
  107. then send it the selector string "boombox.micro.umn.edu@pub/".  The
  108. daemon would interpret this as "Go out to boombox.micro.umn.edu
  109. via anonymous ftp and get a listing of the pub directory."  The
  110. daemon would return this listing to the client in nice gopher
  111. format.  And everything else happens by magic as you would expect.
  112.  
  113. To the client it looks just like any other gopher-type directory.
  114. The script does assume that files ending in .hqx are BinHex files
  115. and gives them the type 4.  It also makes rash assumptions about the
  116. plethora of DOS binary files (.zip et. al.), and maps them all
  117. to a type 5.  Type 5 used to be "IBM BinHex" in the protocol notes,
  118. but since nobody really uses that, we've decided to map all these
  119. pesky binaries into type 5.  The client can decide what to do with
  120. them based on the .xxx extension that most seem to carry. Finally,
  121. it gives tar and Z files a filetype of 9.  And 9 is a new gopher
  122. item type (actually the only one we've allocated since we set up
  123. standards for the protocol.  All other files are given normal 
  124. type 0: that is text.
  125.  
  126. If your client is capable of handling binary types then it can
  127. allow type 5 and/or type 9 in directory listings.  It should be
  128. prepared to do things based just on the extensions (.xxx) of the
  129. files that the user requests.  In particular, it will need to
  130. just read from the connection until the server closes the connection
  131. when sending a binary file.  So there will be no concluding period,
  132. and obviously lines are meaningless.
  133.  
  134. WATCH OUT: The script has no way of knowing for sure that a file at an
  135. ftp site is binary (other than educated guesses based on the suffix of
  136. the filename), so when it presents gopherized listings, it must show
  137. these files too.  When a client attempts to retrieve a file, the script
  138. can peek into the file and make a much more educated guess as to
  139. whether it contains text.  So it should prevent a client from
  140. transferring totally gonzo binary.  I can hear the unix folks, the GIF
  141. folks, the PICT and TIFF folks and all the other special interest
  142. binary folks screaming.... :-) Yes, we need to do add some types... but
  143. we'd like to keep them as few as possible.
  144.  
  145. It would probably be wise to place caution ReadMe files out there for
  146. the users.  Also, if possible good gopher administrators would place
  147. the link all the way inside the "pub" or whatever directory at the
  148. server end.  We really don't want users fumbling around inside the bin
  149. or etc directories and attempting to suck down binary files.
  150.  
  151. Once more: the binary question is still open and we need to resolve
  152. that one yet.
  153.  
  154. All credit for this great and simple idea should go to Craig Rice
  155. (cdr@stolaf.edu).  Thanks Craig.  
  156.  
  157. FXA.
  158.  
  159.