Once installed, the server
runs constantly, listening for and accepting requests. If your server is
running, you'll see the On icon and its green light (to the left of the
server's name) in the Server Administration page. You can start and stop
the server by clicking the icon. You can also start, restart, and stop
the server from the Server Manager.
Stop shuts down the server completely, interrupting service until it is restarted. If you set the etc/inittab file to automatically restart (using "respawn"), you need to remove the line pertaining to the web server in etc/inittab before shutting down the server; otherwise, the server automatically restarts.
To start or stop the server from the Server Manager:
Note
After you shut down the server, it may take a few seconds for the server to complete its shut-down process and for the status to change to "Off."If your machine crashes or is taken offline, the server stops and any requests it was servicing may be lost.
where seconds represents the number of seconds you want to wait before timing out.
The advantages to configuring this value is that if for some reason you want to wait longer for connections to complete, you can. However, because most servers often have connections open from nonresponsive clients, if you increase the time the server waits, you will almost always have to wait the full time before your server shuts down.
If you are using a version of Unix not derived from System V (such as SunOS 4.1.3), you won't be able to use the inittab file.
Normally, you can't start an SSL-enabled
server with either of these files because the server requires that you
enter a password before starting. Though you can start an SSL-enabled server
automatically if you keep the password in plain text in a file, this practice
is not recommended.
Caution!
Leaving your SSL-enabled server's password in plain text in the server's start script on your system is a large security risk. Anyone who can access the file has access to your SSL-enabled server's password. Consider whether you can afford the security risks before keeping your SSL-enabled server's password in plain text on your system.The server's start script, key pair file, and the key password should be owned by root (or, if a non-root user installed the server, that user account), with only the owner having read and write access to them.
If the security risk is not a concern for you, follow these steps to start your SSL-enabled server automatically:
For example, the edited line might look like this:
echo "MBi12!mo"|./$PRODUCT_BIN -d $PRODUCT_SUBDIR/config $@
The -i option prevents the server from putting itself in a background process.http:2:respawn:server_root/type-identifier/start -i
Replace server_root with the directory where you installed the server, and replace type-identifier with the server's directory.
You need to remove this line before you stop the server.
server_root/type-identifier/startReplace server_root with the directory where you installed the server.
server_root/type-identifier/start
Replace server_root with the directory where you installed the server.
You can use the optional parameters -p and -i at the end of the line:
The -p option starts the server on a specific port number. This overrides the setting in magnus.conf.
The -i option runs the server in inittab mode, so that if the server process is ever killed or crashed, inittab will restart the server for you. This option also prevents the server from putting itself in a background process.
If the server is already running, the start command will fail. You must stop the server first, then use the start command. Also, if the server startup fails, you should kill the process before trying to restart it.
To stop the server manually, log in as root or use the server's user account (if that is how you started the server), and then type the following at the command line:
server_root/type-identifier/stop
The following list explains the server's technical settings:
To view or restore a backup copy of your configuration files:
To get the number of simultaneous requests, the server counts the number of active requests, adding 1 to the number when a new request arrives, subtracting 1 when it finishes the request. When a new request arrives, the server checks to see if it is already processing the maximum number of requests. If it has reached the limit, it defers processing new requests until the number of active requests drops below the maximum amount.
In theory, you could set the maximum simultaneous requests to 1 and still have a functional server. Setting this value to 1 would mean that the server could only handle one request at a time, but since HTTP requests generally have a very short duration (response time can be as low as 5 milliseconds), processing one request at a time would still allow you to process up to 200 requests per second.
However, in actuality, Internet clients frequently connect to the server and then do not complete their requests. In these cases, the server waits 30 seconds or more for the data before timing out. Also, some sites do heavyweight transactions that take minutes to complete. Both of these factors add to the maximum simultaneous requests that are required. If your site is processing many requests that take many seconds, you may need to increase the number of maximum simultaneous requests.
If you need to change the number of maximum simultaneous requests, set the number before starting the server. To reset the number:
DNS causes multiple threads to be serialized when you use DNS services. If you do not want serialization, enable asynchronous DNS. You can enable it only if you have also enabled DNS. Enabling asynchronous DNS can improve your system's performance if you are using DNS.
Note
Turning off DNS lookups on your server has the following consequences: host name restrictions won't work, and hostnames won't appear in your log files. Instead, you'll see IP addresses.You can also specify whether to cache the DNS entries. If you enable the DNS cache, the server can store hostname information after receiving it. If the server needs information about the client in the future, the information is cached and available without further querying. You can specify the size of the DNS cache and an expiration time for DNS cache entries. The DNS cache can contain 32 to 32768 entries; the default value is 1024 entries. Values for the time it takes for a cache entry to expire can range from 1 second to 1 year (specified in seconds); the default value is 1200 seconds (20 minutes).
Note
Normally, you should not change the listen-queue size. The default setting is sufficient in most cases.If you manage a heavily used web site, you should make sure your system's listen-queue size is large enough to accommodate the listen-queue size setting from the Server Manager form. If you do change the listen-queue size, make sure that your system supports the new size. The listen-queue size set from the Server Manager form changes the listen-queue size requested by the server. If the server requests a listen-queue size larger than the system's maximum listen-queue size, the size defaults to the system's maximum.
Setting the listen-queue size too high can degrade server performance. The listen-queue size was designed to prevent the server from becoming overloaded with connections it cannot handle. If your server is overloaded and you increase the listen-queue size, the server will only fall further behind.
Note
Normally, you should not change the persistent connection timeout. The default setting is sufficient in most cases.If you need to change the setting:
Note
Do not put spaces between the file suffixes when you are adding or editing a MIME type. If you put a space between them, you may receive an error or your server may not restart. If this happens, edit your mime.types file to delete the space. The mime.types file is in your server root in the https-identifier/config directory. After you have edited the file, from the Server Manager, use the Apply button to apply your manual changes.
To change the server's location:
You don't need to specify a server user
if you chose a port number greater than 1024 and aren't running as the
root user (in this case, you don't need to be logged on as root
to start the server). If you don't specify a user account here, the server
runs with the user account you start it with. Make sure that when you start
the server, you use the correct user account.
If you don't know how to create a new user on your system, ask your system administrator or consult your system documentation.Even if you need to start the server as the root user, you don't want it to run as root all the time. You want the server to have restricted access to your system resources and run as a nonprivileged user. The user name you enter as the server user should already exist as a normal Unix user account. After the server starts, it runs as this user.
If you want to avoid creating a new user account, you can choose the user nobody or an account used by another HTTP server running on the same host. On some systems, however, the user nobody can own files but not run programs.
To change the server's user account:
If your system administrator has set up a DNS alias for your server, use that alias on the Network Preferences form. If not, use the machine's name combined with your domain name to construct the full hostname.
If you aren't sure that the port number you plan to use is available, look at the /etc/services file on the server machine. Port numbers for the most commonly used network-accessible services are maintained in the file /etc/services.The standard unsecure web server port number is 80; the standard secure web server port number is 443. Technically, the port number can be any port from 1 to 65535. If you aren't running as the root user when you install or start the server, you need to use a port number higher than 1024.
If you have already set up your system to listen to multiple IP addresses and want to use this feature, on the Network Preferences form use the Bind To Address field to tell the server which IP address is associated with this hostname.
You might want to change the way a the server behaves when it gets an error for a specific directory. Instead of sending back the default file, you might want to send a custom error response instead. For example, if a client tries repeatedly to connect to a part of your server protected by access control, you might return an error file with information on how to get an account.
Note
There is no support for LDAP or the 3.0 Netscape user databases in the dynamic configuration files. You should not use dynamic configuration files if you use LDAP. You must use NCSA-style user databases to use .htaccess files. You must use either NCSA-style user databases or Enterprise 2.x DBM- format user databases with .nsconfig files. For more information on user databases, see Managing Netscape Servers.If you already use .nsconfig files, you might want to continue using them. However, Netscape also provides a utility for converting your .nsconfig files to .htaccess files.
Init fn="load-modules" funcs="htaccess-init,htaccess-find" \ shlib="server_root/plugins/htaccess/htaccess.so" Init fn="htaccess-init"These lines load and initialize the module when the server is started. server_root is the path to your server root.
To activate .htaccess file processing for all directories managed by the server, add the PathCheck directive:
PathCheck fn="htaccess-find"to the default server object, which is delimited by:
<Object name="default"> ... </Object>Generally, the directive to activate .htaccess processing should be the last PathCheck directive in the object.
To activate .htaccess file processing for particular server directories, place the PathCheck directive in the corresponding object definition in obj.conf.
If you want to name your .htaccess files
something other than .htaccess, you need to specify the filename
in the PathCheck directive using the following format:
PathCheck fn="htaccess-find" filename="filename"Replace filename with the filename you are using.
After editing the configuration file, stop and start your server. Apply your configuration file changes in the Server Manager by clicking the Apply button. Subsequent accesses to the server will be subject to .htaccess access control in the specified directories.
To restrict write access to .htaccess files, create a configuration style for them, and apply access control to that configuration style. For more information, see "Working with configuration styles" on page 68, and Chapter 6, "Controlling access to your server."
server_root/install/perl server_root/plugins/htaccess/htconvert server_root/ https-server_name/config/obj.confThe script converts all .nsconfig files to .htaccess files, but does not delete the .nsconfig files.
The only AuthType supported is Basic.
<Limit GET POST> order deny,allow deny from all allow from all </Limit> <Limit PUT DELETE> order deny,allow deny from all </Limit> AuthName mxyzptlk.kawaii.com AuthUserFile /server_root/mxyz-docs/service.pwd AuthGroupFile /server_root/mxyz-docs/service.grp
When a request is made for a resource in which dynamic configuration is enabled, the server must search for the configuration files within one or more directories of that resource. This search can be an expensive operation in terms of performance, so the server lets you configure how much flexibility you need, weighing it against the efficiency cost.
You can provide a base directory to the server, in which case the server starts its search for configuration files from the filesystem directory. Alternatively, you can provide no base directory, in which case the server attempts to infer the base directory from the URL. That is, if the requested URL is to a file in the document root, the server starts searching from the document root.
You also specify the name of the configuration file to search for within the base directory.
If you centralize all of your configuration information for the subdirectories of the base directory in the base directory's configuration file, the server is more efficient because it doesn't have to search for configuration files in the subdirectories.
However, you may sometimes want the server to search the subdirectories. If you do, the server searches for .nsconfig files starting from the top level directory and searching downward until reaching the directory in which the referenced resource resides. The server processes .nsconfig files in the order it encounters them. If a top level file restricts a user's access, the server does not give the user access, even though a lower level file might allow access.
The server processes all restrictions based on IP address and DNS entry (RestrictAccess directive) as it finds them in a file. If the server finds a file that denies a user access because of IP address or DNS entry, it stops processing files. The server collects restrictions based on user name (RequireAuth directive) and processes them at the end, unless the request has already been denied because of IP address or DNS entry.
For example, if you selected the base directory inferred from URL translation, selected .nsconfig for your filename, and chose to search subdirectories, the following search would occur.
When a user requests the filesystem path /usr/netscape/suitespot/docs/gfx/icons/logo.gif, instead of searching for /usr/netscape/suitespot/docs/.nsconfig the server would search all of the subdirectories:
/usr/netscape/suitespot/docs/.nsconfig
/usr/netscape/suitespot/docs/gfx/.nsconfig
/usr/netscape/suitespot/docs/gfx/icons/.nsconfig
You can also enter a wildcard pattern of file types you want to disable in directories where dynamic configuration is enabled. To disable CGI programs and parsed HTML, for example, use * (cgi|parsed-html).
<Files PATTERN1>
... directives ...
</Files>
<Files PATTERN2>
... directives ...
</Files>
PATTERN1 and PATTERN2 are wildcard patterns that tell the server which filesystem pathnames to apply the directives to. For example, * would apply the directive to all filesystem pathnames. Any pattern given is first prefixed with the directory containing the configuration file to ensure that the directives are applied only to subdirectories. There can be as many sets of Files directives in the .nsconfig file as you need.
The file can contain blank lines. Lines beginning with # are treated as comments.
Each directive can take a variable number of parameters. The Files directives include:
More than one RestrictAccess can appear in the file. The order in which these lines appear is important; later RestrictAccess lines override earlier ones.
<Files *> ErrorFile reason="Unauthorized" code="401" path="/errors/unauthorized.html" ErrorFile reason="Forbidden" code="403" path="/errors/forbidden.html" ErrorFile reason="Not Found" code="404" path="/errors/notfound.html" ErrorFile reason="Server Error" code="500" path="/errors/server-error.html" RestrictAccess method="(GET|HEAD|POST)" type="allow" ip="*" RestrictAccess method="(GET|HEAD|POST)" type="deny" ip="198.95.251.30" return-code="404" </Files> <Files *.gif> AddType exp=*.gif type=application/octet-stream </Files> <Files *.txt> RequireAuth dbm="server_root/authdb/default" realm=Text userpat="user*" </Files>
NoteIf you are inexperienced in Unix system administration, you might want to learn more about Unix before using this feature.
You should keep the server root outside the server chroot directory. You should have the server use the document root as the chroot directory and turn off the document root feature. Log and configuration files should be stored outside your chroot directory. The server process must be started as root (superuser). Any configuration items related to documents will have to be made relative to the new root directory.
You will not be able to use CGI programs or the exec tag to parse HTML if you use the chroot feature. You can't allow users to have public information directories unless the proper system-shared libraries, binaries, and dummy-parsed files are kept in the chroot directory.
Filesystem links are an easy way to create pointers to documents outside of the primary document directory and anyone can create these links. For this reason you might be concerned that people might create pointers to sensitive files (for example, confidential documents or system password files).
If you type a partial pathname, the server looks for the partial pathname you give as a substring of the incoming request. If you enter nolinks, the server looks for a directory called nolinks in the incoming request; if it finds that directory, it checks all following directories for filesystem links.