Join Jon Peck for an in-depth discussion in this video What are modules, and why use them?, part of Practical Apache Web Server Administration.
- View Offline
Httpd is modular, meaning it consist of a system of plugins that add specific functionality. Apache comes with a default set of modules that are included upon compilation. Static modules are compiled into the httpd and are loaded every time Apache is started. Shared modules on the other hand, can be added without recompiling the core configuration. This is typically more flexible. Shared modules can be dynamically loaded, meaning the modules can be turned on or off.
Overall, execution of shared modules is a little bit slower than static modules, but it's way more flexible. From a configuration point of view each module has its own directives that can be used to configure the additional functionality. If the server configuration includes module specific directives and the module isn't enable or available, then the server will not be able to start due to a syntax error. To prevent that situation, it's possible to wrap module specific configuration in an IfModule directive, with an argument containing the module name.
For example, IfModule mod_ssl, will only run if the mod_ssl module was enabled. Let's see what modules are available on the system. From the terminal type, apachectl -t -D DUMP_MODULES. Well there's a few dozen here, each list item has the name of the module, then the word static or shared. Let's disable one of the shared modules, the status module, which provides the status report that we looked at earlier.
To do so, we'll make a change to the Apache Server configuration. However, depending on the Linux distribution or method of installation, the exact way to do it will be different. I'm going to describe step by step how to do it in Ubuntu, and what's happening in each step. At a high level, the steps taken will be similar to other distributions but some of the commands will be different and might not be available on say, CentOS. Therefore, please know which distribution you're using and consult the distribution's documentation for the best practices for making changes to the server configuration.
Debian puts the module configuration into special sub-directories within etc/apache2. Mods-available and mods-enabled. Mods-available lists every single module with a known configuration, and mods-enabled contains symbolic links that link back to the configuration in mods-available. Two Debian commands assist with modules. A2enmod and a2dismod which enable and disable Apache 2 modules by creating and removing symbolic links from the enabled to the available directory.
Let's see how this works. From the terminal I'm going to look at the contents of the mods available directory. So cd /ect/apache2/mods-available, and then do a directory listing, ls -la. A large number of files, .conf files contain configuration directives, and .load actually loads the module. Let's look at the contents of the status configuration. Cat status.conf. We scroll up, notice that it starts with if module.
There's a new directive, location. Which limits the scope of the enclosed configuration by the URL path. In this case, it's server-status. Some additional details specific to the status configuration are also provided. Let's take a look at the .load file. Cat status.load. The directive, LoadModule, loads a dynamic module, which in this case is named status_module, from a directory user > lib > apache2 > modules and the filename itself, mod_status.so.
All right, so that's what the available module directory looks like. So, what's an enabled module directory? Ls -la /etc/apache2/mods-enabled. The blue indicates that they're symbolic links. Which, if you're not familiar with the term, means they're shortcuts to the actual file. I'm going to disable the status module now, which will require elevated privileges. Sudo a2dismod status. It'll ask me for the password. The password is lynda.com. A restart is required after using one of the module changes, as modules affect the functionality of the server itself.
Before we restart, let's see what changed in the mod's enable directory. ls -la /etc/apache2/mod-enabled. This symbolic link for status.conf and status.load aren't there anymore. Let's the new configuration in action by gracefully restarting the server. Sudo service apache2 graceful. After a moment, the server restarts cleanly using the new module configuration. Let's take a look at the module list again.
Apachectl -t -D DUMP_MODULES. Status isn't listed anywhere. And if we try the status command, apachectl status, it'll fail, as well, as the configuration and the module are no longer available. Let's update the worksheet with what we've discovered. The Status module, which provides a real time look into what Apache is doing in any given moment, is currently disabled. But it can easily be turned on again. In this chapter we focused on how Apache's configured.
We started with a very important question. Where exactly is Apache's configuration? The answer is, it depends. But we've explored how to find it. We then took a look at Apache's directives and arguments, which are commands stored in plain text files for configuring Apache. .htaccess files were discussed and not recommended, as servers are best configured with a centralized static configuration, rather than a system of overrides. Virtual hosts were discussed and example was read line by line to describe the syntax.
Finally the use of modules, both static and shared were explored. And we disabled the status module. Coming up we'll discuss Apache's log files which are every system administrator's keys to learning what went wrong and how.