Understanding Sun Web Server 7.0 Configuration Files
- 5.1 The magnus.conf File
- 5.2 The server.xml File
- 5.3 The obj.conf File
- 5.4 The mime.types File
- 5.5 Trust Database Files (*.db Files)
- 5.6 The server.policy File
- 5.7 The certmap.conf File
- 5.8 The default.acl File
- 5.9 The default-web.xml File
- 5.10 The login.conf File
- 5.11 The keyfile File
- 5.12 Summary
- 5.13 Self-Paced Labs
This chapter is from the book
This chapter is from the book
This chapter is from the book
CHAPTER 4, “Web Server 7.0 Administration,” introduced the concept of a Web Server configuration. That chapter described that a configuration consists of various components that are used to configure the runtime services of a Web Server 7.0 instance. Included in these components are various configuration files (such as magnus.conf, server.xml, and obj.conf) that are used to specify global variables and define how the server responds to specific events and client requests.
Each Web Server configuration has its own set of files that are located beneath the config directory for the server instance. Table 5.1 provides an overview of the configuration files associated with Web Server 7.0, as well as a brief description of their purpose.
Table 5.1. Web Server 7.0 Configuration Files
|
Filename |
Overview |
|
cert8.db |
Network Security Services (NSS) certificate database. This database stores publicly accessible objects (such as certificates, certificate revocation lists, and S/MIME records) and works with the key3.db database for certificate management. This file is part of the instance’s trust database. |
|
certmap.conf |
Certificate to LDAP DN mapping configuration. |
|
default-web.xml |
Default values for all web applications. |
|
default.acl |
Default access control list (ACL) file for the server instance. This file contains the default rules governing access within the server instance. |
|
key3.db |
NSS private key database. This database stores the private keys generated by the server and works with the cert8.db database for certificate management. This file is part of the instance’s trust database. |
|
keyfile |
File containing usernames and hashed passwords for flat file authentication. |
|
login.conf |
Information for file authentication used by the Java Authentication and Authorization Service (JAAS). |
|
magnus.conf |
Contains the Netscape server application programming interface (NSAPI) plug-in initialization directives and settings that control the way NSAPI plug-ins are run. |
|
mime.types |
Multipurpose Internet mail extension (MIME) type mapping file. This file contains a mapping of file extensions to MIME types and enables the server to determine the content type of a requested resource. |
|
obj.conf |
NSAPI request processing configuration file. This file contains the instructions that tell the Web Server how to handle various HTTP requests from clients. |
|
secmod.db |
NSS PKCS #11 module database. This database stores PKCS #11 module configuration information that is used for various cryptographic modules (for example, hardware accelerator cards). |
|
server.policy |
Policy controlling the access that applications have to resources. |
|
server.xml |
The main instance configuration file, which contains the majority of settings necessary to run the server. |
Configuration files are updated when you perform administrative tasks through the Administration Console or command line interface. Additionally, you can directly edit each configuration file and modify it as appropriate.
This chapter takes a closer look at each configuration file as well as the syntax, usage, and considerations for each file. Although the configuration files in Table 5.1 appear in alphabetical order, the following sections discuss Web Server 7.0’s configuration files in order of importance.
5.1 The magnus.conf File
The magnus.conf file contains the directives necessary to initialize Netscape Server Application Programming Interface (NSAPI) plug-ins. Directives may also contain additional settings that control the way the NSAPI plug-ins are run.
The Web Server consists of functionality that enables you to perform basic request processing immediately after installation. This functionality is provided by server application functions (SAFs) that are part of the Web Server platform.
You can change the way the server responds to client requests by adding or modifying directives in the magnus.conf and obj.conf files. Each directive references a SAF that is used to perform the work during a particular stage of request processing. You can elect to add directives that call SAFs provided by Web Server 7.0, or extend the functionally of the Web Server by creating your own shared libraries (or plug-ins) through the NSAPI. Additionally, you might find it necessary to include functionality that is provided by third-party vendors or by other Sun Microsystems products.
Plug-ins must be registered with the Web Server in the magnus.conf file; this is accomplished with the Init directive. Once registered, you can use the SAFs contained within the plug-ins to customize request processing within the obj.conf.
Example 5.1 demonstrates the use of the Init directive in a customized magnus.conf file.
Example 5.1. Sample magnus.conf File
# # Copyright 2006 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # Init fn="load-modules"now)" Init fn="load-modules" shlib="libfastcgi.so" Init fn="load-modules" shlib="/sun/webserver7/plugins/myplugin/myplugin.so" funcs="myfunc1,myfunc2"
The load-modules SAF is used to load and register a plug-in with the Web Server. This function is most often used to load third-party plug-ins into the Web Server to provide functionality that is not included in the base platform. An example of this might include a plug-in that is used to provide an interface to an application server.
This example specifies three plug-ins that are registered during the initialization process. The libj2eeplugin.so and libfastcgi.so plug-ins are included with Web Server 7.0. The myplugin.so plug-in is a user-created shared library that can be found beneath the /sun/webserver7/plugins/myplugin directory. The shlib parameter specifies the local file system path to the shared library.
The shlib_flags parameter (as seen in the first directive) specifies how a shared library will be loaded into the Web Server process. After it is started, the Web Server process uses the dlopen function to load additional library files into memory. The options of global and now shown in the first directive refer to the dlopen options of RTLD_GLOBAL and RTLD_NOW, respectively. You can read more about these and other options by using the UNIX man command as follows:
# man dlopen
The third Init directive also demonstrates the capability to register specific functions within a particular plug-in (i.e., myfunc1 and myfunc2). The funcs parameter is not specified in the first two directives, so all functions defined within those plug-ins are available for use.
5.1.1 Syntax
Table 5.2 provides the general syntax for the magnus.conf file.
Table 5.2. magnus.conf Syntax
|
Syntax |
Rules |
|
Case Sensitivity |
Items in the magnus.conf file are case-sensitive, including function names, parameter names, parameter values, and pathnames. |
|
Comments |
Hash symbols (#) are used to designate comments in the magnus.conf file. Any text that appears to the right of a hash symbol is ignored by the Web Server. The first four lines of Example 5.1 include comments. |
|
Directives |
Directives in the magnus.conf file either set a value or invoke a SAF. You can add directives or edit existing directives in the magnus.conf file, but be very careful when doing so. Simple mistakes can make the server fail to operate correctly. |
|
There are three Init directives in Example 5.1. Each of these invoke the load-modules SAF to load the appropriate plug-in. The Init directives load and initialize server modules and NSAPI plug-ins. Refer to the Sun Java System Web Server 7.0 NSAPI Developer’s Guide for a complete list of directives available in the magnus.conf file. |
|
|
Directive Parameters |
For predefined SAFs, the number and names of parameters depend on the function. The order of parameters on the line is not important. |
|
Path Names |
Always use forward slashes (/) rather than backslashes (\) in path names, even on the Windows platform. A backslash character is used to escape the character that follows it. |
|
Quotation Marks |
Quotation marks (") are required around the value strings only when there is a space in the string; otherwise, they are optional. Each open quotation mark must be matched by a closed quotation mark. |
|
Spacing |
Directives in the magnus.conf file appear on their own line. You may continue long directives on the next line by beginning the next line with a space or tab. Spaces are not allowed before or after the equal (=) sign that separates a name and value. Spaces are not allowed at the end of a line or on a blank line. Line continuation is demonstrated for the first and third directives in Example 5.1. The second line for both of these directives begins with a space. |
5.1.2 Context
An Administration Node may contain multiple configurations that have been deployed to the node by the Administration Server. These deployed configurations are called instances. Each instance can contain only one magnus.conf file; therefore, there is a one-to-one correspondence between an instance and the magnus.conf file. The directives defined within the magnus.conf file apply to the entire server instance and therefore any virtual servers defined within that instance.
5.1.3 Modifications
Some changes made through the Administration Console or the command line interface update the magnus.conf file. If this file is updated as a result of changes made through either of these two interfaces, you must deploy the updated configuration before the changes are reflected on the appropriate Administration Node(s).
The magnus.conf file is read when the instance is started; therefore, any changes made to the magnus.conf file require a server restart for the changes to take effect. The Administration Console and command line interface detect changes to the magnus.conf file during the deployment process. If you use these tools to deploy the new configuration, you are prompted to restart the instance. If you directly edit the magnus.conf file, you need to restart the sever on your own.
The magnus.conf file is validated at start-up time. Errors found within the file might prevent the server from starting or processing requests properly.