Complete Contents
About This Guide
Chapter 1 Introduction to iPlanet Web Server
Chapter 2 Administrating iPlanet Web Servers
Chapter 3 Setting Administration Preferences
Chapter 4 Managing Users and Groups
Chapter 5 Working with Server Security
Chapter 6 Managing Server Clusters
Chapter 7 Configuring Server Preferences
Chapter 8 Understanding Log Files
Chapter 9 Using SNMP to Monitor Servers
Chapter 10 Configuring the Server for Performance
Chapter 11 Extending Your Server with Programs
Chapter 12 Working with Configuration Styles
Chapter 13 Managing Server Content
Chapter 14 Controlling Access to Your Server
Chapter 15 Configuring Web Publishing
Chapter 16 Using Search
Appendix A HyperText Transfer Protocol
Appendix B ACL File Syntax
Appendix C Internationalized iPlanet Web Server
Appendix D Server Extensions for Microsoft FrontPage
Appendix E iPlanet Web Server User Interface
Glossary
Index
Previous Next Contents Index Bookshelf


Chapter 13 Managing Server Content

You can use the Server Manager to help manage your server's content. You create HTML pages and other files such as graphics, text, sound, or video, and then you store those files on your server. When clients connect to your server, they can view your files provided they have access to them. This chapter describes how you can configure and manage your server's content.

This chapter contains the following sections:


Changing the Primary Document Directory
The primary document directory or document root is the central directory where you store all the files you want to make available to remote clients. You specified a primary document directory when you installed the iPlanet Web Server software. This section describes how to change the primary document directory from what you specified in the installation process.

The primary document directory provides an easy way to restrict access to the files on your server. It also makes it easy to move your documents to a new directory (perhaps on a different disk) without changing any of your URLs because the paths specified in the URLs are relative to the primary document directory.

For example, if your document directory is C:\Netscape\server4\docs, a request such as http://www.mozilla.com/products/info.html tells the server to look for the file in C:\Netscape\Server4\docs\products\info.html. If you change the document root (that is, you move all the files and subdirectories), you only have to change the document root that the server uses, instead of mapping all URLs to the new directory or somehow telling clients to look in the new directory.

To set your server's primary document directory, use The Primary Document Directory Page in the Server Manager.

Note. Each server instance should have its own primary document directory. If server instances share primary document directories, users could simultaneously modify a document without knowing it.


Setting Additional Document Directories
Most of the time, you keep all of your documents in the primary document directory. Sometimes, though, you may want to serve documents from a directory outside of your document root. You can do this by setting additional document directories. By serving from a document directory outside of your document root, you can let someone manage a group of documents without giving them access to your primary document root.

To add an additional document directory you first need to choose the URL prefix to map. Clients send this URL to the server when they want documents. Next, you specify the directory to map those URLs to. Finally, you might want to use an existing configuration style to specify how this directory should be configured.

Unix/Linux: If you expect web publishing users to publish documents to a directory, you need to set the Unix/Linux file permissions to give them write access to that directory. You should also disable write permissions for directories you do not want them to publish to.

To add additional document directories, use The Additional Document Directories Page in the Server Manager.

By default, the server has several additional document directories. They have the following prefixes:

You should restrict access to these directories so that users cannot write to them. A sample ACL for the /publisher directory would be:


Customizing User Public Information Directories (Unix/Linux)
Sometimes users want to maintain their own web pages. You can configure public information directories that let all the users on your server create home pages and other documents without your intervention.

Another way to do this is to create a URL mapping to a central directory that all of your users can modify.

With this system, clients can access your server with a certain URL that the server recognizes as a public information directory. For example, suppose you choose the prefix ~ and the directory public_html. If a request comes in for http://www.iplanet.com/~jdoe/aboutjane.html, the server recognizes that ~jdoe refers to a users' public information directory. It looks up jdoe in the system's user database and finds Jane's home directory. The server then looks at ~/jdoe/public_html/aboutjane.html.

To configure your server to use public directories, you need to choose a user URL prefix. The usual prefix is ~ because the tilde character is the standard Unix/Linux prefix for accessing a user's home directory. Next, you need to choose the subdirectory in the user's home directory where the server looks for HTML files. A typical directory is public_html.

The server needs to know where to look for a file that lists users on your system. The server uses this file to determine valid usernames and to find their home directories. If you use the system password file for this purpose, the server uses standard library calls to look up users. Alternatively, you can create another user file to look up users. You can specify that user file with an absolute path.

Each line in the file should have this structure (the elements in the /etc/passwd file that aren't needed are indicated with *):

Restricting Content Publication
In some situations a system administrator may want to restrict what user accounts are able to publish content via User Document Directories. This can easily be accomplished by adding a trailing slash to the user's home directory path in the /etc/passwd file:

becomes:

When this modification is made, iPlanet Web Server will not serve pages from this user's directory. The browser requesting the URI receives a "404 File Not Found" error and a 404 error will be logged to the web server access log. No error will be logged to the errors log.

If, at a later time, the system administrator decides to allow this user to publish content the trailing slash should be removed from the /etc/passwd entry followed by restarting the web server.

Loading the Entire Password File on Startup
You also have the option of loading the entire password file on startup. If you choose this option, the server loads the password file into memory when it starts, making user lookups much faster. If you have a very large password file, however, this option can use too much memory.

Using Configuration Styles
Finally, you can apply a configuration style for the server to control access to directories from public information directories. This prevents users from creating symbolic links to information you do not want made public.

To set up user directories, use The User Document Directories Page (Unix/Linux) in the Server Manager.


Enabling Remote File Manipulation
When you enable remote file manipulation, clients are able to upload files, delete files, create directories, remove directories, list the contents of a directory, and rename files on your server. The file obj.conf in the directory server_root/https-serve-id/config contains the commands that are activated when you enable remote file manipulation. By activating these commands, you allow remote browsers to change your server's documents. You should use access control to restrict write access to these resources to prevent unauthorized tampering.

Note. When you enable remote file manipulation, you need to disable Web Publishing functions on your server. When you use Web Publishing, you need to disable remote file manipulation. The two sets of functions cannot operate simultaneously. You can use both remote file manipulation and web publishing functions by manually setting the function to be called for each individual remote method invocation. However, proceed with caution as mixing the functions can affect the server's web publishing state.

Unix/Linux: You must have the correct permissions for your files or this function will not work; that is, the document root user must be the same as the server user.

To enable remote file manipulation, use The File Manipulation Page in the Server Manager.


Configuring Document Preferences
You use the Document Preferences page to set document preferences. This section discusses these topics:

Entering an Index Filename
If a document name is not specified in the URL the server automatically displays the index file. The default index files are index.html and home.html. If more than one index file is specified, the server looks in the order in which the names appear in this field until one is found. For example, if your index filenames are index.html and home.html, the server looks for index.html and if it doesn't find it looks for home.html.

To enter an index filename, edit the Index Filenames field in The Document Preferences Page of the Server Manager.

Selecting Directory Indexing
In your document directory, you'll probably have several subdirectories. For example, you might create a directory called products, another called people, and so on. It's often helpful to let clients access an overview (or index) of these directories.

The server indexes directories by searching the directory for an index file called index.html or home.html, which is a file you create and maintain as an overview of the directory's contents. (Note that these defaults are configurable for the whole server, so your server's files may vary. For more information, see the previous section, Entering an Index Filename). You can specify any file as an index file for a directory by naming it one of these default names, which means you can also use a CGI program as an index if CGI is activated.

If an index file isn't found, the server generates an index file that lists all the files in the document root.

To select directory indexing, use The Document Preferences Page in the Server Manager.

Warning. If your server is outside the firewall, turn off directory indexing as well as web publishing (from The Web Publishing State Page) to ensure that your directory structure, filenames, and web publishing features are not accessible.

Specifying a Server Home Page
When users first access your server, they usually use an URL such as http://www.mozilla.com/. When the server receives a request for this document, it returns a document called a home page. Usually, this file has general information about your server and links to other documents.

By default, the server finds the index file specified in the Index Filename field in the Document Preferences page and uses that for the home page. However, you can also specify a file to use as the home page in The Document Preferences Page of the Server Manager. For more information, see the online help.

Specifying a Default MIME Type
When a document is sent to a client, the server includes a section that identifies the document's type, so the client can present the document in the right way. However, sometimes the server can't determine the proper type for the document because the document's extension is not defined for the server. In those cases, a default value is sent. For information about maintaining your server's MIME types, see The Global MIME Types Page.

The default is usually text/plain, but you should set it to the type of file most commonly stored on your server. Some common MIME types include the following:

To specify a default MIME type, use The Document Preferences Page of the Server Manager. For more information, see the online help.

Parsing the Accept Language Header
When clients contact a server using HTTP 1.1, they can send header information describing the languages they accept. You can configure your server to parse this language information.

For example, if you store documents in Japanese and English, you could choose to parse the accept language header. When clients that have Japanese as the accept language header contact the server, they receive the Japanese version of the page. When clients that have English as the accept language header contact the server, they receive the English version.

If you do not support multiple languages, you should not parse the accept language header.

For more information on using the accept language header, see the section Using the Accept Language Header.

To parse the accept language header, use The Document Preferences Page in the Server Manager.


Setting Up Hardware Virtual Servers
A hardware virtual server is a way to have your server respond to multiple IP addresses without installing multiple servers. With hardware virtual servers you map multiple IP addresses to multiple document roots. For example, if you have two IP addresses, you could map the first IP address to one document root and the second IP address to a second document root. iPlanet Web Server can respond to up to 256 IP addresses.

Note. If you are using more than 100 hardware virtual servers, you should use the method described in the section Setting Up Hardware Virtual Servers for ISPs for setting up hardware virtual servers.

Hardware virtual servers share the same server configuration information. For example, if you turn on encryption for one hardware virtual server, any other hardware virtual servers you create would also have encryption turned on.

If you need servers that respond to different IP addresses and require that they have separate configuration information, install separate instances of the server with specific IP addresses. Alternatively, you can also configure multiple hardware virtual servers on the same IP address by assigning different port numbers for each hardware virtual server. For more information, see Adding a Server: Running Multiple Servers.

Unix/Linux. Before you set up hardware virtual servers, make sure you specified a specific bind-to-address for your server in the Network Settings page (from the iPlanet Web Server, choose Server Preferences and then click Network Settings). If you left the Bind To Address field blank, you may experience errors when using hardware virtual servers. If you are an ISP using hardware virtual servers, the bind-to-address should be your main IP address.

You can set up hardware virtual servers through The Hardware Virtual Servers Page in the Server Manager. For more information, see the online help.


Setting Up Hardware Virtual Servers for ISPs
ISPs that need to support more than 256 IP addresses or that want the server to use less memory can use the ISP-version of the hardware virtual server function. As with default hardware virtual servers (discussed in the previous section), ISP-version hardware virtual servers allow you to configure your server to respond to multiple IP addresses without installing multiple servers, but you can configure your server to support an arbitrary number of IP addresses.

ISP-version hardware virtual servers share the same server configuration information. For example, if you turn on encryption for one hardware virtual server, any other hardware virtual servers you create would also have encryption turned on. If you need servers that respond to different IP addresses and require that they have separate configuration information, install separate instances of the server with specific IP addresses. For more information, see Changing Network Settings.

For HP servers, the number of virtual servers must work well with the max_thread_proc entry in the HP-UX kernel and RqThrottle. Since threads are never "released," but moved to another pool, the number of threads used can get quite high when using hardware virtual servers in the object model. For more information, see About RqThrottle (Maximum Simultaneous Connections).

Note. If you set up this hardware virtual server function, make sure that the Bind to Address field in the Network Settings page is blank (choose Server Preferences and click Network Settings).

This section includes the following topics:

To Set Up Hardware Virtual Servers For an ISP
To set up hardware virtual servers for an ISP, perform the following steps:

  1. Uncomment the line for setting up hardware virtual servers for an ISP in the index.1st file in server_root/bin/https/httpadmin/html directory.

  2. From the Server Manager, choose the Content Management tab.

  3. Click Hardware Virtual Servers.

  4. Enter the server's IP address in the IP field.

  5. Enter the primary document directory in the Doc Root field, and click OK.

  6. Click Apply in the top right portion of the Server Manager to apply your changes.
To Edit a Server Instance
To edit a server instance, perform the following steps:

  1. Click Edit on the line for the server instance you want to edit.

  2. On The Hardware Virtual Servers Page, enter the new IP address and document root, anc click OK.

  3. Click Apply in the top right portion of the Server Manager to apply your changes.
To Remove a Server Instance
To remove a server instance, perform the following steps:

  1. Click Remove on the line for the server instance you want to remove.

  2. Click OK in the confirmation dialog box.

  3. Click Apply in the top right portion of the Server Manager to apply your changes.
The ISP-hardware virtual servers are listed in the virtual.conf configuration file. This file lists the IP addresses you entered through the Server Manager and the document root to which they apply.

You can return to using the default hardware virtual server function, by performing the following steps:

  1. From the Server Manager, choose Content Management tab.

  2. Click Hardware Virtual Servers.

  3. Click No to deactivate the ISP-version hardware virtual server function, then click OK.

  4. Click Save and Apply.
Migrating Hardware Virtual Server Configuration Files
If you run multiple IP addresses using the obj.conf file, you may have restrictions using virtual servers. For better reliability, you can migrate from the obj.conf file to the virtual.conf file by running the following script:

When you do this, the executable removes all the NameTrans directives, for individual hardware virtual servers, from the obj.conf file that corresponds to the config directory server_root/http-server-id, and replaces them with corresponding directives in a virtual.conf file, located in the same directory. It also references the virtual.conf file from the magnus.conf. file in the server_root/https-server-id/config/ directory, and removes addresses that are found in the magnus.conf file.

To use the Server Manager for the hardware virtual servers that are uses with ISPs, see the section Setting Up Hardware Virtual Servers for ISPs.


Setting up Software Virtual Servers
Setting up a software virtual server enables you to host several web sites on one computer without needing to have more than one IP address on it. For example, you can set up your system so that both www.siroe.com and www.iplanet.com resolve to 192.3.4.5, then set up software virtual servers to handle both server names (for example, http://www.siroe.com/ and http://www.iplanet.com).

The server can respond to requests differently depending upon the URL, even though the server only has one IP address. For example, one server can serve different pages for http://www.siroe.com/ and http://www.iplanet.com.

The following example shows how software virtual servers might be used. An Internet service provider (ISP) installs a web server and then wants to set up a software virtual server for each of its customers (for example, customers aaa, bbb, and ccc) so that each customer can have an individual domain name.

The ISP first configures DNS to recognize that a customer's URL, www.aaa.com, resolves to the ISP's IP address. The ISP then creates a subdirectory for each company (aaa, bbb, and ccc) in the document root. These subdirectories contain the files for that company, including the home page, aaa/home.html. Next the ISP sets up software virtual servers. The URL host would be www.aaa.com and the home page would be aaa/home.html. The ISP would do this for all the companies.

Because software virtual servers use the HTTP Host header to direct the user to the correct page, not all client software works with software virtual servers. Only client software (such as Netscape Navigator) which supports the HTTP Host header works. In the previous example, the ISP would set up the index.html file in the document root to be an index page that links to all the virtual servers hosted by the system, so all users could access the home pages.

Note. You cannot use Netscape Navigator version 1.x with software virtual servers. You should use Netscape Navigator 3.01 or later.

You can set up a software virtual server using The Software Virtual Servers Page in the Content Management tab of the Server Manager.

For information on how to configure a unique CGI directory for specific software virtual servers, see Configuring a Unique CGI Directory for Each Software Virtual Server.

Adding a Doc Root for Software Virtual Servers
You can assign a unique doc root for each software virtual server.

Note. You can not use the Administration Server to accomplish this task.

To assign every software virtual server its own doc root, add the following code to the obj.conf file:


Changing the Character Set
The character set of a document is determined in part by the language it is written in. You can override a client's default character set setting for a document, a set of documents, or a directory by selecting a resource and entering a character set for that resource.

Netscape Navigator can use the MIME type charset parameter in HTTP to change its character set. If the server includes this parameter in its response, Netscape Navigator changes its character set accordingly. The following are some character set examples:

The charset names recognized by Netscape Navigator are specified in RFC 1700 (except for the names that begin with x-). These charset names include the following:

Additionally, the following aliases are recognized for us-ascii:


The following aliases are recognized for iso_8859-1:

To change the character set, use The International Characters Page in the Server Manager.

 

© Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.