The Apache module is broken up into several sections to address different aspects of an Apache configuration. On the main page, these sections are grouped into Global Configuration and Virtual Servers groups. Using virtual servers it is possible to locate several web sites with unique domain names on a single IP address, in order to conserve the rapidly diminishing IPv4 address space. In the context of the Apache module, Global Configuration refers to configuration information that will apply to all virtual hosts that are run from the same httpd daemon. It is usually unnecessary to run more than one httpd daemon on a single machine but it is possible. It is also possible to manage more than one such daemon with Webmin via the module cloning feature.
![[Note]](http://swelltech.com/support/webminguide/images/note.png) | Note |
|---|---|
The official Apache documentation is a good source of additional information about Apache and its modules. | |
Global Configuration is found on the top half of the divided Apache module page, as shown in Figure 7.1, “Apache Global Configuration”. It provides access to the various options that will be shared across all virtual servers, such as which modules to load, network addresses, MIME types, etc. The options configured here will apply to every virtual server and the default server. To configure an option for one specific virtual server it must be configured in the virtual servers configuration section.
This page provides the following options, which set many of the limits for Apache. Generally, the defaults are reasonable, but may need to be altered for high load or low memory situations. The options on this page cover two distinct, but related limits that are configurable in Apache.
The first set of limits are related to the length or number of request-headers that will be accepted by the server. A request-header is a term that refers to all of the information that a client sends to the server to indicate the object it would like to receive. The most important portion of the request-header is usually made up of the HTTP method (such as GET, POST, HEAD, etc.), the URI (the complete path and domain name of the object being referred to), and the HTTP protocol version number.
The second set of limits refers to connection and process specific limits of Apache. Apache usually operates in what is known as a process-per-connection mode, wherein each client connection to the server will be served by a single and independent httpd process. Thus to provide service to 30 simultaneous clients, the system will run 30 Apache processes.
- Maximum headers in request
Sets the maximum number of request headers accepted per request. Each time a web client (usually a web browser) makes a connection to a web server, it includes request headers to indicate information about the encoding capabilities, HTTP version support, cache-control, content negotiation and other information about the client agent. As HTTP standards and non-standard extensions to the HTTP protocol have been developed, the number of request headers usually received has risen slowly, but is rarely more than 20. The LimitRequestFields directive in the Apache configuration file is modified by this option, and usually defaults to 100.
It may be possible to prevent certain types of denial of service attacks by restricting the number of headers accepted, though it is unlikely the be a problem at the default value. It should rarely need to be altered from its default, unless clients receive error messages from the server indicating too many headers were in the request.
- Maximum request header size
Defines the maximum header field size that will be permitted. Apache sets aside a buffer for processing of header entries received from the client. This buffer must be large enough to contain a single header entry in its entirety. The LimitRequestFieldsize directive is modified by this option, and it usually defaults to 8190 and this value is also the normal maximum value possible. It is worth noting that the maximum value for this option is system dependent and is compiled into the Apache executable when it is built. Raising this value above the default of 8190 may not be supported on your Apache, and should not be necessary under any normal circumstances.
- Maximum request line size
Defines the maximum length of an HTTP request-line. The request-line contains the HTTP method, the complete URI, and the protocol version. The accepted line size needs to be long enough to contain any resource name on the system, and the default is generally recommended. This option edits the LimitRequestLine directive in the Apache configuration and defaults to 8190 bytes, which is also usually the compiled-in upper bound for this value.
This option rarely needs to be altered from its default, but may be useful in preventing certain types of Denial of Service attacks by preventing client applications from overloading the server with many extremely large and complex request lines.
- Maximum concurrent requests
The maximum number of allowed concurrent requests. Each request to Apache spawns a new daemon, and this defines the upper limit on how many such daemons will be spawned to answer requests. This option correlates to the MaxClients directive. To configure more than 256 you will probably have to edit HARD_SERVER_LIMIT entry in httpd.h and recompile your Apache, unless the package that is installed has already been configured for high loads or you did so when building Apache from the source tarball.
Except in extremely high load environments it is rarely beneficial to raise this to very high levels. Because every new process requires resources, in the form of memory and CPU time, it can be counter-productive and cause service to become less responsive rather than more. If all processes are busy, the request will usually be queued up to the limit imposed by the Listen Queue Length discussed in the next section of this chapter.
- Maximum requests per server process
The maximum number of requests that each child process will answer before being killed and re-spawned. This is useful for a couple of reasons. First, if there are any accidental memory leaks (anywhere in the process, including its modules), the damage can be minimized by restarting processes regularly. Also, without using this option the system will always keep alive the largest number of processes it has ever needed, even during low load periods when far fewer processes are needed to answer requests. This option correlates to the MaxRequestsPerChild directive.
Note On Keepalive requests, only one request is counted per connection from a client. Thus, a number of requests from the same client may be served before the counter is incremented if the client supports Keepalive requests. In this case, this directive acts to limit the number of connections per process rather than number of individual requests.
![[Caution]](http://swelltech.com/support/webminguide/images/caution.png)
Caution Though Apache is historically a quite solidly written program, and has rarely exhibited major memory leaks, many of the shared modules in use by Apache may not be quite as commonly used or as well-tested. These modules may lead to memory leakage even if the Apache httpd process does not exhibit such leakage.
- Maximum spare server processes
This defines the maximum number of unused server processes that will be left running. This option configures the MaxSpareServers directive and defaults to 10. There is usually no need to tune this option, except on extremely high load servers.
- Minimum spare server processes
The minimum number of child processes that will be left running at all times. For high load servers, this may need to be raised, and for low memory and low load systems it might be best to reduce the number. This option correlates to the MinSpareServers directive and defaults to 5.
Caution It is a very common mistake to raise the above two options to extreme levels when performance of an Apache installation seems sluggish. It is very rarely actually the source of the problem, but it seems a popular first reaction among new Apache administrators. Tuning Apache for performance is well documented in a number of locations, and much documentation about tuning for specific OS platforms is also available on the Internet. A good place to start is the Apache Performance Notes page. The documentation found there will address nearly all performance issues that most users will ever run into.
- Initial server processes
The number of child processes that are spawned when the httpd is started. Correlates to the StartServers directive and defaults to 5. This usually does not need to be modified, except on high load servers.
- Display extended status information
If the status module is enabled on the server, turning this on will keep track of extended status information for each request and present them in a web page or machine readable format. This option edits the ExtendedStatus directive. This option requires the mod_status module be loaded.
Note To access the extended status information from a running Apache server, you can browse to the address http://www.yourdomain.com/server-status. Note that access control should generally be configured to tightly restrict access to this URL, as it may contain sensitive data about your web server environment.
The information provided by mod_status, with extended status enabled, includes statistics about the number of child processes and the number of connected clients, the average number of requests per second being served, the average number of bytes per request, and the current CPU percentage being used by each Apache process. A machine readable form of this data may be collected from http://www.yourdomain.com/server-status?auto. The latter is ideal for use in scripts to gather statistics from your server automatically.
Caution Because of the persistent nature of this type of data, this module is only functional when Apache is run in standalone mode, and not when run in inetd mode. Because of the large number of problems involved in running Apache under inetd, and problems inherent to inetd, it is simply best to avoid inetd altogether, anyway.
This section is for configuring the network addresses and ports where Apache will listen, and some other access limits, timeouts, and queue options (Figure 7.2, “Networking and Addresses”.
- Listen on addresses and ports
This option defines the addresses and ports where Apache will listen for requests. The default is to listen on port 80 on all addresses, and this is often all that is needed. Port 80 is the standard port for web traffic, and should generally be used for all normal web traffic. It is also possible to configure multiple Apaches to run on the same machine with different global configurations on different ports or addresses. Also, because ports below 1024 are privileged ports, regular users running Apache without administrator access will have to run it on a non-standard port. 8080 is a common port for web servers run by unprivileged system users who cannot bind to port 80. A good overview of these options can be found at Setting which addresses and ports Apache uses. These options correlate to the Listen and Port directives.
- Multiple requests per connection
When KeepAlive is enabled the server will support persistent connections, which can result in improved performance and a generally better experience for the end user. This option sets the maximum number of requests to be handled per client connection. If set to 0, the server will impose no limit on the number of requests during a single connection. This option correlates to the MaxKeepAliveRequests directive. The default is usually 100.
Caution If you develop web sites, resist the temptation to rely on persistent connections to maintain state. An unfortunate effect of persistent connections becoming available on most browser clients, as well as most web servers, is that some web application and commerce site developers have attempted to use a long-lasting persistent connection to maintain the shopping cart, or other state information of the user. This seemingly easy method of keeping up with users is fraught with problems in the real world, and the time spent doing it right using back-end storage and cookies or similar session ID information will be well-rewarded in the decrease of support problems you run into. Problems caused by the abuse of persistence include older web proxies that do not support persistence breaking the connection and causing your application to not work for anyone behind such a proxy. Even some network address translation devices and load balancing systems can cause mysterious failures of the site. It is also an inefficient use of resources, potentially leading to many more server processes running than are necessary to service requests.
- Keep-alive timeout
The number of seconds Apache will wait for a subsequent request before closing a connection. This option edits the KeepAliveTimeout directive. The default is 15 seconds. A too large value for this directive may lead to performance problems, as many clients may hold open idle connections to Apache processes which cannot exit or process requests for other users, thus they take up resources but remain idle.
- Listen queue length
The maximum length of the queue of pending connections. Generally no tuning is needed or desired, however on some systems it is desirable to increase this when under a TCP SYN flood attack. As discussed in the Processes and Limits section, the listen queue is where requests that cannot be served immediately end up. If this number is exceeded, subsequent requests will be dropped. Correlates to the ListenBacklog directive.
- Addresses for name virtual servers
This option is used to configure the IP address on which Apache will listen for requests to virtual servers. Virtual servers are name based servers, wherein several different domain names can answer on the same IP address. For example, I run two test servers on my local network. One is named liberty while the other is named constitution. Both run on the same server, but they answer on different named addresses and provide different root directories. So a visit to each will bring up different web pages. This, of course, works for real domain names as well (www.nostarch.com or www.swelltech.com, for example). Note that your DNS server, or the DNS server that is authoritative for the domain you wish to run virtual servers on, will also have to have entries for each virtual server you run that resolves to the IP of your server. It is also possible to specify a different port for a given name virtual server to listen on, by appending the port following a colon (i.e., 192.168.1.1:8080 would cause Apache to listen on port 8080 on the given IP. This option affects the NameVirtualHost directive. A tutorial on setting up Apache virtual hosts is provided later in this chapter. Another good source of information on virtual servers in Apache is the Apache Virtual Host documentation.
- TCP send buffer size
Sets the size of the send buffer for TCP packets. It is usually safe to leave this at the default, which is determined by the default of your operating system. This option edits the SendBufferSize directive.
- Request timeout
Defines the maximum number of seconds that Apache will wait for a request after a connection has been established. Correlates to the TimeOut directive.
Apache is designed in a modular fashion, so that the base server can be a small easily debugged application, while nearly unlimited additional functionality can be added easily by loading additional modules. The base process can then be smaller, and only those additional features that are needed can be loaded. This Webmin module allows you to select the available Apache modules that you can load (Figure 7.3, “Apache Modules”).
The first module listed in the figure above is mod_so, which is the module that provides shared object loading at run-time. This module is required if you are using run-time module loading and is the only module other than core.c that cannot be a dynamically loaded module. It must be compiled into the Apache binary at build time if you will be using dynamically loaded modules. Dynamic Shared Objects are not supported by all operating systems, currently, but they are supported by the majority of modern systems including UNIX variants that support loadable .so libraries and Windows systems in the form of DLLs. There are several other modules in common use listed in the above figure, some of which will be discussed below. A good place to go to find out more about available standard modules and third party modules is Apache modules and Apache Module Registry.
Configured modules are loaded into the Apache process on startup, thus it is possible to add new modules without recompiling the server. The modular nature of Apache is one of its primary benefits over other web servers. Without modules, Apache would be just another web server. But because modules are relatively easy to program, the variety available has proliferated, providing functionality for Apache that is unavailable in any other web server product, commercial or Open Source.
Because of the importance modules play in the configuration and management of an Apache web server, it is worthwhile to step out of Webmin for a short time to discuss some of the lower-level details of Apache and its modules. While the usage of these modules via Webmin is discussed throughout this chapter, an overview of the modules will help put the modular structure of Apache into perspective, and hopefully make clearer the interaction between Webmin and the underlying configuration files.
| Note |
|---|---|
The official Apache modules documentation page is an informative, and more comprehensive list of modules that are part of the Apache distribution. Only the most commonly used modules and their purposes will be discussed here. A similar page covers the Apache 2.0 modules. | |
The Apache Core module provides the basic functionality that is required to provide web service as described by RFC 2616. The features in core are always available in any Apache installation, regardless of what other modules are available. Most of the basic network, system and HTTP limits and functions are handled by the core module, and many of the configuration directives are available with no additional modules required.
Beginning with Apache version 2.0, a new model (or more accurately, a number of new models) for handling connection concurrency has been added to the system. Concurrency in Apache versions prior to 2.0 used a model known as connection-per-process, with some enhancements to that model like pre-forking. New versions provide what are known as Multi-Processing Modules which allows Apache to use the concurrency model that makes the most sense for a give operating system. Most UNIX and UNIX-like systems use a module called worker which implements a hybrid model utilizing a pool of multi-threaded processes.
When the worker module is enabled, Apache runs a single control process that is responsible for launching child processes. The child processes spawn a configurable fixed number of threads each, and these individual threads listen for connections and serve them. Threads are lighter weight, or less resource intensive, than real processes, and thus a machine of a given capacity can provide higher throughput from a worker style Apache than from a traditional pre-forking Apache. This was a primary motivation in the development of the new Apache 2.0 service modules.
If your UNIX variant doesn't support threads, or supports them in an incompatible way, Apache will likely use the prefork model instead. Windows machines will likely use the mpm_winnt Multi-Processing module, which creates a single control process which spawns a child process, which in turn creates threads to handle requests. Because Webmin only runs on UNIX-like operating systems at this time, you will likely have no use for the Windows module.
This module provides access control based on client host name, IP address and other information taken from the client request. This module also provides some of the functionality involved in supporting directory .htaccess files to control access to certain parts of the server.
User authentication of several types is supported by Apache. The oldest and most commonly used is supported by this module. It is known alternately as HTTP Basic Authentication or NCSA authentication. This method authenticates users from a plain text file located somewhere on the system. The password file can be generated using the htpasswd program that is included with Apache.
| Note |
|---|---|
To generate a password file using htpasswd, simply run the program with the -c option, a new filename, and the first user name to add to the file: [joe@delilah mydocs]$ htpasswd -c .htpasswd joe This file can then be used by the mod_auth module to authenticate users based on this file. This must be explicitly configured in the Apache configuration file, or in the local .htaccess file. Creating an .htaccess file is discussed in the tutorial section of this chapter. | |
The CGI module must be used in order to run scripts or programs on the server to generate content dynamically for users. It is possible to configure at runtime the file types that will be handled by the CGI module. Configuration of the CGI module can be handled separately for virtual hosts, or it may be applied globally to all virtual hosts on the server, or a combination of global defaults with specific differences in some virtual hosts.
The HTTP specification defines a set of rules for clients and intermediary devices (specifically, web caching proxies, like Squid) to follow when deciding whether to serve a cached document, re-validate the object, or fetch a new copy. A primary method for the website maintainer to dictate the result of these decisions for any given object is the Expires header. This module provides a flexible, and simple method for configuring server wide, as well as per-directory or by file type.
This module provides an extremely flexible (some would say too flexible) means of redirecting user requests to different URLs based on information contained in the request. The basis of this module is a regular expressions based parser and rewriting engine. The URL alterations can depend on a large variety of additional data, including environment variables, client headers, time, external database lookups, and more.
| Note |
|---|---|
To fully understand URL rewriting, it may be worth your time to study the URL Rewriting Guide written by Ralf Engelschall, the original author of the mod_rewrite module. | |
Normally, the HTTP protocol is not encrypted, and thus, not secure from prying eyes at any stage along the request path. Ordinarily, this is OK, and man-in-the-middle security problems of this sort are extremely rare (because the vast majority ISP and backbone administrators are honest folks who have no inclination to snoop on your web browsing habits). However, for extremely private matters, such as online banking, investing, or making online purchases, it is important to have a more secure means of communication. The solution is Secure Sockets Layer, also known as simply SSL. The Open Source implementation is called OpenSSL, and it is the core of the mod_ssl Apache module.
To use SSL connections, you must generate or purchase an SSL certificate from one of several Certificate Authorities. A locally generated certificate can be used for authentication within a company, or for a small number of users whom you already have a trust relationship with. However, if your secure site will be used by a number of users who have no direct relationship with you, a certificate from a trusted certificate authority will be required so the user will know that the site is operated by who it claims to be.
| Note |
|---|---|
Certificate Authorities, or CAs as they are often called, supported by most modern browsers include VeriSign, GeoTrust, and Thawte Consulting in the US. Options outside of the US include Internet Publishing Services and BelSign. | |
In many web hosting environments, a single server is shared by a number of users, and it would be inappropriate to allow the files of all users to be viewed by any other user. Because CGI scripts are run, by default, with the permissions of the web server itself, and the web server must have access to all content and scripts, it would be possible for a malicious user to use a CGI script to browse the contents of any other users private directories using Apache as an intermediary. In order to combat this problem in virtual hosting environments, the server may be configured to run CGI scripts as a specified user rather than as the more privileged Apache user (usually nobody). This module makes this feature possible by performing a suexec function on the created process when CGI scripts are run. There is some complexity in this solution, and many security pitfalls to beware of, but it is a required step to providing a secured virtual hosting environment with CGI script capabilities.
MIME Types is the method by which the server, and its clients, know what type of data a given object is. This information is generally more important to the client, as they must know how to interpret the data where the server only needs to send it to the client along with MIME identification information. MIME, or Multipurpose Internet Mail Extensions was originally defined to easily allow sending of data other than text via email. It has now become the standard method for many types of network connection to declare data type. The MIME Types module merely provides a list of the currently accepted MIME types, and their optional extensions. At the bottom of the page, the Add a MIME type link allows you to add new MIME types easily (Figure 7.4, “Apache MIME Types”.
A great resource for more information on MIME types can be found at the MIME Page maintained by Earl Hood. Links to relevant RFCs as well as a MIME FAQ can be found there.
The Miscellaneous options page is just what it sounds like (Figure 7.5, “Apache Miscellaneous Page”. It's the global options that didn't seem to fit anywhere else. As such, there aren't very many fields on this page, but nonetheless there are a few items of interest.
- Core dump directory
This is the directory where Apache will send its core dump file, in the event of a crash. By default this will be the same directory as the Apache servers root directory. However, the server process will not normally have write access to this directory, so in order to get a core dump on crashes, it is necessary to change it to a directory that is writable by the Apache process. Core dumps are often used for debugging purposes. This option affects the CoreDumpDirectory directive.
- Server lock file
This sets the location for Apache's lock file to the file named. A lock file is the file that is used to notify a new instance of a process that one is already running. This prevents Apache from trying to start again, using the same configuration, if it is already running. Note that if you use a different configuration, and a different lock file, it is possible to start multiple instances of Apache. This option corresponds to the LockFile directive.
- Server PID file
The PID file for Apache. Edits the PidFile directive.
- Shared memory scoreboard file
Some architectures require a file for the children and parent processes can communicate. For performance this can be placed on a RAM disk. This corresponds to the ScoreBoardFile directive.
- Server HTTP header
This option allows you to set the data that will be contained within the HTTP header. This corresponds to the ServerTokens directive.
- Server execution
Defines how the server will be started. Standalone indicates that it will run as a standalone daemon, while Run from inetd will cause it to run periodically, as called by the inetd daemon. It is strongly recommended to avoid the inetd option, as it does not always work as expected. This option edits the ServerType directive.
CGI, or Common Gateway Interface, provides a means for a website to have dynamic, program generated, content on a web page. CGI programs can interact with the user through the use of input fields and can provide different data based on the information returned. CGI programs can be written in nearly any language, though it is most common for them to be written in Perl, PHP, Python, Java, C, and bash or other shell scripting languages. The CGI Programs module provides an interface to the global CGI options of Apache (Figure 7.6, “Apache CGI Programs”.
- CGI Script log
Is the log directory for the CGI script error log file. If none is given, no log is created. Edits the ScriptLog directive.
- Maximum logged post data size
Data from a PUT or POST request to a CGI script that is written to the error log file can be limited in size, because PUT and POST requests can be extremely large. The default is 1024 bytes. This option correlates to the ScriptLogBuffer directive.
- Maximum CGI log post size
Limits the size of the CGI script log file. When the log file exceeds this size, no more errors will be written to the log file. Corresponds to the ScriptLogLength directive.
- Variables set based on browser type
If the server should set some environment variables differently depending on the client browser type, it is possible to enter that data here. This option edits the BrowserMatch directive. Note that the mod_setenvif and mod_browser modules should be loaded when using these features.
- Variable set based on request headers
Allows you to set environment variables based on attributes of the request. This corresponds to the SetEnvIf directive.
Apache offers the ability to modify many global settings on a per-directory basis (Figure 7.7, “Per-Directory Options File”. This module provides access to that feature. To create an options file for a directory, simply enter the path and filename in the field and click Create Options File. By convention these files are called .htaccess, but that is a configurable option in Apache. This file also allows configuration of per-directory authentication among other access control features.
More information on options files can be found in the Apache docs under the Options directive.
The lower half of the Apache page contains a list of configured virtual servers (Figure 7.8, “Virtual Servers”. Each virtual server entry on this page shows the address and port the virtual server listens on, the server name, and the document root. Clicking on the icon for the virtual server will bring you to a page filled with many new options and many of the same options found in the Global section discussed earlier. The options that are repeated from that section generally behave the same, and so are not covered again.
It's important to remember that each virtual server has its own configuration. While it is possible to set default behaviors by editing the Default server (the first in the list of Virtual Servers, each virtual server may have configuration directives that override the default behavior. Each may have its own directory structure, server settings, MIME types, logging configuration, and more. Apache provides near infinite options, and most of those can be applied to any individual virtual server, as well as to the server as a whole.
Logs provide a window into the operation of your web server, and Apache provides a great set of logging options so you can keep up with what your server is up to. In short, Apache allows you to configure each virtual host as though it were an independent server. This includes the ability to independently log information to a separate file and in a custom format.
| Caution |
|---|---|
Beware that there are particular security issues associated with logging in Apache. Because any logging helper programs will be started as the user that started Apache (usually root), the program must be secure. A good resource for further security information is the Security Tips section of the official Apache Documentation. | |
- Error log to
This sets where Apache sends error information for this virtual server. Usually this goes to the syslog daemon, which writes it to the primary web server error log. However, Apache can send this to an alternate logging program, or to a file. This option configures the ErrorLog directive, and usually defaults to logging to the syslog daemon, if available.
- Browser log file
Here you can define whether Apache will keep logs of the user agents (browsers, most often, though robots and autodownloaders will show up also) that access the web server. This information is usually only of passing interest, except perhaps when you're thinking of implementing some technology that is incompatible with some browsers (like Flash, Shockwave, and a host of lesser known and even less widely accessible data formats). Reviewing these logs will often remind you of what percentage of your clients such technologies may alienate. Agent information not logged by default. This option configures the AgentLog directive.
- Default log format
This option allows you to configure Apache to write logs in an arbitrarily chosen format. If you want Apache to log in the Common Log Format you simply leave this on the default. However, to log in a different manner, you would select the Format choice, and fill in the field with either a nickname of a named log format (discussed next) or with a log format string. This option configures the CustomLog directive.
- Named log formats
A named log format is a custom log format, as discussed above, that has been defined and given a nickname for use by other log directives. A custom log format is created by entering a series of variables to indicate the data fields that should be present and the order in which they will appear. For example, a custom log type that mimics the Common Log Format looks like this:
%h %l %u %t \"%r\" %>s %b
This option configures the LogFormat directive.
- Access log files
Here, you can define additional locations, formats, or programs, for Apache to send logs to. Configuration is much like the Default log above, except that you may have any number of access log files. This allows you, for example, to log accesses of images to a separate file, or to log visits to another format for processing and analyses. This option correlates to the TransferLog directive. Beware that the same security implications that effect all of the other logging directives effect this option as well.
- Don't log references from
This option adds the host names provided to a list of hosts from whence referral information will not be logged. For example, if I wanted my web server at penguinfeet.org to ignore referrals from my other web page, swelltech.com, I would enter swelltech.com here. Then, my statistics wouldn't be skewed by the large number of referrals from my own pages. This option correlates to the RefererIgnore directive.
- Referer log file
Here you define where referer information is logged to. This can be a file, or a program. This option configures the RefererLog directive.
Here you have access to many of the virtual server specific options that will effect permissions, locations, and behaviors.
The first field of this page has no label. It is the document root. This is usually set when the virtual server is created, and is created automatically by Webmin. This option correlates to the DocumentRoot directive.
- User WWW directory
Here, you configure the location where users can publish HTML documents via Apache. The syntax has several forms that perform different types of expansion to create the actual path. First, a relative link, of the form htmldocs translates for user joe to ~joe/htmldocs. An absolute link, such as /usr/htmldocs will translate to /usr/htmldocs/joe. Finally, it is possible to use an * to represent the username in the translation. For example, /home/*/htmldocs, will translate to /home/joe/htmldocs. This option configures the UserDir directive.
The following fields are continued options connected to the above User WWW directory option. They control which users' directories will have the translation performed. Selecting All users accessible means that for any username entered in the URL, the translation will occur and the users web directory will be browsable. All users except allows you to disallow some users, while the rest are translated. This could be used, for example, to disable the website of a user who violated the terms of service. Finally, Only users means that only those users explicitly named will have directory translation performed.
- Per-directory options file
Here you can specify a filename to be checked for directory access options. Unless prohibited elsewhere in Apache's configuration, options found in a file by this name in any directory will override the default permissions for that directory. For example, if I chose the filename .acl, and in one of my directories I created such a file that included instructions to Generate directory indexes, then for that directory such indexes would be generated. This would apply even if the default with to not generate indexes. If you are operating a virtual hosting server, this can allow your users to have some freedom in the behaviour of the web server for their individual site, without interfering with or altering the behaviour of other sites on the same server. This can be thought of as one more layer of the onion of configurability that is Apache. This option configures the AccessFileName directive and defaults to .htaccess.
- Directory options
Here, you can choose to use the default options for this directory. This effects the root directory for your virtual server and all subdirectories, except those the contain and AccessFileName file as discussed in the Per-directory options file section above. This option correlates to the Options directive and defaults to all, except for Generate Multiviews.
The available directory options are as follows:
Available directory options
- Execute CGI programs
Allows execution of CGI scripts located in this directory.
- Follow symbolic links
The server will follow symbolic links in this directory. This correlates to the ExecCGI directive.
- Server-side includes and execs
Server-side includes are permitted. This correlates to the FollowSymLinks directive.
- Server-side includes
Permits server side includes, but disallows #exec command and the use of #include for CGI scripts. This correlates to the IncludesNOEXEC directive.
- Generate directory indexes
When a URL maps to a directory in which there is no index html file (usually index.html, but this is a configurable option), then Apache can generate a formatted file list for the directory. This option correlates to the Indexes directive.
- Generate Multiviews
Content negotiated multiviews are permitted. This allows for multiple languages, character sets, a presentations to be referenced by the same URL. The client browser then negotiates with the server to select the appropriate one for the user. For more, see Content Negotation. This option correlates to the MultiViews directive.
- Follow symbolic links if owners match
Apache will only follow symbolic links for which the target file or directory ownership matches that of the link. This option correlates to the SymLinksIfOwnerMatch directive.
Note that if multiple items apply (inherited from a parent directory), then the ones specific to the selected directory apply, unless Merge with parent is selected. For example, if /home/httpd/penguinfeet has All permissions, but the subdirectory /home/httpd/penguinfeet/users has only ExecCGI, then that directory would only have the execute CGI option available. Merging with the parent however, gives the subdirectory the same options, except where explicitly turned off.
- Generate MD5 digests
This option turns on generation of Conten-MD5 digest headers. When enabled, Apache will generate a message digest, or fingerprint, for each static page served. When using MD5 digests, the client can be assured with a very high degree of confidence that if the content has been altered during transit from the origin server those alterations will be reflected in alterations in the message digest. The Content-MD5 standard is described in RFC 1864 and RFC 2616. This option configures the ContentDigest directive. Be aware that this option can have performance implications, since the digest is generated for each request, and digests will not be created for any requests that are served by modules.
- Generate ETag header from
ETag is an HTTP response header to provide a means of differentiating two or more objects with the same URL. The header is useful for intermediary devices that perform caching, as well as client browsers that cache results. Using the ETag, an object can be uniquely identified to the client. Usually, Apache generates the ETag based on the i-node number of the file, the last modified time of the file, and the size of the file. If Select attributes is chosen, you may select any or all of these criteria. This option correlates to the FileETag directive.
- Virtual server path
Very old browsers and proxies cannot address name based virtual servers, and know only how to request a site by its IP. This leads to the unfortunate effect that those browsers will only be able to reach the default website on a given IP. A workaround for this problem, is to provide a path from the default server to each virtual server. Using this directive, you can define where in the path of the default server this particular virtual server will reside. So, if my virtual server www.penguinfeet.org resides on a server at IP 123.45.67.89, and an older browser visits that name, it will end up browsing to the default server on the host--which can provide the user with a list of links to virtual servers hosted on this server. If this were set to /penguinfeet, the link would then take the user to http://www.penguinfeet.org/penguinfeet/ which is the correct page! Not exactly pretty, but the web wasn't always as well thought out as it is today. And who can blame the original designers of the web for not realizing the one day everyone would have their own domain name! The good news is that those old web clients are simply no longer in use in any statistically significant quantity (they don't show up on any of my web server logs, anyway, your mileage may vary). This option configures the ServerPath directive. For more on Virtual Hosts and the potential issues, see also the Apache Virtual Host Documentation.
- Error message footer
This option allows you to add a footer to all server generated documents (such as error pages, mod_proxy ftp directory listings, mod_info output, etc.). This is usually only needed when your Apache is acting as a proxy, as it is most useful in discovering where an error message originates from in a chain of multiple proxies. This option configures the / ServerSignature directive and defaults to Off.
- Automatically correct misspelled URLs?
This option configures whether Apache will attempt to correct user spelling errors in the URL. If enabled, and a URL does not match a document on the server, a check will be performed of all of the objects available that could possibly match the users request. If one object is found that closely matches what the user requested, for example if there was incorrect capitalizations but the object is spelled correctly or only one letter is missing, Apache will silently redirect the user to the corrected URL. If multiple possible matches are found, the user will be redirected to a page containing a list of possible pages so they may select the correct page. If not possible matches are found, the request traverses the normal error path and will result in a 404 not found error. This option correlates to the CheckSpelling directive and defaults to off.
In the event of a server error, Apache can be configured to provide custom error messages, or redirect to a local or external URL, or by default output a simple hardcoded error message. Here, you may configure any error types for which you'd like to provide a custom message. So, for example, if you wanted a custom 404 message that directed users to a local site search page (a convenient and polite thing to do), you could do that on this page. To configure the custom error responses feature of Apache, simply enter to error code, and then enter the URL or message to be displayed. See the Custom error responses documentation for more on this feature.
This page configures the user and group under which the Apache server will run. This sets the privileges the Apache and child processes will have while operating. It is strongly suggested that you set this to a user and group with as little privilege as possible (while still allowing the server to do its job). This is often configured to nobody and nogroup on many UNIX operating systems, and this is a good choice in most cases. Do not set this to root unless you know exactly what you're doing, and the security implications of doing so. Note that the Apache parent process, if started as root, will remain as root, while the child processes that actually service requests will run as the user and group set here. If the parent process is started by a non-root user, Apache will not be able to su to another user, and so will run as the user that started the process. This option configures the User and Group directives.
Apache provides several forms of alias and redirection. This allows you to present more unified or simpler paths to your users in the URL, as well as serve objects from outside of your servers root directory. It also allows you to redirect users to a new website during a transition period, or direct their browser to the correct link if directory structure has changed.
- Document directory aliases
This allows objects to be stored in directories other than the root directory. Be aware the aliases that end in a / will require the slash in the requested URL to be translated. This option correlates to the Alias directive.
- Regexp document directory aliases
This option is very similar to the above, except that it allows the use of regular expressions to match paths to be translated. This option correlates to the AliasMatch directive. For more on regular expressions, consult the regex man page.
- URL redirects
This option redirects an old URL into a new one. The new URL is returned to the client, which will attempt to fetch again with the new address. You can also specify a status message for the redirect, which can be one of several HTTP status codes, as described below. This option configures the Redirect directive.
Redirect status codes
- 301
Moved permanently.
- 302
Moved temporarily.
- 303
See other, meaning the resources has been replaced.
- 410
The object is no longer available. When this status is used, the redirect To URL should be omitted.
- Regexp URL redirects
This option behaves exactly like the above, except the From field can contain a regular expression to match. This option correlates to the RedirectMatch directive.
- Permanent URL redirects
This option behaves as the above URL Redirect with a status of 301 (moved permanently). Correlates to the RedirectPermanent directive.
- Temporary URL redirects
This option behaves as the above URL Redirect with a status of 302 (moved temporarily). Correlates to the RedirectTemp directive.
- Map local to remote URLs
This option allows a remote server to be mapped onto the space of the local server; the local server does not act as a conventional proxy, but appears to be a mirror of the remote server. For example, if the Local URL is /mirror/otherdomain and the Remote URL is http://www.otherdomain.com then users will be able to access http://www.otherdomain.com via http://www.thisdomain.com/mirror/otherdomain. This option corresponds to the ProxyPass directive.
- Map remote Location: headers to local
This option provides roughly the reverse functionality of the previous option. It adjusts the location header on HTTP redirect responses, which is necessary when Apache is being used as a reverse proxy in order to avoid having the reverse proxy bypassed by a redirect request. This option configures the ProxyPassReverse directive.
An index in Apache is simply a page that is displayed when a client browses to a directory on the server rather than an object or document. For example, if someone browses to my Squid patches directory on my server, which is located at http://www.swelltech.com/pengies/joe/patches/, Apache will serve an index page. If there is no file in the directory that matches Apache's definition of an index page, it will instead generate an index page containing a file list, or it will serve an error page, if index generation is prohibited. This page allows you to configure the behavior of Apache when displaying index pages.
- Directory index options
This option sets the appearance and information contained in Apache-generated indexes. This option configures the IndexOptions directive. The following options are available:
- Display fancy directory indexes
This turns on fancy indexing of directories, which means that icons will be provided for files and directories. This configures the FancyIndexing sub-directive.
- Display HTML title as description
If files within the directory contain HTML title information, those titles will be displayed as the filenames for their respective files. This option configures the ScanHTMLTitles sub-directive.
- Icon height
This sets the height of the icons in fancy directory listings. This correlates to the IconHeight sub-directive.
- Icon width
This sets the width of the icons in fancy directory listings. This correlates to the IconWidth sub-directive.
- Allow user sorting of columns
By default, Apache will generate listings that can be sorted by the user by clicking the column headings. If you do not wish for users to be able to sort by last-modified date, or size, then you may disable this, and no sorting links will be provided. This option configures the SuppressColumnSorting sub-directive.
- Show file descriptions
Enable this to display descriptions of the files in the fancy index listings. This option correlates to the SuppressDescription sub-directive.
- Output HTML header tags
If using a header file (also configured on this page) for directory indexes, you may choose to allow Apache to output a standard HTML preamble containing enough to start a legal HTML page. If this is disabled, your header will have to contain its own preamble to make it into a legal HTML page. This option configures the SuppressHTMLPreamble sub-directive.
- Show last modified times
By default, Apache will display the last modified time of each file in a generated index. Unselecting this option will cause Apache not to do so. This option configures the SuppressLastModified subdirectory.
- Show file sizes
This option is much like the previous option, except that it allows you to disable display of the size information about the files listed in a generated index. This option correlates to the SuppressSize sub-directive.
- Include icon in link
This will cause Apache to display icons as part of the link. This option configures the IconsAreLinks sub-directive.
- Filename width
Here you may configure the number of characters Apache will display in the filename of indexes. This option correlates to the NameWidth= sub-directive. If this is set to * Apache will set the length to the length of the longest filename in the directory.
- Description width
The number of characters that will be displayed in the description field of generated indexes. This option correlates to the DescriptionWidth= sub-directive. As above, if this value is set to * the description length will be set to that of the longest description in the directory.
- Display directories first
You may choose to have Apache sort the listing such that directories are listed first in the index. This option corresponds to the FoldersFirst sub-directive.
- Directory index files
Here you configure the filenames that Apache will look for when entering a directory, and if one of them exists it will be displayed as the index of the directory rather than an auto-generated file index. This file will be displayed to clients who request any directory on the server by specifying a / at the end of the URL. This may be any filename or list of filenames, though those used by convention include index.html or index.htm on operating systems with filename limitations. It is now not uncommon to use script suffixes on index pages, such as index.pl, index.cgi, or index.php. This option correlates to the DirectoryIndex directive.
- Files to ignore in directory index
If an auto-generated index is being displayed, you may specify files that are not to be listed in the index. This option configures the IndexIgnore directive.
- Directory index default icon
Apache will automatically add icons to index listings when the file types of files are recognized. When no icon is known for a file type, you may configure an icon to be displayed here. This option correlates to the DefaultIcon directive.
- Directory index header file
Indexes may have a custom header file attached to them using this option. The file may either be a plain text file, or an HTML file. This option correlates to the HeaderName directive.
- Directory index footer file
Sets the path to the file to append to the end of an index. This option corresponds to the ReadmeName directive.
- Sort directory index by
This option allows you to select how Apache will sort the entries on the index page. The order may be Ascending or Descending, and it may sort based on the Name of the file, Date of last modification, Size of the file, or the Description of the file. This option correlates to the IndexOrderDefault directive and defaults to sorting by filename in ascending order.
- Directory index icons
Here you may select the graphic icons that will be displayed beside filename links in the fancy directory listing index pages. The Icon is the relative path to the image file. The Alt text is the text to be displayed if the clients browser does not support images. Match by is the attribute to match against when deciding which icon will be displayed, and it can be one of Filename, MIME type, or Encoding. The Filenames, Types, or Encodings is simply the terms to be matched for this icon type to be displayed. This option configures the AddIcon, AddIconByEncoding, and AddIconByType directives. When matching against the filename of the MIME type, you can use wildcards to match any of several variations. For example, to match all backup files (as generated by ispell and other software), you could use the file match *~. Or, for a MIME type wildcard example, to match all images types, you could use image/*. It is generally recommended to match based on the MIME type rather than file extensions, when possible, as it tends to be less prone to missing files of certain types or misidentifying a file type.
Note When adding a filename matched icon, there are a couple of special names that allow you to match directories and blank lines (Apache uses blank lines to format the list). These are ^^DIRECTORY^^ and ^^BLANKICON^^, respectively.
- Directory index ALT tags
Much like the previous option, this option allows you to configure the text to be displayed for files instead of icons. The possible values and wildcard usage are the same as for the previous option. This configures the AddAlt, AddAltByEncoding, and AddAltByType directives.
- Directory index descriptions
Here you may define what descriptions will be displayed for a given filename extension. The length of this will be limited by the Description width option discussed above. This option configures the AddDescription directive.
Image maps provide a method to make images clickable in regions, where each region results in a different URL. Options on this page dictate default paths for image map URLs, actions to take on clicks within image maps, and the handling of error conditions.
- Default base for imagemaps
This option sets the base directory for image maps. If this is not set, the default is http://servername/. This correlates to the ImapBase directive.
- Default action for imagemaps
Sets the default used in image map files. This will be overridden by a default directive within the image map file. The default is nocontent or Do nothing which sends a 204 No content message to the browser. The browser should continue to display the original page. This option correlates to the ImapDefault directive.
- Action on incorrect use of imagemaps
This option determines what action Apache should take if an image map file is called without valid coordinates. This correlates to the ImapMenu directive. The options are as follows:
Imap Menu Options
- none
If ImapMenu is none, no menu is generated, and the default action is performed.
- Show formatted menu
A formatted menu is the simplest menu. Comments in the image map file are ignored. A level one header is printed, then an hrule, then the links each on a separate line. The menu has a consistent, plain look close to that of a directory listing.
- Show semi-formatted menu
In the semi-formatted menu, comments are printed where they occur in the image map file. Blank lines are turned into HTML breaks. No header or hrule is printed, but otherwise the menu is the same as a formatted menu.
- Show unformatted menu
Comments are printed, blank lines are ignored. Nothing is printed that does not appear in the image map file. All breaks and headers must be included as comments in the image map file. This gives you the most flexibility over the appearance of your menus, but requires you to treat your map files as HTML instead of plain text.
For more on image map files in Apache visit the mod_imap Module documentation.
This page configures the mod_proxy module, which allows Apache to act as a full-featured HTTP proxy. While Squid is a higher performance and more featureful option in most cases, Apache can also provide some interesting functions and features for proxying and reverse proxying in very simple environments. For additional information on proxying with mod_proxy see the mod_proxy module documentation. Generally, however, if you need HTTP proxying, or web caching, Squid is a far better choice, and usually no more complicated to configure.
- Act as proxy server?
This option simply turns proxying on or off in Apache. This is not required for passing requests on to another server using the ProxyPass directive, which was documented briefly in the Directory Options section, and also is configurable on this page. This option correlates to the ProxyRequests directive, and defaults to off
- Cache directory
This option sets the directory where cached files will be stored. This directory must be writable by the server. If this option is not set, proxying will still function, but not caching will occur. This option correlates to the CacheRoot directive and defaults to none.
- Block requests to domains
Provides a simple means of access control, wherein any domain or domain containing a word listed will be inaccessible through the proxy. The sites listed will be blocked even if the site is accessed via IP address, as Apache will resolve the names on startup and cache the IP information. This option correlates to the ProxyBlock directive and defaults to none.
- Requests to pass to another proxy
This option configures remote proxies that requests will be sent to if the request contains the words or domains in the match field. This option correlates to the ProxyRemote directive and defaults to none.
- Don't pass requests to another proxy for
Here you can configure any number of domains, IP addresses, IP subnets, or host names that will not be forwarded to another proxy via the above option. This option correlates to the NoProxy directive, and defaults to none.
- Domain for requests with no domain
This option is useful for proxy servers on intranets. It allows you to configure a domain name to be redirected to if a request is encountered without one. This option correlates to the ProxyDomain directive and defaults to none.
- Domains not to cache
If caching is enabled above, here you can select some number of domains that will not be stored on the local proxy. This is useful for local domains, for which no benefit would be gained by locally caching the content thereof. This option configures the NoCache directive and defaults to none.
- Ports to which CONNECT is allowed
This option dictates which ports Apache will allow the proxy CONNECT method on. This method is used to set up a tunnel for https connections. This option correlates to the AllowCONNECT directive and defaults to ports 443 (https) and 563 (snews). Enabling this option overrides the default, so if you add ports here, you must include at least the https port for secure connections to work correctly through your proxy.
- Cache default expiry time
If an object is fetched via a protocol that does not support expiry times (such as ftp), or no expiry time is present, the cached data will be stored the specified number of hours. This option configures the CacheDefaultExpire and defaults to 1 hour.
- Cache directory name length
Sets the number of characters in proxy cache subdirectory names. This option correlates to the CacheDirLength directive and defaults to 1.
- Cache directory levels
Sets the number of levels in the proxy cache subdirectory hierarchy. This option correlates to the CacheDirLevels directive and defaults to 3.
- Finish and cache transfer after
If a transfer is canceled before completion, but after this percentage of the object has been received, Apache will continue to fetch the object in order to cache the complete object. Entering 0 here will cause the default to be used, and 100 will not store an object unless the whole transfer was completed. A number between 60 and 90 is suggested. This option configures the CacheForceCompletion and defaults to 90.
- Cache garbage collection interval
If this is configured, Apache will perform periodic garbage collection, wherein it deletes files if the space used for cached objects is greater than the configured Cache size. This option accepts floating point values, so can be configured to perform garbage collection every 30 minutes, for example, by entering 0.5 here. If this is unset, the cache will grow indefinitely. This option configures the CacheGcInterval and defaults to none.
- Cached file expiry time factor
If the origin HTTP server does not provide an expiry time for the object, Apache can estimate one by multiplying the time since the last modification by this factor. This option configures the CacheLastModifiedFactor directive, and defaults to 0.1.
- Cached file maximum expiry time
After an object has been stored for this many hours, Apache will check for new content with the origin server, even if the expiry time supplied by the origin server has not yet been reached. This option configures the CacheMaxExpire directive and defaults to 24 hours.
- Cache size
Assuming garbage collection has been configured, Apache will restrict the size of the cached object storage directories to this number of kilobytes. This option correlates to the CacheSize directive and defaults to 5 KB.
This page allows you to reconfigure the basic configuration details of your virtual server. For example, if when you created your virtual server you placed it on port 8080 for testing, but now want to move it over to port 80 for production, you can perform that update here.
- Address and Port
If your system has multiple interfaces, Apache will answer on any of them by default on port 80. However, you can configure your virtual server to only answer on one address using this option. You can also configure a different port here.
- Document Root
This is the root directory, from whence the paths to access objects on your server will begin. This option configures the DocumentRoot directive.
- Server Name
When using name based virtual servers, this name should match the name under which this server should answer. This is also used when creating redirection URLs. If not specified Apache will try to deduce it from the IP address, which isn't always reliable. This option correlates to the ServerName directive.
Apache is an extremely large and feature-rich piece of software. Approaching it for the first time can be daunting. Luckily, it is extremely easy to install, configure, and maintain as long as you proceed with care and pay attention to the documentation relevant to your installation and environment. Installation of Apache is not covered here, as it is well-documented on the Apache website, and it is also very likely that your OS vendor provides a suitable package to make installation automatic. What will be covered is the initial hurdle of setting up Apache to serve HTML web pages. The next section will take the configuration one step further to configuring virtual hosting service. Later, a section in the BIND module chapter will cover adding name service for your web server.
| Note |
|---|---|
If you've installed Apache from a package from your OS vendor or if your vendor does not provide a package and it has been installed in the default location selected by the program, you can probably skip this section and proceed to the next section covering initial module selection. For any supported OS, Webmin has a configuration file that includes sensible default paths for the programs that it administers. These configurations assume an installation in the default location for your operating system. So, for example, on a Red Hat Linux system, Webmin will expect to find the httpd.conf file in the /etc/httpd/conf dircetory, while on Solaris it is expected to be in /usr/local/apache/conf. | |
Webmin works directly with the Apache configuration files, and so must know where to find them. When you browse to the Apache module of Webmin for the first time you may be greeted with an error stating that the configuration file could not be found. You'll need to locate the configuration files, as well as the Apache binary, and possibly startup and shutdown scripts for your system, and configure Webmin to search the appropriate locations. The most important paths are probably Apache server root directory and the Path to httpd executable.
Apache is extremely modular, and the vast majority of its available functionality is broken out into small modules that can be loaded at run-time depending on the needs of the specific environment in which it runs. Webmin needs to know about the modules that are available to your Apache so that it can provide configuration options for options that are available and hide options that are not. So, the first time you visit the Webmin Apache module, you'll be presented a list of Apache modules with check boxes beside them. If you've used a package or a default Apache source installation, you can simply click Configure. If you've built your Apache from scratch with customizations, you'll need to choose the modules that you have made available in your installation, and then click Configure.
Believe it or not, we're now very nearly ready to serve up content with Apache. Once you've reached the primary Apache module page in Webmin, you'll see a set of icons for the global server options as well as a single virtual server configuration section labeled Default server. The default server is the server that will answer a request when no other virtual servers do. Because we have no virtual servers configured on our system yet, the default server will answer all HTTP requests that reach our machine. Take note of the path in the Document root field, as this is where we'll be placing our first web page.
On my system the Document root for the default server is /var/www/html, which was automatically created during the installation process. So I will create a web page called index.html and drop it into that directory, making sure the page has permissions that will allow the Apache process to read it. The name index.html is significant, and you must use the correct filename for your default page, or else Apache won't serve it without having the file specified after the address in the URL. Other common names for the index page are index.htm and default.htm.
Now all that is left is to startup your Apache server. Assuming Webmin has been configured correctly for your installation it can even be started from within Webmin with the click of a button. Simply browse to the Apache module main page, and click the Start Apache link in the upper right corner of the page.
To test your new website browse to the IP on which your server resides with your favorite browser. For example, my testing server is located on IP 192.168.1.1, so I would enter http://192.168.1.1 into my browser URL field. Assuming everything went right, you'll see your new web page.
In the real world, it is rare to only operate one website on a machine. For all but the most demanding websites, it would be a waste of resources to do so, because a single modest computer can serve hundreds or thousands of web requests every minute without much effort. It would also be a waste of the finite IP space on the Internet, as there is a fixed number of IP addresses available and the majority of them are already in use. To solve both problems Apache provides a feature known as name-based virtual hosts. With name-based virtual hosts, you may serve hundreds or thousands of websites, each with their own domain name, from a single machine running on a single IP!
| Note |
|---|---|
The terms virtual host and virtual server are generally interchangeable for our purposes. The terminology is constantly shifting, however, and you may hear the terms used differently in different contexts. In our case, the terms have the same meaning, but the term virtual host may be used to indicate a concept, while the term virtual server will generally be used to indicate a specific configuration detail. | |
In this short tutorial we will convert our existing default server into a virtual server, and create a new server that can be hosted alongside our first website on a different domain name. With the mention of domain names, you may have realized we won't be able to test our new virtual servers until domain name service has been configured. Luckily, there is a short tutorial for that as well in the BIND chapter to which you can refer when you are ready to try out your new virtual hosts.
The first step to using virtual servers in a generic, and thus easily scalable and flexible manner, is to convert our already configured default server to a virtual server. Though this isn't strictly necessary to make this change, it is common practice to instead provide an appropriate error page, or a page of links to all of the virtual hosts on the machine using a traditional URL syntax for web clients that are incompatible with name-based hosts (however extremely rare such clients may be). Because the default server will be used in the event no virtual servers match, it could also be left as-is, with all other hosts being configured using the virtual hosts mechanism.
To create a new virtual server, fill in the form at the bottom of the primary Apache module page. You may leave the address and port empty and select the Any option for the address, unless your server has many IP addresses and you only want this virtual host to respond on one of them or you want this virtual host to respond on one ore more non-standard ports. For our example setup, we'll just leave them empty.
The Document Root can be any directory on your system to which the Apache process has read access, however there are some conventions that you can follow in order to make your server more immediately comprehensible to subsequent administrators. If all of the virtual servers on your system are to be under the control of your company, and you will be administering all of them yourself, it is wise to place all of the document roots into subdirectories of whatever the default server document roots parent directory is. For example, on my system the default document root is /var/www/html, so it makes good sense for my virtual server document roots to reside in subdirectories of /var/www. The more common convention, however, is used in environments where many users will be maintaining many websites, and none of the users should have access to the other users website directories directly. In this case, the normal practice is to place the document root into the users home directory, in a sub-directory called htdocs or www.
Finally, fill in the server name, which is the domain name on which you'd like this server to answer (Figure 7.9, “Creating a new virtual host”). If you don't happen to own a domain that can be used for experimenting, you can simply make one up. We'll be configuring our own local domain name server later on, so there are no rules about how you have to name it. You could call it google.com, or whitehouse.gov, or just george, if you wanted to. However, since it is likely you intend to put the server online for production use at some point in the future, you'll likely just name it whatever domain name it will be at that point. In my case, I'd call it swelltech.com.
Click Create. Now move your content from your default server document root directory into your new document root. In my case it is /var/www/swelltech.com. After applying the changes to your server, your Apache configuration should be finished, though we'll tackle a few more small issues before calling it done.
| Note |
|---|---|
To test your new virtual server, you can't simply browse to your IP as you did in the previous tutorial. The browser request must contain the domain name for the virtual host in the URL. There are a couple of ways to achieve this. The first is to configure a local name server to temporarily provide name service for your new domain, the second is to setup your system hosts file to point to the appropriate IP for the domain name. The easiest is obviously to add it to your hosts file. You can do this in Webmin, if your client machine is a UNIX machine running Webmin, using the Networking:Network Configuration:Host addresses module. On a Windows client machine, you'll need to edit the hosts file manually. It is located in c:\windows\hosts on Win98 and Me, c:\winnt\system32\drivers\etc\hosts on WinNT, 2000, and XP Pro, and c:\windows\system32\drivers\etc\hosts on XP Home. The more interesting and educational method is to configure BIND to serve your new address, and then configure your client to get name service from the newly configured BIND. This is documented later in the BIND chapter, feel free to skip ahead and work through that tutorial now. I'll wait for you here... | |
Perhaps you noticed when we configured the above virtual server, it was named simply swelltech.com. Did you wonder why I didn't call it www.swelltech.com instead? The reason is simple: I'd like for users to be able to browse to either address and get the same website. So I named the virtual server swelltech.com, and now a new server alias can be added to cause it to answer on both names. To add a new virtual server name to an existing virtual server, click on the icon for the virtual server on the main Apache module page. Then click the Networking and Addresses icon. Now fill in all of the other domain names on which you'd like your website to appear. Note that these names must each have their own DNS record for users to be able to use them, just like the original swelltech.com name. Every additional host name in the domain is a new address, so www.swelltech.com and mail.swelltech.com have to have their own name record in the name server even if they are on the same machine.
Tidak ada komentar:
Posting Komentar