Using Graphical Configuration Tools - Apache

Although Apache has no official configuration applications, there are many capable third-party GUI tools available and under development. Some are freely available, and others are commercial offerings.

The best place to look for software and information on GUI configuration tools is the Apache GUI Development project page located at http://gui.apache.org/. This contains links to all the major Apache GUI configuration applications as well as current news and information on existing and developing projects. This section covers a selection of freely available graphical configuration tools.

Comanche is a graphical configuration editor for Apache, freely available for both Unix and Windows, and is the most widely used tool to configure Apache. The latest version supports Apache 1.3.

The Windows version contains a static binary with the Tcl/Tk libraries linked in and runs out of the archive; it reads the Windows registry for Apache’s configuration information, so additional configuration shouldn’t be necessary.

The Unix version is available as source, which requires the prior installation of Tcl/Tk and iTcl, and as a binary package for several platforms, which come with all necessary components included. RPM packages for Linux are also available. Both versions are available from http://www.comanche.org/ or http://apache.covalent.net/projects/
comanche/. Comanche’s interface style mirrors that of a tree-based organizer or, in Windows terminology, an explorer. Although it doesn’t provide extensive configuration options, it does the work of making sure the basic organization of the configuration file is logical and valid while allowing the administrator to enter individual configuration options—which are then written to the appropriate points in the file when it’s regenerated.

Like Apache itself, Comanche is a work in progress. It’s worth checking the Comanche Web site at regular intervals to download new versions as they become available.

Installing Comanche on Linux

Comanche is available as an RPM for most Linux distributions, as well as a compressed tar archive. To install Comanche on Linux, use the tar command:

# tar -zxvf comanche3.0b4-x86-linux-glibc2.tar.gz

The tool is installed under the directory comanche3-0b4. This completes the installation of Comanche. To start Comanche, run the startup script as follows:

# ./comanche3.0b4 &

This should produce the startup screen as shown in Figure 2-4.

Figure 2-4. Comanche startup screen

Now press the Comanche button on the screen. Because Comanche is not yet configured with Apache, you have to configure Apache installation for Comanche. Follow the New Apache Installation link to configure Apache with Comanche, as shown in Figure 2-5.

Figure 2-5. Comanche main screen

Comanche will then ask for the location of your Apache installation; by default it uses /usr/local/apache. This is where a default installation from source installs Apache. You’ll use the same path (see Figure 2-6).

This is all that’s necessary to configure an Apache installation with Comanche. With the Server Management option, you can now start, stop, and restart the server.

Now select the Default Web Server option. It shows the link to default Web site properties (see Figure 2-7).

Figure 2-6. Adding an Apache installation to Commanche

 
Figure 2-7. Default Web server main Screen

This link leads to the window shown in Figure 2-8.

Figure 2-8. Default Web server basic configuration

Here you can modify basic directives such as DocumentRoot, ServerName, and so on. Make changes for these directives, and restart the server to see the changes.

Modularization

Management modules (plug-ins) can be built using the Comanche framework. There are plug-ins for Apache, Samba, and so on, but because Apache is a complex program, the plug-in itself is modular and support for directives and modules is achieved via an extension mechanism. The process is relatively simple—all you have to do is write a few Extensible Markup Language (XML) files.

Modules are located under ComancheHome\plugins\apache\modules. Each module is placed under a separate folder. There are certain files that are needed to support the module:

• moduleDescription.xml: This file contains basic information about the module such as its name, nodes in which you’re interested, and so on.

• directives.xml: This file contains description of the directives that are declared in this module.

• propertyPages.xml: This file contains the description of the property pages for this module, which are presented to the user during configuration.

• specialCases.tcl: This file contains the actual Tcl code used to convert from XML format to httpd.conf.
  
• messages: The text corresponding to the messages are stored in the messages/ subdirectory so they can easily be translated by other people. The messages are stored with a suffix corresponding to the language—messages.en, messages.es, and so on.

TkApache is a graphical configuration editor for Unix systems. It’s written in Perl/Tk and therefore needs Perl and the Perl::Tk package installed as prerequisites; however, it doesn’t require Tcl.

TkApache is available from http://ultra.litpixel.com:82/TkApache/ TkApache_content.html or http://everythinglinux.org/TkApache/.

Installation of TkApache is slightly fiddly—after running TkApache for the first time, you see a dialog box of basic configuration details. This dialog box must be given an installation directory that’s different from the one in which the TkApache files are initially located, for example, /usr/local/apache/gui/TkApache.

The TkApache configuration file must have this directory explicitly prefixed to it in order for the installation to proceed successfully. You must also supply the server root and configuration parameters with the correct locations for your installation. The installation process is likely to be much improved in future versions.

The interface for TkApache is based on a layered folder/tab dialog box for each part of the configuration.

TkApache is a little less advanced in development than Comanche, but shows promise. It also provides some limited abilities to track the access and error logs as well as the Apache process pool.

LinuxConf is an all-purpose configuration tool that has gained increasing popularity on the Linux platform and is bundled as standard with several distributions. Modern versions of LinuxConf come with a fairly credible Apache configuration module.

Current releases of LinuxConf in source, binary, and RPM packages are available for most distributions of Linux from http://www.solucorp.qc.ca/linuxconf/.

Webmin is a server configuration tool that provides a graphical user interface for configuring different servers such as Apache, FTP server, MySQL database server, Samba server, and many others. It’s Perl-based, so Perl must also be installed to use it. You can download it from http://www.webmin.com/download.html.

Installing Webmin

The Webmin installation comes with both RPM and conventional archive distributions. To install the RPM, use a command line such as the following:

$rpm -i webmin1.100-1.noarch.rpm

The installation program prints a message to the user after the program is successfully installed:

Operating system is SuSE Linux 8.2
webmin #######################################
Webmin install complete. You can now login to https://localhost:10000/

as root with your root password.

Despite the previous messages, Webmin may not yet be running. If the URL isn’t accessible, then Webmin can be started up manually with a command like this:

$ /etc/webmin/start

RPM distributions typically install start and stop scripts, so this will also work on many servers:

$ /etc/rc.d/init.d/webmin start

For the example SuSE server, here you would instead use either of these:

$ /etc/init.d/webmin start
$ rcwebmin start

Accessing Webmin

Because Webmin is a Web-based administration tool, it must be accessed using a browser. By default the access URL is the local host, port 1000, in order not to conflict with the Apache server (or servers) that it’s going to configure. The first time Webmin is accessed, it’ll present the login screen shown in Figure 2-9.

Use the root username and password to log in and access Webmin’s main page, as shown in Figure 2-10.

This page provides options to configure Webmin itself. Select Servers and then Apache Server to access the Apache configuration module. Webmin will perform a scan to detect the installed Apache instance and then offer to manage it and any available dynamic modules. Once you pass this step, you get to the Apache configuration screen.

Figure 2-9. Webmin login page

Figure 2-10. Webmin main page

Webmin understands both Apache 1.3 and Apache 2 configurations. For Apache 2 the Apache configuration screen looks like this, notably including a Filters configuration option, as shown in Figure 2-11.

Apache 1.3 instead produces the screen shown in Figure 2-12.

 
Figure 2-11. Webmin Apache 2 main page

Figure 2-12. Webmin Apache 1.3 main page

Select the Module Config tab to configure the Webmin Apache module. Here the locations that the module uses can be changed, if necessary, to point to a different Apache installation. Change just the server root and set the other options to Automatic to have Webmin pick up most locations automatically, as shown in Figure 2-13.

Figure 2-13. Apache module configuration

After setting the basic parameters on this screen, Webmin will return to the main Apache configuration page where you can customize the chosen Apache’s configuration. Webmin initially shows you a list of all the virtual servers configured on the server, along with both the main (nonvirtual) server and the configuration details that you may modify. You may also add a new virtual server or remove an existing one.

The following global configuration options are provided by Webmin:

• Processes and Limits: This allows you to set limits for various server options such as the maximum number of concurrent requests, the maximum number of headers in a request, and so on.

• Networking and Addresses: Here you can set the default IP addresses and the ports to which Apache listens. You can also set the request and keep-alive time-out values and the maximum requests per child.

• Apache Modules: This option allows you to choose which dynamic modules are included in the server.

• MIME Types:Here you can configure the location of the MIME-type definitions file, which usually points to conf/mime types in the server root. You can also view the list of MIME-type definitions here.

• User and Group (Apache 2): Here you can configure the user and group that Apache runs under. If the perchild MPM is in user, the user and group of each virtual host can also be set here.

• M iscellaneous: This allows you to configure the core dump file, server PID file, server lock file, shared memory scoreboard file, and so on.

• CGI Programs (Apache 1.3): This allows various CGI program configurations such as CGI script log, maximum CGI log size, and so on.

• Filters (Apache 2): This allows filter configurations to be added, removed, or altered.

• Per-Directory Options Files: Here you can set per-directory option files (such as .htaccess) for any selected directory.

• Reconfigure Known Modules: This provides lists of all the modules whose configuration is known and supported by the Webmin interface and that are currently enabled. Individual module configurations may be carried out from here.

• Edit Defined Parameters: This allows you to edit the definitions passed with the -D option while starting. This is covered in detail in Chapter 4.

Lower on the page is a form to add, remove, and modify virtual hosts, as Figure 2-14 demonstrates.

 
Figure 2-14. Virtual host configuration form

ApacheConf is a configuration tool installed with Red Hat Linux if you choose to install the version of Apache bundled with the operating system. It can also be found as an RPM on http://www.rpmfind.net and elsewhere. (Confusingly, it’s also the name of a number of different configuration tools available on the Internet, including a commercial Windows offering.)

Similar tools exist for all Linux and BSD platforms and are roughly similar in capabilities. You may also install the configuration tool subsequently by locating the apacheconf package and installing it with this:

# rpm -ivh apacheconf-0.8.1-1.noarch.rpm

ApacheConf provides a simple graphical user interface to configure Apache. It’s suited only to simple configurations as it has a fairly restricted set of features and may not read hand-modified configuration files, as shown in Figure 2-15.

 
Figure 2-15.  ApacheConf main screen

This figure shows the configuration dialog box for basic settings such as the server name and administrator’s email address. It also lists which addresses and ports Apache is configured to listen to—all addresses on port 80, in this example. You can add to or modify these addresses before going on to configure virtual hosts, which you do by selecting the Virtual Hosts tab. This produces a screen like that shown in Figure 2-16.

Figure 2-16.  ApacheConf virtual host selection

If you click the Add button to configure a new virtual host, you get to the screen shown in Figure 2-17. Here you can enter the specific details for this virtual host.

Figure 2-17.  ApacheConf virtual host configuration

None of the GUI configuration tools for Apache go much beyond the configuration file itself, with the notable exception of Webmin, which is a generic configuration tool that happens to support Apache reasonably well. In addition to the tools mentioned here, there are a diverse number of other options of varying quality and usefulness.

One popular and capable package for user- and host-based access configuration is user_manage, available from http://stein.chl.org/~lstein/user_manage/. This is an HTML-based interface implemented in a Perl CGI script and manages user and group account details in text, .dbm and .db files, and SQL databases. It provides for both administrator-level management as well as permitting users to alter their own details and change their password.

user_manage is ideally suited to remote administration, but it should be set up carefully according to the installation instructions for reasons of security.

Having outlined a few of the options for graphical configuration, it’s worth pointing out that editing configuration files by hand is not all that hard, and for many purposes it’s easier because it doesn’t require extra software. It also enables you to control the exact layout of the file or files, if you choose to split them up. You can easily edit a text file over a simple telnet (or preferably encrypted with ssh) connection. Complex configurations involving large numbers of virtual hosts or automated configuration generation also benefit from the text file approach. As many of the virtual host examples in Chapter 7 will demonstrate, there are many practical configuration techniques that are either hard or simply impossible to implement with a GUI editor. When using a GUI tool, be aware that it may limit your options in circumstances where Apache is actually more than capable.

In this chapter, you have seen how to install Apache from both a binary distribution and a prebuilt package, with special attention paid to Windows installer files and Linux RPM packages. You have carried out the initial configuration of the server, started it up, and tested it to prove that it’s up and running.

You have also examined Apache’s various means of invocation, including its command line options and the apachectl script. You have looked at how to start up multiple Apache servers and directing the server to use a different file for its configuration, as well as supplying configuration directives on the command line.

Finally, you discussed some of the graphical configuration tools for Apache, summarized their features, and considered some of the reasons you might choose to forego a GUI tool and configure Apache by hand.

Now that you have Apache on your server, you can start to worry about the next steps in configuration, which you start in Chapter 4. You may also at this point decide to customize the makeup of the server by building it from source—that’s the subject of the next chapter.