Figure 1. Socksified proxy server and a firewall
Figure 2. Machine with both a firewall and proxy server
Your server is operational once you install it. After you have the server installed and running, you will probably want to change some parts of the default configuration file to make the server meet your own particular needs.
This chapter explains what you can change about your server's configuration, as well as how to change these items, by using the Configuration and Administration forms or by editing the configuration file.
You can configure your server either by using the Configuration and Administration forms or by editing the server's configuration file.
The server comes with Configuration and Administration forms. These forms are a combination of CGI programs and HTML forms that provide an easy way for you to configure your server or to view your server's current configuration settings.
Once the server is running, you can access the Configuration and Administration forms from WebExplorer (or any other Web browser). The browser can be on the same machine as the server or on any remote client that has access to the server.
To use the Configuration and Administration forms:
http://your.server.name/
where your.server.name is the fully qualified name of your host. For example, http://www.ibm.com/
Enter the user name and password you specified in the Administrator ID and Password fields during installation. If you did not change the installation defaults, the authorized user name is webadmin and the authorized password is webibm. If you did not change the defaults during installation, it is strongly recommended that you do so now to prevent unauthorized access to your server configuration. See "Controlling access to the Configuration and Administration forms".
After you enter an authorized user name and password, you go to the Configuration and Administration forms page.
When you go to a form, it is displayed with the current configuration values in its input fields. (If you haven't changed your configuration since installation, these are the default values.)
Each form provides instructions to assist you in deciding what changes to make. For further information, you can click the help icon at the bottom of each form. The help icon links you to a help page that provides detailed steps for using the form to perform particular tasks.
If you decide you do not want to use the changes you made to the form, click Reset. This returns the fields on the form to the values they had when you first came to the form.
Note: A few of the form pages have more than one set of Apply and Reset buttons. These pages are actually treated as multiple forms. If you click Apply or Reset, the action takes place only for the portion of the page associated with that set of buttons.
If the input was not accepted, you see a Configuration Error page explaining what was wrong with the information you entered. Go back to the form and try to correct the information. From the form you may also want to click the help icon at the bottom of the form.
If the Confirmation page does not contain a Restart Server button, then you need to stop your server and start it again for the configuration changes you made to take effect. For instructions on stopping and starting your server, see Chapter 2. "Starting to use your server".
Note: From the Confirmation page or the Restart Confirmation page, use the Configuration Page button to return to the Configuration and Administration forms.
The other way to configure your server is by editing the configuration file.
By default, the configuration file is named httpd.cnf. If the ETC environmental variable has been set, httpd.cnf is on that path; otherwise, httpd.cnf is in the system directory, which is typically WINNT35 or WINDOWS.
The configuration file is made up of statements called directives. You change your configuration by editing the configuration file, updating the directives, and saving your changes.
When you restart the server, your changes take effect, unless you changed one of the following directives:
If you changed one of the directives in the above list, you must stop the server and start it again. For instructions on stopping and starting your server, see Chapter 2. "Starting to use your server".
Chapter 3. "Using the configuration file" describes each of the configuration file directives.
After installation, your server has one authorized user name and one password that can be used to access the Configuration and Administration forms.
You specified the authorized user name and password in the Administrator ID and Password fields during installation. If you did not change the installation defaults, the authorized user name is webadmin and the authorized password is webibm.
The user name and password are stored in the ADMIN.PWD password file. If the ETC environmental variable has been set, the ADMIN.PWD is on that path; otherwise, the password file is in the system directory, which is typically WINNT35 or WINDOWS.
If you have not yet changed the default user name or password, you should do so now to prevent unauthorized access to the Configuration and Administration forms.
You can use either the htadm command or the Configuration and Administration forms to control user names, passwords, and password files.
If you just want to change the password for the default user name with the htadm command, you would enter the following:
htadm -passwd c:\pathname\ADMIN.PWD user-name password
In the above example:
See "htadm command" for complete instructions on how to use the htadm command.
For more information about limiting access to the resources on your server, see Chapter 7. "Protecting your server".
If you installed your server on an NT File System (NTFS), be careful when you copy files to ensure you give the right permissions to the user ID and group ID under which the server is running. For example, the server needs write permission to modify ACL files. A secure server also needs write permission to modify key files.
When the user ID or group ID changes, you need to switch any ACL files to the new user ID or group ID. For a secure server, in addition to switching ACL files, you also need to switch key files and the stashed password files.
One of the first configuration tasks you will want to perform is changing your server so that it returns your own home page. The home page is the document that your server returns when a client sends a request that does not point to a specific directory or file. So when a client sends a URL in the format of:
http://your.server.name/your server responds by sending back your home page. When you first start the server, the server uses the Front Page as your home page and uses the default configuration file.
Configuration settings tell your server where to look for your home page and what its name is. So that you can understand how this works, this section contains background information about the document root directory and the welcome page list. The section then describes an easy way to create your own home page and have the server use it instead of the server's Front Page.
Note: Some Web browsers use the term "home page" to also refer to the first page that the browser loads when it is started. This document uses the term only to refer to the server home page.
When the server receives requests that do not point to a specific directory, it tries to serve the request from the document root directory. Because you want your home page to be returned for requests that do not specify a directory or file name, you need to have your home page in your document root directory.
The document root directory is the directory you specified as your HTML directory during installation. If you used the installation defaults, the document root directory is C:\WWW\HTML.
At some point you may decide to change the directory your server uses for its document root directory.
For example, you might want to change your document root directory if you are creating a new set of HTML documents for your server to use. While you are creating the new documents, you might want to keep them on a directory not accessible to the server. When the new documents are ready, you can change your document root directory rather than copying and replacing the documents on your current document root directory.
Follow these steps to change your document root directory:
After restarting, the server begins to use the new document root directory.
So now you know where your server looks for your home page, but how does it know which file to return? This is defined by the list of welcome pages.
The server's configuration defines a list of file names that the server can use as welcome pages. These are the files the server looks for when it receives URL requests that do not specify a file name.
For requests that do not specify either a directory or file name, you want the server to return your home page. As described in the previous section, the server looks for your home page on the document root directory. It then determines which file contains your home page by matching the list of welcome pages to the files in the directory. The first match it finds is the file it returns as your home page.
The default configuration file defines a list of four welcome pages. The order of the welcome pages is important because the server goes down the list from top to bottom when looking for the file it should return.
The default welcome page file names and their default order are:
The server returns the first file it finds that matches a file name in the list. Until you create a Welcome.html, welcome.html, or index.html file and place the file in the document root directory, the server uses Frntpage.html as your home page.
For example, if you are using the default configuration and your document root directory does not contain a file named Welcome.html, or welcome.html, but does contain files named index.html and Frntpage.html, the index.html file is used as your home page.
For more information on welcome pages and how they are used by directories other than the document root directory, see "Directories and Welcome Page - Set viewing options".
The easiest way to have your server start returning your own home page is to create the page in a file named Welcome.html and store the file on your document root directory. The next section explains how to do this.
You can use any HTML document for your home page.
If you already have a document you want to use as your home page, just copy it into your document root directory and rename it to Welcome.html, welcome.html, or index.html.
If you want to create a new home page and have your server start using it, you can use the following procedure:
http://your.server.name/
where your.server.name is the fully qualified name of your host. For example, http://www.ibm.com/.
Need some help with HTML? Depending upon your current level of expertise with HTML, there are many sources of information available.
You can write your HTML documents using any editor capable of producing flat text files. However, if you use a plain text editor you will have to key in each of the HTML tags. There are several editors and related tools designed specifically to help users create HTML documents without having to key in all the surrounding tags.
For example, non-commercial users can get a free copy of an editor called HoTMetaL Free from SoftQuad. Go to the following URL for instructions on how to get HoTMetaL Free:
http://www.sq.com/products/hotmetal/hm-ftp.htm
When you have documents ready that you want to show the world, you can start to register your server with various databases. For example, the following URLs take you to sites where you can register your server:
http://www.w3.org/hypertext/DataSources/WWW/Geographical_ generation/new-servers.html
Note: The URL above is shown on two lines only because of its length. When entering the URL on your browser, type one continuous string with no spaces.
http://www.yahoo.com/ http://www.lycos.com/
Each of the two URLs shown above contains links to a form you can use to register your server.
Clients connected to a proxy server can ask the server to retrieve documents for them from other servers.
You can also set up a firewall machine, such as the IBM Internet Connection Secured Network Gateway. A firewall machine is connected to both your internal network, or intranet, and the external Internet. Users of the intranet are inside the firewall. The firewall machine can be set up to prevent external machines from reaching your intranet.
Two types of proxy/firewall configurations are available:
Figure 1. Socksified proxy server and a firewall
Figure 2. Machine with both a firewall and proxy server
You can also use caching to have the proxy server store the documents it retrieves from other servers in a local cache. The server can then respond to subsequent requests for the same documents without having to retrieve them from other servers. This can improve response time.
Within an intranet you may want to set up a server as a caching proxy to reduce the amount of traffic on the network. In large networks you can connect a hierarchy of caching proxies. A client request cascades up through the hierarchy of servers until the document is retrieved from a server's cache or from the actual server where the document resides.
To set up a proxy, you need to:
After you've configured your proxy server, tell your users so they can configure their browsers to point to it.
To configure your server as a proxy, specify which protocols you want the server to act as a proxy for. You do this by one of two methods:
Either method enables your server to act as a proxy.
To fill in the form:
When you specify a socks server on this form, you indicate that you want this proxy server to be chained to a socks server.
Once the changes take effect, your server runs as a proxy.
Perform this step if you want to make your proxy server a caching proxy server.
Perform this step only if you want your proxy server to listen to a port number other than the HTTP default of 80.
You can specify that certain protocol requests are routed to another proxy server. This allows you to chain together a hierarchy of proxy servers.
If you've set up a hierarchy of proxies, you can specify any domain names the proxy can get to directly rather than going to the next proxy in the hierarchy. These are called non-proxy domains.
To control how long HTTP or HTTPS files are kept in the cache after they are last used, do the following:
To control how long FTP files are kept in the cache and how long to keep unused FTP files in the cache, do the following:
To specify how you want expired files removed from the cache, do the following:
To specify which files you want your server to consider for caching, you can create a list of URLs you do want to cache or a list of URLs you do want not to cache. If you do not create either of these lists, any file is a candidate for caching. The server considers files for caching if the request is a GET, the URL does not contain a question mark (?), and the requested file is not protected by a user ID/password.
You can use the server's protection function to control which clients can use your server as a proxy.
The default configuration file contains commented lines that you can use as a basis for controlling access to your proxy. For this reason, it is easier to accomplish this task by editing the configuration file than by using the Configuration and Administration forms.
Follow these steps to define which clients can use your server as a proxy:
By default, the configuration file is named httpd.cnf. If the ETC environmental variable has been set, httpd.cnf is on that path; otherwise, httpd.cnf is in the system directory, which is typically WINNT, WINNT35, or WINDOWS.
# Protection PROXY-PROT {
# ServerId YourProxyName
# Mask @(*.ibm.com, 128.141.*.*, *.ncsa.uiuc.edu)
# }
# Protect http:* PROXY-PROT
# Protect ftp:* PROXY-PROT
# Protect gopher:* PROXY-PROT
# Protect https:* PROXY-PROT
# Protect wais:* PROXY-PROT
# Protect news:* PROXY-PROT
The Protect statement for https is in the configuration
file.
In order to use host name templates, you must set the DNS-Lookup directive to On. If the DNS-Lookup directive is set to Off (the default), you can use IP address templates only. See "DNS-Lookup - Specify whether you want to look up host names of clients".
The Internet Connection Secure Server distinguishes between a user ID and password used for authentication at the proxy server and those used for authentication at the end-point server.
When a user ID is specified in the protection mask for a proxy request, the proxy server requires the browser to send a PROXY-AUTHENTICATE header. If the header is missing or incorrect, the proxy server sends a message (HTTP 407 error status) back to the browser stating that proxy authentication is required.
If request authentication is required at the end-point server, that server sends back a message (HTTP 401 error status) stating that authentication is required. The end-point server's error message is returned to the browser by the proxy server. A WWW-AUTHENTICATE header sent by the browser is forwarded by the proxy server to the end-point server.
PROXY-AUTHENTICATE headers are never forwarded by a proxy server; this ensures that validated proxy user IDs and passwords are not sent to servers that they are not intended for.
Note: Web browsers must also support proxy authentication if you require user ID authentication in your proxy protection setup mask.
The server will now act as a proxy only for clients and requests that meet the specifications on the mask subdirectives.
If you are using SSL, the kind of connection between the client and the proxy and between the proxy and the destination server can vary depending on whether the client uses SSL tunneling.
Some clients, such as Netscape Navigator, use SSL tunneling to establish a secure connection to a destination server through a proxy. The proxy can be a base or secure server.
Because SSL tunneling is generic, it can be used to access resources on different ports. For example, the Internet Connection Secure Server uses port 443 for https requests and Netscape uses port 563 for SNEWS (Secure News).
To set up a proxy for SSL tunneling:
Enable CONNECT
Examples:
Secure WebExplorer does not use SSL tunneling. You need Pass directives defined for https and http requests.
Here's how the connection from a Secure WebExplorer client to a destination server through a proxy is handled:
The server's certificate will not be displayed on Secure WebExplorer if the URL specifies https.
You may want to use one server to provide Web sites for multiple customers. For example, you might have two customers (customerA and customerB), both of whom want to make information about their companies available on the World Wide Web. You might want to put both Web sites on the same machine if the expected number of requests for the information is not great enough to justify a separate machine for each customer.
With the Internet Connection Secure Server, you can use multiple IP addresses, virtual hosts, or both to provide multiple Web sites on one server.
To use multiple IP addresses, your server must be installed on a machine with multiple network connections.
If you have only one network connection and run two instances of the server on the same machine, then only one server has the benefit of using the default port number. Requests to the other server would have to include a port number.
If your machine has two network connections, you can run just one instance of the server and assign each customer to a different IP address. For each IP address you would define a different host name. So customerA could be www.customerA.com on IP address 9.67.106.79 and customerB could be www.customerB.org on IP address 9.83.100.45. You could then configure the server to serve a different set of information depending on the IP address the request comes in on. Because the server can accept requests from the default port of each network connection, requests to either host name would not require a port number.
With virtual hosts, no additional hardware is required, and you can save IP addresses. However, clients must support HTTP 1.1 or HTTP 1.0 with 1.1 Extensions.
With virtual hosts, you can run just one instance of the server and assign each customer to a different host. In the domain name server, you define your hosts and associate them with the IP address of your server. You can then configure the server to serve a different set of information depending on the host for which the request is made. Requests do not require a port number.
Setting up your server to use multiple IP addresses or virtual hosts is very similar. For multiple IP addresses, you'll need to specify the IP address a request comes in on and for virtual hosts, you'll need to specify the host name for which a request is made.
You configure the server to serve different information for each customer by indicating that certain parts of your configuration apply only to requests coming in on certain addresses or for certain hosts. You can configure three key parts of your server so that requests are processed differently based on the IP address they come in on or the host name in the URL.
You can specify a different set of file names to use as welcome pages depending on the address a request comes in on or the host name in the URL. The file names you define as welcome pages determine how the server responds to requests that do not contain a file name.
For example, you might want to specify that homeA.html is a welcome page only for requests received on 9.67.106.79 or for hostA, and homeB.html is a welcome page only for requests received on an address 9.83.100.45 or for hostB.
From the Configuration and Administration forms page, you can configure your list of welcome pages by clicking on Initial Page. From the Initial Page form, click the help icon for information on defining welcome pages and how to associate a welcome page file name with an IP address or a host name.
Alternatively, if you are editing the configuration file, you can add an IP-address or hostname at the end of a Welcome directive to associate a welcome page file name with an IP address or a host name. For details, see the description of the Welcome directive in "Directories and Welcome Page - Set viewing options".
You can specify a different set of mapping rules for the server to use depending on the address a request comes in on or the host name in a URL. Mapping rules map a request to a physical file on the server and determine whether the server processes a request.
For example, you might want to specify that a request beginning /cgi-bin/ received on address 9.67.106.79 or for hostA is mapped to the /customerA/cgi/ directory, and the same request received on 9.83.100.45 or for hostB is mapped to the /customerB/cgi/ directory.
From the Configuration and Administration forms page, you can configure your mapping rules by clicking on Request Routing. From the Request Routing form, click the help icon for information on how to use mapping rules and how to associate a mapping rule with an IP address or a host name.
Alternatively, if you are editing the configuration file, you can add an IP-address or hostname at the end of Exec, Fail, Map, Pass, and Redirect directives to associate the directive with an IP address or a host name. For details, see the description of these directives in "Resource mapping - Redirect URLs".
You can activate different protection rules for a request based on the address the request comes in on or the host name in a URL. Protection rules are defined in protection setups and determine how your server controls access to files and programs.
For example, you might want to specify that a request beginning /cgi-bin/ received on address 9.67.106.79 or for hostA is protected by the rules in a protection setup named PROT-A and the same request received on 9.83.100.45 or for hostB is protected by the rules in a protection setup named PROT-B.
From the Configuration and Administration forms page, you can configure how protection is activated by clicking on Document Protection. From the Document Protection form, click the help icon for information on protecting documents and how to associate protection with an IP address or a host name.
Alternatively, if you are editing the configuration file, you can add an IP-address or hostname at the end of DefProt and Protect directives to associate the directive with an IP address or a host name. For details, see the description of these directives in "Access control - Set up access control for the server".
It is recommended that you periodically back up the following files:
For a secure server, you should also back up: