|
This simple list of directives and their associated values define how the Apache web server will handle requests. Because of its simplistic nature, most administrators responsible for managing a single instance of Apache choose to manage the web server manually rather than use a management tool that provides additional functionality.
An administrator of a typical Apache server manages the configuration by manually changing the contents of the configuration file. For a single instance of the web server or even a small number of servers, this method of administering the server is tolerable. But it becomes much more tedious in a web farm environment. If a directive needs to be changed on all servers, or a new module needs to be [Figure-1, Apache’s HTTPD.CONF file]
loaded, each server’s httpd.conf file will need to
be opened, changed, and saved.
Apache must then be restarted so that the changes can be applied.
Some alternatives to manual administration have been proposed and some have been implemented. But for the most part, these alternatives are platform specific and can only be run on a machine that has direct file access to the httpd.conf file. Some of these solutions provide a simpler user interface and perform some simple tasks during configuration file management, but they only solve the problem for a single localized Apache server. The real problem of easily administering an Apache web farm still exists. The answer to this problem is couched within in a directory-based approach to configuration as implemented by Apache Manager.
Advantages of Using the Apache Manager
Apache Manager provides a simple solution to the problem of managing an Apache web farm. Some of the advantages provided by Apache Manager include platform independence, single web-based location for managing all instances of Apache, and consolidation of common directives across Apache instances. Apache Manager eliminates the need for an administrator to have to edit and maintain a large number of configuration files as many of the directives are common across each Apache web server instance
Platform Independence
Apache Manager was designed and built specifically with platform independence in mind. The basic idea is that since Apache is a cross-platform web server, managing Apache should also be cross-platform activity. With this in mind, the runtime environment as well as the implementation of the administration tool had to be cross platform. There are few technologies that could be considered completely cross platform. The most obvious was to build a web based management utility that implemented java technology in tandem with LDAP as the protocol for accessing the directory. Apache Manager is composed of two separate pieces: the Apache Manager web utility and the configuration daemon that runs along side the Apache web server. Both of these pieces are built using Java and LDAP technologies allowing the solution to run on all major operating systems.
The Apache Manager Configuration Daemon is built as a Java utility that utilizes the Java Naming and Directory Interface (JNDI) classes along with an LDAP provider to access an LDAP-compliant directory. The web pages are implemented as Java Server Pages (JSP) and take advantage of the same JNDI interfaces for reading and writing data in the directory. The only platform requirements associated with the Apache Manager instance is a web server, a JSP/servlet engine, an LDAP-compliant directory and a Java Virtual Machine. All of these exist on all of the major platforms. The Apache web server and the configuration daemon is the only piece that must be running on any platform when managed through the Apache Manager instance. The Apache web management interface need only run on one server in the network.
Single-Web based Location
Apache Manager has the ability to manage the configuration for any number of Apache servers through a single interface. Administrators can log in to a single instance of Apache Manager to view and configure every instance of Apache running on their network. Once the configuration has been changed in the directory, the configuration daemon handles saving the new configuration to the httpd.conf file as well as restarting Apache web server. This solves the problem of having to physically access the configuration file of each individual Apache server just so the administrator can manually edit the configuration files and then restart each web server. Apache Manager allows the administrator to do it all from one single location while leveraging the web based interface.
Common Directive Consolidation
Since the Apache Web Server is a cross platform application, configuring Apache on different platforms is basically the same. For the most part, a configuration file used to configuration Apache on one platform can easily be used to configure Apache on another platform. This means that most of the configuration directives themselves are completely common regardless of the platform that the web server is running on.
Apache Manager allows directives that are common across multiple Apache servers to be stored in a common location and while being inherited by each Apache server. For example, assume that the directive on every Apache server for “HostNameLookups” is set to “On”. With Apache Manager this directive can be stored in a server group object that is inherited by every Apache server. If the administrator wanted to change the value of “HostNameLookups” to “Off”, the change could be made in the server group object and all Apache servers would automatically inherit the configuration change. This saves the administrator from the tedious task of manually changing each server’s configuration file. It also provides the administrator with a much easier way of adding new Apache servers to the web server farm. Adding a single server object to the directory with just a few specific directives is all that is needed. The remainder of the configuration file can be constructed by inheriting the common set of directives that were already established in the directory. This eliminates having to duplicate directives that have already been defined in another configuration file.
How the Apache Manager Functions
Apache Manager has three basic parts, the directory service, the configuration daemon, and the web-interface. The directory service not only acts as the database where the configuration directives are stored, it also provides an environment that allows configuration objects to be shared and inherited. The configuration daemon is a small java application that runs in parallel with the actual Apache server software. It extracts the configuration directive out of the directory server objects, assembles them creating the httpd.conf file. In addition to creating the configuration file, it is also able to restart the Apache web server when specific flags have been set in an Apache server object within the directory. The web-interface presents the Apache configuration in an easy to manage format enabling changes to be made quickly to one or many Apache servers through a web browser.
Apache Manager uses a directory-based, hierarchical object model to simplify the management of and share configuration directive within a web farm. The basic idea is that when an identical directive exists for multiple Apache servers, that directive can be stored in a single directory object rather than duplicated in multiple configuration files. This allows the directive to be shared among multiple Apache server configurations and provide a way for the administrator to modify the directive once and apply the modification across multiple servers. The implementation of this idea is more complex, but Apache Manager masks the complexity and presents the administrator with a simple solution to managing the web farm.
The Directory
Apache Manager divides the Apache configuration file into a hierarchy of configuration objects and then stores them in a directory service. By storing directives in a hierarchy of objects, those directives can be applied to a single server, a group of servers, or to an entire web farm.
An HTTPD.CONF file can be broken up into a set of parts that can be represented by five different object classes. These object classes are:
Server Group
Server
Virtual Host
Module
Block
By defining a server object within the directory service and combining the object with one or more virtual host, module and block objects, an entire configuration for an Apache web server can be stored, manipulated, and shared through the directory service. Each object class contains a set of attributes that can store the data required to produce a portion of the configuration in a complete httpd.conf file. Additionally, each object class may store any number of specific directives that the administrator wants defined at that location of the object hierarchy.
The definitions of the five object classes are as follows:
Server Group
The server group is a representation of a set of Apache configuration directives common to all server objects contained in the group. A server group may contain any number of server groups, servers, modules, and blocks.
Server
The server object is a representation of a single Apache server. It contains standard attributes such as Server Name. It is used as a definition of any single server and is an anchor point for its configuration. It may contain any number of virtual hosts, modules, and blocks.
Virtual Host
The virtual host object is a representation of a virtual host within an instance of an Apache server. The object contains the necessary attributes to create a block in the Apache configuration file. A virtual host object must be contained by a server object and can contain any number of block objects.
Module
The module object is a representation of an Apache module. The module object defines the “LoadModule” directive and the tag within a configuration file. A module can be defined at any level of the hierarchy so that it can be inherited by one or more server configurations. This allows the module to be loaded and configured in exactly the same way by multiple web servers without having to redefine the module for each server. It can contain any number of block objects.
Block
The block object is a representation of a Directory, Location or File block or any of their derivatives. It defines the tag within a configuration file. A block can be defined at any level of the hierarchy so that one or more server configurations can inherit it. This allows the block definition to be applied in exactly the same way by multiple web servers without having to redefine the block for each instance. A block cannot contain any other objects.
Configuration Daemon
[
1) The configuration Daemon is started.
2) The new configuration data is extracted from the directory.
3) Configuration data is written to a configuration file on the local file system.
4) The Apache web server is started or restarted.
5) Apache then reads the configuration file.
6) The configuration Daemon waits for changes in the directory and restarts from step number 2 when necessary.
Figure-2, Configuration Daemon]
As explained in the object hierarchy section, the configuration for any given Apache web server is stored in a series of objects in the directory. The information in the directory is extracted by a configuration builder service
known as the Apache Manager Configuration Daemon. The daemon runs in parallel with each instance of Apache and knows how to extract the objects from the directory and order them to construct the httpd.conf file.
Therefore, each Apache server on the network should also have a Configuration Daemon running with it. The configuration daemon is the conduit between the physical configuration file stored for each Apache web server instance and the directory service that holds the configuration objects.
After the daemon is started it monitors the directory for any changes made to a particular server. If a change is detected, it updates the configuration file and notifies the Apache Server that it is time to reload its configuration file.
Additionally, if an Apache server’s configuration has not been stored in the directory, the daemon has the ability to import the current configuration file into the directory. For example, the first time the daemon runs in conjunction with a specific instance of the Apache web server, it will create a server object in object hierarchy to ensure that the configuration stored in the directory matches the current configuration file of the Apache server. In addition to importing a new configuration, it also has the ability to detect when a physical configuration file has been changed. If an administrator makes a change directly to the Apache configuration file stored on disk, the daemon can detect the change and import it into the server configuration previously stored in the directory. One purpose of the configuration daemon is to make sure that the configuration file used to configure a specific instance of Apache remains synchronized with the shared configuration objects in the directory.
|
