Until recently, there were no Web browsers that supported encryption stronger than 40 bits, mainly due to U.S. export restrictions (based on the rather silly idea that no one outside the U.S. could make stronger encryption). With these restrictions gradually loosening and strong (128-bit) encryption now available on Web servers sold inside and outside the U.S., browsers are appearing which support stronger encryption. Within the U.S., it is possible to get enhanced versions of Netscape's browser, which use 128-bit encryption. For more information on encryption and security, see the chapter on security.

Below is a sampling of secure and unsecure httpd servers.

Since Apache is freely available, a number of Linux distributions are shipped with it, Red Hat included.

Aside from the various modules that can be used to extend Apache at compile time, there are many items that can be specified at run-time in the .conf files, httpd.conf and srm.conf. These two files control parameters, such as aliases for directories, aliases for icons, images, CGI scripts/programs, virtual host directives, the document root directory, the file to be served from a directory if no other file is specified in the URL, and various access control and authentication directives.

These two tools are used to modify access of all types for directory trees. <Directory> directives typically reside in the srm.conf or httpd.conf file. They can also occur in the <Virtualhost> directive (more on this later.) The .htaccess file resides somewhere in a directory tree of HTML documents. In both instances, directives placed in the directories are recursively effective for all the files and subdirectories in those directories. For example, to enforce basic authorization for a directory and all its contents, you could put the following in a .htaccess file in that directory (say /home/web):

AuthType Basic
AuthUserFile /home/cary/etc/passwd
AuthGroupFile /dev/null
AuthName Realm of the Kazoos
<LIMIT GET POST PUT>
require valid-user
</LIMIT>

or in a <Directory> directive:

<Directory /home/web>
AuthType Basic
AuthUserFile /home/cary/etc/passwd
AuthGroupFile /dev/null
AuthName Realm of the Kazoos
<LIMIT GET POST PUT>
require valid-user
</LIMIT>
</Directory>

The <LIMIT> directive tells the server what HTTP methods require a valid user, in this case, GET, POST, and PUT ( PUT is used for file uploading).

The Common Gateway Interface (CGI) and Server Side Includes (SSI) are the two most common ways to execute external programs. CGI is designed to both receive and send information from and to the server. SSI is more one-way; mainly it sends information. SSI can do more than simply call external programs. It can also include files, echo some simple system information such as the local time, and even execute CGI.

Perl is the preemptive language for CGI programming. This is something of a double-edged sword. On the one hand, large collections of "canned" scripts for various common CGI tasks exist. It also has very powerful features for processing strings, including a large set of regular expression atoms and operators. Since CGI frequently involves large amounts of text processing, this helps to fuel Perl's popularity. On the other hand, Perl is not the easiest language to learn, nor is its syntax particularly easy to read (there are obfuscated Perl contests!).

After Perl, there are several languages that are popular for use in CGI programs: Python, Tcl, C, and Java. Additionally, there are languages that can be embedded in HTML and parsed later by a CGI program; PHP (discussed later) falls into this category. The PHP parser can also be embedded into Apache and servers based on it.

The number of books published on CGI is considerable and they cover the topic much more thoroughly than is suitable for us to do here. One criticism of most of the literature available is that it tends to focus nearly entirely on Perl, ignoring, for the most part, C, Python, and other languages. C, in particular, is very useful since, as a compiled language, CGI written in it is faster and lighter weight. Of course, development times in C are much longer.

At this point in time, all of the languages mentioned have more or less equivalent extensions/modules /libraries for dealing with the peculiarities of CGI and interfacing with everything from TCP/IP sockets to the operating system to a database. As such, the choice of a language for CGI is largely up to you. All of the above are shipped with most Linux distributions and are available for free from their respective authors.

In a situation where you have multiple users on your machine, be it at an ISP or at a publisher, some of them will likely be interested in setting up a home page for themselves. This is not something that will typically consume a large amount of resources on your server, unless you have a large number of home pages or have very popular users. Additionally, serving static HTML poses no security concerns beyond those of running the server itself. All that aside, there will almost certainly be users who will want to use CGI, SSI, or some other server-parsed content that will add a dynamic element to their Web pages. Now, you have a security issue.

The various solutions range from simply allowing users full access to tools like SSI and CGI (in a situation where you trust all your users) to some sort of limited SSI/CGI to completely forbidding the use of them. You can also allow or disallow the use of them on a user-by-user basis.

In a small business, or possibly on a corporate LAN, you may likely choose the former route, while at an ISP, where you know few of the users personally, you will likely choose one of the latter two routes.

Fortunately, Apache makes controlling access to these and other tools fairly easy via the .htaccess file and <Directory> directive.

The <Directory> directive is your friend. It is the way you specify what can and can't be done in which directories. Couple this with Linux user and group permissions, and you can exercise very fine control over who can do what in which areas of your Web space.

In general, unless the server is already so insecure it doesn't matter, or you can trust your users to not inadvertently or purposefully write CGI that compromises your server in some way, you will not want CGI to be executable from arbitrary directories. Of course, if the server is accessible only to you and possibly a few others, you can leave things fairly open and not worry about it.

Additionally, you will likely want to prohibit browsers from roaming through the filesystem, be it a particular user's or the root filesystem. In other words, if a URL points to a directory that does not contain an index file, the server will return a 404 (File not Found) error instead of displaying the directory's listing.

To make the entire filesystem off-limits to the server, a directive like this would be placed in the access.conf:

<Directory />
 AllowOverride None
 Order deny,allow
 Deny from all
 Options None
</Directory>

"Wait a second! I want to serve Web pages!" Ahh... then you need to tell Apache what directories it can serve pages from. A statement like this:

<Directory /home/*/public_html>
 Order allow,deny
 Allow from all
 AllowOverrides IncludesNOEXEC
</Directory>

lets you serve pages from your users'public_html (this is the default directory from which files are served when a request that ends in ~username is received) directories and lets them use SSI that doesn't execute external programs or CGI scripts, and:

<Directory /home/httpd /htdocs>
Order deny,allow
Allow from all
AlowOverrides All
</Directory>

lets you serve pages from what is commonly the document root for the server and allows all of the restrictions to be overridden. Now you can set up CGI directories in this tree. You can do this with additional <Directory> directives or in an .htaccess file. If you choose the latter route, be sure to make the .htaccess file not writable by the user, unless they can be trusted not to abuse the privilege. However, if you plan to have all CGI pass by you, or perhaps someone else, you may want to set up one directory that is writable by root or httpd only. In any event, to turn on CGI in a directory, assuming it can be overridden, using . htaccess, you need the following:

Options ExecCGI

There are many other options you can turn on and off, including the symbolic links, indexing, and multiviews. For details on them, look at the Apache documentation.

Whole books have been written on Apache, and since this is only one chapter, we're only going to touch on the more interesting and useful features. We aren't going to talk about most of the directives that appear in the configuration files since it's fairly easy to understand their syntax from the usage, and they are explained fairly well in the Apache documentation.

We've already met some of them: .htaccess, <Directory>, Options, AllowOverride, Allow, and Deny, and we've given a few examples of their use. Now we'll discuss the other most common and useful directives.

A server for http://www.dognails.com on port 80 with its own cgi-bin and document root is:

<VirtualHost www.dognails.com>
ServerName www.dognails.com
DocumentRoot /web/dognails/www
ScriptAlias /cgi-bin/ /web/dognails/cgi-bin/
</VirtualHost>

To serve all requests on port 1200, as from a separate DocumentRoot looks like:

Listen 1200
<VirtualHost *:1200>
DocumentRoot /usr/local/www1200
</VirtualHost>

One of the more complicated extensions with a difficult setup process, suEXEC is a wrapper that allows CGI programs to be executed under a different UID than that under which the server is running. This is often used by ISPs that let their users maintain their own CGIs; this forces the scripts to execute as those users. This obviously strongly encourages the user to create good, secure CGI scripts. It also allows access control similar to that allowed by the password file.

Because suEXEC can open some serious security holes, its security model imposes several additional restrictions. The target program must reside in the ApacheWeb space and thus, the path to it cannot start with a / or have back references (..). Obviously, the target user and group must be valid and their IDs must be above a minimum (typically 100 or 500), which will prohibit execution as the root user or group. The target program cannot be set uid or gid, and the final, non-trivial restrictions are that the directory containing the program to be executed and the program itself can only be writable by the target user and they must belong to the target user and target group.

suEXEC comes in a separate C source file and accompanying header file. Before compiling suEXEC, the header file needs to be edited to reflect the particulars of your system. The following may need to be changed: HTTPD_USER, typically nobody, or maybe a "Web" or "WWW" user; LOG_EXEC, the log file for suEXEC transactions; DOC_ROOT, the root of the Apache Webspace; and SAFE_PATH, the PATH environment variable for suEXEC. Then you need to compile suEXEC (gcc -o suexec suexec.c), chown it to root, set the set userID bit (chmod4711 suexec), and copy it to its final destination.

Apache must now be recompiled to use the suEXEC wrapper. In the src/httpd.h file, you will need to add or edit a line like this:

#define SUEXEC_BIN "/usr/sbin/suexec"

to reflect where you installed the suid root suexec binary. When you start your new httpd, you should see this message:

Configuring Apache for use with the suexec wrapper.

To disable suEXEC, you can remove the binary, change its ownership from root, or unset the set uid bit.

User and Group directives in VirtualHost directives can be used to tell suEXEC the target user and group for executing CGI. Another way is for the target user to do so in HTTP requests to user directories. For example, http://thppt.org/~dweezle/somescript.cgi-somescript.cgi would be executed as the user dweezle. If neither of these conditions exists, the script will be executed as the main user and group.

./Configure
make
						

SSLProtocol SSLv2

If possible, when you are anticipating large amounts of database activity, MySQL should be installed on a separate physical disk from the document root of your Web server. The MySQL source is available from the MySQL home page at http://www.tcx.se/, as well as from mirror sites in the U.S. If you prefer, you can retrieve a precompiled binary distribution. There is also an active mailing list for MySQL. Information on joining it can be found on the MySQL home page. Documentation is available there as well.

The most recent versions of MySQL require recent versions of libc. If you don't have a new enough libc and are skittish about upgrading it, just install a binary version.

If you install a binary distribution, it will create a directory named mysql-<version> with various subdirectories for libraries, header files, and data files. If you compile and install from the source, mysql subdirectores will be created in /usr/local/lib and /usr/local/include. The data folders and files will be created in /usr/local/var.

Note the prefix path (/usr/local by default); it will be needed when you compile PHP and, later, Apache.

MySQL uses GNU autoconf. There are a few configuration options to be especially aware of:

--prefix                        Installation directory prefix (/usr/local
                                by default)
--enable-thread-safe-client     Make thread safe client library
--without-debug                 Compile without extra debugging code
--without-server                Only compile client library and programs 
--without-perl                  Don't build and install the Perl interface
--enable-shared                 Build a shared client library

After the configuration finishes, you can run make and then make install. If this is your first time installing MySQL, you will also need to install the grants database. Chapter 12 has more details on installing and setting up MySQL. If you are just upgrading MySQL, you need only to start and restart the server.

Okay, this is the paragraph where we tell you that you need to know SQL to start using your new Web server and that this isn't a book on SQL and that you will need to either search out tutorials on the Web or buy a book on SQL. The MySQL home page has some examples in its online documentation and a separately maintained manual, more importantly, tells what additional features MySQL has beyond the standard ones. A good SQL tutorial can be found at http://w3.one.net/~jhoffman/sqltut.htm and there are others to be had, as well as numerous books.

PHP is the next item to compile. You will, however, need to have Apache unpacked since at the end of the compile, the PHP module and libphp will be copied into the Apache source directory. The PHP home page is at http://www.php.net/; very complete documentation, information on the PHP mailing list, the source code, and other related items can be found there.

Since you are building only the library and not the CGI version of PHP, compilation should be easy; there is no linking step, so there are no linking errors. All the potentially sticky linking will come when you compile and link Apache. You will need to know the MySQL install root and the location of the Apache source code. PHP, as you will notice when you run the install script (something of a misnomer since it does not install anything), supports a large number of databases and enhanced file uploading, logging, and access control. Depending on your system's resources and your Web site's style, you may want to enable some or all of these.

Obviously you will want to answer Yes to MySQL support. If you have any of the other supported databases, you may want to enable them as well. PHP also supports the GD graphics library. If you wish to enable this, make sure libgd and its associated header file are in /usr/lib and /usr/include, or /usr/local/lib and /usr/local/include, or provide the directories in the list of additional directories to search for libraries and header files. It is fine to let PHP use the Linux system regex library, and it should find the gdbm library and header that come with Linux as well. Change directories to the src directory and run make.

At the end of the make, directions for editing the Apache configuration file will be printed. You may want to copy them into a file or editor to keep them for the Apache compilation.

The Apache configuration and compilation are straightforward. Move into the source directory, edit the file Configuration, and make the changes indicated at the end of the PHPmake. The configuration file is loaded with various modules you can disable or enable by commenting or uncommenting the appropriate lines in the file. In general, the slimmer you can make the server, the better. Comment out what you obviously don't need. If you're not sure, leave the module in. If you anticipate having large numbers of users to authenticate, you will probably want to enable a database-based authentication scheme using (g)dbm, MySQL, or mSQL. A complete list of modules and their descriptions can be found at http://www.apache.org/.

After you have finished editing, run the Configure script and then make. If you have linking errors, 90 percent of the time they can be solved by rearranging the list of libraries in LFLAGS in the Configuration file. Most of the rest of the time it is simply a forgotten library or library path. Persevering though a little trial and error should result in an httpd binary. After testing the server a little, you will likely want to strip it to save on memory requirements.

If you still can't get your server to link, the best forums for help will likely be the PHP and/or MySQL mailing lists, unless you believe the problem to be unrelated to the addition of these packages.

Now check httpd.conf and srm.conf.

Under Linux, Apache is commonly set up as follows:

All of these are alterable. Obviously, you can keep the server binary wherever you choose. The configuration files' location is settable on the command line, and the log location and document root are settable in the configuration files.

To tell Apache to parse . php3 files with the embedded PHP parser, add a line like this to your srm.conf:

AddType application/x-httpd -php .php3

If you want to parse every file and end them all in .html, change ".php3" to ".html" in the statement.

Now start up the server. With the above setup, you would enter httpd-f /etc/ httpd/conf/httpd.conf -d /home/httpd. Make or edit (if it already exists) an index.html in the document root. Somewhere in the document, add a line like <? phpinfo(); ?>.

The phpinfo function should spit out a few screenfuls of CGI environment variables and configuration information. If it doesn't, check to make sure you added the correct line to your srm.conf or httpd.conf to tell Apache to parse .php3 or .html files, and then make sure you have the right extension on your file and mod_php enabled in your Apache source Configuration file.

The PHP documentation describes how to connect to MySQL databases either locally or remotely, as well as the usage of the various functions for performing queries and database and table administration.

There are other goodies you may want to consider adding to your server. If you use lots of Python or Perl CGI, you can embed the interpreters for these into Apache. Respectively, these modules are PyApache and Mod_Perl. If you wish to enhance security, you can use digest authentication instead of basic authentication. Also you can add in SSL support as mentioned earlier in this chapter. Finally, there are modules for powerful URL rewriting using regex pattern-matching and replacement, correcting misspelled URIs, and tracking users through the site using cookies. New modules are being added all the time and not all are shipped with the source. Check the Apache Web site for the most up-to-date list.

Various encoders exist for creating real audio and video. Unfortunately, only an audio encoder exists for Linux. To encode video or audio/video, you will need an MS Win32 machine or a Macintosh.

The media encoder, rmenc, for Linux is free as well and can be used to convert .wav and .au files into RealMedia files. Additionally, if you have the OSS sound drivers, it can listen to your soundcard's output and record that.

If you wish to record individual tracks from your CD-ROM, you can use cdda2wav to make .wav files and convert them using rmenc.