If your system supports perl, the quickest way to get your server configured is to run the perl script "configure" which is in the main source directory. Do this with the command
perl configureThis script will ask you various questions, like what version of Unix you are using and the path to the directory you want to be the root of your data hierarchy.
Default answers are printed in square brackets [ ] so you can simply press return to enter that value. You can quit at any time by pressing Ctrl-C and nothing should be changed. If you want to try it once to see what the questions are, that is fine.
This script creates two files: "config.h" and "Makefile" which are customized based on the answers you gave. You may rerun this script as many times as you like. The first time you run the script the default values are those in the file config.h.dist. Subsequent times the default values are taken from the most recent config.h you have produced (if it still exists).
An alternative to running this script is to copy the files "Makefile.dist" and "config.h.dist" to "Makefile" and "config.h" respectively and edit them manually. If you want to use some of the features which are not turned on by default like multiple IP interfaces, you will have to edit at least "config.h". I recommend starting with the perl script and getting your server up and running. Then you can go back browse through config.h to see if there are things you want to change. If there are you will have to re-compile but that takes only a few minutes.
Here are some of the questions you will be asked when you run "configure." You will be given a list of supported operating systems and asked to pick the one you are using, e.g. SUNOS, SOLARIS2, AIX, LINUX, etc. You will be asked the complete path name of your data directory. You will also have to enter the names of the access logfile and the error logfile you wish to use (they can be the same file). If you don't want logging or you want to use the system syslog facility (i.e. the -S option) then these should both be defined to be the empty string (i.e. a pair of double quotes with nothing between them like "" ). If you specify the names of these log files then you must make sure that either these two files exist and are writable by the server or that they are files in a directory where the server has permission to create them.
Additional customizations in config.h are possible but should not be needed. These cusomizations require that you manually edit the config.h file. For example, there is a #define DEFAULT_URI line in the config.h file. It is set to "/index.hmtl". This is the document returned in response to a request with only the hostname, (something like http://hostname.edu/ with no file name at the end). You would need to change it if, for example, you wanted to have the default server response be to run a CGI script.
There is also a #define NO_DNS_HOSTNAMES line in config.h which is commented out by default. Uncommenting this line will mean that there will be no hostnames in your log file, just IP addresses. This will reduce the load on your server (but probably not speed up responses since the lookups usually take place after the transaction is complete). Keep in mind that uncommenting this will mean that none of your CGI scripts will get the hostname and also that your access files cannot have hostnames in them, just IP addresses.
You may also customize the file "Makefile" in the top level directory. In particular you should do this if you wish to specify a C compiler other than cc (e.g. gcc) should be used for compiling. Also some systems require that special libraries for sockets, or whatever, be mentioned in the compile command. The configuration script attempts to do this, but I am working from user reports since I do not have access to most of the UNIX variations. If they are incorrect please let me know.
In the top level directory do a "make" to produce the server wn, the standalone version swn and the utility "wndex". This utility is used to produce "index.cache files" for use by the server (it is described below). If the "make" proceeds without problem you should next do a "make install". This will strip the binaries and place them in the top level bin directory or whatever directory you specified when you ran the configure script.
If you specified a log file name or error log file name when you ran the configuration script or edited config.h you will need to make sure that these files exist and that they are writable by the user id under which the server will run. The best way to do this is create the files as root ("touch wn.log"), then change their ownership to the appropriate user ("chown nobody wn.log") and finally set the permissions appropriately ("chmod 644 wn.log"). An alternative is to create a directory in which these files will reside and make sure that the user "nobody" has permission to create files in this directory. Then the server will create the files with proper ownership and permissions.
swn -p port [other options] /path/to/wnroot
where "port" is the number of the port on which you wish the server to run. If this is a non-privileged port (i.e. > 1024) then swn can be run as an ordinary user. However, for privileged ports like 80 you must run the command above as root. If swn is run without the -p option it will use port 80 by default. If swn is run by root then when it starts up it will change its user id to the one set when running the configuration script or by editing the config.h file line where USERID is #defined. Otherwise it will have all the permissions of the user who runs it.
The safest practice is to use the numeric UID of "nobody" for the USERID set in config.h (this is the default) and then start the server as root. [Note: on HPUX and perhaps other systems user "nobody" cannot be used. In this case just create a new user, say www, with the fewest possible privileges and no shell.] The server needs to have root permissions to connect to a socket on a privileged port and listen for requests. But immediately after doing so it will change its user id to that of "nobody" and have minimal access permissions. In this situation the user "nobody" needs to have only read permission to your server data and should not own or have have write permission. In particular "nobody" should not have ownership or write access of the index.cache database file described in the data hierarchy chapter of this guide.
wn 80/tcp
(or replace 80 by the port you wish to use). Then edit the file /etc/inetd.conf and insert the line
wn stream tcp nowait nobody /full/path/for/wn wn
After the last wn you can have optional arguments to turn on logging or use a different data directory. Some inetds limit the number of arguments you may use so I prefer to use a small script in place of wn here. My inetd.conf line looks like
wn stream tcp nowait nobody /full/path/for/wnwrap wnwrapand wnwrap contains only the two lines
#!/bin/sh
exec /full/path/for/wn -t 202 -L /my/log/file /my/WN/root/dir
It is important to run wn as "nobody" (the fifth field in the inetd.conf line above) or some other user with no special 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 USERID and GROUPID and set the values appropriately). It should never be necessary to run wn under inetd as root and to do so would be a serious mistake for maintaining security. Every attempt has been made to make wn 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. (See the security guide).
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. You find the process_id# using the UNIX command ps. If you have never done this before, get someone who has to help you.
Note: To use multiple vanity names for different IP addresses on a single server see the section on multi-homed servers.
There are a few instances, however, where the WN server does use its own hostname. Ideally, in my opinion, the server should do nothing with its hostname and not even need to know it. This is not possible for two reasons. First, the CGI protocol requires the server to pass its hostname to CGI scripts in an environmental variable whenever those scripts are run. Secondly clients often implement redirection so that it cannot handle relative URLs but only complete URLs. (This is a mistake in my view, but one we have to live with.) Thus when a server redirects to another local document it must supply its own hostname. These are the only places WN uses hostname.
For most cases then, WN only uses it hostname when a redirection is done. This happens in several circumstances. The most common is when a request is made for a directory any the trailing '/' is left off of the URL.
So how does WN know its hostname? When you run the "configure" program you are queried for the value you want or you have the option of using a system call at the time the server is run. This value is placed into the config.h header file and compiled into your server. In the file config.h the WN_HOSTNAME value is set by default to the empty string. If this is not changed the server will get its name from the gethostaddr() system call. If this is set to another string that string will be used. If you are using WN as a multi-homed server then you need to set different names for the different IP addresses. This is done in the file wn/vhost.h which you edit to set up the correspondence between IP addresses and root directories.
Now you are ready to test your server installation on this directory. Try it with your favorite HTTP client. The URL should be
http://YourHost/docs/index.html
If you are running swn, the standalone version of WN you will have to use the UNIX ps command to find the process id of the running swn daemon. Then as root you run the command "kill -9 process_id#" where, of course "process_id#" is the process id of swn.
For example, executing the command
swn -L /path2/logfile -l /path2/error.log /path/wnrootwill cause the server to use "logfile" and "error.log" as the logfile and error log respectively. Of course, it is necessary for the server to have write permission to these files and execute permission on the directory containing them.
A good way to achieve this if the server is running as "nobody" is to create the files yourself and change their ownership to the user "nobody." This can be done, for example, with the commands
touch logfileexecuted as root in the directory where the logfile is to reside. The first of these commands creates the file "logfile". The second makes "nobody" the owner and the third gives "nobody" (and no one else except root) permission to read and write this file. You might want to allow others to read, but not write to the logfile, or security of the logfile might not be a concern.
/usr/etc/chown nobody logfile
chmod 600 logfile
Thus a script executed by cron to rotate logfiles might look like
cd /logfile/dirwhere wn.pid is a file containing the processs id of the server created by using the -q option or by specifying this filename when the "configure" script is run. If neither of these has been done the standalone server, swn, will print its process id on standard output when it is run. If you are using wn under inetd there is no need to send the -HUP signal as the server must close this file after each transaction.
mv logfile logfile.old
touch logfile
/usr/etc/chown nobody logfile
chmod 600 logfile
kill -HUP `/bin/cat wn.pid`
/usr/etc/chown maintainer logfile.old
chmod 600 logfile.old
There are two modes which the server can use in writing its logfiles: verbose and "common log format". The verbose mode is essentially the common log format but with the user-agent, referrer, and HTTP cookie of a transaction appended to the line for that transaction as well as better transaction error messages if necessary. The mode is chosen by answering the relevant question when running the configure script before compilation (or by editing config.h).
When the server is invoked with the -v option it will write a log file in the format specified by the value of this option. The legal values for this option are "common", "verbose", and "ncsa". They cause the logfile to be written in the so-called common log format, or WN's verbose format including user agent, referrer and cookies, or in the NCSA extended format which includes referrer and user agent. If this option is not specified the server will default to either the common log format or the WN verbose format depending on which was selected when the "configure" script was run.
The utility V2C can convert verbose log files to log files in the shorter common log format.
If the compilation was successful you can check the server itself by executing it from the command line. If you use the command
wn /full/path/of/root/dirit should run and pause for input. Type the line
GET /<ret>and in response wn should print the raw HTML of the index.html file in your top level directory (perhaps along with a message about not being able to open a log file). If instead you type
GET /docs/overview.html<ret>(and you still have the /docs subdirectory in your top level directory) the overview document should be sent to your screen. 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 wn again with the additional arguments "-L logfile" and then examine the contents of the logfile. Or if you run "wn -L /dev/tty" the log entries will be printed to your screen instead of being put in a file. If the server 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 wn serves must be world readable. More serious errors are put in a separate error log. So you might want to try the command "wn -L file -l file2" and then type the GET requests described above.
If this succeeds you should should run the server for real, either under inetd (as described above) or standalone (with an swn command). In order to use port 80 the server must be started by root. It will then switch to user "nobody". It does this immediately after connecting to port 80, before it does anything else including openning its log file. If you get a message that the server cannot open its log file then either you have specified putting the log file in a directory where user "nobody" does not have permission to create files or you have specified an existing file which the server does not have permission to write. After starting the server a useful test is to telnet to your server at port on which you are running. You should get a connection message and a pause for input. If you get a "Connection refused" message and you are running under inetd, 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 wn binary. If you are using swn this message means that swn is not in fact running.
If you still have problems feel free to ask questions on the WN listserver. There are many helpful people there. But it is a good idea to try the steps above first and to include the relevant logfile messages with your request.