![]() |
NSAPI Programmer's Guide |
Chapter 8 Virtual Server Configuration Files
The server.xml file configures virtual servers. A master file, server.dtd, determines the format and content of the server.xml file. This chapter describes both these files and contains the following sections:
The server.dtd File
Elements in server.dtd and server.xml
The server.dtd File
The server.dtd file defines the various elements that the server.xml file can contain and the attributes these elements can have. The server.dtd file is located in the server_root/server_id/config directory.
Note Do not edit the server.dtd file. Its contents change only with new versions of iPlanet Web Server.
For example, the following code defines the VSCLASS (or virtual server class) element. The first line specifies that a VS element can contain VARS, VS, or QOSPARAMS elements (if this element could not contain other elements, you would see EMPTY instead of a list of element names in parentheses). The remaining lines specify that a VSCLASS element can contain id, connections, objectfile, or rootobject attributes, but only the id attribute is required.
<!ELEMENT VSCLASS (VARS?,VS*,QOSPARAMS?)>
<!ATTLIST VSCLASS
id ID #REQUIRED
objectfile CDATA #IMPLIED
rootobject CDATA #IMPLIED
acceptlanguage (yes|no|on|off|1|0) #IMPLIED
Labels such as ID and CDATA are XML data types. For more information about XML, see the XML specification at:
The server.xml File
The server.xml file configures the addresses and ports that the server listens on and assigns virtual servers to these listen sockets. The encoding is UTF-8 to maintain compatibility with regular UNIX text editors. The server.xml file is located in the server_root/https-server_id/config directory.
Here is a simple server.xml file. It contains two listen sockets (LS), two virtual server classes (VSCLASS), and three virtual servers (VS).
<?xml version="1.0" encoding="UTF-8"?>
<!-- declare any variables to be used in the server.xml file in the ATTLIST below -->
<!DOCTYPE SERVER SYSTEM "server.dtd" [
<!ATTLIST VARS
docroot CDATA #IMPLIED
adminusers CDATA #IMPLIED
webapps_file CDATA #IMPLIED
webapps_enable CDATA #IMPLIED
accesslog CDATA #IMPLIED
user CDATA #IMPLIED
group CDATA #IMPLIED
chroot CDATA #IMPLIED
dir CDATA #IMPLIED
nice CDATA #IMPLIED
>
]>
<SERVER legacyls="ls1">
<VARS accesslog="/iws60/https-server.iplanet.com/logs/access"/>
<LS id="ls1" ip="1.1.1.1" port="80" security="off"
acceptorthreads="1">
<CONNECTIONGROUP id="group1" matchingip="default"
servername="server.iplanet.com"
defaultvs="server.iplanet.com"/>
</LS>
<LS id="ls2" ip="any" port="80" security="off"
acceptorthreads="1">
<CONNECTIONGROUP id="group2" matchingip="default"
servername="server2.iplanet.com"
defaultvs="server2.iplanet.com"/>
</LS>
<MIME id="mime1" file="mime.types" />
<ACLFILE id="acl1"
file="/iws60/httpacl/generated.https-server.iplanet.com.acl" />
<VSCLASS id="defaultclass" objectfile="obj.conf"
rootobject="default" >
<VARS docroot="/iws60/docs" />
<VS id="server.iplanet.com" connections="group1" mime="mime1"
aclids="acl1">
<VARS webapps_file="web-apps.xml" webapps_enable="on" />
<USERDB id="default" database="default" />
</VS>
</VSCLASS>
<VSCLASS id="class2" objectfile="class2.obj.conf"
rootobject="default" >
<VARS docroot="/iws60/docs/class2" />
<VS id="server2.iplanet.com" connections="group2"
mime="mime1" aclids="acl1">
<VARS webapps_file="web-apps.xml" webapps_enable="on" />
<USERDB id="default" database="default" />
</VS>
<VS id="acme.com" connections="group2"
mime="mime1" aclids="acl1">
<VARS docroot="/iws60/docs/class2/acme"
webapps_file="web-apps.xml" webapps_enable="on" />
<USERDB id="default" database="default" />
</VS>
</VSCLASS>
</SERVER>
If no virtual server (VS) can be found that matches an IP address or Host header, requests are processed using the default VS defined in the CONNECTIONGROUP. This VS could be made to output a customized error message, or even handle the request using a special document root.
Variables
Defining variables for use in the obj.conf file is not required, but it is sometimes useful. The following code defines and uses a docroot variable:
<?xml version="1.0" encoding="UTF-8"?>
<!-- declare any variables to be used in the server.xml file in the ATTLIST below -->
<!DOCTYPE SERVER SYSTEM "server.dtd" [
<!ATTLIST VARS
docroot CDATA #IMPLIED
...
>
]>
...
<VS id="acme.com" connections="group2"
mime="mime1" aclids="acl1">
<VARS docroot="/iws60/docs/class2/acme"
webapps_file="web-apps.xml" webapps_enable="on" />
<USERDB id="default" database="default" />
</VS>
...
This variable allows different document root directories to be assigned for different virtual servers. The variable can then be used in the obj.conf file. For example:
NameTrans fn=document-root root="$docroot"
Using this docroot variable saves you from having to define document roots for virtual server classes in the obj.conf files. It also allows you to define different document roots for different virtual servers within the same virtual server class.
Format of a Variable
A variable is found when the following regular expression matches:
This expression represents a $ followed by one or more alphanumeric characters. A delimited version ("${VARS}") is not supported. To get a regular $ character, use $$ in files to have variable substitution.
The id Variable
A special variable, id, is always available within a VS element and refers to the value of the id attribute. It is predefined and cannot be overridden. The id attribute uniquely identifies a virtual server. For example:
<VARS
docroot="/export/$id"
/>
If the id attribute of the containing VS is myserver, the docroot variable is set to the value /export/myserver.
Variables Used in the Interface
The following variables are used by the Administration Server, Server Manager, Class Manager, and Virtual Server Manager. Unlike the $id variable, they are not predefined in the server, and they can be overridden.
The document root of the virtual server. Typically evaluated as the value of the document-root parameter in the obj.conf file.
The path and name of the web application configuration file, which is usually web-apps.xml. For more information about web-apps.xml, see the Programmer's Guide to Servlets for iPlanet Web Server.
A flag that indicates whether web applications are enabled for a VS. Allowed values are on and off. If the webapps_file variable has a value for a VS, this variable need not be defined and is assumed to be on.
The value of the user parameter of the send-cgi SAF.
The value of the group parameter of the send-cgi SAF.
The value of the chroot parameter of the send-cgi SAF.
The value of the dir parameter of the send-cgi SAF.
The value of the nice parameter of the send-cgi SAF.
Variable Evaluation
Variables are evaluated when generating specific objset for individual virtual servers.
Evaluation is recursive: variable values can contain other variables. For example:
...
<SERVER>
<VARS docrootbase = "/export" />
...
<VSCLASS ...>
<VARS docroot = "$docrootbase/nonjava/$id" />
...
</VSCLASS>
<VSCLASS ...>
<VARS docroot = "$docrootbase/java/$id" />
...
</VSCLASS>
...
</SERVER>
...
Variables lower in the tree override variables from above. For example, it is possible to set a variable for a class of virtual servers and override it with a definition of the same variable in an individual virtual server.
Using the Server Manager and Class Manager
You can add virtual server classes and virtual servers to iPlanet Web Server through the Server Manager and Class Manager interface, as described in the iPlanet Web Server Administrator's Guide.
Elements in server.dtd and server.xml
This section describes the XML elements in the server.dtd and server.xml files. Subelements must be defined in the order in which they are listed.
Defines a server. There can only be one of this element in a server.xml file.
Subelements: VARS, LS, MIME, ACLFILE, VSCLASS, QOSPARAMS
Defines variables that can be given values in server.xml and referenced in obj.conf. "Variables". For a list of variables commonly defined in server.xml, see "Variables Used in the Interface".Variables Used in the Interface
(optional) The socket family type. A socket family type cannot begin with a number.
When you create a secure listen socket in the server.xml file, Security must be turned on in magnus.conf. When you create a secure listen socket in the Server Manager, security is automatically turned on globally in magnus.conf. A listen socket name cannot begin with a number.
IP address of the listen socket. Can be in dotted-pair or IPv6 notation. Can also be any for INADDR_ANY. Configuring a listen socket to listen on any is required if more than one CONNECTIONGROUP is configured to it.
Port number to create the listen socket on. Legal values are 1 - 65535. On Unix, creating sockets that listen on ports 1 - 1024 requires superuser privileges. Configuring an SSL listen socket to listen on port 443 is recommended. Two different IP addresses can't use the same port.
(optional) Determines whether the listen socket runs SSL. Legal values are on, off, yes, no, 1, 0. The default is no. You can turn SSL2 or SSL3 on or off and set ciphers using an SSLPARAMS object in a CONNECTIONGROUP object.
The Security setting in the magnus.conf file globally enables or disables SSL by making certificates available to the server instance. Therefore, Security in magnus.conf must be on or security in server.xml does not work. For more information, see Chapter 7 "Syntax and Use of magnus.conf."
(optional) Number of acceptor threads for the listen socket. The recommended value is the number of processors in the machine. The default is 1, legal values are 1 - 1024.
(optional) The socket family type. The default is inet, legal values are inet, inet6, and nca. Use the value inet6 for IPv6 listen sockets. When using the value of inet6, IPv4 addresses will be prefixed with ::ffff: in the log file. Specify nca to make use of the Solaris Network Cache and Accelerator.
(optional) Determines whether the listen socket and the accepted socket are put in to blocking mode. Use of blocking mode may improve benchmark scores. Legal values are on, off, yes, no, 1, 0. The default is no.
Blocking mode sockets should not be used in real world deployments. Use of blocking mode sockets precludes dynamic reconfiguration and exposes the server to denial of service attacks.
Defines a group of connection properties to which you can assign virtual servers. See "Virtual Server Selection for Request Processing" for more information.
Defines SSL parameters of a connection group.
An SSLPARAMS element is required inside, and only allowed inside, a CONNECTIONGROUP element contained by a listen socket that has its security attribute set to on.
The most common way that the server determines the MIME type of a requested resource is by invoking the type-by-extension directive in the ObjectType section of the obj.conf file. The type-by-extension function does not work if no MIME element has been defined in the SERVER element.
Internal name for the MIME types listing. Used in a VS element to define the MIME types used by the virtual server. The MIME types name cannot begin with a number.
(required if no TYPE subelements are present; otherwise optional) The name of a MIME types file. For information about the format of this file, see Appendix B "MIME Types."
References one or more ACL files.
Defines a virtual server class.
Subelements: VARS, VS, QOSPARAMS
Subelements: VARS, QOSPARAMS, USERDB
Defines quality of service parameters of a SERVER, VSCLASS, or VS.
Attributes of the SERVER element activate the quality of service features. In addition, the qos-handler and qos-error SAFs must be included in the obj.conf file.
For more information, see the Performance Tuning, Sizing, and Scaling Guide for iPlanet Web Server.
Defines the user database used by the virtual server.
See "User Database Selection" for more information about how a user database is selected for a given virtual server.
Virtual Server Selection for Request Processing
Before the server can process a request, it must accept the request via a listen socket, then direct the request to the correct connection group and virtual server. This section discusses how the virtual server is determined.
After the virtual server is determined, the server executes the obj.conf file for the virtual server class to which the virtual server belongs. For details about how the server decides which directives to execute in obj.conf, see "Flow of Control in obj.conf.".
A connection group is first selected as follows:
If the listen socket is configured to listen on a particular IP address, it can contain only one connection group, and that group is selected.
If the listen socket is configured to listen on any, the IP address to which the client connected is matched to the matchingip attribute of a connection group contained by that listen socket. If no matchingip attribute matches, the connection group with matchingip=default is selected. A virtual server is then selected as follows:
If the connection group is configured to only a default virtual server, that virtual server is selected.
If the connection group has more than one virtual server configured to it, the request Host header is matched to the urlhosts attribute of a virtual server. If no Host header is present or no urlhosts attribute matches, the default virtual server for the connection group is selected. If a virtual server is configured to an SSL listen socket, its urlhosts attribute is checked against the subject pattern of the certificate at server startup, and a warning is generated and written to the error log if they don't match.
User Database Selection
A USERDB object selects a user database for the containing virtual server. How this selection occurs depends on the virtual server's ACL file and the dbswitch.conf file.
The ACL file format is unchanged from previous iPlanet Web Server versions. However, the following changes have been made in iPlanet Web Server 6.0:
Virtual servers in server.xml reference ACL files. The magnus.conf file no longer references ACL files.
The ACL file's database attribute does not map to a dbswitch.conf entry directly, but instead maps to an id attribute of a USERDB element. The database attribute of the USERDB element then maps to a dbswitch.conf entry. This extra layer between the ACL file and the dbswitch.conf file gives the server administrator full control over which databases virtual server administrators and users have access to. iPlanet Web Server 6.0 introduces the following changes to the dbswitch.conf file and LDAP databases:
The base DN in the LDAP URL in dbswitch.conf defines a root object for all further DN specifications. So, for most new installations, it can be empty, because the final base DN is determined in other ways -- either through a DC tree lookup or an explicit "basedn" value in the USERDB tag.
A new dbswitch.conf attribute for LDAP databases, dcsuffix, defines the root of the DC tree. This root is relative to the base DN in the LDAP URL. You can use dcsuffix if the database is schema compliant. Requirements for schema compliance are listed in "The iPlanet LDAP Schema." A user database is selected for a virtual server as follows:
If a VS has no USERDB subelement, user- or group-based ACLs fail.
When no database attribute is present in a virtual server's ACL definition, the VS must have a USERDB subelement with an id attribute of default. The database attribute of the USERDB then points to a database in dbswitch.conf. If no "database" attribute is present, "default" is used.
If an LDAP database is schema compliant, the base DN of the access is computed using a DC tree lookup of the servername attribute of the CONNECTIONGROUP. The DC tree lookup is based at the dcsuffix DN. The result must contain an inetDomainBaseDN attribute that contains the base DN. This base DN is taken as is and is not relative to any of the base DN values.
If the basedn attribute of the USERDB element is not present and the database is not schema compliant, the accesses happen relative to the base DN in the dbswitch.conf entry, as in previous iPlanet Web Server versions.
The iPlanet LDAP Schema
You can use the dcsuffix attribute in the dbswitch.conf file if your LDAP database meets the requirements outlined in this section.
The subtree rooted at an ISP entry (for example, o=isp) is called the convergence tree. It contains all the directory data related to organizations (customers) served by an ISP.
The subtree rooted at o=internet is called the domain component tree or dc tree. It contains a sparse DNS tree with entries for the customer domains served. These entries are links to the appropriate location in the convergence tree where the data for that domain is located.
The directory tree may be single rooted, which is recommended (for example, o=root may have o=isp and o=internet under it), or have two separate roots, one for the convergence tree and one for the dc tree.
The Convergence Tree
The top level of the convergence tree must have one organization entry for each customer (or organization), and one for the ISP itself.
Underneath each organization, there must be two organizationalUnit entries: ou=People and ou=Groups. A third, ou=Devices, can be present if device data is to be stored for the organization.
Each user entry must have a unique uid value within a given organization. The namespace under this subtree can be partitioned into various ou entries that aggregate user entries in convenient groups (for example, ou=eng, ou=corp). User uid values must still be unique within the entire People subtree.
User entries in the convergence tree are of type inetOrgPerson. The cn, sn, and uid attributes must be present. The uid attribute must be a valid e-mail name (specifically, it must be a valid local-part as defined in RFC822). It is recommended that the cn contain name initial sn. It is recommended that the RDN of the user entry be the uid value. User entries must contain the auxiliary class inetUser if they are to be considered enabled for service or valid.
User entries can also contain the auxiliary class inetSubscriber, which is used for account management purposes. If an inetUserStatus attribute is present in an entry and has a value of inactive or deleted, the entry is ignored.
Groups are located under the Groups subtree and consist of LDAP entries of type groupOfUniqueNames.
The Domain Component (dc)Tree
The dc tree contains hierarchical domain entries, each of which is a DNS name component.
Entries that represent the domain name of a customer are overlaid with the LDAP auxiliary class inetDomain. For example, the two LDAP entries dc=customer1,dc=com,o=Internet,o=root and dc=customer2,dc=com,o=Internet,o=root contain the inetDomain class, but dc=com,o=Internet,o=root does not. The latter is present only to provide structure to the tree.
Entries with an inetDomain attribute are called virtual domains. These must have the attribute inetDomainBaseDN filled with the DN of the top level organization entry where the data of this domain is stored in the convergence tree. For example, the virtual domain entry in dc=cust2,dc=com,o=Internet,o=root would contain the attribute inetDomainBaseDN with value o=Cust2,o=isp,o=root.
If an inetDomainStatus attribute is present in an entry and has a value of inactive or deleted, the entry is ignored.
Previous Contents Index DocHome Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated April 12, 2002