Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp .com.
Some people today think that if you're going to provide information, the Web is the only way to go. This isn't entirely true. The Web is certainly flashy for those who have graphical browsers, but if you are trying to track down information on a specific subject, it's easy to get sidetracked following other interesting links, or to end up at a dead end and have to backtrack. When it comes down to it, the Web is a great general catch-all tool, but if you have specific tasks in mind often a more focused tool is more efficient (e.g., an FTP client instead of a Web client).
Gopher, instead, offers an interface that is just as simple to use as the Web, but with a menu-driven setup enabling you to narrow down your subjects without quite as much sidetracking. Also, because Gopher is text-based, it's faster to use and available to those on the Net who don't have access to the fancier tools-so you can reach a wider audience.
If you don't intend to install a Gopher server, feel free to go on to the next chapter. Or, read the first section describing Gopher and then decide whether you want to use a Gopher server on your site.
In this chapter, you learn how to:
Gopher is somewhat obscure on today's Internet. It was the predecessor of the World Wide Web developed at the University of Minnesota, its purpose being to offer a number of types of documents in an easy to navigate format. The primary difference between Gopher and the WWW is that Gopher is a strictly text interface-though it has graphically based clients, Gopher itself is only text. To look at a picture through Gopher, for instance, you must download it first, then pull it up with your graphics viewer.
Gopher's name comes from its function, in that it gets files for you: go-fer. Gopher servers are menu based, each server pointing to items on its own site and on other sites; you simply select which menu item you want and press Enter to follow it or get the appropriate file. The type of file the menu points to is unimportant. Like the Web, it can point to text, graphics, word processor, sound files, and so on. It can also, like the Web, use clients' pointers to other applications to follow telnet, FTP, and other such links using the appropriate application.
As a system administrator, you will discover over time that you have to compile most of the applications that you use on your site. Because of all the assumptions that have to be made in preparing something as a precompiled binary, it's common to find that binaries don't work on many individual setups.
Gopher is one such instance of a program that you need to compile. However, this compilation should be fairly painless.
The Gopher server you're going to use is the University of Minnesota's (the very same university that initially developed Gopher) Internet Gopher+ distribution for Linux version 2.1.3. This is a daemon, which will run in the background and wait for Gopher requests to come in.
If you find that the instructions for unpacking files in this section are too sketchy, the process is covered in more detail in chapter 7, "Installing Web Server Software."
To unpack the file containing everything necessary to compile your Gopher server, do the following:
The source code for Gopher isn't set up specifically for Linux, instead it's set up for UNIX systems in general. There are special cases included for the more popular UNIX systems so you can choose which one you want to compile it for. Therefore, since you need to tell the source code which UNIX OS you intend to use the binary on, you have some files to edit. And, of course, there are the usual changes you can make before compilation to configure the binary for your particular setup.
There are two files you will need to edit before you begin your compiling: Makefile.config and conf.h.
Because this is a generic UNIX server, you need to go through Makefile.config and edit it to ensure that it will not only compile for Linux, but also for your needs. As this is not a book on programming or compiling, I am going to show you the quickest ways of getting such programs ported to Linux.
Each part of Makefile.config is clearly labeled with commented lines explaining what it's used for. Let's jump past the revision listings and walk through the changes step by step:
Step 1
#------------------------------------------------ # Your favorite C compiler # # Note that sun international users should use /usr/5bin/cc instead of cc # # Sco's cc compiler gives lots of problems that gcc will fix, and gcc # is now reasonably easy to get running under SCO. Using this removes # the need for -UM_XENIX -DSCO_UNIX as used for Gopher1.1 # note that if you use gcc, you'll also need -lintl in SCOLIBS # CC = cc
Although you likely have a symlink from cc pointing to gcc (Gnu C Compiler), just for neatness' sake you may want to change this to CC = gcc.
Step 2
#------------------------------------------------ # System Selection, note that you won't have to edit # unless you have compilation problems. # # Add -DUSG for System V # -DBSD for BSD # -DNO_WAITPID if you have wait3 instead of waitpid() # -DUSE_FLOCK if you have flock instead of fcntl() locking GSYSTYPE=
Linux and BSD are closely compatible versions of UNIX. When you don't have the option of telling a Makefile that you're using Linux specifically, BSD is a good choice. Therefore, I'll change this line to GSYSTYPE=-DBSD.
Step 3
#---------------------------------------------------- # Compatibility defines # # Most of these are automatically defined via the built in compiler # definitions. Don't worry about them unless you have problems # # Add -DNOSTRSTR if you don't have strstr() # -DNO_STRDUP if you don't have strdup() # -DNO_STRCOLL if you don't have strcoll() # -DNO_TEMPNAM if you don't have tempnam() # -DNO_BZERO if you have memset()/memcpy instead of bzero()/bcopy() # -DNO_GETWD if you have getcwd() instead of getwd() # -DNO_TZSET if you don't have tzset() # -DNO_STRCASECMP if you don't have strcasecmp() # -DNO_SETEUID if you have setresuid/setresgid, but not seteuid/setegid # -DNO_GETDTABLESIZE if you don't have getdtablesize() # -DNO_LINGER if you can't use linger with setsockopt() # -DNO_VFORK if you have fork() but not vfork() # -DNO_PID_T if your headers don't define pid_t # -DNO_STRFTIME if you don't have strftime() # -DNO_MKTIME if you don't have mktime() # -DNO_WAITPID if you have wait3() instead of waitpid() # -DUSE_FLOCK if you want to use flock() instead of fcntl() locking # -DNO_UNISTD_H if you don't have a <unistd.h> header # -DNO_LOCALE if you don't have <locale.h>/setlocale() # -DNO_XPGCAT if you don't have the X/Open catopen() & catgets() COMPAT =
Although you could certainly search through your libraries to make sure you have all of these items, there is another way to take care of this item. Simply leave it be, and if the compiler tells you later that you don't have a particular library or function, then you can come back to this portion of the file and set the particular routine as not being there. For example, if the compiler says you don't have strcasecmp(), then you'll come back to Makefile.conf and enter COMPAT=-DNO_STRCASECMP. The compiler will take it from there.
Step 4
#------------------------------------------------- # Where shall we install stuff? # PREFIX = /usr/local CLIENTDIR = $(PREFIX)/bin CLIENTLIB = $(PREFIX)/lib SERVERDIR = $(PREFIX)/etc # On SCO manuals are in /usr/man but it's easiest to do a # symbolic link from /usr/local/man to /usr/man for this and other packages MAN1DIR = $(PREFIX)/man/man1 MAN5DIR = $(PREFIX)/man/man5 MAN8DIR = $(PREFIX)/man/man8
When possible, try to put the programs you install under one of the /usr/local directories. It will make it easier to locate them later!
What these items are set to depends on your preferences. If you keep all your system items in /usr rather than /usr/local, then you'll want to change the value of PREFIX to PREFIX=/usr. If you leave PREFIX as it is but keep your man pages in /usr, then you may want to change the man lines to the following:
MAN1DIR = /usr/man/man1 MAN5DIR = /usr/man/man5 MAN8DIR = /usr/man/man8
Step 5
#---------------------------------------------------- # DEBUGGING control... # # Comment this to make a slimmer executable... DEBUGGING = -DDEBUGGING
This item turns on the debugging flag. Some like to have this flag on at first, compile the file, and run the program (in this case the server). The program will then run with debugging options on to help you find any problems. If the program runs fine, you can then go back into Makefile.config and comment this line out by adding a pound sign (#) in front of it (e.g., #DEBUGGING = -DDEBUGGING). Without the debugging code, a program will be smaller, so it's a good practice to exclude it if you don't need it. Also, if you don't know how to use the debugger and don't have a use for it, don't include it.
Step 6
#------------------------------------------------ # Uncomment out the following lines to use SOCKS #SOCKSFLAGS=-Dconnect=Rconnect -Dgetsockname=Rgetsockname -Dbind=Rbind -Daccept=Raccept -Dlisten=Rlisten -Dselect=Rselect #SOCKSLIBS=-lsocks If you are using a socks-compliant firewall (firewalls will be discussed in Chapter 13, "Maintaining Linux"), uncomment these lines out (not the header, but the actual variables) by removing the pound signs (#) at the beginning of each line, like so: SOCKSFLAGS=-Dconnect=Rconnect -Dgetsockname=Rgetsockname -Dbind=Rbind -Daccept=Raccept -Dlisten=Rlisten -Dselect=Rselect SOCKSLIBS=-lsocks
SOCKS is used to create a firewall for your system for maximum security. For more on SOCKS, see appendix E, "Setting Up a Firewall."
Step 7
#---------------------------------------------------- # Optional server features. #
There are a number of server features you can choose to use or not use. To use any one of these, add it to the line as follows:
SERVEROPTS = -DSETPROCTITLE -DCAPFILES #-DBIO -DDL -DLOADRESTRICT
Note that anything on this line after the # is commented out, so this line originally really reads as follows:
SERVEROPTS = -DSETPROCTITLE -DCAPFILES
The following are the options you may want to consider:
A number of the options mentioned in this segment that I didn't discuss involve WAIS (Wide Area Information Server). Setting up a WAIS server is not covered in this book, but there is a lot of information available on the subject from the Internet. Check out the following URL for more on WAIS:
Step 8
#-------------------------------------------------- # Libraries for clients and servers
You won't want to touch this part. These are special case statements, and you don't fall into any of the cases listed.
Step 9
#---------------------------------------------------- # If your hostname command returns the Fully Qualified Domain Name # (i.e. it looks like foo.bar.edu and not just foo) then make # the domain name a null string.
Log into your system and type hostname. If it just gives you the machine name (for example, davinci), then change DOMAIN=.micro.umn.edu to DOMAIN=.your.domain (e.g., DOMAIN=.renaissoft.com). If it returns the full host name (i.e. davinci.renaissoft.com), then change the DOMAIN statement to DOMAIN= to make it a null statement.
Step 10
# SERVERDIR is the default directory for gopherd.
If you don't want your default gopherd directory to be gopher-data, change the statement SERVERDATA = /gopher-data to reflect the directory you want to use.
Step 11
# SERVERPORT is the default port for gopherd.
If you don't want your default Gopher port to be 70, change the statement SERVERPORT = 70 to reflect the port number you want to use. Keep in mind, however, that it's often a good idea to stick with the default port because it makes it easier for people to locate your services.
If you do change the port from the default, go into the /etc/services file and change the port the gopher server is defined to use in this file to match the new one you assigned to SERVERPORT.
Although Makefile.config mostly deals with server configuration, conf.h mostly deals with client configuration. You will compile your system's Gopher client from the same code as the server, so make sure you go through this file carefully as well.
In this file, commented sections begin with /*, and end with */. Any line that starts with a pound sign (#) is not commented out in conf.h.
Once again, let's walk through the changes you will want-or need-to make, step by step:
Step 1
* Defaults for the client program
These two items define the home Gopher that a user's Gopher client will first contact upon starting up. Right now, they're set to two different aliases for the Mother Gopher at UMN (University of Minnesota). If you would rather have them connect to another home Gopher, then go ahead and change one of these items. The Gopher server is determined randomly between CLIENT1_HOST and CLIENT2_HOST.
The variables CLIENT1_PORT and CLIENT2_PORT go with these items. Make sure to set these values appropriately if you change the host settings above (if you're not sure, the default port is 70 so try that first).
If you don't want two different home Gopher possibilities, just set CLIENT2_PORT=0.
Step 2
* Default language for client when multiple language views are available
The language that is preset is English (US). If you would rather use another language from the available listing (Danish, German, English (UK), Spanish, French, Italian, Japanese, Norwegian, or Swedish), add a /* at the beginning of the English (US) definition line and erase the /* at the beginning of the line for the language you would like to use.
Step 3
* Define this if you want a To: prompt containing the administrator's * address included for the gripe command.
If you want people to be able to easily modify the userid in the To line when they go to send a comment regarding a Gopher item, set this item. To do so, uncomment it. For example, it is in the file originally as
/* #define MODIFIABLE_GRIPE_TO /* */
You will want to change it to
#define MODIFIABLE_GRIPE_TO
Step 4
/* Define LOCAL_GRIPE_ADMINISTRATOR and use your site's Gopher Administrator * address if you want gripes sent there for Gopher0 servers (or Gopher+ * servers without Admin info for the link).
If you want people to be able to easily send comments to the admin of your Gopher server, set this item. It is in the file originally as
/* #define LOCAL_GRIPE_ADMINISTRATOR "<GopherAdmin@host.domain>" /* */
You will want to uncomment it out, and configure it to match with your system. For example, if I was going to be the Gopher admin, I would set this to be
#define LOCAL_GRIPE_ADMINISTRATOR "<dee@renaissoft.com>"
Or, you could leave it as GopherAdmin and add an alias to your /etc/aliases file. For example, I'd add GopherAdmin: dee
Yes, I didn't touch on a lot of this file. Keep in mind, though, that several pages of it deal with configuration items specific to VMS systems, and you are obviously not running a VMS system.
Compared to configuring Makefile.config and conf.h, actually compiling and installing the server and client can be a piece of cake.
Now that you've configured both Makefile.config and conf.h, you can compile your Gopher client and server. Take your time handling any compilation errors-though there shouldn't be many!
To compile your Gopher server and client, do the following:
Installing your server and client, once you've configured and compiled them, is as simple as typing the following command in the same directory that you did the compilation: make install.
Now that you've got your Gopher server and client installed, you can start setting up its menus and the files you want to offer. Then, you can use the Gopher client you installed at the same time as the server to test it.
The same structure discussion here can apply to arranging your Web site as well, covered in chapter 7, "Installing Web Server Software."
To put your files in place so your Gopher server can offer them, start in your gopher-data directory. This directory acts as your Home (main) Gopher menu, and is the first menu people will see if they tell their client to go to your server. Take a moment to decide how you might want to present your files. Maybe sketch out on paper what you want your directories to look like, or at least far enough to give you a general feel for how you want to lay it out (see figure 8.1).
Fig. 8.1 An example partial Gopher menu tree.
First, let's create the directory menu items. To do this, simply create the directories themselves. Following the example shown in figure 8.1-the first directories I would create inside the gopher-data directory are:
Information
Programs
You can have spaces in file names, so if you want to have a menu item with more than one word, simply create the directory the way you want the menu item to look.
If you put spaces in directory or file names, you may find that when you try to create these directories and files they come out as a list of separate files and directories. Plus, if you try to change into the directory or access the file you get the error Too many arguments. If this is the case, you need to put quotes ("") around the file or directory name so your system understands that it's all in one piece.
Now, to finish making the directory structure in my Gopher server look like the one in the figure, I'll go inside the Information directory and create the directories Products and Services. Then, I'll back up and go inside the Programs directory and create the directories Games and Productivity.
Next, all I need to to is put the files in place. I can quickly write up the three files referenced in figure 8.1 and put them in the proper directories. These should be text files if at all possible so people can easily read them. The following files go into the following directories:
To test your Gopher server, you can use the client you installed at the same time you installed the server. However, first let's test the client itself and make sure it's working. All you need to do is log into an account and type gopher to start the client (see fig. 8.2). If you set CLIENT1_HOST and CLIENT2_HOST, the client will randomly choose between the two. If you only set CLIENT1_HOST, the client will go straight to that Gopher server.
Fig. 8.2 The main menu of the Mother Gopher, the Gopher at the University of Minnesota, itself.
Once you've verified the client is working, take it to your own server. If your server isn't defined as the home server, you can turn your client there by either starting it with gopher <name of your Gopher server> (e.g. gopher gopher.renaissoft.com), or if the client's already open choose o to open a new Gopher server (see fig. 8.3).
Fig. 8.3 Filled in dialog box where you enter the machine and port of the Gopher server you want.
Enter the address of your Gopher server (once again, e.g., gopher.renaissoft.com). Enter the port if it's different than the default of 70. Press Enter to go to the main menu for the new server (see fig. 8.4).
Fig. 8.4 The main menu for my example Gopher server.
From here, wander through your server. Make sure you can enter all of the directories and download all the files. Try it from a non-root account, and ask someone to try it from outside your site as well. If you or someone else has problem accessing items, make sure the permissions are correct (the files are readable).
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation
