The first thing to do is to make certain that the server software answers requests as the user nobody and that nobody is a not a member of any actual group. For the Web server to auto-start whenever the system boots, it must run as root, since the root user must initiate any process started on boot-up. However, the # User/Group: entry in the httpd.conf file (by default, located in the /usr/local/etc/httpd/conf/ directory) will force any children of the server process (i.e.--all of its responses to requests) to run as the specified user. # User/Group: takes two arguments, User and Group, each on its own line. These default to User nobody and Group #-1. It's not safe to change either value. Resist the urge to experiment.

Next, make sure that the files and subdirectories of the Web server root (by default,/usr/local/etc/httpd/) have the proper permissions and ownership. In a nutshell, the world should have read and execute permission to the cgi-bin, htdocs and icons directories and no other permissions to ServerRoot (as defined in httpd.conf) or to any of its subdirectories.

Now, decide whether you will allow any users you've defined on the Web host machine to set up their own home pages and have the NCSA server automatically serve them. This feature is enabled by default. To disable it, edit the line UserDir public_html in /usr/local/etc/httpd/conf/srm.conf (the default) to instead read UserDir DISABLED.

The access.conf file is where much of the NCSA server's access control configuration is accomplished. By default, it contains only two entries: one each for your cgi-bin script directory and for your document root.

The default values for cgi-bin are usually safe.

The default values for the default document root are set as follows:

     <Directory /usr/local/etc/httpd/htdocs>
     Options Indexes FollowSymLinks
     AllowOverride All

     <Limit GET>
     order allow,deny
     allow from all
     </Limit>

     </Directory>

The Indexes option, if set, allows the NCSA server to generate a directory listing on the fly and send it to a requesting browser. If Indexes is not one of the listed Options, the server will only send a file named index.html in response to a request for a URL (Uniform Resource Locator) which specifies a directory name, rather than a document name. (If index.html doesn't exist in that directory, the server returns a '403 Forbidden!' message to the requesting browser.) Leaving this option unset may inconvenience some users, but it will considerably reduce the opportunity for casual snooping through your directory structure.

The FollowSymLinks option, if set, permits a browser to follow Unix symbolic links, if they are included in a URL or returned by an index request. If you have left the Index option unset, FollowSymLinks is mostly harmless.

The Includes option allows you (and your users) to create documents which perform actions. These actions can be as simple as returning the date the file in question was last modified, or as complex as running a Unix shell script or cgi-bin (Common Gateway Interface-to-Binary) script. If set, this option also requires you uncomment a line in srm.conf defining which files the NCSA server is to treat as what are called parsed files, as follows:

     AddType text/x-server-parsed-html .shtml

Because the Include option allows users to construct documents which allow outsiders to run shell scripts on your Web host, enabling it entails certain potentially serious security risks. On the other hand, for most serious business applications, you will want to be able to run cgi-bin scripts to provide services such as database queries, on-line ordering, providing running counts of accesses to your pages and so on. If your users' home directories share a common parent directory, you can add another <Directory> listing to the end of access.conf to disable the Include option for their personal pages as follows:

     <Directory /*/public_html*>
     Options None
     AllowOverride None

     <Limit GET>
     order mutual-failure
     allow from all
     </Limit>

     </Directory>

The <limit> section of each directory listing is optional, but very useful in controlling access. It first defines which method (GET or PUT) will be limited. Next it defines in which order allow and deny arguments will parsed, (allow, deny or deny, allow or mutual-failure) then lists the servers from which requests will be honored or refused. Listed servers can be defined as DNS or IP addresses and partial addresses are treated as masks for groups of servers (thus, deny from .sun.com would deny access to your server by any of the hosts in Sun Microsystems' network). Both deny and allow will accept ALL as an argument. The end of the <Directory< listing must be defined with a tag.