2. Edit the file "config.h" in the top level directory. You should enter the host name of the computer on which you plan to run GN and the complete path name of your gopher data directory. If you want to run at a port other than 70 also edit the DEFAULTPORT entry. You should also specify the complete path of the file mkcache/gn_mime.types on your system. You can put this file anywhere convenient (and give it any name). This file is used by the mkcache program; see the section below on Content-type for an explanation of the function of this file. Other customizations are possible but should not be needed.
3. Edit the file "Makefile" in the top level directory. This allows you to specify the C compiler used if you wish to use something other than cc, e.g. gcc. You can also specify two directories in which things are placed when you do a "make install". The first of these SERVBINDIR is the path of the directory in which you want the executable file for the gn server installed. The second BINDIR is the location for the mkcache and uncache programs. If you are using a SysV version of UNIX you will need to uncomment the "-DSYSV" compiler directive also.
4. In the directory gn-1.1X do a "make" to produce the server "GN" and the two utilities "mkcache" and "uncache". The utility mkcache produces "cache files" for use by the server (it is described below) and uncache is used to convert from the Minnesota server gopherd to GN. If you want a C compiler other than cc you will need to edit the Makefile in each directory. The binary GN is the server and can be installed anywhere you choose. The binaries mkcache and uncache are utility programs for maintainers and should be installed somewhere in your path, e.g. /usr/local/bin.
5. You must be setup to run GN under inetd. There are surely variations on how this works from system to system so you may need to look at the man page for inetd.conf(5). Here's how it works under many systems, e.g. Suns: Edit the file /etc/services and create the line
gn 70/tcp
(or replace 70 by the port you wish to use). Then edit the file
/etc/inetd.conf and insert the line
gn stream tcp nowait nobody /full/path/for/gn gn
After the last GN you can have optional arguments to turn on logging or use a different data directory (see the man page gn.8).
It is important to run GN as "nobody" (the fifth field in the inetd.conf line above) or some other user with no no access privileges. If you are using an inetd with without the capability to set UID on startup (e.g., Ultrix), you should define the group ID and user ID in config.h so that the program is not running as root (look for the #defines GID_SET and UID_SET and uncomment them). It should never be necessary to run GN as root and to do so would be a serious mistake for maintaining security. Every attempt has been made to make GN as secure as possible, even if it is run as root, however, no program accessible to remote users on the internet can be assumed perfectly secure.
After editing the inetd.conf and services files you should find the process id number of the inetd process and do the command "kill -HUP pocess_id#". This must be done as root. If you have never done this before get someone who has to help you.
Name=This description of the file will display on the client
Path=0/path/to/dir/file
Type=0
Host=YourHost.YourU.edu
Port=70
Name=This is a subdirectory
Path=1/path/to/dir/subdir
Type=1
Host=YourHost.YourU.edu
Port=70
Name=This is a remote link
Path=0/myfile/path
Type=0
Host=MyHost.MyUniv.edu
Port=70
There are several things to note about these examples. The Name field
must be first, the Path field starts with a GN type (e.g. '0' for a
file or '1' for a directory, see the Appendix
to this document for more details). It is followed by the path name
of the file or directory relative to the top level data directory.The Type, Host, and Port fields are optional for local items, but required for remote links. If they are not present, the Type will be taken from the first character of the Path field and the Host and Path fields will be those specified in config.h (or on the command line of mkcache). In general it is a good idea not include the Host and Port fields for local items. This makes it much easier if at some future time you should wish to move your server to a new host or new port. For more details on the format of menu files see the man page mkcache.1 and the sample menu files in each directory of the source hierarchy.
2. After the menu files have been created you must run the mkcache program to produce a .cache file. This can be done once for each directory or once in the top data directory with the "-r" option to make all the .cache files for the hierarchy. You might want to look a .cache file to see what it is like.
Next edit the file "docs/sample.root.menu" to replace the host name "your.host.edu" with the name of the host for your server. Place a copy of the edited file in your root datat directory and name it "menu" (be sure to save the previous menu file if you have created one). Now in your root directory run the program mkcache with the command "mkcache -r". This will produce some messages including a warning about the file docs/Install, which you can ignore. (To understand the meaning of this warning read the section on structured files below.) Running mkcache with the "-r" option should produce two ".cache" files, one in your root directory and one in the docs subdirectory. Now change to the directory docs/images and run mkcache again to produce a .cache file here. Using the "-r" directory didn't take care of this directory because we don't want it to show on our menus and hence it isn't in any menu file. The image in this directory will appear "inline" in the menu for the root directory (if it is viewed with an HTTP client like Mosaic -- gopher clients lack the capability to display it and will ignore it.
Now you are ready to test your server installation on this directory. Try it with your favorite gopher or http client.
If this doesn't happen there should be an error message which may be helpful. Better error messages are placed in the log file so you may want run gn again with the additional arguments "-L logfile" and then examine the contents of the logfile. Or if you run "gn -L /dev/tty" the log entries will be printed to your screen instead of being put in a file. If it can't open a file, for example, the name of that file will be recorded in the logfile. Check its permissions. Remember that all files that gn servers must be world readable.
A second useful test is to telnet to your server at port 70. You should get a connection message and a pause for input. If you get a "Connection refused" message it is likely there is a problem with your inetd setup or for some reason your system can't find or can't execute the gn binary.
You may also list the domain names of the machines using wildcards provided the machines all have proper PTR domain name records. To allow access to all machines under nwu.edu, use the line *.nwu.edu. Note that this will not allow access to a machine called nwu.edu if it exists. One would need to add in the record nwu.edu to allow access.
You can also exclude IP addresses or domain names by prefixing them with an '!', so if .access contained only the lines
!boombox.micro.umn.edu *Access would be permitted to every machine except boombox. Likewise
!129.111 *would allow access to everyone except those on subnet 129.111. It is important to note that in determining access GN reads the .access file only until it finds a match (with or without '!') and then quits. So if .access consisted of the two lines
* !129.111then access would be granted to everyone since the * comes first and it matches everyone.
The "-A" option is similar to the -a option except access is allowed on a per directory basis. Each client request is processed by first looking for a .access file in the directory containing the requested item and comparing the IP address of the client with the addresses in this file. If no .access file exists in this directory, one is sought in the parent directory and then if necessary the parent of the parent, etc. up to the root data directory. If no .access file is found by this process access is allowed to all clients provided the item requested exists in a .cache file.
It is possible with GN to attain even finer access discrimination than on a per directory basis, though it is somewhat cumbersome to do so. Nevertheless if you have a need to make certain menu items visible (and accessible) to a select group of hosts, this is possible. Details on how to do it are in the last section of the document /docs/technical.notes.
In the remainder of this section we will describe the grep-like builtin search capabilities of gn. The example GN server on hopf.math.nwu.edu there has a top level menu item which is called "Full text search of GN documentation." When a user selects this item the client will prompt for a search term and then return a menu of all the available files in the documentation directory which contain the search term. The searches are case insensitive. In fact they use grep like regular expressions (see the UNIX man page for grep(1)). The searching is not done by actually invoking the UNIX grep program, however. Gn has its own builtin regular expression code.
This feature is enabled by putting two entries in appropriate menu files. The first looks like this:
Name=Documentation for the GN server Path=1s/docsThis is just a minor modification of the normal entry for the directory "docs" which contains the documentation files we want to make available by GN. The only difference is that the path is "1s/docs" instead of "1/docs". The "s" that we are making the directory searchable, i.e. giving permission to run grep like searches of all the files which are listed in the menu file for the docs directory. Of course, docs must be a directory in the GN hierarchy and it must contain a .cache file allowing files to be served by GN in the usual way.
As yet, however, we have no menu item for the search. This is achieved with the second menu item:
Name=Full text search of GN documentation Path=7g/docsThe "7" indicates that this is a search type and the "g" indicates that this is a "grep" type search. In this example docs is a directory in the GN root directory, but it could be lower in which case we would have the line Path=7g/foo/bar/docs. Both of these menu items might, as in this example, go in the same menu, but this is not necessary. You might, for example, want to have the "Full text search of GN documentation" item occur in the menu which lists the documentation files, rather than menu which lists the documentation directory. Or you might want to have it occur in both menus, which is fine. This menu item can occur in any menu of your GN hierarchy. But, of course, the "Documentation for the GN server" menu item is corresponds to the physical directory "docs", so it must be in the menu corresponding to the directory containing "docs". In this example that is the GN root directory.
You can also do full text grep-like searches through any collection of directories (instead of a single directory) but it requires a little trick. Here's how you do it.
In the directory whose menu you want to contain the search item (let's call it dir1) create a new directory (call it newdir). Take the menu files from all the directories you want to search, concatenate them into a single file and make it the menu file in newdir. Run mkcache on this concatenated menu file to produce a .cache file in newdir. Now in the menu file in dir1 put the follow entry:
Name=Search a bunch of files from mulitple directories Path=7g/dir1/newdirthen make a new .cache from this menu file. That's all there is to it. If you want also to have a menu visible to users showing all the files in the multiple directories you can add an item