1. 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 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: ServerName ipalias DocumentRoot path

2. 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 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

3. More Each 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) ServerName www.company1.com DocumentRoot /home/company1 ServerName www.company2.com DocumentRoot /home/company2 ServerName www.company3.com DocumentRoot /home/company3 ServerName www.company1.com DocumentRoot /home/company1 ServerName www.company2.com DocumentRoot /home/company2

4. 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 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 ServerName www.company1.com DocumentRoot /home/company1 ServerName www.company2.com DocumentRoot /company2 ServerName www.company3.com DocumentRoot /home/company3

5. 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 ServerName www.company1.com ServerAlias company1.com ServerAlias www.company1.org ServerAlias www.company1.net ServerAlias sales.company1.com DocumentRoot /home/company1 Or ServerName www.company1.com ServerAlias company1.com ServerAlias *.company1.com ServerAlias www.company1.* DocumentRoot /home/company1

6. 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

7. 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 …

8. 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

9. 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 directives

10. Directives These are some of the directives that are generally thought to be used for server configuration but can also be used in containers – AcceptPathInfo – AccessFileName (to override.htaccess as the default access file name) – DefaultType –,,,,, – 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

11. 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 container for company1, you will add 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 ServerName www.company1.com DocumentRoot /home/company1 AllowOverride Indexes Options

12. Example NameVirtualHost 172.19.31.12 Order allow,deny Deny from all ServerName www.company1.com DocumentRoot /var/www/hosts/company1 AllowOverride all Allow from all ServerName www.company2.com DocumentRoot /var/www/hosts/company2 AllowOverride all Allow from all Establish protection for directories above any virtual host’s directory Override any directives and protection from the previous directory

13. Web Site Structure

14. 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, containers and if necessary, and containers

15. 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

16. 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

17. 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

18. 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

19. Configuring Many Similar VHs Imagine that you have dozens of VHs that you want to configure using 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 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

20. 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

21. 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