Mass virtual hosting using mod_vhost_alias or mod_rewrite module simplifies pattern-based virtual hosting. However, there is a major problem if your virtual host application makes use of the DOCUMENT_ROOT environment variable. According to the Apache documentation, the mod_vhost_alias does NOT correctly sets the DOCUMENT_ROOT variable and hence pontentially break PHP web applications that makes use of this environment variable. It seems that one logical thing to do is to use the VirtualDocumentRoot to map DOCUMENT_ROOT variable, but current mod_vhost_alias does NOT implement this function and it is very unlikely that it will any time soon.

To best way to solve this problem is to applying a patch for mod_vhost_alias.c, which is written by a person with an email address (cbs[at]cts.ucla.edu) that dynamically sets DOCUMENT_ROOT environment variable. The behavior is controlled by setting SetVirtualDocumentRoot to “on” or “yes”. The original patch can be found apache bugzilla. To apply the patch, you’ll have to rebuild the version of apache you’re running. There is no easy way to rebuild mod_vhost_alias module only.

1. To rebuild apache, you’ll need a source RPM for your platform. We’re running Fedora Core 1, so we’ve downloaded the version from Fedora Legacy. RPM Find provides binary and source RPMs for various platforms.

2. Install source RPM by running, rpm -i httpd-2.0.x.y.z.tar.gz. Where x.y.z is the version of Apache you are installing. The source RPM will be installed in the rpm source directory. For redhat (and Fedora), the location of source rpm is /usr/src/redhat.

3. The next step is to modify the mod_vhost_alias.c as specified in the patch above, and rebuild the binaries. To get the mod_vhost_alias.c file, you’ll need to untar httpd-2.0.x.y.z.tar file locaated in the /usr/src/redhat/SOURCE directory. Extract the tar archive in the temporary directory, and edit the mod_vhost_alias.c file located in the ./httpd-2.0.x/modules/mappers directory.

4. After modifying the mod_vhost_alias.c file, tar up the file and place it in the /usr/src/redhat/SOURCE folder. The new file replaces the old httpd-2.0.x.y.z.tar file.

5. Now, we need to rebuild a binary rpm. However, there are several development rpms that are needed to successfully compile the httpd RPM. There are a few dependencies that you’ll have to resolve by installing a dozen or so rpms. You may retrieve those necessary rpms from the same place where you downloaded source rpm (step 1).

# cd /usr/src/redhat/SPECS
# rpmbuild -bb httpd.spec

6. Upon successfully rebuilding the Apache, extract the mod_vhost_alias.so file from the binary RPM. We only need to replace the mod_vhost_alias.so located in the /usr/lib/httpd/modules directory, and there is no reason to reinstall binary RPM. To extract a file from the RPM, use the rpm2cpio command below.

# cd /tmp
# rpm2cpio /usr/src/redhat/RPMS/i386/httpd-2.0.x.y.z.legacy.i386.rpm | cpio -d -i
# mv /tmp/usr/lib/httpd/modules/mod_vhost_alias.so /usr/lib/httpd/modules

You may wish to make a back of the mod_vhost_alias.so file before overwriting the original. You’ll need to add SetVirtualDocumentRoot on in the httpd.conf file, and restart the apache.

htpasswd is used to create and update the flat-files used to store usernames and password for basic authentication of HTTP users. Resources available from the Apache HTTP server can be restricted to just the users listed in the files created by htpasswd. This program can only manage usernames and passwords stored in a flat-file.

To restrict access to certain HTTP resources, we need to create two files: .htaccess and .htpasswd (or equivalent per httpd.conf setting). The .htaccess file looks something like:

– [.htaccess] file content begins –

AuthUserFile /location/of/.htpasswd
AuthName “Enter Password?”
AuthGroupFile /dev/null
AuthType Basic
require valid-user

– [.htaccess] content ends –

Line 1 [AuthUserFile]: Location of .htpasswd file.
Line 2 [AuthGroupFile]: For multiple user names.
Line 3 [AuthName]: Title of the authentication message box that pops up.
Line 4 [AuthType]: The simplest authentication type.
Bottom 3 lines: A user who can access the limited resource.

The .htpasswd file can be generated using the htpasswd command as described below.

% htpasswd -c -m /path/to/.passwd {username}
New password: ******
Re-type new password: ******
Adding password for user {username}

Synopsis
htpasswd [ -c ] [ -m ] [ -D ] passwdfile username

htpasswd -b [ -c ] [ -m | -d | -p | -s ] [ -D ] passwdfile username password

htpasswd -n [ -m | -d | -s | -p ] username

htpasswd -nb [ -m | -d | -s | -p ] username password

Options
-b
Use batch mode; i.e., get the password from the command line rather than prompting for it. This option should be used with extreme care, since the password is clearly visible on the command line.

-c
Create the passwdfile. If passwdfile already exists, it is rewritten and truncated. This option cannot be combined with the -n option.

-n
Display the results on standard output rather than updating a file. This is useful for generating password records acceptable to Apache for inclusion in non-text data stores. This option changes the syntax of the command line, since the passwdfile argument (usually the first one) is omitted. It cannot be combined with the -c option.

-m
Use MD5 encryption for passwords. On Windows, Netware and TPF, this is the default.

-d
Use crypt() encryption for passwords. The default on all platforms but Windows, Netware and TPF. Though possibly supported by htpasswd on all platforms, it is not supported by the httpd server on Windows, Netware and TPF.

-s
Use SHA encryption for passwords. Facilitates migration from/to Netscape servers using the LDAP Directory Interchange Format (ldif).

-p
Use plaintext passwords. Though htpasswd will support creation on all platforms, the httpd daemon will only accept plain text passwords on Windows, Netware and TPF.

-D
Delete user. If the username exists in the specified htpasswd file, it will be deleted.

passwdfile
Name of the file to contain the user name and password. If -c is given, this file is created if it does not already exist, or rewritten and truncated if it does exist.

username
The username to create or update in passwdfile. If username does not exist in this file, an entry is added. If it does exist, the password is changed.

password
The plaintext password to be encrypted and stored in the file. Only used with the -b flag.

See Apache Manual for details.
To generate encrypted htpasswd online, please visit Generate Password.

Here is simple steps that can be followed to setup webalizer on a host machine.

1. Edit /etc/webalizer.conf
Edit the LogFile entry, OutputDir and Hostname.

2. Set up DNS and edit /etc/httpd/conf/httpd.conf file. (i.e. webstats.domain.tld)

3. Run ‘webalizer’ on the Unix command line.
# webalizer

The log index file should be created in the /var/www/usage directory.

Platform setup:
Fedora Core 3
Apache 2.0.52-3
SELinux enabled.

Apache configuration is setup correctly with right permissions, we the server throws a 403 error.

The log entry in the /etc/httpd/logs/error_log:
“[error] [client xx.xx.xxx.xxx] (13)Permission denied: access to / denied”

The issue is well known but the fixes only apply to Fedora 3, such as :
“Use : chcon -R -t httpd_sys_content_t ”

or

“deactive SELinux at the command line or GUI”.

or

Turn off SELinux enforcing off at boot.
You can specify the SELinux mode using the configuration file /etc/sysconfig/selinux.”

However these commands do not work with Fedora 1.

Here are some of the explanation.
******************************************************
Note for SELinux / Fedora Core 3+ / RedHat Enterprise users:

In addition to regular Unix permissions, under SELinux every file, directory, process, etc. has a ‘security context’. When a process attempts to access a file, besides checking the Unix permissions the system also checks to see if the security context of the process is compatible with the security context of the file.

Fedora Core 3, among other systems, comes with SELinux installed by default, configured so that Apache runs in a fairly restricted security context. To run Subversion under Apache, you have to set the security context of the repository to allow Apache access (or turn off the restrictions on Apache, if you think all this is overkill). The chcon command is used to set the security context of files (similarly to how the chmod sets the traditional Unix permissions). For example, one user had to issue this command

To view the current security contexts of any given file, you can use the unix command ‘ls’ with only the ‘-Z’ option.

$ ls -Z PATH_TO_REPOSITORY
$ chcon -R -h -t httpd_sys_content_t PATH_TO_REPOSITORY
$ ls -Z PATH_TO_REPOSITORY

to set the security context to be able to successfully access the repository.
******************************************************