Modules


Apache is a skeletal program that relies on external modules, called dynamic shared objects (DSOs), to provide most of its functionality. This section lists these modules and discusses some of the more important ones. In addition to the modules included with Red Hat Linux, many other modules are available. See httpd.apache.org/modules for more information.

Module List

Following is a list of some of the modules that are available under Apache:

access (mod_access.so) Controls access based on client characteristics.

actions (mod_actions.so) Allows execution of CGI scripts based on the request method.

alias (mod_alias.so) Allows outside directories to be mapped to DocumentRoot.

asis (mod_asis.so) Allows sending files that contain their own headers.

auth (mod_auth.so) Provides user authentication via .htaccess.

auth_anon (mod_auth_anon.so) Provides anonymous user access to restricted areas.

auth_dbm (mod_auth_dbm.so) Uses DBM files for authentication.

auth_digest (mod_auth_digest.so) Uses MD5 digest for authentication.

autoindex (mod_autoindex.so) Allows directory indexes to be generated.

cern_meta (mod_cern_meta.so) Allows the use of CERN httpd metafile semantics.

cgi (mod_cgi.so) Allows the execution of CGI scripts.

dav (mod_dav.so) Allows Distributed Authoring and Versioning.

dav_fs (mod_dav_fs.so) Provides a filesystem for mod_dav.

dir (mod_dir.so) Allows directory redirects and listings as index files.

env (mod_env.so) Allows CGI scripts to access environment variables.

expires (mod_expires.so) Allows generation of Expires HTTP headers.

headers (mod_headers.so) Allows customization of request and response headers.

imap (mod_imap.so) Allows image maps to be processed on the server side.

include (mod_include.so) Provides server-side includes (SSIs).

info (mod_info.so) Allows the server configuration to be viewed.

log_config (mod_log_config.so) Allows logging of requests made to the server.

mime (mod_mime.so) Allows association of file extensions with content.

mime_magic (mod_mime_magic.so) Determines MIME types of files.

negotiation (mod_negotiation.so) Allows content negotiation.

proxy (mod_proxy.so) Allows Apache to act as a proxy server.

proxy_connect (mod_proxy_connect.so) Allows connect request handling.

proxy_ftp (mod_proxy_ftp.so) Provides an FTP extension proxy.

proxy_http (mod_proxy_http.so) Provides an HTTP extension proxy.

rewrite (mod_rewrite.so) Allows on-the-fly URI rewriting based on rules.

setenvif (mod_setenvif.so) Sets environment variables based on a request.

speling (mod_speling.so) Auto-corrects spelling if the requested URI has incorrect capitalization and one spelling mistake.

status (mod_status.so) Allows the server status to be queried and viewed.

unique_id (mod_unique_id.so) Generates a unique ID for each request.

userdir (mod_userdir.so) Allows users to have content directories (public_html).

usertrack (mod_usertrack.so) Allows tracking of user activity on a site.

vhost_alias (mod_vhost_alias.so) Allows the configuration of virtual hosting.

mod_cgi and CGI Scripts

The CGI (Common Gateway Interface) allows external application programs to interface with Web servers. Any program can be a CGI program if it runs in real time (at the time of the request) and relays its output to the requesting client. Various kinds of scripts, including shell, Perl, Python, and PHP, are the most commonly encountered CGI programs because a script can call a program and reformat its output in HTML for a client.

Apache can handle requests for CGI programs in several different ways. The most common method is to put a CGI program in the cgi-bin directory and then enable its execution from that directory only. The location of the cgi-bin directory, as specified by the ScriptAlias directive (page 812), is /var/www/cgi-bin. Alternatively, an AddHandler directive (page 806) can identify filename extensions of scripts, such as .cgi or .pl, within the regular content (for example, AddHandler cgi-script .cgi). If you use AddHandler, you must also specify the ExecCGI option in an Options directive within the appropriate <Directory> container. The mod_cgi module must be loaded to access and execute CGI scripts.

The following Perl CGI script displays the Apache environment. This script should be used for debugging only because it presents a security risk if outside clients can access it:

#!/usr/bin/perl ## ##  printenv -- demo CGI program that prints its environment ## print "Content-type: text/plain\n\n"; foreach $var (sort(keys(%ENV))) {      $val = $ENV{$var};      $val =~ s|\n|\\n|g;      $val =~ s|"|\\"|g;      print "${var}=\"${val}\"\n"; }


mod_ssl

SSL (Secure Sockets Layer), which is implemented by the mod_ssl module, has two functions: It allows a client to verify the identity of a server and it enables secure two-way communication between a client and a server. SSL is used on Web pages with forms that require passwords, credit card numbers, or other sensitive data.

Apache uses the HTTPS protocolnot HTTPfor SSL communication. When Apache uses SSL, it listens on a second port (443 by default) for a connection and performs a handshaking sequence before sending the requested content to the client.

Server verification is critical for financial transactions. After all, you do not want to give your credit card number to a fraudulent Web site posing as a known company. SSL uses a certificate to positively identify a server. Over a public network such as the Internet, the identification is reliable only if the certificate contains a digital signature from an authoritative source such as VeriSign or Thawte. SSL Web pages are denoted by a URI beginning with https://.

Data encryption prevents malicious users from eavesdropping on Internet connections and copying personal information. To encrypt communication, SSL sits between the network and an application and encrypts communication between the server and the client.

Setting Up mod_ssl

The /etc/httpd/conf.d/ssl.conf file configures mod_ssl. The first few directives in this file load the mod_ssl module, instruct Apache to listen on port 443, and set various parameters for SSL operation. About a third of the way through the file is a section labeled SSL Virtual Host Context that sets up virtual hosts (page 818).

A <VirtualHost> container in ssl.conf is similar to one in httpd.conf. As with any <VirtualHost> container, it holds directives such as ServerName and ServerAdmin that need to be configured. In addition, it holds some SSL-related directives.

Using a Self-Signed Certificate for Encryption

If you require SSL for encryption and not verificationthat is, if the client already trusts the serveryou can generate and use a self-signed certificate, bypassing the time and expense involved in obtaining a digitally signed certificate. Self-signed certificates generate a warning when you connect to the server: Most browsers display a dialog box that allows you to examine and accept the certificate. The sendmail daemon also uses certificates (page 650).

The self-signed certificate depends on two files: a private key and the certificate. The location of each file is specified in /etc/httpd/conf.d/ssl.conf. The files have different names and are stored in different locations under FEDORA and RHEL.

FEDORA


# grep '^SSLCertificate' /etc/httpd/conf.d/ssl.conf SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key


To generate the private key that the encryption relies on, cd to /etc/pki/tls/certs and enter a make command:

# cd /etc/pki/tls/certs # make localhost.key umask 77 ; \ /usr/bin/openssl genrsa -des3 1024 > localhost.key Generating RSA private key, 1024 bit long modulus ...............++++++ .........++++++ e is 65537 (0x10001) Enter pass phrase: Verifying - Enter pass phrase:


The preceding command generates a file named localhost.key that is protected by the pass phrase you entered: You will need this pass phrase to start the server. Keep the server.key file secret.

The next command generates the certificate. This process uses the private key you just created. You need to supply the same pass phrase you entered when you created the private key.

# make localhost.crt umask 77 ; \ /usr/bin/openssl req -utf8 -new -key localhost.key -x509 -days 365 -out localhost.crt -set_serial 0 Enter pass phrase for localhost.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:US State or Province Name (full name) [Berkshire]:California Locality Name (eg, city) [Newbury]:San Francisco Organization Name (eg, company) [My Company Ltd]: Sobell Associates Inc. Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []: www.sobell.com Email Address []:mgs@sobell.com


The answers to the first five questions are arbitrary: They can help clients identify a site when they examine the certificate. The answer to the sixth question (Common Name) is critical. Because certificates are tied to the name of the server, you must enter the server's FQDN accurately. If you mistype this information, the server name and that of the certificate will not match. The browser will then generate a warning message each time a connection is made.

As specified by ssl.conf, Apache looks for the files in the directory that you created them in. Do not move these files. After you restart Apache, the new certificate will be in use.

RHEL


The process of creating the key and certificate is similar under RHEL. The following output shows the location of the two files:

# grep '^SSLCertificate' /etc/httpd/conf.d/ssl.conf SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key


To generate the private key, cd to /etc/httpd/conf and give the command make server.key. From the same directory, give the command make server.crt to generate the certificate. These commands create files in the working directory. Next move server.key into the ssl.key directory, and server.crt into the ssl.crt directory. After you restart Apache, the new certificate will be in use.

Notes on Certificates
  • Although the server name is part of the certificate, the SSL connection is tied to the IP address of the server: You can have only one certificate per IP address. For multiple virtual hosts to have separate certificates, you must specify host-by-IP rather than host-by-name virtual hosts (page 818).

  • As long as the server is identified by the name for which the certificate was issued, you can use the certificate on another server and/or IP address.

  • A root certificate (root CA) is the certificate that signs the server certificate. Every browser contains a database of the public keys for the root certificates of the major signing authorities, including VeriSign and Thawte.

  • It is possible to generate a root certificate (root CA) and sign all your server certificates with this root CA. Regular clients can import the public key of the root CA so that they recognize every certificate signed by that root CA. This setup is convenient for a server with multiple SSL-enabled virtual hosts and no commercial certificates. For more information see www.modssl.org/docs/2.8/ssl_faq.html#ToC29.

  • You cannot use a self-signed certificate if clients need to verify the identity of the server.

Authentication Modules and .htaccess

To restrict access to a Web page, Apache and third parties provide authentication modules and methods that can verify a user's credentials, such as a username and password. Some modules enable authentication against various databases including LDAP (page 1040) and NIS (page 655).

User authentication directives are commonly placed in a .htaccess file. A basic .htaccess file that uses the Apache default authentication module (mod_auth) follows. Substitute appropriate values for the local server.

# cat .htaccess AuthUserFile /var/www/.htpasswd AuthGroupFile /dev/null AuthName "Browser dialog box query" AuthType Basic require valid-user


The /var/www/.htpasswd is a typical absolute pathname of a .htpasswd file and Browser dialog box query is the string that the user will see as part of the dialog box that requests a username and password.

The second line of the preceding .htaccess file turns off the group function. The fourth line specifies the user authentication type Basic, which is implemented by the default mod_auth module. The last line tells Apache which users can access the protected directory. The entry valid-user grants access to the directory to any user who is in the Apache password file and who enters the correct password. You can also specify Apache usernames separated by SPACEs.

You can put the Apache password file anywhere on the system, as long as Apache can read it. It is safe to put this file in the same directory as the .htaccess file because, by default, Apache will not answer any requests for files whose names start with .ht.

The following command creates a .htpasswd file for Sam:

$ htpasswd -c .htpasswd sam New password: Re-type new password: Adding password for user sam


Omit the c option to add a user or to change a password in an existing .htpasswd file. Remember to use an AllowOverride directive (page 813) to permit Apache to read the .htaccess file.

Scripting Modules

Apache can process content before serving it to a client. In earlier versions of Apache, only CGI scripts could process content. In the current version, scripting modules can work with scripts that are embedded in HTML documents.

Scripting modules manipulate content before Apache serves it to a client. Because they are built into Apache, they are fast. Scripting modules are especially efficient at working with external data sources such as relational databases. Clients can pass data to a scripting module that modifies the information that Apache serves.

Contrast scripting modules with CGI scripts that are run externally to Apache: CGI scripts do not allow client interaction and are slow because they must make external calls.

Red Hat provides packages that allow you to embed Perl, Python, and PHP code in HTML content. Perl and Python, which are general-purpose scripting languages, are encapsulated for use directly in Apache and are implemented in the mod_perl and mod_python modules, respectively.

PHP, which was developed for manipulating Web content, outputs HTML by default. Implemented in the mod_php module, this language is easy to set up, has a syntax similar to Perl and C, and comes with a large number of Web-related functions.




A Practical Guide to Red Hat Linux
A Practical Guide to Red HatВ® LinuxВ®: Fedoraв„ў Core and Red Hat Enterprise Linux (3rd Edition)
ISBN: 0132280272
EAN: 2147483647
Year: 2006
Pages: 383

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net