A free gopher protocol server for UNIX
John Franks
Version (0.1)
Gn is freely available for any use commercial or otherwise. The
software is freely redistributable under the terms of the GNU public
license. It can be obtained as the compressed tar file gn-0.1.tar.Z
via gopher to hopf.math.nwu.edu port 70. It is not currently
available by anonymous ftp.
WHAT IT HAS AND WHAT IS MISSING.
Gn is a server only (there is no client) which is written in C and
runs under UNIX. It supports the standard text and binary types,
including sound and image. Since the CSO type requires nothing from
the server it is supported too. Also gn will exec programs (with
arguments) much like gopherd does. Index types are limited. There is
not yet support for WAIS indices, only for programs (or shell scripts)
which return "virtual directories" and also for the "grep" type
searches. There is not yet ftp daemon support, (though the perl
go2ftp gateway should work). Gn runs only under inetd. See the man
page for details.
Gn has "per directory" access control. You can have different access
(by IP address or subnet) to every directory if you want to. You don't
need to run different servers on different ports to have different
levels of access! On the other hand, the access is no finer than a
directory. There are no distinctions like separate browsing,
searching and viewing permissions as in gopherd. (I just never found
these worth the trouble.)
A DIFFERENT VISION AND DIFFERENT SERVER DESIGN.
My vision of the future of gopherdom is that servers will be much more
distributed than they are now. I see no reason that servers won't be
as common as clients. We are all information providers as well as
consumers. Information should be served from the same desktop where
it is created. I am convinced that *electronic* desktop publishing
will be as important -- maybe more important -- than paper desktop
publishing.
As a professor, I am very interested in gopher as an electronic
distribution mechanism for scholarly work and materials for students.
Gopher is becoming popular as a "preprint database" mechanism. But it
seems silly to me to have to "upload" my work to the database, when I
could more easily make it available from my desktop. This would have
the important side effect of leaving my work completely in my control,
for example, to correct errors or make modifications.
A corollary of this vision is that we need to pay as much attention
the the user interface of the server as we do to the interface of the
client. The server needs to have a user friendly graphical interface
too!
Unfortunately, gn does not realize this vision, but its design has
been influenced by these ideas. Instead of creating a special
directory hierarchy, which the server can access, gn provides a window
into the file system where the information naturally resides.
Here's how it works -- to see this example in action gopher to
hopf.math.nwu.edu port 70. Suppose I want to make available the
source files for gn via gopher. My root data directory is the top
of my gn development directory hierarchy -- where I am writing and
testing the code. Of course, there is a lot stuff there that I don't
want to publicize (*.o, *.c~ etc). In each directory that I choose to
make public I place a "menu" file which has essentially the same
format as a gopherd .links or .names file. From this menu file a
.cache file is produced in the same format as gopherd, but containing
*only* items in the menu file. This provides a window, or mask if you
like, for that directory, making visible precisely what I choose.
This is also the basis of security. Except for an optional log file,
the gn server writes *nothing* to disk (.cache files are written by a
separate program called mkcache). And it will send no files to
clients, except files listed in .cache files, and .cache files
themselves. If /etc/passwd isn't put in a menu file which gets made
into a .cache file it won't be transmitted by gn.
Ideally the mkcache program would have a graphical user interface and
allow the user to select and annotate which items in a directory
should be "published" and would then make the .cache file. In this
implementation however, it is up to the user to create a menu file
(same format as .links) with an editor and then mkcache makes a .cache
file from it and optionally does the same for all subdirectories
recursively. To see examples of all these things gopher to
hopf.math.nwu.edu.
Of course, if you choose, it is possible to use gn almost exactly like
gopherd and have a separate gopher hierarchy. Maintenance is
practically the same as with gopherd. You create a menu file for a
directory (which is just like a .names directory for gopher+ and can
be called .names or .links if you like) and produce the .cache file.
There are two differences. With gopherd every time a new file is
created in the gopher hierarchy it is automatically added to a new
.cache file. With gn this does not happen. You must enter an item in
the menu file and update the .cache file. The work involved is
essentially the same as maintaining the gopherd .cap files. The other
difference is that while the menu file format is the same as a .links
or .names file, it does not have a Numb field. Items are printed by
the client in the order they occur in the menu file.
While this discussion has emphasized gn as a server for the desktop, I
think that gn is well designed for a dedicated server also. I
maintain a moderate size gopher protocol server and much prefer the
control I get by having only the files I select displayed rather than
any file which happens to be in the hierarchy and not on the ignore
list. I also find dealing with one menu file much easier than many
.cap files. Efficiency was not a prime goal in writing it --
simplicity always took precedence -- but I think gn should be a fairly
efficient server.
CHANGING FROM GOPHERD TO GN (OR VICE VERSA)
Despite the differences between gn and gopherd, it is very simple to
switch from gopherd to gn. Here's all you have to do. If you are
using gopherd, make sure that .cache files are being created (this is
the default, but directory permissions must be correct for them to be
created). Then simply stop gopherd and start up gn under inetd. Gn
will use the .cache files produced by gopherd and will function
properly with no changes made to the gopher hierarchy files. When you
want to add or delete a file to this hierarchy first run the "uncache"
utility provided with gn which produces menu files from all the .cache
files. Now simply edit the appropriate menu file to accomplish the
change and continue maintenance appropriate for gn.
If you wish to change back to gopherd there is no problem as long as
you have not removed your .cap files or .links files (or .names files
for gopher+). Simply stop gn, remove the menu files and start up
gopherd.
John Franks Dept of Math. Northwestern University
jo...@math.nwu.edu