| Previous Contents Index Next |
| iPlanet Web Server, Enterprise Edition Administrator's Guide |
Chapter 16 Content Management
This chapter describes how you can configure and manage content for classes of virtual servers and virtual servers.This chapter contains the following sections:
Setting the Primary Document Directory
Setting Additional Document Directories
Customizing User Public Information Directories (Unix/Linux)
Restricting Symbolic Links (Unix/Linux)
Enabling Remote File Manipulation
Configuring Document Preferences
Setting the Primary Document Directory
The primary document directory (also called the document root) is the central directory where you store all the files you want to make available to remote clients.When you add a class, you specify a document directory with an absolute path. If you do not use a variable as part of that path, the document root for every virtual server in the class will default to the same directory. You can then change them individually in the Class Manager.
Another approach is to use a variable when you set the path for the class. For example, you can use the $id variable to create a directory named with the virtual server id for every virtual server in the class. You can set the class' document root to be class_doc_root/$id. Using this path, if your class' document directory is /iplanet/servers/docs/$id, the default document directory for a virtual server vs1 that belongs to the class is /iplanet/servers/docs/vs1.
For more information about the document directory and how it is used at the server instance, class, and virtual server level, see Document Root.
To change the primary document directory to use a different path or variable, follow these steps:
From the Class Manager, click the Content Management tab.
For more information, see the online help for The User Document Directories Page.Click Primary Document Directory.
Enter an absolute directory path or a variable, or a path and variable combination next to the virtual server.
Click OK.
- If you include the variable $id at the end of your document root absolute path, every virtual server has a default document root of class_doc_root/virtual_server_ID. For example, if your class' document directory is /iplanet/servers/docs/$id, the default document directory for a virtual server vs1 that belongs to the class is /iplanet/servers/docs/vs1.
- For more information about variables, see Using Variables.
Note Typically, each virtual server has its own primary document directory.
Setting Additional Document Directories
Most of the time, the documents for a virtual or server instance are in the primary document directory. Sometimes, though, you may want to serve documents from a directory outside of the document root. You can do this by setting additional document directories. By serving from a document directory outside of the document root, you can let someone manage a group of documents without giving them access to your primary document root.If you set up an additional document directory without using variables, that directory will be set at the class level, and used by all virtual servers in the class.
If you want to set up additional document directories for individual virtual servers in the class, you must use variables so that the directory the URL prefix is mapped to is different for every virtual server.
To add an additional document directory, follow these steps:
From the Class Manager, click the Content Management tab.
To for more information, see the online help for The Additional Document Directories Page.Click Additional Document Directories.
Specify the directory to map those URLs to.
- Clients send this URL to the server when they want documents.
If you want to, use an existing configuration style to specify how this directory should be configured.
By default, the server instance 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 would be:
- deny (all) anyone;
- allow (rxli) all;
- allow (wd) privileged_user;
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 a server create home pages and other documents without your intervention.You can only set these up for the entire class. There's no way to customize them on a per virtual server basis.
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, follow these steps:
From the Class Manager, click the Content Management tab.
For more information, see the online help for The User Document Directories Page.Click User Document Directories.
Choose the subdirectory in the user's home directory where the server looks for HTML files.
- The usual prefix is ~ because the tilde character is the standard Unix/Linux prefix for accessing a user's home directory.
Designate the password file.
- A typical directory is public_html.
Choose whether to load the password database at startup.
- 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 user names 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 *):
- username:*:*:groupid:*:homedir:*
Choose whether to apply a configuration style.
- For more information, see Loading the Entire Password File on Startup.
Another way to give users separate directories is to create a URL mapping to a central directory that all of your users can modify.
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. To restrict a user's publishing, add a trailing slash to the user's home directory path in the /etc/passwd file:
becomes:
- jdoe::1234:1234:John Doe:/home/jdoe:/bin/sh
After you make this modification, 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.
- jdoe::1234:1234:John Doe:/home/jdoe/:/bin/sh
If, at a later time, you decide to allow this user to publish content, remove the trailing slash from the /etc/passwd entry, then restart 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
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. For more information on configuration files, see Chapter 17 "Applying Configuration Styles."
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 a server's documents. You should use access control to restrict write access to these resources to prevent unauthorized tampering.Note that enabling remote file manipulations should have no effect on using content management systems such as Microsoft Frontpage.
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, follow these steps:
From the Class Manager, click the Content Management tab.
For more information, see the online help for The Remote File Manipulation Page.Click Remote File Manipulation.
Configuring Document Preferences
You use the Document Preferences page to set document preferences. This section discusses these topics:
Setting the Document Preferences
These settings are all configured for the class, not individual virtual servers.
Setting the Document Preferences
To set the document preferences, follow these steps:
From the Class Manager, click the Content Management tab.
The preferences you can set are discussed more fully in the sections that follow. For additional information, see the online help for The Document Preferences Page.Choose the appropriate field values, as discussed in the following sections.
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.
Selecting Directory Indexing
A document directory will probably have several subdirectories. For example, there might be 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. 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.
If your server is outside the firewall, turn off directory indexing to ensure that your directory structure and filenames are not accessible.
Specifying a Server Home Page
When end users first access the server, the first file they see is usually 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.
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.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:
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.
Configuring URL Forwarding
URL forwarding allows you to redirect document requests to another server. Forwarding URLs or redirection is a method for the server to tell a user that a URL has changed (for example, because you have moved files to another directory or server). You can also use redirection to seamlessly send a person who requests a document on one server to a document on another server.For example, if you forward http://www.iplanet.com/info/movies to a prefix film.iplanet.com, the URL http://www.iplanet.com/info/movies redirects to http://film.iplanet.com/info/movies.
You can use variables to map directories to new directories. For example, you can map /new to /$docroot/new. The mapping will go to the document root for the virtual server.
For more information about variables, see Using Variables.
Sometimes you may want to redirect requests for all the documents in one sub-directory to a specific URL. For example, if you had to remove a directory because it was causing too much traffic, or because the documents were no longer to be served for any reason, you could direct a request for any one the documents to a page explaining why the documents were no longer available. For example, a prefix on /info/movies could be redirected to http://www.iplanet.com/explain.html.
To configure URL forwarding, follow these steps:
From the Class Manager, click the Content Management tab.
For more information see the online help for The URL Forwarding Page.Type the URL prefix you want to redirect, and whether you want to redirect it to another prefix or to a static URL.
Customizing Error Responses
You can specify a custom error response that sends a detailed message to clients when they encounter errors from your virtual server. You can specify a file to send or a CGI program to run.For example, you can change the way the server behaves when it gets an error for a specific directory. If a client tries 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.
Before you can enable a custom error response, you must create the HTML file to send or the CGI program to run in response to an error. After you do this, enable the responsein the Class Manager.
To enable a customized error response, follow these steps:
From the Class Manager, click the Content Management tab.
For more information see the online help for The Error Responses Page.Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.
For each error code you want to change, specify the absolute path to the file or CGI that contains the error response.
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. Examples are:
The following charset names recognized by Netscape Navigator are specified in RFC 1700 (except for the names that begin with x-):
Additionally, the following aliases are recognized for us-ascii:
The following aliases are recognized for iso_8859-1:
To change the character set, follow these steps:
From the Class Manager, click the Content Management tab.
For more information, see the online help for The International Characters Page.Click International Characters.
Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.
Set the character set for all or part of the server.
Click OK.
- If you leave this field blank, the character set is set to NONE.
Setting the Document Footer
You can specify a document footer, which can include the last-modified time, for all the documents in a certain section of the server. This footer works for all files except output of CGI scripts or parsed HTML (.shtml) files. If you need your document footer to appear on CGI-script output or parsed HTML files, enter your footer text into a separate file and add a line of code or another server-side include to append that file to the page's output.To set the document footer, follow these steps:
From the Class Manager, click the Content Management tab.
For more information see the online help for The Document Footer Page.Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.
Specify the type of files that you want to have include the footer.
- If you choose a directory, the document footer applies only when the server receives a URL for that directory or any file in that directory.
Type any text you want to have appear in the footer.
- The maximum number of characters for a document footer is 765. If you want to include the date the document was last modified, type the string :LASTMOD:.
Using htaccess
For information on using htaccess, see Using .htaccess Files.
Restricting Symbolic Links (Unix/Linux)
You can limit the use of the file system links in your server. File system links are references to files stored in other directories or file systems. The reference makes the remote file as accessible as if it were in the current directory. There are two types of file system links:
Hard links—A hard link is really two filenames that point to the same set of data blocks; the original file and the link are identical. For this reason, hard links cannot be on different file systems.
For more information about hard and symbolic links, see your Unix/Linux system documentation.Symbolic (soft) links—A symbolic link consists of two files, an original file that contains the data, and another that points to the original file. Symbolic links are more flexible than hard links. Symbolic links can be used across different file systems and can be linked to directories.
File system 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).
To restrict symbolic links, follow these steps:
From the Class Manager, click the Content Management tab.
For more information, see the online help for The Symbolic Links Page.Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.
Choose whether to enable soft and/or hard links and the directory to start from.
Setting up Server-Parsed HTML
HTML is normally sent to the client exactly as it exists on disk without any server intervention. However, the server can search HTML files for special commands (that is, it can parse the HTML) before sending documents. If you want the server to parse these files and insert request-specific information or files into documents, you must first enable HTML parsing.To parse HTML, follow these steps:
From the Class Manager, click the Content Management tab.
For more information on setting your server to accept parsed HTML, see the online help for The Parse HTML Page.Choose a resource for which the server will parse HTML.
Choose whether to activate server-parsed HTML.
- Choose Entire Server from the resource picker to apply your change to the whole class, or navigate to the document root for a specific virtual server, or to a specific directory or within a specific virtual server.
- If you choose a directory, the server will parse HTML only when the server receives a URL for that directory or any file in that directory.
Choose which files to parse.
- You can activate for HTML file s but not the exec tag, or for HTML files and the exec tag, which allows HTML files to execute other programs on the server.
Click OK.
- You can choose whether to parse only files with the .shtml extension, or all HTML files, which slows performance. If you are using Unix/Linux, you can also choose to parse Unix/Linux files with the execute permission turned on, though that can be unreliable.
For more information on using server-parsed HTML, see the Programmer's Guide.
Setting Cache Control Directives
Cache-control directives are a way for iPlanet Web Server to control what information is cached by a proxy server. Using cache-control directives, you override the default caching of the proxy to protect sensitive information from being cached, and perhaps retrieved later. For these directives to work, the proxy server must comply with HTTP 1.1.For more information HTTP 1.1, see the Hypertext Transfer Protocol--HTTP/1.1 specification (RFC 2068) at:
To set cache control directives, follow these steps:
From the Class Manager, click the Content Management tab.
For more information see the online help for The Cache Control Directives Page.Click Cache Control Directives
Fill in the fields. Valid values for the response directives are as follows:
Public. The response is cachable by any cache. This is the default.
Click OK.Private. The response is only cachable by a private (non-shared) cache.
No Cache. The response must not be cached anywhere.
No Store. The cache must not store the request or response anywhere in nonvolatile storage.
Must Revalidate. The cache entry must be revalidated from the originating server.
Maximum Age (sec). The client does not accept a response that has an age greater than this age.
Using Stronger Ciphers
For information on setting stronger ciphers, see Setting Stronger Ciphers.
Previous Contents Index Next
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated May 09, 2002