The Apache Web server configuration file is /etc/httpd/conf/httpd.conf. The httpd.conf file is well-commented and somewhat self-explanatory. Its default configuration will work for most people, so you should not need to change the directives in httpd.conf. However, you may want to be familiar with the most important configuration options.
The empty srm.conf and access.conf files are also in the /etc/httpd/conf/ directory. The srm.conf and access.conf files were formerly used, along with httpd.conf, as configuration files for Apache.
If you need to configure Apache, edit httpd.conf and then either reload, or stop and start the httpd process. How to reload, stop and start Apache is covered in the Section called Starting and Stopping httpd .
General Configuration Tips. If configuring the Apache HTTP Server, edit /etc/httpd/conf/httpd.conf. See a sample httpd.conf file at Configure the Apache HTTP Server Plug-In. Ensure that the WebLogic Server modules are included for Apache 2.2.x. Add the following line to the httpd.conf file if you have not already done so. For Windows, specify the.DLL file.
Before you edit httpd.conf, you should first copy the original file to something like httpd.conf-old, for example. By creating a backup, you can recover potential mistakes made while editing the new configuration file.
If you do make a mistake, and your Web server does not work correctly, first review what you have recently edited in httpd.conf. Make sure that you did not make a typo. The next place to look is your Web server's error log (/var/log/httpd/error_log). The error log may not be easy to interpret, depending on your level of experience. If you have just experienced a problem, however, the last entries in the error log should provide information about what has happened.
- The task priority and stack size are configurable during server instance creation by passing httpdconfigt structure to httpdstart. TCP traffic is parsed as HTTP requests and, depending on the requested URI, user registered handlers are invoked which.
- We will keep the default apache configuration for now, and we’ll just start the web server service. You can do this either using systemctl or apachectl (they both do the same thing behind the scenes): $ systemctl start httpd # or $ apachectl start We will cover apachectl command in more detail later, but for now we’ll stick to using systemctl.
The next sections provide short descriptions of the directives included in httpd.conf. These descriptions are not exhaustive. If you need more information, refer to the Apache documentation provided in HTML format at http://localhoast/manual/ or to the Apache group documentation at http://httpd.apache.org/docs/. For more information about mod_ssl directives, refer to the documentation included in HTML format at http://localhost/manual/mod/mod_ssl/ or see the mod_ssl User Manual at http://www.modssl.org/docs/2.8/.
ServerType Your ServerType must be set to standalone. By default, your Web server is set to ServerType standalone.
The ServerRoot is the top-level directory which contains the server's files. Both your secure and non-secure servers are set to use a ServerRoot of '/etc/httpd'.
LockFile The ScoreBoardFile stores internal server process information, which is used for communication between the parent server process and its child processes. Red Hat Linux uses shared memory to store the ScoreBoardFile, the default of /etc/httpd/logs/apache_runtime_status is only used as a fallback.
ResourceConfig The ResourceConfig directive instructs the server to read the file named after ResourceConfig for more directives. The ResourceConfig directive is commented out, because your Web server only uses httpd.conf for configuration directives.
AccessConfig The AccessConfig directive instructs the server to read the file named after AccessConfig for more directives, after it has read the file named by ResourceConfig. The AccessConfig directive is commented out, because your Web server only uses httpd.conf for configuration directives.
Timeout By default Keepalive is set to off. If Keepalive is set to on and the server becomes very busy, the server can quickly spawn the maximum number of child processes. In this situation, the server will slow down significantly. If Keepalive is enabled, it is a good idea to set the the KeepAliveTimeout low (see the Section called KeepAliveTimeout ) and monitor the servers /var/log/httpd/error_log. This log will report when the server is running out of child processes.
MaxKeepAliveRequests This directive sets the maximum number of requests allowed per persistent connection. The Apache Group recommends a high setting, which will improve your server's performance. MaxKeepAliveRequests is set to 100 by default, which should be appropriate for most situations.
KeepAliveTimeout The Apache Web server dynamically adapts to the perceived load by maintaining an appropriate number of spare server processes based on the traffic. The server checks the number of servers waiting for a request and kills some if there are more than MaxSpareServers or creates some if the number of servers is less than MinSpareServers.
Your server's default MinSpareServers is 5; your server's default MaxSpareServers is 20. These default settings should be appropriate in most situations. You should not increase the MinSpareServers to a large number. Doing so will create a heavy processing load on your server even when traffic is light.
StartServers The Listen command identifies the ports on which your Web server will accept incoming requests. Your Web server is set to listen to port 80 for non-secure Web communications and (in the virtual host tags that define the secure server) to port 443 for secure Web communications.
If you set Apache to listen to a port under 1024, you must be root to start it. For port 1024 and above, httpd can be started as a regular user.
The <IfDefine> and </IfDefine> tags surround configuration directives that are applied if the 'test' stated in the <IfDefine> tag is true. The directives are ignored if the test is false.
The test in the <IfDefine> tags is a parameter name (for example, HAVE_PERL). If the parameter is defined, meaning that it is provided as an argument to the server's start-up command, then the test is true. In this case, when your Web server is started, the test is true and the directives contained in the IfDefine tags are applied.
By default, <IfDefine HAVE_SSL> tags surround the virtual host tags for your secure server. <IfDefine HAVE_SSL> tags also surround the LoadModule and AddModule directives for the ssl_module.
ClearModuleList The ClearModuleList directive is located immediately before the long list of AddModule directives. ClearModuleList erases the server's built-in list of active modules. Then the list of AddModule directives re-creates the list, immediately after ClearModuleList.
AddModule The ExtendedStatus directives controls whether Apache generates basic (off) or detailed server status information (on), when the server-status handler is called. Server-status is called using Location tags. More information on calling server-status is included in the Section called Location .
Port Normally, Port defines the port that your server is listening to. Your Web server, however, is listening to more than one port by default, since the Listen directive is also being used. When Listen directives are in effect, your server listens at all of those ports. See the description of the Listen directive for more information about Listen.
The Port command is also used to specify the port number used to construct a canonical name for your server. See the Section called UseCanonicalName for more information about the server's canonical name.
User The User directive sets the userid used by the server to answer requests. User's setting determines the server's access. Any files inaccessible to this user will also be inaccessible to your website's visitors. The default for User is apache.
The User should only have privileges so that it can access files which are supposed to be visible to the outside world. The User is also the owner of any CGI processes spawned by the server. The User should not be allowed to execute any code which is not intended to be in response to HTTP requests.
Note For security reasons, Apache will refuse to run as User root. Using root as the User will create large security holes for your Web server.
The parent httpd process first runs as root during normal operations but is then immediately handed off to the apache user. The server must start as root because it needs to bind to a port below 1024 (the default port for secure Web communications is port 443; the default port for non-secure Web communications is port 80). Ports below 1024 are reserved for system use, so they can not be used by anyone but root. Once the server has attached itself to its port, however, it hands the process off to the User before it accepts any connection requests.
Group The Group directive is similar to the User. The Group sets the group under which the server will answer requests. The default Group is apache.
ServerAdmin Typically, a good way to set up ServerAdmin is to set it to webmaster@your_domain.com. Then alias webmaster to the person responsible for the Web server in /etc/aliases. Finally, run /usr/bin/newaliases to add the new alias.
ServerName You can use ServerName to set a hostname for your server which is different from your host's real name. For example, you might want to use www.your_domain.com when your server's real name is actually foo.your_domain.com. Note that the ServerName must be a valid Domain Name Service (DNS) name that you have the right to use (do not just make something up).
If you do specify a ServerName, be sure its IP address and server name pair are included in your /etc/hosts file.
DocumentRoot The DocumentRoot is the directory which contains most of the HTML files which will be served in response to requests. The default DocumentRoot for both the non-secure and secure Web servers is the /var/www/html directory. For example, the server might receive a request for the following document:
The server will look for the following file in the default directory:
If you want to change the DocumentRoot so that it is not shared by the secure and the non-secure Web servers, see the Section called Using Virtual Hosts.
Directory By default, very restrictive parameters are applied to the root directory, using the Options (see the Section called Options ) and AllowOverride (see the Section called AllowOverride ) directives. Under this configuration, any directory on your system which needs more permissive settings has to be explicitly given those settings.
Using Directory tags, the DocumentRoot is defined to have less rigid parameters, so that HTTP requests can be served from it.
The cgi-bin directory is set up to allow the execution of CGI scripts, with the ExecCGI option. If you need to execute a CGI script in another directory, you will need to set ExecCGI for that directory. For example, if your cgi-bin is /var/www/cgi-bin, but you want to execute CGI scripts from within /home/my_cgi_directory, add an ExecCGI directive to a set of Directory directives like the following to your httpd.conf file:
To allow CGI script execution in /home/my_cgi_directory, you will need to take a few extra steps besides setting ExecCGI. You will also need to have the AddHandler directive uncommented to identify files with the .cgi extension as CGI scripts. See the Section called AddHandler for instructions on setting AddHandler. Permissions for CGI scripts, and the entire path to the scripts, must be set to 0755.
Options The Options directive controls which server features are available in a particular directory. For example, under the restrictive parameters specified for the root directory, Options is set to only FollowSymLinks. No features are enabled, except that the server is allowed to follow symbolic links in the root directory.
By default, in your DocumentRoot directory, Options is set to include Indexes, Includes and FollowSymLinks. Indexes permits the server to generate a directory listing for a directory if no DirectoryIndex (for example, index.html) is specified. Includes means that server-side includes are permitted. FollowSymLinks allows the server to follow symbolic links in that directory.
You will also need to include Options statements for directories within virtual hosts directives, if you want your virtual hosts to recognize those Options.
For example, server side includes are already enabled inside the /var/www/html directory, because of the Options Includes line within the <Directory '/var/www/html'> directives section. However, if you want a virtual host to recognize server side includes, you will need to include a section like the following within your virtual host's tags:
AllowOverride The AllowOverride directive sets whether or not any Options can be overridden by the declarations in an .htaccess file. By default, both the root directory and the DocumentRoot are set to allow no .htaccess overrides.
Order The Order directive simply controls the order in which allow and deny directives are evaluated. Your server is configured to evaluate the Allow directives before the Deny directives for your DocumentRoot directory.
Allow By default, the subdirectory is public_html. For example, the server might receive the following request:
The server would look for the file:
In the above example, /home/username is the user's home directory (note that the default path to users' home directories may be different on your system).
Make sure that the permissions on the users' home directories are set correctly. Users' home directories must be set to 0711. The read (r) and execute (x) bits must be set on the users' public_html directories (0755 will also work). Files that will be served in users' public_html directories must be set to at least 0644.
DirectoryIndex The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name.
When a user requests the page http://your_domain/this_directory/, they will get either the DirectoryIndex page if it exists, or a server-generated directory list. The default for DirectoryIndex is index.htmlindex.htmindex.shtmlindex.phpindex.php4index.php3index.cgi. The server will try to find any one of these files, and will return the first one it finds. If it does not find any of these files and Options Indexes is set for that directory, the server will generate and return a listing, in HTML format, of the subdirectories and files in the directory.
AccessFileName Immediately after the AccessFileName directive, a set of Files tags apply access control to any file beginning with a .ht. These directives deny Web access to any .htaccess files (or other files which begin with .ht) for security reasons.
CacheNegotiatedDocs By default, your Web server asks proxy servers not to cache any documents which were negotiated on the basis of content (that is, they may change over time or because of the input from the requester). If you uncomment CacheNegotiatedDocs, you are disabling that function and proxy servers will be allowed to cache the documents from then on.
UseCanonicalName For more information about AddType, refer to the Section called AddType .
DefaultType The mod_mime_magic.c file is included in these IfModule tags. The mod_mime_magic module can be compared to the UNIX file command, which looks at a few bytes of a file's contents, then uses 'magic numbers' and other hints in order to figure out the MIME type of the file.
If the mod_mime_magic module is compiled in to Apache, these IfModule tags tell the mod_mime_magic module where the hints definition file is: /usr/share/magic in this case.
The mod_mime_magic module is not compiled in by default. If you would like to use it, see the Section called Adding Modules to Your Server, for instructions on how to add modules to your server.
HostnameLookups Generally, you should leave HostnameLookups set to off, because the DNS requests add a load to your server and may slow it down. If your server is busy, the effects of HostnameLookups will be noticeable.
If you like to see the hostnames in your log files, consider running one of the many log analyser tools that perform the DNS lookups more efficiently and in bulk when you come to rotate your log files.
ErrorLog The error log is a good place to look if your Web server generates any errors or fails, and you are not sure what happened.
LogLevel The LogFormat directives in your httpd.conf file set up a format for the messages in your access log. The actual LogFormat used will depend on the settings given in the CustomLog directive (see the Section called CustomLog ).
CustomLogThe remote hostname. If the hostname is not available from DNS, or if HostnameLookups is set to Off, then remotehost will be the IP address of the remote host.
Not used. You will see a - in the log file in its place.
If authentication was required, this is the username with which the user identified herself. Usually, this is not used, so you will see a - in its place.
The date and time of the request.
The request string exactly as it came from the browser or client.
The HTTP status code which was returned to the browser or client.
The size of the document.
This can give the URL of the webpage which linked to the the current request.
This gives the name of the browser or client making the request.
ServerSignature The ServerSignature directive adds a line containing the Apache server version and the ServerName of the serving host to any server-generated documents (for example, error messages sent back to clients). ServerSignature is set to on by default. You can change it to off, so no signature line will be added, or you can change it to EMail. EMail will add a mailto:ServerAdmin HTML tag to the signature line.
Alias The Alias setting allows directories to be outside the DocumentRoot directory and yet still accessible to the Web server. Any URL ending in the alias will automatically resolve to the alias' path. By default, one alias is already set up. An icons directory can be accessed by the Web server, but the directory is not in the DocumentRoot. The icons directory, an alias, is actually /var/www/icons/, not /var/www/html/icons/.
ScriptAlias The ScriptAlias setting defines where CGI scripts (or other types of scripts) can be found. Generally, you do not want to leave CGI scripts within the DocumentRoot. If CGI scripts are in DocumentRoot, they could potentially be viewed as text documents. Even if you do not care if people can see and then use your CGI scripts, revealing how they work creates opportunities for unscrupulous people to exploit any security holes in the script and may create a security risk for your server. By default, the cgi-bin directory is a ScriptAlias of /cgi-bin/ and is actually located in /var/www/cgi-bin/.
Your /var/www/cgi-bin directory has Options ExecCGI set, meaning that execution of CGI scripts is permitted within that directory.
See the Section called AddHandler and the Section called Directory for instructions on how to execute CGI scripts in directories other than the cgi-bin.
Redirect When a webpage is moved, Redirect can be used to map the old URL to a new URL. The format is as follows:
So, if an HTTP request is received for a page which used to be found at http://your_domain/path/foo.html, the server will send back the new URL (http://new_domain/path/foo.html) to the client, which should attempt to fetch the document from the new URL.
For more advanced Redirection you can use the mod_rewrite module included with the server.
IndexOptions http://your_domain/this_directory/
First, your Web server looks in that directory for a file from the list after the DirectoryIndex directive (usually, index.html). If your Web server does not find one of those files, it creates an HTML directory listing of the subdirectories and files in the directory. You can modify the appearance of this directory listing using certain directives in httpd.conf, including IndexOptions.
Your default configuration sets FancyIndexing on. If FancyIndexing is turned on, clicking on the column headers in the directory listing will sort the order of the display by that header. Another click on the same header will switch from ascending to descending order and back. FancyIndexing also shows different icons for different files, depending upon file extensions. If you use the AddDescription directive and turn FancyIndexing on, then a short description of a file will be included in the server generated directory listing.
This directive names icons which will be displayed by files with MIME encoding, in server generated directory listings. For example, by default, your Web server shows the compressed.gif icon next to MIME encoded x-compress and x-gzip files in server generated directory listings.
AddIconByType This directive names icons which will be displayed next to files with MIME types in server generated directory listings. For example, your server is set to show the icon text.gif next to files with a mime-type of 'text,' in server generated directory listings.
AddIcon You can use AddDescription to show text that you specify for certain files, in server generated directory listings (you will also need to enable FancyIndexing as an IndexOptions). You can name specific files, wildcard expressions or file extensions to specify the files which this directive should apply to. For example, you could use the following line:
In server generated directory listings, all files with extensions of .ni would have the description A file that ends in .ni after the filename. Note that you will also need FancyIndexing turned on.
ReadmeName Use the AddType directive to define MIME type and file extension pairs. For example, if you are using PHP4, your Web server is using the AddType directive to make your Web server recognize files with PHP extensions (.php4, .php3.phtml.php) as PHP MIME types. The following directive tells Apache to recognize the .shtml file extension:
You will need to include the above line within the virtual host tags for any virtual hosts which should allow server side includes.
AddHandler You have a CGI AddHandler line in your httpd.conf file:
You will have to uncomment the line. Then Apache will execute CGI scripts for files ending in .cgi, even if they are outside of the ScriptAlias, which is set by default to locate your /cgi-bin/ directory in /var/www/cgi-bin/.
You will also need to set ExecCGI as an Options for any directory containing a CGI script. See the Section called Directory for more information about setting ExecCGI for a directory. Additionally, you will need to make sure the permissions are set correctly for the CGI scripts and the directories containing CGI scripts. CGI scripts and the entire directory path to the scripts must be set to 0755.
You will need to add the same AddHandler line to your VirtualHost setup, if you are using virtual hosts and you want them to also recognize CGI scripts outside the ScriptAlias.
In addition to CGI scripts, your Web server also uses AddHandler to process server-parsed HTML and imagemap files.
Action By default, in the event of a problem or error, your Web server outputs a simple and usually cryptic error message back to the requesting client. Instead of using the default, you can use ErrorDocument to configure your Web server so that it outputs a customized message or redirects the client to a local or external URL. The ErrorDocument directive simply associates a HTTP response code with a message or a URL which will be sent back to the client.
BrowserMatch The BrowserMatch directive allows your server to define environment variables and take appropriate actions based on the User-Agent HTTP header field — which identifies the client's browser. By default, your Web server uses BrowserMatch to deny connections to specific browsers with known problems and also to disable keepalives and HTTP header flushes for browsers that are known to have problems with those actions.
Location The next use of Location tags is located within IfModule mod_perl.c tags. These configuration directives are in effect if the mod_perl.so DSO is loaded. See the Section called Adding Modules to Your Server for more information about adding modules to Apache.
The Location tags name the /var/www/perl directory (an Alias for /perl) as the directory from which Perl scripts will be served. If a document is requested with an URL containing /perl in the path, your Web server will look in /var/www/perl/ for the appropriate Perl script.
Several other <Location> options are commented out in your httpd.conf file. If you want to enable the functionality they provide, you will need to uncomment the appropriate section of directives.
Note The put module is no longer distributed as part of the Apache package. You will have to load the mod_put package separately.
Immediately after the Perl directives is a section of directives for enabling http put (used by Netscape Gold's publish feature), which can post webpages to a Web server. If you want to allow http put, you will need to uncomment the following lines:
You will also need to uncomment the following lines at the beginning of httpd.conf so that the mod_put module is loaded when Apache starts:
If you want to allow people connecting from your domain to see server status reports, you should uncomment the next section of directives:
You must replace .your_domain.com with your second level domain name.
If you want to provide server configuration reports (including installed modules and configuration directives) to requests from inside your domain, you will need to uncomment the following lines:
Again, you must fill in .your_domain.com.
The next section of directives use Location tags to allow access to the documentation in /usr/share/doc (for example, with a URL like http://your_domain/doc/whatever.html). These directives only allow this access to requests made from the localhost.
Another use of the Location tags is a commented-out section which is intended to track attacks on your Web server which exploit an old bug from pre-Apache 1.1 days. If you want to track these requests, uncomment the following lines:
If these lines are uncommented, your Web server will redirect any requests which end in /cgi-bin/phf* to a logging CGI script run by the Apache Group.
ProxyRequests If you uncomment the IfModule tags surrounding the ProxyRequests directives, your Apache server will also function as a proxy server. You will also need to load the mod_proxy module. For instructions on how to load in modules, see the Section called Adding Modules to Your Server.
ProxyVia The ProxyVia command controls whether or not an HTTP Via: header line is sent along with requests or replies which go through the Apache proxy server. The Via: header will show the hostname if ProxyVia is set to On, the hostname and Apache version for Full, any Via: lines will be passed along unchanged for Off, and Via: lines will be removed for Block.
Cache Directives A number of cache directives are commented out in the proxy IfModule tags mentioned above. If you are using the proxy server functionality and you want to also enable the proxy cache, you should uncomment the cache directives as described. The default settings for your cache directives should be appropriate for most configurations.
Cached HTML documents will be retained (without a reload from the originating Web server) in the cache for a maximum number of hours set by CacheMaxExpire. The default is 24 hours.
The CacheLastModifiedFactor affects the creation of an expiry (expiration) date for a document which did not come from its originating server with its own expiry set. The default CacheLastModifiedFactor is set to 0.1, meaning that the expiry date for such documents equals one-tenth of the amount of time since the document was last modified.
Any document that is retrieved from a host or domain that matches one set in NoCache will not be cached. If you know of hosts or domains from which you do not want to cache documents, uncomment NoCache and set their domains or hostnames here.
NameVirtualHost You will need to use the NameVirtualHost directive for the IP address and port number, if necessary, of any name-based virtual hosts you are setting up. The name-based virtual hosts configuration is used when you want to set up different virtual hosts for different domains, but you do not have or do not want to use different IP addresses for all of the different domain names for which your Web server serves documents.
Note You cannot use name-based virtual hosts with your secure server. Any name-based virtual hosts you set up will only work with non-secure HTTP connections and non-SSL connections.
Samsung pc studio for mac. You cannot use name-based virtual hosts with your secure server because the SSL handshake (when the browser accepts the secure Web server's authenticating certificate) occurs before the HTTP request which identifies the correct name-based virtual host. In other words, authentication occurs before there is any identification of different name-based virtual hosts. If you want to use virtual hosts with your secure server, you will need to use IP address-based virtual hosts.
If you are using name-based virtual hosts, uncomment the NameVirtualHost configuration directive and add the correct IP address for your server after NameVirtualHost. Then add more information about the different domains using the VirtualHost tags which surround the ServerName for each virtual host, plus any other configuration directives which are only applicable to that virtual host.
VirtualHost A set of commented out VirtualHost tags surround some example configuration directives and placeholders for the information you would need to fill in to set up a virtual host. Please see the Section called Using Virtual Hosts, for more information about virtual hosts.
SetEnvIfApache Httpd Config
The Apache configuration directive SetEnvIf can be used to set environment variables based on headers in the request. In the supplied httpd.conf file, it is used to disable HTTP keepalive and to allow SSL to close the connection without a close notify alert from the client browser. This setting is necessary for certain browsers that do not reliably shut down the SSL connection.
SSL Configuration Directives The SSL directives in your server's httpd.conf file are included to enable secure Web communications using SSL and TLS.
For more information on SSL directives, please point your browser to http://localhost/manual/mod/mod_ssl/. More information on SSL directives is also available at http://www.modssl.org/docs/2.8/ssl_reference.html, a chapter in a Web document about mod_ssl by Ralf Engelschall. The same document, the mod_ssl User Manual, begins at http://www.modssl.org/docs/2.8/ and is a great reference source for mod_ssl and for Web cryptography in general.
Note Do not modify your SSL directives unless you are absolutely sure about what you are doing. In most cases, the SSL directives are configured appropriately as installed.
In Apache (httpd) virtual hosts are used to host web content for multiple domains off of the same server depending on the IP address or domain name that is being used. Depending on the request received different virtual host configuration can apply, resulting in different settings and web content being served from a single web server. For example a web server with one IP address can host multiple domain names such as example.com and example.org and many more.
Here we are going to cover how to configure virtual hosts for Apache 2.4 so that we can have multiple domains serving different websites based on what is requested.
Studying for your RHCE certification? Checkout our RHCE video course over at Udemy which is 20% off when you use the code ROOTUSER.
Example Apache Virtual Host Configuration
Virtual host configuration is typically placed within the /etc/httpd/conf/httpd.conf file, and also in unique .conf files within the /etc/httpd/conf.d directory. It is good practice to create a new .conf file within /etc/httpd/conf.d if you are adding multiple websites to be hosted from the same web server, as this keeps the configuration clean and is easier to manage. In our example we will be working with /etc/httpd/conf.d/example1.conf which will be for the website www.example.com and /etc/httpd/conf.d/example2.conf which will be for the website www.example.org.
First we’ll start with some example virtual host configuration and then discuss what each line is actually doing. For additional examples, see the Apache documentation.
The below example virtual host configuration has been saved within the /etc/httpd/conf.d/example1.conf file.
The below example virtual host configuration has been saved within the /etc/httpd/conf.d/example2.conf file.
In the above examples we have two virtual host configuration blocks. The first is for www.example.com while the second is for www.example.org. Below we will explain each line for the example1/example.com virtual host as the configuration is mostly the same between the two.
- <Directory /var/www/html/example1> – This opens the directory tag and is used to enclose a group of directives that apply to the directory specified.
- Require all granted – This is required to grant access, without it the Apache logs will show “authz_core:error” as the default configuration within the /etc/http/conf/httpd.conf file defines the directory of “/” with “Require all denied”.
- </Directory> – This closes the directory tag.
- <VirtualHost *:80> – This virtual host tag indicates that the configuration after it will apply to any IP address as per “*” on port 80, “*” can instead be modified to a particular IP address that is available on the server. The port can also be changed if the Listen directive for that port is defined within the main httpd.conf file.
- DocumentRoot “/var/www/example1” – The document root is the directory where the content exists that Apache should serve when we visit the domain name, in this case going to www.example.com will direct us to files within the /var/www/example1 directory on the web server. The directory specified should exist and ideally contain content.
- ServerName www.example.com – This is the unique name that the virtual host is for, in this case the virtual host configuration block is for the www.example.com website.
- ServerAlias example.com – Alternate names can be used when matching a request and are specified with ServerAlias, these allow us to provide other name based aliases as only one ServerName is allowed per virtual host.
- ServerAdmin [email protected] – This is an email address that is provided in error messages, allowing users to contact the web master of the web server.
- ErrorLog “/var/log/httpd/error_log_example1” – This is the file where error logs are stored that are related to this virtualhost, which are useful when troubleshooting problems.
- CustomLog “/var/log/httpd/access_log_example1” combined – This is where access logs are stored, for instance when a client views a web page the access requests will be logged here.
- </VirtualHost> – This is the closing tag for the virtual host block, indicating the end of the configuration for the particular virtual host.
If any configuration within a virtual host is missing, the defaults specified in the main /etc/httpd/conf/httpd.conf file will be used instead.
The second virtual host block in the example2.conf file is mostly the same, except that it takes care of requests for www.example.org and example.org serving the content within /var/www/html/example2. Errors are logged to /var/log/httpd/error_log_example2 and access requests are logged to /var/log/httpd/access_log_example2.
The syntax of our two .conf files can be tested with the ‘apachectl configtest’ command as shown below. In this case the document root directories have not yet been created so we are given a warning and should create these.
The directories can be created with mkdir as shown below.
Now that our directories exist the warning should no longer come up. In this example I have created two index.html files with a text editor in both directories, the contents are shown below.
Auto Config
Before testing our virtual host configuration, any changes to Apache configuration files such as modification to virtual hosts will require the httpd service to either be restarted or reloaded to pick up the configuration changes. Apache can be reloaded to make use of configuration changes with ‘systemctl reload httpd’, for further information see our service management guide.
Testing the Virtual Hosts
Once virtual host configuration has been put in place and Apache reloaded, the relevant DNS records will need to be created so that the domains will resolve to the web server. Alternatively you can test by modifying your hosts file. In this example we can modify the /etc/hosts file and add the following entry.
This will make these domains resolve to localhost, now we can browse the content and confirm our virtual hosts are working correctly. In this instance we are going to use the curl command to view the contents of each website.
This confirms that the correct index.html pages within /var/www/html/example1 and /var/www/html/example2 are being retrieved successfully for each domain, as defined within the virtual host configuration.
Further Information
If you get stuck or have trouble remembering any of this, remember the httpd-manual package which can be installed and viewed at http://localhost/manual.
From the main page, simply select Virtual Hosts for help on this topic.
Summary
With a few lines of virtual host configuration we can enable Apache to serve multiple websites from the same web server, allowing us to host multiple websites within the same shared hosting environment.
This post is part of our Red Hat Certified Engineer (RHCE) exam study guide series. For more RHCE related posts and information check out our full RHCE study guide.