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:
The advantage of multiple processes is that legacy applications which are not thread-aware or thread safe can now be run more effectively in the current Enterprise server. However, because all the Netscape extensions are built to support a single-process, threaded environment, they cannot run in the multiprocess mode. WAI, LiveWire, Java, Server-side JavaScript, LiveConnect and the Web Publishing and Search plugins fail on startup if the server is in multiprocess mode. There are two approaches to multithread design:
In the multiprocess design, the server spawns multiple server processes at startup. Each process contains one or more threads (depending on the configuration) which receive incoming requests. Since each process is completely independent, each one has its own copies of global variables, shared libraries, caches, and other resources. Using multiple processes requires more resources from your system. Also, if you try to install an application which requires shared state, it has to synchronize that state across multiple processes. NSAPI provides no helper functions for implementing cross-process synchronization.
To set up multiprocessing and multithreading for your server, follow these steps:
If you aren't running any NSAPI in your server, Netscape recommends using the default settings: one process and many threads. If you are running an application which is not scalable in a threaded environment, Netscape recommends using a few processes and many threads, for example, 4 or 8 processes and 256 or 512 threads per process.
Thread models on HP/UX
Prior to HPUX 10.30, HPUX thread support consisted of DCE threads. The implementation of DCE threads were "user level" threads, which means that they are schedule only in user space. Since the kernel does not know anything about the user threads, these threads are cooperatively scheduled within the context of a single process. This means that on multiprocessor systems, all the DCE threads will only be scheduled on one processor at a time- and this prevents MP scaling. With HPUX 10.30, HPUX introduced its first kernel based threading model (pthreads). Since the kernel has knowledge of these threads, and since the kernel is responsible for scheduling these threads, programs written to the pthreads API can be scheduled on all processors in a multiprocessor system. The current Enterprise Server now uses HP's kernel-level threads.
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.
username:password:group1,group2,group3,...groupn
Or, alternatively, you can:
groups-with-users="yes"
<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. Note that lines are limited to a maximum of 512 characters.
Each directive can take a variable number of parameters, all of which must be lowercase. 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>
Note that device files in a chroot directory that allow access to the raw disk may allow a determined and knowledgeable cracker to access files outside the chroot file tree.
Further, if a cracker succeeds in using a setuid root program to get a shell with superuser permissions inside the chroot tree, they can still read or write to system memory or raw disks by creating device files.
Chroot is used to make the FTP process ftpd more secure. Be sure to acquire a fairly recent version of ftpd. A good source site is ftp.uu.net. The BSD ftpd version has fewer features, but therefore potentially fewer problems than the Washington University (WU) ftpd.
A program wrapper provides additional security for a program by:
Wrapper programs such as tcpd and netad can be used to change to a more secure directory, run chroot, then invoke ftpd. The ftpd process will then be trapped inside the directory tree below the new root. This provides some level of insulation from dangerous software.
The tcpd wrapper is available from ftp.cert.org. Use the tcpd wrapper to run between the Internet daemon inetd and any programs that inetd runs. You can set up rules to have tcpd do the following:
NoteYou 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.If you are inexperienced in Unix system administration, you might want to learn more about Unix before using this feature.
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).
Note
If you choose "Only when Owners match," the server user and the target
file must have the same owner. If, for example, you install the server
as nobody and the target file is owned by root, the soft link is rejected.
Setting this option can cause many links in Web Publisher to fail.
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.
However, with the addition of a number of subsystems to the server in Enterprise 3.0, it was felt that the server should be completely stopped and started for a restart operation, as the most expedient way to be sure that all subsystems were properly initialized. This had several immediate drawbacks. First, it became necessary to reenter the key file password for a secure server during a restart. This was particularly a problem for a secure server with automatic log rotation enabled, since log rotation relies on a server restart operation. Finally, every server configuration change required the server to be completely stopped and started.
The basic idea of uxwdog is to have a lightweight process that keeps around just enough state information to be able to start a new server process during a restart operation, without human intervention. This state consists mainly of any passwords or PINs required to start a secure or Fortezza server, and open file descriptors for sockets on which the server will listen. The socket file descriptors had to be kept around because some of them might be for privileged TCP ports, port 80 for example, which would require a process running as root to bind them. When this is the case, the Admin Server generally runs as root, and starts uxwdog as root, or else an administrator who is running as root executes the server start script. Once uxwdog binds the server listen port(s), it changes its uid to the server uid, often "nobody", and then starts the server process as that uid.
One consequence of this is that NSAPI Init directives always run under the server uid, unlike in Enterprise 3.0 and earlier, where it was possible to have them run as root. This has created some problems in upgrade situations, when a plugin Init function was creating a file during the Init. The file would be owned by root in the older server version, and when installing the plugin in Enterprise 3.01 and later, it would be necessary to change the ownership or protection on the migrated file.
In order to determine on which ports the server listens, uxwdog must read magnus.conf and obj.conf. It does this each time the server is restarted, and verifies that the port numbers have not been changed. If they have, a restart operation is not possible, uxwdog will exit, and the server will have to be manually started. This is also true if security is turned on, the server uid is changed, or the PidLog filename is changed. Likewise, changing certain Fortezza parameters in a Fortezza server (Enterprise 3.5) will require a manual startup.
The restart and stop scripts send SIGHUP and SIGTERM, respectively, to uxwdog. In both cases, uxwdog sends SIGTERM to the ns-httpd process to shut down the server. For a restart operation, uxwdog then creates a new server process, passing it the file descriptors of the listen ports, and any passwords or PINs it has saved.
Prior to Enterprise Server version 3.5.2, if the server process exited or died unexpectedly, uxwdog also exited.
The default behavior of the server watchdog process now automatically restarts the server if the server process should terminate unexpectedly. You can revert to the previous default behavior, which was for the watchdog process to exit if the server terminates unexpectedly. To revert to the original default behavior, set the environment variable, UXWDOG_NO_AUTOSTART, at the beginning of the server start script as follows:
(following the "#!/bin/sh" line):
UXWDOG_NO_AUTOSTART=1; export UXWDOG_NO_AUTOSTARTYou also now have the option to have the watchdog restart the server if the server process calls exit() with a non-zero argument value. This feature is disabled by default, but can be enabled by setting the UXWDOG_RESTART_ON_EXIT environment variable in the server start script as follows:
There may be some cases where wdnotify does not get deleted
when it should, which may cause uxwdog to exit instead of starting
or restarting the server. This can be corrected by manually removing the
wdnotify file from the logs directory.