Virtual Hosts• The apache server can handle multiple “web sites” at a time– a web service provider company may have multiple different

sites to offer (see figure 6-2)– a single company may wish to partition their web site into

multiple domains (e.g., sales, accounting, management, research, etc) (see figure 6-1)

– a single organization may wish to give each user their own web site

• In any of these cases, the idea is to have the web server create several virtual hosts – although in the last case, we just divide the file space up

• We use the <VirtualHost> container for this, which allows each “host” to have their own server-specific configuration– we can divide our hosts up based on IP addresses or IP aliases– the container looks like this: <VirtualHost ipaddress>

ServerName ipalias DocumentRoot path</VirtualHost>

IP-Based• Assume that we want each of our servers to have a

unique IP address– in fact, we will have to set up the DNS entries so that all

of the different IP addresses resolve to the same IP address, that of our web server• see figure 6-3

• Now we place in our httpd.conf file <VirtualHost> containers for each server– one container per server– this allows us to add more servers over time (or remove

servers) just by modifying the httpd.conf file• each virtual host will apply the overall server configuration but

you can also specify server-specific directives for each virtual host as is needed

• many of the directives we saw from chapter 5 that dealt with 1 server can be applied to any, each or some combination of servers

More• Each <VirtualHost> container will have its own unique IP address

• To the right, you see three different servers

• Notice how each server maps to a different location under DocumentRoot

• We might create symbolic links so that each company can edit their own directory from a location that they are more familiar with

• We can also set up our various servers to respond to different ports of the same IP address (see the right below)

<VirtualHost 172.19.31.1> ServerName www.company1.com DocumentRoot /home/company1</VirtualHost><VirtualHost 172.19.31.2> ServerName www.company2.com DocumentRoot /home/company2</VirtualHost><VirtualHost 172.19.31.3> ServerName www.company3.com DocumentRoot /home/company3</VirtualHost>

<VirtualHost 172.19.31.1:80> ServerName www.company1.com DocumentRoot /home/company1</VirtualHost><VirtualHost 172.19.31.1:8080> ServerName www.company2.com DocumentRoot /home/company2</VirtualHost>

Name-Based• If we want all of our servers

to share the same IP address, there is only one major difference required to the apache server– we must add the directive

NameVirtualHost ipaddress to our httpd.conf file where ipaddress is the shared IP address of all servers• this same address will be placed

in each server’s <VirtualHost> container

• We will also have to ensure that all DNS servers resolve any of the servers’ aliases to this same address

NameVirtualHost 172.19.31.1

<VirtualHost 172.19.31.1> ServerName www.company1.com DocumentRoot /home/company1</VirtualHost><VirtualHost 172.19.31.1> ServerName www.company2.com DocumentRoot /company2</VirtualHost><VirtualHost 172.19.31.1> ServerName www.company3.com DocumentRoot /home/company3</VirtualHost>

More• We can use the name-based approach to allow multiple alias names to map to the same server by supplying numerous ServerAlias directives within a VirtualHost container– for instance, imagine that

www.company1.com wishes to also be recognized by company1.com, www.company1.org, www.company1.net and sales.company1.com

• We can also permit the * or ? wildcard to save on the number of entries we might want to put into our container– however, this can easily result in

problems with respect to have misspelled server names map to the wrong thing

<VirtualHost 172.19.31.1> ServerName www.company1.com ServerAlias company1.com ServerAlias www.company1.org ServerAlias www.company1.net ServerAlias sales.company1.com DocumentRoot /home/company1</VirtualHost>

Or<VirtualHost 172.19.31.1> ServerName www.company1.com ServerAlias company1.com ServerAlias *.company1.com ServerAlias www.company1.* DocumentRoot /home/company1</VirtualHost>

Some Additional Comments• If we just add the previous entries into our httpd.conf file,

it does us no good unless we also ensure that DNS entries have the same mappings– for instance, if you are at site X and issue an http request for

www.company1.org, if the DNS for site X does not map www.company1.org to 172.19.31.1, then the http request never makes it to our server for processing!

– so we have to make sure that the DNS tables across the Internet reflect the proper mappings• we have already set up a BIND server, so we will explore this in the

next labs

• You can use both IP-based and Name-based virtual hosts if desired by having some VirtualHosts share the same IP address and others have different addresses– this will require that you use NameVirtualHost for any shared

address

Continued• If you are using name-based virtual hosts, then any

http request that reaches your server will already have had the IP address resolved– because of this, we do not have to put IP addresses in our

VirtualHost containers, but can replace them with * • the * will match any IP address• only do this with the name-based approach, if you use the IP-

based approach, then each virtual host maps to a unique address

• If your computer has multiple IP addresses (e.g., an internal address and an external address)– you can place all IP addresses in the VirtualHost container

(and the NameVirtualHost directive)• NameVirtualHost 172.19.31.12• NameVirtualHost 10.11.31.12• <VirtualHost 172.19.31.12 10.11.31.12> … </VirtualHost>

Include Files• Recall that not all directives need to be placed in the

httpd.conf file– in fact, for virtual hosts, you would not want this because

each server’s web administrator(s) will need to edit the configuration file for that server• if all directives were shared in one file, then you would have to

give many different people access to that one file

– typically, we want to place additional directives in an htaccess file • these are directives that apply to a particular directory • however, it is likely that the directives desired by the

administrator(s) are ones to impact the entire virtual server

– therefore, we allow the administrators to place these server-wide directives in a different file, which is then included with the httpd.conf directives via include directives

More• The include statement is followed by the filename– the filename typically reflects the virtual host’s name

such as include www.company1.com• If there are multiple files to be included and they are

in the same directory, we can specify the directory instead as in include /etc/httpd/includes– as an example, each server’s administrator will probably

want their own error log– while we can set the Error Log file’s location in

httpd.conf, we can allow each server’s administrator to override this in their own include file

• Many of the directives available in the server context are also available in the virtual host context – but not all, for instance User, Group, StartServers,

ServerLimit, etc are only available in the server context– the next slide provides a partial list of useful <VH> directives

<VirtualHost> Directives• These are some of the directives that are generally thought to be

used for server configuration but can also be used in <VirtualHost> containers– AcceptPathInfo– AccessFileName (to override .htaccess as the default access file

name)– DefaultType– <Directory>, <Files>, <Location>, <IfDefine>, <IfModule>,

<Limit>– Include– Options, SetHandler– KeepAlive, KeepAliveTimeout, TimeOut, MaxKeepAliveRequests– ServerAdmin, ServerName, ServerSignature– ErrorDocument, ErrorLog, LogLevel (covered in chapter 7)

• There may not be useful reasons to alter the values as established by the server configuration such as AcceptPathName and DefaultType

• On the other hand, the virtual host may use different types of logging and want to establish different Options and Handlers

Overriding httpd.conf Directives• Recall that the outermost context is the server’s settings– we do not want our individual administrators to have access to

httpd.conf but we want to allow them to have their own specific directives in their include files

– so, in our httpd.conf file, we need to add the AllowOverride directive to any DocumentRoot directory• for instance, in the <VirtualHost> container for company1, you will

add <Directory /home/company1> and place the AllowOverride All directive in that container

– the question is, do we want to use “All” in our AllowOverride or be more specific?• AllowOverride can have

None, All, or any subset of this list:– AuthConfig, FileInfo,

Indexes, Limit, Options

• see the example to the right

<Virtualhost 172.19.31.1> ServerName www.company1.com DocumentRoot /home/company1 <Directory /home/company1> AllowOverride Indexes Options </Directory></VirtualHost>

ExampleNameVirtualHost 172.19.31.12<Directory /var/www/hosts>

Order allow,deny Deny from all</Directory><VirtualHost 172.19.31.12>

ServerName www.company1.comDocumentRoot /var/www/hosts/company1<Directory /var/www/hosts/company1>

AllowOverride allAllow from all

</Directory></VirtualHost><VirtualHost 172.19.31.12>

ServerName www.company2.comDocumentRoot /var/www/hosts/company2<Directory /var/www/hosts/company2>

AllowOverride allAllow from all

</Directory></VirtualHost>

Establish protection fordirectories above anyvirtual host’s directory

Override any directives andprotection from the previousdirectory

Web Site Structure

Structure Continued• The httpd.conf file will store– all of the server-wide values– set up server directories (/, document root, cgi-bin)– set up the virtual hosts– include any conf files that might be virtual host wide

• these files would be located under the virtual host directories so that the virtual host web admins have access

– set up initial Options and Deny/Allow permissions– permit overriding

• Each virtual host will have– an Include file that contains virtual host-wide directives

(optional)– .htaccess files that will contain specific directives,

<Directory> containers and if necessary, <Files> and <Location> containers

Continued• Server-wide directives will include

– Listen, TCP directives– Deny/Allow for specific directories– under document root, -Indexes, +FollowSymLinks, +Includes, -

ExecCGI• Let’s assume that dept1 will only permit specific users, then

the include file or .htaccess file for dept1 will need– LoadModule for the proper authentication– for the dept1 directory, authentication directives and a password file

(probably stored in that directory)• Let us further assume that dept2 will permit CGI execution, so

its Include file or .htaccess file will need– Options +ExecCGI– either its own cgi-bin directory, or the ability to place cgi code in

/var/cgi-bin and links• Finally, assume that the web administrator for company2 will

allow Indexes but not symbolic links, then the company2 .htaccess file will need– Options +Includes -FollowSymLinks

Virtual Host Performance and Status• The only real drawback to using virtual hosts is that

the more hosts you have, the worse the server’s performance will be– running 10 servers instead of 1 will probably result in 10

times the number of requests to service and thus the server will be 10 times more busy

– running 10 servers instead of 1 will probably require 10 times the amount of disk usage• an ISP that wishes to provide web server services will have to

take this into account when purchasing server hardware

• To determine the status of the various servers, use httpd –S which will list – IP address and port (if different from the default server)– name of the server– location of DocumentRoot for the given server

• we will examine status information in more detail in chapter 7

Other Performance Impacts• The flexibility of overriding directives sounds great,

as does the ability to place directives in include files and htaccess files– however, directives are not just read once– for any http request, each htaccess file is read and the

overrides must be compared to any new directives• the more you override directives, the more you place specific

directives in htaccess files, and the more you separate server directives from virtual host directives, you are creating more work for your apache server

• Is there some way to control this but still provide flexibility?– you might want to limit the number of virtual hosts that

you are running on your apache server

Another Concern: Log Files• Aside from having performance problems by hosting

too many servers, you may also run out of log files– Unix/Linux limits the number of descriptors available to

any process to 64 (usually), file names are one example of a descriptor but Apache tends to use 10-20 descriptors internally• consider if each virtual server uses three log files, one for

successful accesses, one for errors, and one to log redirections then there would be only be enough descriptors for perhaps 17 virtual hosts, possibly far fewer

• One solution is to force all servers to use the same log file(s) – but to include the host’s name in the log file

• your customers may not like this as they may want to keep the log information confidential

• Another solution is to force each virtual host to use a single log file

Configuring Many Similar VHs• Imagine that you have dozens of VHs that you

want to configure using <VH> containers– all of the containers will be nearly identical except for

the VirtualHost ServerName and DocumentRoot• it would be a hassle to enter the dozens of containers, or

even copy and paste them

– the mod_vhost_alias module allows you to specify the server names and it will create the <VH> containers for you• it will fill in DocumentRoot names for each VH using

VirtualDocumentRoot /usr/local/apache2/htdocs/vhosts/%0– each host name (or host IP address) is filled in for %0– you can also use %1 or %2 for the name’s “first part” or “second

part” or %-1 or %-2 for “last part” or “penultimate part” or some combination as in %1/%-1

Per User Directories• What happens when you use the URL

www.nku.edu/~foxr?– what does the ~foxr mean?– in Linux, ~foxr means “user foxr’s home directory”– this is known as a user directory

• How do we set up user directories in general– by permitting user directories, rather than directories

under DocumentRoot, users can edit their web sites from their own home directories

• These are known as per user directories (part of the mod_userdir module, which is part of Apache’s core)– to establish one, you add the directive UserDir dirname

• dirname is the name of the directory underneath each user’s home directory where their web pages will be found

• this typically defaults to public_html

More• We could put the user directories outside of their home

directories, for instance in /var/web by using UserDir /var/web/*/public_html, but this defeats the idea of users have easy access to their web directories

• The UserDir directive allows you to include the argument disabled or enabled

– the enabled/disabled options are used to control whether a specific user has their own user directory

– you can place as many individual users in a list as you want, or leave it blank (to indicate all users)

– for instance, imagine that you want all regular users to have a user directory of public_html but you do not want root or apache to

• UserDir enabled -- the default user dir is public_html• UserDir disabled root apache -- so we don’t need to specify it

here