Chris Tyler - Fedora Linux

# htpasswd -c /var/httpd/team_scores_password chris

New password:

bigsecret

Re-enter new password:

bigsecret

Adding password for user chris

Once the file has been created, leave out the -c option, or you'll erase existing entries:

# htpasswd /var/httpd/team_scores_password diane

New password:

neverguess

Re-type new password:

neverguess

Adding password for user diane

If you prefer, you can include the password at the end of command linewhich works well for scriptsby adding the -b option:

# htpasswd -b /var/httpd/team_scores_password frank TheBestPitcher

Adding password for user frank

If other users are logged in to the system, there is a small chance that they will be able to discover these passwords if you set them using the -b option because the command line is visible in the output of the ps command (although very briefly).

If you enter an existing user ID instead of a new one, the old password will be updated instead of creating a new record:

# htpasswd -b /var/httpd/team_scores_password diane new-secret

Updating password for user diane

.htaccess files have traditionally been used for access control, and they work well for ~/public_html directories because users can configure them on their own. For directories in your document root, it's just as easy to place the authentication directives in a directory container in httpd.conf :

/var/www/html/scores/ >

AuthType Basic

AuthName " team scores "

AuthUserFile /etc/httpd/team_scores_password

Require valid-user

Apache is the most widely used web server software in the world. It is actively developed by the Apache Software Foundation ( http://apache.org ) and can be scaled from a static personal web site on a desktop-class computer to a extremely high-volume database-backed web site running on clusters of computers.

In order to meet such a wide range of needs, Apache can be configured using over 370 distinct directives. Although many different graphical configuration tools have been developed, none of them can configure all directives or handle all possible deployment scenarios for the software.

The Fedora graphical configuration tool for Apache is named system-config-httpd . The options entered into the configuration dialogs are saved in XML and then converted into a working httpd.conf by using the XSLT transformation stylesheet /usr/share/system-config-httpd/httpd.conf.xsl . You can customize that file to change the generated httpd.conf file.

The actual Apache server program is /usr/sbin/httpd . It can be started or stopped with the service command or system-config-services , which use the Fedora-specific script file /etc/rc.d/init.d/httpd ; it can also be started and stopped with Apache tool /usr/sbin/ apachectl, but the SELinux security context will be different.

Apache listens on the configured ports and waits for incoming connections from client software such as web browsers. Once a connection is established, the client sends a request , plus additional headers with information such as the client software version and preferred languages and encodings, followed by a blank line. The server responds with a result code, additional headers, a blank line, and then the content requested (or an error message). In its most basic form, the conversation goes something like this (the request is shown in bold; the response headers are in italic, and the rest of the listing is the body of the response):

GET /testfile.html HTTP/1.1

Host: www.fedorabook.com

HTTP/1.1 200 OK

Date: Wed, 01 Mar 2006 02:49:54 GMT

Server: Apache/2.2.0 (Fedora)

Last-Modified: Mon, 27 Feb 2006 21:25:54 GMT

ETag: "f0518-4a-5b0edc80"

Accept-Ranges: bytes

Content-Length: 85

Connection: close

Content-Type: text/html; charset=UTF-8

Success!

In an elementary configuration, Apache is responsible for mapping the web namespace to the local filesystem namespace, performing access control and logging, collecting the requested resource (either by reading a file or executing code), and sending the resource to the client.

Logfiles come in two forms: access logs and error logs. An access log in the default common format contains entries like these (all on one line):

24.43.223.54 - - [28/Feb/2006:22:01:33 -0500] "GET / HTTP/1.1" 200 956

The fields here are the IP address of the remote host (24.43.223.54); the remote user login name (-); the authenticated username on the local system (- , because the user did not authenticate); the date, time, and time zone of the request ([28/Feb/2006:22:01:33 -0500]); the request string (GET / HTTP/1.1); the status code returned to the client (200, meaning OK); and the number of bytes sent to the client (956).

If you use the combined log format, the entries will look like this:

24.43.223.54 - - [28/Feb/2006:22:01:33 -0500] "GET / HTTP/1.1" 200 956 "http://www.fedorabook.com/index.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7"

The additional fields are the referring page, which linked to or contained the information requested ( http://www.fedorabook.com/index.html ), and the user agent header, which describes the client software (Firefox on a Fedora system in this case). The user agent information is interesting, but the referrer information is critical if you want to analyze where your visitors are coming from, which pages they visit first, and how they progress through your web site.

The error logfile contains entries like this:

[Tue Feb 28 22:01:33 2006] [error] [client 24.43.223.54] File does not exist: /var/www/html/favicon.ico

This indicates the date and time, the fact that this is an error, the client IP address, and the detail of the error.

The problem with basic authentication is that the user ID and password travel in plain text across the network. Anyone snooping on the network can see the password.

A slightly better approach is to use digest authentication, which hashes the password before sending it across the network. This is still not nearly as secure as encrypting the connection.

To use digest authentication, use the same authentication configuration as you would for basic authentication, but substitute Digest for the AuthType :

AuthType Digest

AuthName " prices "

AuthUserFile /var/www/digest