Apache: Basic Setup Guide

This guide was written using the enhanced Apache 1.3 that, for years, has been included with OpenBSD. (It might be true that some of these details differ for Apache 2.)

Sometimes, using one style of configuration lines seemed to work better than another style. This is probably an error with some documentation. Recently, a clean-up effort was made to compilie different versions of the documentation. The current version includes some notes that may need adjustment. As a result, this guide is expected to be an excellent resource once some rough edges are smoothed out... for the time being, some tinkering/testing may be needed.

There are some details at: Web transfer: Apache section. (That section is recommended to read first.)

Basic configuration
Location of web content

A common location may be at /var/www/htdocs/ although that could vary. If that directory does not exist, it may be worth checking where the program will look.

The location of the web content is specified by Apache's configuration file (located as discussed in the section about the location of Apache's the configuration file.

The location can likely just be customized, overriding any defaults, by using “ -d /var/www/htdocs ” as a command line parameter to httpd

[#apcheclc]: The location of Apache's configuration file Location of the configuration file

This file is typically, by default, named httpd.conf and might be at /var/www/conf/ by default. If there is a desire to try get the compiled-in (hard-coded) default configuration file reported, try running:

echo $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2)
Starting the web server

Optional but recommended for first-time users: First, verify how many instances/processes of the Apache webserver are currenty running. (This way, one can check again later, and have little doubt as to whether all those processes are new processes or not.)

This may vary. If HTTPS is already set up with any needed certificates (which is usually not the case the first time the webserver is started), then the preferred command to run is:

apachectl startssl

In other cases, for at least some versions of Apache, the preferred command to run is:

apachectl graceful

If the Apache webserver is not running, then this will attempt to start the Apache webserver. If the Apache webserver is running, this will instead try to perform a “graceful restart.”

If that does not work, try reading the manual page. Other possibilities might be apachectl restart or (perhaps just for older releases) apachectl reload (or some other option shown by running “ apachectl --help ” at the command line). Another possibility may be to run “apachectl start” to start the server (without HTTPS support enabled).

This may start several copies of the Apache webserver's httpd executable. Then, the preferred way to stop the web server (if there becomes a desire to stop the webserver) is to use:

apachectl stop

If there are problems starting the service, check the webserver's logs. (This is different than many other services that will use a centralized log for the OS.) The path might be /var/www/logs/error_log

[#apachrt]: Apache chroot

If the web server is not finding some expected files, the behavior may be the result of a chroot. A chroot is designed to enhance security by restricting what files are available. (The concept of chroot is not limited to Apache. For example, the web server thttpd can also support using a chroot.)

OpenBSD FAQ: chroot with Apache (FAQ 10.16) states, “Put bluntly,” using a chroot with “Apache is something not done by default in most other operating systems. Many applications and system configurations will not work in a” chroot “without some customization.” For many operating systems, setting up a chroot enhances security. (A guide about How to 'chroot' an Apache tree with Linux and Solaris describes how to start enabling this.) With OpenBSD, perhaps unusually, chrooting pre-exists.

If an existing problem seems to be that files are just not being accessed the way that they are expected, consider checking whether a chroot is in effect. For example, with OpenBSD, consider just disabling the chroot temporarily. Note that this could cause security vulerabilities, and so should generally not be done on a machine unless the computer is sufficiently protected (such as if the Ethernet cable is removed). So, this might not be a long term solution. However, if disabling a chroot causes things to be fixed, then the cause of the problem will likely be rather clearly identified.

To disable chroot, the basic approach will be to add a -u parameter. First find any running occurrences of Apache, figure out what command lines are used, and stop those instances. This can likely be done with something like:

ps -auxww | http
ps -auxww | apache
apachectl stop

Then, run the server using -u. (The easy way to do this may be to not use apachectl.) (According to OpenBSD's manual page for OpenBSD's version of the Apache httpd command, this -u stands for “unsecure” behavior.) For example, run:

httpd -u

If the results are desirable, then don't just leave the web server running in “unsecure” mode! With the cause clearly identified, determine whether the effects of the “chroot” are desirable. OpenBSD FAQ on using Apache's chroot (FAQ 10.16) may provide an overview to help figure out if this feature is desirable. If so, consider leaving the chroot in place. To get things to work, some change in the configuration may be appropriate.

In some cases, limitations may make a chroot undesirable. For example, maybe there is a desire to run just one copy of the web server, but some files are most appropriate to store under a specific directory like /mnt/. According to OpenBSD's FAQ, “Your options are to restructure or do not use the chroot” functionality.

If using chroot is desired

Review OpenBSD FAQ on using Apache's chroot to make sure there are not going to be unexpected problems. For example, dynamic content requiring external files can be a challenge to implement.

Logs may be more clear/precise by making sure a copy of the time zone configuration is stored in a place where Apache can find it. For instance, run:

mkdir -p /var/www/etc
echo n | cp -i /etc/localtime /var/www/etc/.
ls -l /var/www/etc/localtime

Make sure that what got copied is not the actual soft symlink, but is the file. The file will likely be at least triple digits in size (>99 bytes), and the output of the example ls command should not contain “ -> ”.

If chrooting is considered to be undesirable

Rather specific to OpenBSD: To disable the chroot on each reboot, consider adding -u to httpd_flags in the /etc/rc.conf.local file. (The httpd_flags might not pre-exist in that file. Maybe the file itself doesn't even pre-exist. A less customized variation of the file, the /etc/rc.conf file, may show some other usage.) First, as a routine practice, make sure to back up the file. This may be done using a file called cpytobak by using the following command:

cpytobak /etc/rc.conf.local

Naturally, any other suitable backup software can be effectively used.

For example, to disable chrooting and to enable SSL support so that HTTPS may be used, the following line may be appropriate:

echo httpd_flags=\"-u -DSSL\" | tee -a /etc/rc.conf.local

That should take care of things in the long term (after the system is rebooted). For the short term, either reboot (to fully test the entire process that occurs during a reboot) or, for a quicker immediate effect, just modify the command line parameters that are being used.

Next steps
  • Check results with web browser (to verify that the server is running and is being fairly functional).
  • Put files in the specified DocumentRoot directories. If there will be multiple sites:
    • Have things look nice but also make sure they look unique per site. That will help to make sure that each individual website is being uniquely loaded. (Otherwise, having multiple sites using the same data files could be an easy mistake to make.)
    • After making such customizations, check results with a web browser.
Supporting multiple websites

A single webserver can respond to multiple websites, so that browsers making the appropriate HTTP 1.1 requests can specify which website is desired. By doing this, it is not required that each website has its own IP address. (There may be a need for a unique IP address when SSL certificates are being used to provide support for HTTPS, but this is not needed for a basic HTTP connection.

Configuration file support for virtual hosts

Naturally, a great idea to perform before editing the configuration file is to back up the configuration file. (For details on where this file is at, see the section about The location of Apache's configuration file.) e.g.:

cpytobak $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2)

Edit the configuration file. (Use “ nano -w somepath/file ”, or any other preferred software to edit a text file, and edit the httpd.conf file which may be in a directory called /var/www/conf/.)

Enabling Name-based Virtual Host support

In section 3, about virtual hosts, define what IP address(es) will have Virtual hosts.

A broken option?

One tactic used, which seemed to work when running “ httpd -S ” (to show configuration details):


(The above example IPv4 addresses used are from TEST-NET-2, and are simply meant to be used as examples in documentation. Customize them!)

However, in some old documentation, there were some notes that this did not actually seem to have an impact when web pages were loaded.

Recommended approach

One tactic that was actually found to work was:

#NameVirtualHost *
NameVirtualHost *:80
Yet another approach

Before trying to add HTTPS support (in addition to still providing HTTP support), the following seemed to work okay.

#NameVirtualHost *
NameVirtualHost *

That syntax will probably not work as well when later adding HTTPS support. (However, it is mentioned as a possible configuration that may work with HTTP, so non-HTTPS web servers might show this configuration being used.)

Adding details for each specific virtual host
Choosing a name

The basic implementation here is that each different website will have a couple of directories created. (One of these directories contains the files that will be accessed via the web browser. Another directory stores the log files, which might not be something intended for public viewing. This sort of layout may not be strictly required for technical reasons, but is sensible and so is what this guide will be demonstrating.) There is no technical requirement (to simply have woring functionality) for these directory names to match each other, nor to have the directory names match any data related to DNS. However, since consistency just makes sense, it may make sense to check the pre-created DNS configuration (if that exists).

(For instance, if the BIND DNS server is being used, check what filenames were used in the /var/named/master/ area. For further details about the configuration used by that software or similar software, see the section about DNS servers.)

[#apchcfvh]: Creating a configuration section for the virtual host
Example of lines configuring a virtual host

Here is an example of a section that applies to miscellaneous requests (e.g. when the web browser does not specify one of the supported server names, such as a request using HTTP 1.0 (which is likely to be exceedingly rare) or if a web browser specifies the webserver's IP address. After that, two examples are provided.

<VirtualHost *:80>
ServerName ServerBasedOnMatchingIPButNotName
DocumentRoot /var/www/vhosts
UserDir disabled
ErrorLog logs/vhosts/noname/error.log
CustomLog logs/vhosts/noname/access.log combined

<VirtualHost *:80>
ServerName example.com
ServerAlias *.example.com
DocumentRoot /var/www/vhosts/exampcom
UserDir disabled
ErrorLog logs/vhosts/exampcom/error.log
CustomLog logs/vhosts/exampcom/access.log combined

<VirtualHost *:80>
ServerName example.org
ServerAlias *.example.org
DocumentRoot /var/www/vhosts/examporg
UserDir disabled
ErrorLog logs/vhosts/examporg/error.log
CustomLog logs/vhosts/examporg/access.log combined

Note: The idea here is that the first section catches IP addresses. However, it seems sensible that the default (discussed in the next section) would do that... Some testing may be in order.

Some older versions of the notes would have <VirtualHost *>” (without the “:80”). Various experiments were done as part of a learning process: another possible variation is to use an exact IP address instead of the asterisk (the *). Some experimentation may still be wise to anticipate, in order to confirm what works best.

Specific configuration lines

This section is not meant to be complete, but is meant to describe some of the lines that people may have more questions with. To see all of the lines that are needed to have a complete configuration, see the section which shows an example of the relevant configuration lines. This section is about providing more details for some of those configuration lines.

Starting the section for a specific virtual host

For each Virtual Host, make a VirtualHost section:

  • For the names of directories, users of the BIND name server may want to make the directory names on the web server match the names of the filenames that were used for each virtual host on the name resolution server. This is not any sort of technical requirement, but consistency just seems to make sense (from an organizational perspective).

    To see those filenames, on the system that is running the BIND name resolution server software, run: “ ls -l /var/named/master/*”.

  • The first line should start with "<VirtualHost " and then an IP address used by the NameVirtualHost section as described above. Once again, though, some old notes found that specifying an exact IP address didn't ultimately work, but simply using an asterisk ("<VirtualHost *>") worked like a charm. (Some further testing may be appropriate.)
Extraneous information

(This multi-paragraph section may often be unneeded when just following the steps of this guide, although these details could help deal with a problematic configuration file.)

Other option that could, at least in theory, be used is to start the section with:

<VirtualHost *>

The key difference here is that the port number is not specified.

Using that method worked fine when setting up the server for HTTP. However, using that method worked less fine when a different configuration is needed when listening to a different TCP port, which becomes common when adding support for HTTPS. Namely, the problem is that at least one site needed to have a separate configuration for HTTPS, so there were two lines:

<VirtualHost *:80>


<VirtualHost *:443>

Now, that worked all fine. However, if any other hosts (including _default_) specified just * while another site specified the port number(s) with “ *:80” and/or “ *:443”, then the web server would not start. An error message may be displayed (to the terminal, not to the logs), stating something like:

VirtualHost _default_:443 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results

Yipes: the “proceeding with undefined results” sounds scary. In reality, it seemed that the webserver may have stopped, so it did not really proceed. At least, that seemed to be the reality sometimes...

The error message itself also seems a bit confusing: the “ports” it refers to is the combination of an address (e.g. *) followed by a port number. The phrase “non-* ports” probably refers to a section where the host name and port combination are specified, rather than being generic. However, the host name may still be using a *. So this is a bit confusing when the error message refers to “non-*” but is actually referring to a line that does include a “*”.

The solution was to change the configuration file so that all HTTP references to VirtualHost included a reference to “*:80”. (An alternative, to make the nasty error message to away,, would be to make sure that absolutely none of the lines referenced “*:80” or “*:443”, but instead if they all referenced “*” without a port number. However, that didn't help much in the efforts to get HTTPS working.)

Disabling UserDir support
In this example, UserDir support is “ disabled”. If a user (e.g. named exampusr) isn't part of a domain (e.g. example.com), we don't want don't want http://example.com/~exampusr to go to exampusr's directory, even if exampusr is a member of the example of one supported domain (like example.org).
Having a “default” virtual host

It might be true that this should go after the other VirtualHost sections.

#<VirtualHost _default_>
# or, perhaps something like: <VirtualHost _default_:*>

<VirtualHost _default_>
# or, perhaps something like: <VirtualHost _default_:80>

# This may have had no impact
DocumentRoot /var/www/vhosts/defsite
UserDir disabled
ErrorLog logs/vhosts/defsite/error.log
CustomLog logs/vhosts/defsite/access.log combined

(Following is some old example text that has been moved here...)

<VirtualHost _default_>
# Comment : This section unexpectedly had no impact
ServerName DefaultWebsiteWithoutClientProvidingName
DocumentRoot /var/www/vhosts/defsite
UserDir disabled
ErrorLog logs/vhosts/defsite/error.log
CustomLog logs/vhosts/defsite/access.log combined

<VirtualHost _default_:*>
# ServerName www.defaultsite.com
DocumentRoot /var/www/vhosts/defsite
UserDir disabled
ErrorLog logs/vhosts/defsite/error.log
CustomLog logs/vhosts/defsite/access.log combined

(and yet some more example configuration text......)

<VirtualHost *>
ServerName www.exampdomain.com
ServerAlias *.exampdomain.com
DocumentRoot /var/www/vhosts/exampdomain_com
UserDir disabled
ErrorLog logs/vhosts/exampdomain_com/error.log
CustomLog logs/vhosts/exampdomain_com/access.log combined

(In yet another example of some changes, the ServerName was commented out, and the ServerAlias line did not exist (effectively acting the same as if it was commented out).

More configuration file changes

Make /var/www/vhosts/ act like the DocumentRoot (e.g.: Allow directory listings to show). To do this:

  • Find out what the DocumentRoot is set to. To do this, search the configuration file. If a command prompt is handy, something like the following may work:
    $ grep -i "^DocumentRoot " $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2)
    DocumentRoot "/var/www/htdocs"

    In this example case (and probably in many actual cases), the Document Root is set to /var/www/htdocs (in the configuration file).

  • Find the definition for the directory (e.g. /var/www/htdocs/) that is serving as the DocumentRoot. This may end up finding lines such as:

    <Directory />
    Options FollowSymLinks
    AllowOverride None

    (Actually, there is no real significance to the above lines. However, searching for “<Directory />” and then the following “</Directory>” line might help to locate the following lines. After the previous example lines, there may be a blank line and then the following lines.)

    # [ more comment lines and other lines ]
    # This should be changed to whatever you set DocumentRoot to.
    <Directory "/var/www/htdocs">

    After finding the start of the “<Directory” section that defines the directory that is being used as the DocumentRoot (e.g. “<Directory "/var/www/htdocs"”), find the end of that “<Directory” section, by finding the matching </Directory> tag.

    After that </Directory> tag (that ends the “</Directory” section for the directory that is the DocumentRoot), make a new </Directory> tag for the directory that will store virtual hosts. For instance, make something like:

    <Directory "/var/www/vhosts">

    Then, copy all of the options from the previous “<Directory ” section (which is the “<Directory ” section for the directory which is the DocumentRoot). (Copying all of the comments may not be necessary: Just copy the lines that do things.) The end result may look something like this:

    <Directory "/var/www/vhosts">
    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
Changes for each virtual host
Configuration file handling

First, a quick re-cap:

One change needed for each virtual host is that the configuration file should have a VirtualHost line that includes a ServerName for the file. (Also, to support both example.com and www.example.com and any other domains that people might try, set the ServerAlias to “*.example.com”. This, and other lines, were covered in the section about creating a configuration section for the virtual host.

Making required directories

Then, make sure that any referenced directories exist.

Log directories

Some files that need to exist can be shown using:

echo $( grep -i ErrorLog $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2) | grep -v \# | cut -d L -f 2-10 | cut -d " " -f 2 | xargs )
echo $( grep -i CustomLog $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2) | grep -v \# | cut -d L -f 2-10 | cut -d " " -f 2 | xargs )

Understand that what is shown are files, relative to /var/www (or probably (more accurately) the ServerRoot defined by the configuration file). The directories need to pre-exist. There must not be a directory by that name, because the webserver will try to make a file by that name. So, manually make any such directories that are needed.

Other directories

This probably isn't needed, but some fast copy-and-paste lines could potentially make a required directory that might otherwise be overlooked. (The following command lines should not require any customization.)

To (rather quickly) see a list of directories that need to exist, run commands such as:

grep -i DocumentRoot /var/www/conf/httpd.conf

For those who can easily copy and paste this text, the following may do this nicely:

echo $( grep -i DocumentRoot $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2) | grep -v \# | cut -d c -f 2-10 | cut -d " " -f 2-10 | xargs )
echo $( grep -i "\<Directory" $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2) | grep -v \# | cut -d c -f 2-10 | cut -d " " -f 2-10 | cut -d \> -f 1 | xargs )

Note: The above example does not create any of the necessary directories. It simply lists some directories that need to exist. (Also, some of the listed directories might pre-exist, in which case there isn't a need to make them.) (For details about how to make a directory, see the details in the section about making directories.)

These directories are shown as full paths. Directories with spaces in their filenames might have part of their name chopped by the cut command, in which case the following example may not work so well. However, if the output of the above looks good/safe/desired, at least some of those directories may be created using this variation:

sudo mkdir -p $( grep -i DocumentRoot $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2) | grep -v \# | cut -d c -f 2-10 | cut -d " " -f 2-10 | xargs )
sudo mkdir -p $( grep -i "\<Directory " $(httpd -V | grep -i HTTPD_ROOT | cut -d \" -f 2)/$(httpd -V | grep -i SERVER_CONFIG_FILE | cut -d \" -f 2) | grep -v \# | cut -d c -f 2-10 | cut -d " " -f 2-10 | cut -d \> -f 1 | xargs )
Older documentation

The following section represents what is probably some older documentation. (This should be reviewed and, as applicable, either merge with the earlier text, or replace the earlier text, or more likely, be replaced by the earlier text.)

Make the directories needed
  • For the example domain above:
    • This might need to be adjusted to reflect changes made in the example text above mkdir /var/www/vhosts/exampdomain_com
    • mkdir /var/www/vhosts/default_site
    • mkdir /var/www/logs/vhosts
    • mkdir /var/www/logs/vhosts/exampdomain_com
  • For the default as shown in above httpd.conf
    • mkdir /var/www/logs/vhosts/
    • mkdir /var/www/logs/vhosts/default_site
  • Note: This is vitally important. When mistyping a directory name once in the httpd.conf file so that the ErrorLog line in just one of several hosts pointed to an invalid path, httpd would appear to start but wouldn't. apachectl graceful or apachectl restart would say that httpd could not be started. /var/www/logs finally clued me it when it said: httpd: could not open error log file /var/www/logs/vhosts/default_site/error.log.
Check config

Check the validity of the Virtual Hosts section of the configuration file. (It makes sense to do this after the required directories exist, so that the configuration file checker doesn't complain about a reference to a non-existant directory.)

The section about configuring virtual hosts can be checked with httpd -S ”. A line of output saying “VirtualHost configuration:” will likely be displayed. If the virtual hosts are being successfully configured, a more elaborate bunch of output should be shown. The following is an example of what may be shown. (Output is likely to exceed 80 columns, so word wrapping might be commonly experienced on a traditional 80 column terminal.)

$ httpd -S
VirtualHost configuration:
wildcard NameVirtualhosts and _default_ servers:             is a NameVirtualHost
                       default server ServerBasedOnMatchingIPButNotName (/var/www/conf/httpd.conf:971)
                       port 80 namevhost ServerBasedOnMatchingIPButNotName (/var/www/conf/httpd.conf:971)
                       port 80 namevhost aname.example.com (/var/www/conf/httpd.conf:979)
                       port 80 namevhost example.com (/var/www/conf/httpd.conf:988)
                       port 80 namevhost websrv-if0.mylocal (/var/www/conf/httpd.conf:1009)

Then, check the rest of the configuration file:

$ apachctl configtest
Proccessing config directory: /var/www/conf/modules/*.conf
Syntax OK

The desired results from the configtest is “Syntax OK” Note that such results do not suggest that the configuration will be accepted by Apache.

Make sure the configuration file gets re-loaded.

apachctl graceful
Supporting short filenamed index file

To add support for a short filenamed index (index.htm):

Use nano or any other preferred software to edit a text file. Edit the configuration file, which may often be a file named httpd.conf and that file may often be in a directory called /var/www/conf/.

Find the line that says "DirectoryIndex index.html" and append a " index.htm"

Restart the httpd daemon.

Supporting HTTPS
Supporting SNI

The two options are, naturally, to support SNI or to not support SNI.

Web server technical requirements

Ivan Ristić's Blog about TLS added to Apache identifies this as being added on July 28, 2009's Apache 2.2.12. (This was added on May 19th, 2009, as shown by Apache code Revision 776281 and was based on code from Apache PR 34607.)

Methods to determine if SNI is supported by the Apache build
Config Test

The easiest way to tell whether this is supported by the web server may be to check the configuration file for “SSLStrictSNIVHostCheck

If that text doesn't exist, try adding:

SSLStrictSNIVHostCheck off

Then run:

apachectl configtest

Undesired results:

Syntax error on line 960 of /var/www/conf/httpd.conf:
Invalid command 'SSLStrictSNIVHostCheck', perhaps mis-spelled or defined by a module not included in the server configuration

All of the following text about SNI is speculative: At the time of this writing, the author of this text hasn't fully verified at least some of the following statements, or at least some of the functionality discussed in the following portions of documentation related to Apache's SNI support.

If that shows up, use a different web server. For instance, OpenBSD FAQ 1.8: What is included with OpenBSD mentions coming with an “improved and secured version of the Apache 1.3 web server.” As SNI was added with Apache 2.2.12, SNI is not supported by the included web server. However, a package named apache-httpd does come with version 2.x, and so may support SNI. (Of course, for those who are not quite as ready to accept some of the licensing restrictions that the Apache team added to version 2.x, there are other options such as Nginx.)

If the configtest ends up showing:

Syntax OK

... then Apache supports this syntax, which is a promising start.

Apachi Wiki: Prerequisites to use SNI mentions some details that can be found in the error log after everything is more fully set up. (Search for “named-based virtual hosts”.)

Apachi Wiki: Prerequisites to use SNI discusses some of the technical requirements. Namely, in addition to the web browser supporting this, the SSL support needs to support SNI.

Configuration requirements

As for modifying the web server configuration, one step is to address SSLStrictSNIVHostCheck. TechRepublic guide about SNI discusses how this impacts clients: By disabling the SSL strict SNI VHost Check, the web server “will not throw a 403 error if the client does not support SNI; instead, they will be redirected to the SSL site defined first” in the configuration file, “so be sure to define your default site first.” Some documentation at Apache Wiki: sectiona bout clients not supporting SNI does provide a reference to the result being a 403.

Josh Prewitt's guide seems to show how this is done.

The following represents some old notes. They have not yet been merged into the style of the latest website.

Adding support for making material password-protected

Hmm, I don't know why I reference /var/www/conf/htdocs/index.html, that doesn't seem to be accessed. ???

Restart apache so passwords can take affect: apachectl reload

Add support for user directories

Ensure username support is added to httpd: modify /var/www/conf/httpd.conf, change "#UserDir disabled" to "UserDir /var/www/users" and then uncomment the Directory /users/* section. (Then same httpd.conf and restart w/ apachectl graceful) per http://www.nomoa.com/bsd/apache.htm


Visit the web site, notice it works. It has apache_pb.gif in it. cd /. find . -iname apache_pb.gif. One result is /var/www/htdocs/. Inside that directory is also a index.html file. This is the file that gets loaded, so make that file interesting: