Difference Between IIS and Apache

Difference Between IIS and Apache| Difference Between Apache And IIS

Apache is a software foundation that develops and provides open source software that is meant to run web servers. Their primary product is their HTTP server which is the most popular HTTP server in use today. IIS or Internet Information Services is the software pack developed by Microsoft to provide their Windows operating system the ability to host internet services. IIS is second only to HTTP as the most used HTTP server in the world.

The Apache web server is very popular due to the fact that is free. This is very advantageous to those who are just trying out web publishing and is still unsure about it. Apache is most commonly included in a totally free web server solution called LAMP (Linux/Apache/MySQL/PHP) which is a collection of open source software that would totally handle all of your web publishing needs from the OS down to the scripting language. Aside from being free, the open source community is also a good source of support for users who have the time and patience to ask for answers.

IIS is from Microsoft and thus it would only run on the Microsoft Windows OS. Although it might seem to be free, the fact that you need to buy Windows to use it shatters that dream. The clear advantage with running IIS is the fact most people are already familiar with the Windows operating system and IIS would be a lot easier to learn for Windows users. IIS also comes with the support of the .NET Framework released by Microsoft; in fact, ASPX scripts are exclusive to IIS. Support for IIS is provided by Microsoft which is an assurance that you would have answers to your problems direct from the makers themselves.

The IIS ‘“ Windows combo is both a boon and bane for users. The fact that they are made by the same company assures you that they would operate at the best capacity with each other. The only problem with the Windows OS is its too popular and a lot of malware, virus, and trojans exist on the Windows OS. Even more are being created everyday and that might pose a threat in the future.

Summary:

1. Apache is free while IIS is packaged with Windows.

2. IIS only runs on Windows while Apache can run on almost any OS including UNIX, Apple’s OS X, and on most Linux Distributions.

3. ASPX runs only in IIS.

4. IIS has a dedicated staff to answer most problems while support for Apache comes from the community itself.

5. IIS is optimized for Windows because they are from the same company.

6. The Windows OS is prone to security risks.

Configuring Apache with JBoss

Configuring Apache with JBoss, Configuring Apache with JBoss

Steps for configuring Apache with Jboss:

  1. Apache Installation:
  • Windows:
  • Linux:
    • Download the Apache webserver source from the websitehttp://httpd.apache.org/download.cgi.
    • Once, the source had been downloaded, it needs to be extracted to some folder say“/usr/local/Apache” using the command gunzip <source zip>. This command will output a .tar file in the same folder.
    • Untar the .tar file using the command tar –xvf <source tar>.
    • This creates a new directory under the current directory with the source files.
    • Now, we need to configure the source files. To achieve this, we will execute a command called ./configure.
    • The next step is to build the source files. To build the source, execute the following commands sequentially.

make
make install

            Once these two commands gets executed successfully, a directory will be created under“/usr/local/apache2” and the Webserver config files and would have been copied to this directory.


  1. Apache webserver and JBoss Application server needs an interface to interact between themselves. The interface has been developed by Apache and is ready for download from their website http://tomcat.apache.org/connectors-doc/.
  2. mod_jk Connector Installation:
  • Windows:
  • Linux:
    • workers.tomcat_home            =D:\Jboss
    • workers.java_home=C:\Program Files\Java\JDK1.5
    • ps=\ for windows and ps=/ for linux
    • worker.list=<myproject>
    • worker.<myproject>.type=ajp13
    • worker.<myproject>.host=localhost
    • worker.<myproject>.port=8009
     Click on the link to download the latest connector for Windows platform  mod_jk-1.2.28-httpd-2.2.3.so. 

This download will be applicable only for Win32 platforms.


     Click on the link to download the latest connector for Linux platform mod_jk-1.2.28-httpd-2.2.X.so . 

This download will be applicable only for i586 processors.



  1. Rename the downloaded connector file to mod_jk.so.


  2. Copy the mod_jk.so file to C:\Program Files\Apache\modules folder in windows and/usr/local/apache2/modules in linux.


  3. Create a file called worker.properties in the C:\Program Files\Apache\conf folder in windows and /usr/local/apache2/conf in linux.


  4. Update the worker.properties file with the following lines



            Where



D:\Jboss = path where JBoss server is installed.



                  C:\Program Files\Java\JDK1.5 = path where JDK is installed.



                  <myproject> = any user defined name.




  1. Append the below given lines at the end of an apache configuration file named httpd.confwhich will be available under the folder C:\Program Files\Apache\conf for windows and/usr/local/apache2/conf for linux.




  • LoadModule jk_module modules/mod_jk.so


  • JkWorkersFile conf/worker.properties


  • JkLogFile logs/mod_jk.log


  • JkLogLevel error


  • JkRequestLogFormat “%w %V %T”


  • JkMount /* <myproject> (Make sure that the value which you assigned for worker.list in theworker.properties is specified here).




  1. Look out for the below given code in httpd.conf



<Directory />



            Options FollowSymLinks



            AllowOverride None



            Order deny, allow



            Deny from all                        



</Directory>



And change the last line Deny from all as Allow from all. After update, it should look like the one given below.



<Directory />



            Options FollowSymLinks



            AllowOverride None



            Order deny, allow



            Allow from all                       



</Directory>




  1. The configuration change mentioned in Step 11 is a must, because, if not updated, all the requests to access the resources of the JBoss server via the Apache server would return a Forbidden error (403).




  1. After making the configuration changes to the httpd.conf file, we can check whether the entries which were added in Step 8 and Step 9 are correct. To do so, please follow the steps given below.




  • Windows:



   Open up a command prompt and go to folder “C:\Program Files\Apache\bin” and execute the following command  



httpd.exe –t




  • Linux:



Open up a terminal and change to the folder “/usr/local/apache2/bin” and execute the following command



./httpd -t



If it gives a message Syntax OK, then the content what we updated is correct. If not, review steps 8 and 9.




  1. Now, start the JBoss server and access the URL http://localhost:8080. This would display the JBoss Console.


  2. Start the Apache server and access the URL http://localhost. This would again, display the JBoss Console. If not, then please redo the previous steps.


  3. Now try accessing any of the deployed applications in JBoss via Apache using the URLhttp://localhost/${application}



Where



${application} = any deployed application in Jboss.



If the previous 2 steps are successful, then this step would render the page which you requested. If it fails, redo the previous steps.

Comparision between Apache and IIS

Comparision between Apache and IIS| Comparision between IIS and Apache

Basics:

  • IIS has been an optional component of the Windows Server operating systems since Windows NT 4.0. Back then; this was a basic Web server in the form of IIS 3.0. An Option Pack, released shortly after Windows NT 4.0 was released, included IIS 4.0 and was the first “real” version of IIS to be used heavily as a Web server platform.
  • IIS 5.0 was included in Windows 2000 in both the server and desktop versions, and the updated version, IIS 5.1, is incorporated into Windows XP. The changes between IIS 4 and IIS 5 are fairly minor.
  • Windows Server 2003 includes the new IIS 6.0, which is an almost complete rewrite from the previous editions. It sports a new execution model, better management facilities, and significantly increased performance.
  • Apache, on the other hand, has an older heritage; having been originally based on the httpd code that some would argue started the entire Web revolution in the first place. Apache 1.3.x, which was the production version until 2002, was a largely UNIX product that used a number of tricks to enable it to execute within other operating systems, including Windows.
  • The production release of Apache 2.0 hit the shelves in 2002. The new release incorporated a brand-new execution environment that separated the core functionality of the Apache system from the system that actually supported and processed requests. Apache 2.0 is now supported under a wide array of potential operating systems, including all versions of Windows, Linux, Unix, and Mac OS X, in addition to an array of non mainstream OS’s, like BeOS and VMS.

Execution Environment:

  • IIS and Apache operate very differently and thus have a variety of advantages of disadvantages. IIS is obviously designed and available to work only within the Windows environment. With IIS 6.0, the only platform currently supported is Windows Server 2003. Although this limits the deployment platforms for IIS-based Web services, it also provides a number of benefits, including greater cooperation with the host operating system and easier management and control through a variety of standard OS tools and utilities.
  • In IIS 6.0, the cooperation between the operating system and the server is greater than ever. In a change to previous versions, the component that accepts requests from clients and processes them is now two separate components. The kernel mode listener, HTTP.sys, listens and accepts requests from clients, placing the requests into one or more request queues. IIS then processes the requests in these queues using at least one worker process to control the execution of the individual requests and applications.
  • This separate process allows requests to be accepted even when IIS worker processes aren’t technically running, and also enables finer control on the worker processes that handle requests. Thus, the admin (or the server, automatically) can recycle requests to recover from extension and application failures that would have previously required a shutdown/restart of the IIS service or, in extreme cases, a reboot of the entire server.
  • Apache 2.0 was a major rewrite from the previous versions. Among the many changes, the Web server is now directly available on a variety of platforms, including Windows. The redesign enables it to support a wide array of platforms in more efficient ways that lead to UNIX and Windows-specific execution models that make the best use of the OS.
  • The core of the system is the Apache Portable Runtime (APR), which enables the Apache core to run on more or less any system with a C compiler. A number of multi-processing modules (MPMs) then provide the support for actually accepting and processing requests. Under UNIX, this can be the traditional “forked” model or a newer threaded model making use of the threading built into most modern kernels. Under Windows, this also uses a threaded model, which in some respects is similar to the threaded model used by the worker processes within IIS 6.0.

Feature
IIS
Apache

Independent Request Handler
Yes
Yes (limited)

Multiple Process Request Handlers
Yes
Yes

Thread Support
Yes
Yes (on a suitable OS)

Dynamic Components:

  • The primary dynamic environment for development within IIS is Active Server Pages. This is a generic term for a solution that allows code to be embedded into HTML pages. These ASP pages are parsed by the server before being supplied to the client as HTML. The ASP system allows developers to work in a number of different languages, including Visual Basic, VBScript, JavaScript, Java, and C/C++, along with other open source alternatives, such as Perl and Python. In addition, IIS continues to support traditional CGI methods along with its own suite of filtering and execution systems in the form of ISAPI filters.
  • Apache is also designed to work with a wide range of languages, either via the CGI model, or through the use of dynamic modules by directly incorporating the language interpreter into the Apache environment. This significantly speeds up the execution of dynamic components for languages like PHP, Perl, and Python.
  • Both systems support the Java Server Pages model, and it’s possible to migrate most JSP applications between the two platforms with few changes. Other languages can achieve this with varying results. Even ASP can be supported under UNIX through the ChilliSoft ASP component (www.chillisoft.com), through the Apache: ASP module, or the Apache modmono module (http://apacheworld.org/modmono/).
  • One element that currently cannot be emulated under UNIX is the Microsoft.NET environment. IIS 6.0 and Windows Server 2003 make heavy use and provide excellent levels of integration with the .NET Framework.

Feature       IIS              Apache

ASP                  Yes                  With Chilisoft, Apache: ASP, or modmono

CGI                   Yes                  Yes

Perl                  Yes                  Yes

Python            Yes                 Yes

PHP                 Yes                 Yes

JSP                   Yes                  Yes

.NET Integrated          Yes        No

 

Security and Authentication:

  • IIS benefits from close integration with the operating system. The same user and group configuration system that powers the main authorization system within Windows also provides security and authentication services for the main IIS system. It reduces the management overhead by supporting only one system, and enables the sys admin to automatically log in users through an intranet, assuming they are already authenticated within the Windows environment.
  • Because the same system is used throughout the OS, it can also be used to define security and access to different components of the file system on which the Web site relies. For example, when a user logs on to the Web site, his ability to browse the directories within the site is defined by one set of user and group structures.
  • Apache’s security and administration system is not this well-integrated with the OS’s it supports. Although there are modules and adaptors that support a variety of different authentication and security sources, including Active Directory, the UNIX passwd file, and LDAP servers, the resulting server is relatively isolated from the system it supports. For example, when a user authenticates against the UNIX passwd file, Apache still ignores the file permissions on the underlying file system.
  • In terms of secure transactions, both systems support encryption technology in SSL, and can be used with IPSec implementations and IPv6.

Feature                     IIS                        Apache

Secure Login                   Yes                                  Yes

SSL                                      Yes                                  Yes

Basic Authentication  Yes                                  Yes

Digest Authentication Yes                                 Yes

LDAP Authentication  Yes                                 Yes

Active Directory Authentication   Yes         Only with third-party modules

Passport Authentication       Yes                       No

Performance:

  • Gauging performance is always difficult because no matter how identical the systems to be tested are, minute changes in their configurations can have a dramatic effect on performance. It is possible to pick a “winner” based on bare-bones installations of both systems on the same hardware, but this doesn’t really reflect the true performance capabilities of a system in the field. It’s equally possible to configure one Apache and one IIS system to be either over- and under-efficient, again skewing the potential results.
  • Instead it’s better to look at the potential capabilities of each system. IIS incorporates a wide range of features designed to improve performance. The worker process execution model provides significant performance benefits on multiprocessor machines, and the ASP and ISAPI extensions enable applications to be executed directly from within the processes handling the requests. The kernel mode driver, HTTP.sys, is also capable of serving pages directly from the cache (memory or disk) for both static and dynamic components, eliminating the need to send the request to a worker process. IIS automatically caches pages generated from dynamic elements to speed up responses.
  • Under Apache, the same ranges of facilities are present. Much information can be cached, and tools like mod_perl and mod_php enable the execution of dynamic and template pages almost as quickly as static pages. Like ASP and ISAPI filters under IIS, the modules effectively place the interpreter directly within the Apache executable, eliminating the need to run an external application and greatly improving performance.

    Feature                           IIS                              Apache

In-Memory Cache                           Yes                                            Yes

On Disk Cache                                  Yes                                            Yes, with mod_file_cache

Built-In Execution support          Yes, with a suitable ISAPI filter   Yes, with suitable modules

Cached Execution support          Yes, with ASP/ASP.NET      Yes, with mod_perl and others

Management:

  • The two systems differ radically when it comes to management. The only method of administering Apache is through a simple text-based configuration file. Although a variety of command line, Web, and GUI interface tools are available, they all rely on the central text file to actually the update the configuration. Comanche, for example, provides a full interface to the Apache system. A list of alternative GUIs, both stand-alone and Web-based, is online at gui.apache.org.
  • Using a text file this way has its advantages; it’s easy to share configuration information between machines by copying the relevant content from the text file. The primary disadvantage is that it’s relatively easy to corrupt the file and therefore upset the configuration. Without a “soft” restart, Apache cannot update its configuration, so before restarting Apache the admin must ensure the configuration file is working. This can be achieved using a built-in testing mechanism.
  • IIS, on the other hand, offers a number of different interfaces to modify the configuration of the system. Although the underlying configuration is primarily stored in an XML-based text file, the IIS system enables the admin to change the configuration and the underlying file while the system is still running. Because the file is XML, it has a more rigid structure, yet is still flexible enough to support the different configuration options. For remote support, Windows Server 2003 also incorporates a telnet server, which keeps the XML Metabase modifiable and allows the use of various command-line tools for remote server management.
  • The various editing interfaces include a GUI-based interface through the Microsoft Management Console, a Web-based administration system, and a suite of command line tools for adding, updating, and configuring different components. Admins can also edit the XML file live and have saved changes automatically reflected within the IIS system. The XML format also makes it easy to export and import configuration information between machines to share configuration details.
  • System for system, there is not a huge amount to compare. The MMC within IIS provides a consistent and distributed interface for updating the configuration across a wide range of machines. However, Web-based administration tools, like Webmin, or dedicated GUI tools, like Comanche, can provide the same functionality.

Feature                             IIS                               Apache

Text File Configuration        Yes, through XML Metabase            Yes

Command Line Management   Yes                                   Limited

Remote CLI                                Yes                                               Yes

Web-Based Management     Yes                                         Yes, through Webmin and others

GUI-Based Management       Yes                                         Yes, through Comanche and others

Reliability:

  • This last comparison is probably the most contentious when comparing IIS and Apache. There’s very little differentiation between the most recent versions both applications.
  • IIS 6.0 now provides extensive management and control systems over the worker processes that control most requests. To improve the reliability, IIS can also compartmentalize applications, giving them their own memory and execution space, or using a space shared with other applications. This means that when an application causes a problem, it dies within the worker process and doesn’t affect any of the other applications or the request processing core in the process.
  • Apache automatically handles much of the process and thread management aspects, but memory and application isolation is still an issue that has not been effectively resolved or covered. Apache avoids some of the problems by automatically recycling components, with the core continuing to run even in the event of a serious failure in one of the components. There are still situations, however, where Apache may need to be restarted.
  • One example of this is the configuration of the Apache system itself. For a Web site running from an IIS-based server, most updates and improvements will have no effect on users’ ability to access them because the configuration changes are made while the system is still running. Apache, however, requires a notional restart.
  • That said, the use of .htaccess within Apache means many items that normally need modification through the course of a Web site’s life can be handled dynamically.

Feature                                                   IIS                              Apache

Process/Thread Management                          Yes                                        Yes

Isolated Applications                                           Yes                                         Limited

Live Configuration Editing                                 Yes                                        No

Finally:

  • Despite the array of differences between the two systems, choosing between them comes down to the needs and requirements of the organization and, to a lesser extent, the personal needs and preferences of those using it. For example, many developers prefer to work in Perl in a Unix-based Apache environment, even though Perl and Apache are available under Windows, and Perl is supported separately under IIS.
  • If server management is a prime concern, then the extensive management capabilities of IIS may be the way to go. The security aspect and integration with Active Directory, and therefore the rest of the security mechanisms, is also a major benefit.
  • However, it’s important not to ignore the cost of deployment issue. Apache is free, and can be installed on OS’s like Linux that are also free. IIS is available only as part of Windows Server 2003. Although a new Windows Server 2003, Web Edition is available at a significant discount compared to its Standard Edition cousin, it is still, at least on the surface, more expensive than Apache.

Apache webserver integration with tomcat

Apache webserver integration with tomcat

How to integrate tomcat in apache webserver and load balance the requests to two tomcat instances.
_____________________________________________________________________
Configure the JK Module in httpd.conf
Download the mod_jk.so for apache website suitable for your apache installed and tomcat as well.

Edit the Apache server’s configuration file httpd.conf which is located in the /usr/apache2 /conf directory.

# Load mod_jk

#

LoadModule jk_module modules/mod_jk.so

#

# Configure mod_jk

#

JkWorkersFile conf/workers.properties

JkLogFile logs/mod_jk.log

JkLogLevel info

NOTE : You will need to change mod_jk.so to mod_jk.dll for Windows.

Below the “DocumentRoot” line, insert the following two lines:

JkMount /*.jsp loadbalancer

JkMount /servlet/* loadbalancer

Create the workers.properties file

Now we will create a file called workers.properties, and we will place it under /usr/apache2/conf. The workers.properties file tells Apache about the various Tomcat servers that are running, and on which port they are listening.

In my setup, I installed the two Tomcat servers in different directories, on the same machine as Apache. Feel free to put your Tomcat servers on different machines.

I made the first Tomcat server’s AJP13 connector listen on port 8801 instead of the default port which is 8009, and the second one listens on port 8802.

I have decided to name my tomcat servers tomcat1 and tomcat2.

Create the file exactly like this:

#

# workers.properties

#

# list the workers by name

worker.list=tomcat1, tomcat2, loadbalancer

# ————————

# First tomcat server

# ————————

worker.tomcat1.port=8801

worker.tomcat1.host=localhost

worker.tomcat1.type=ajp13

# Specify the size of the open connection cache.

#worker.tomcat1.cachesize

#

# Specifies the load balance factor when used with

# a load balancing worker.

# Note:

#  —-> lbfactor must be > 0

#  —-> Low lbfactor means less work done by the worker.

worker.tomcat1.lbfactor=100

# ————————

# Second tomcat server

# ————————

worker.tomcat2.port=8802

worker.tomcat2.host=localhost

worker.tomcat2.type=ajp13

# Specify the size of the open connection cache.

#worker.tomcat2.cachesize

#

# Specifies the load balance factor when used with

# a load balancing worker.

# Note:

#  —-> lbfactor must be > 0

#  —-> Low lbfactor means less work done by the worker.

worker.tomcat2.lbfactor=100

# ————————

# Load Balancer worker

# ————————

#

# The loadbalancer (type lb) worker performs weighted round-robin

# load balancing with sticky sessions.

# Note:

#  —-> If a worker dies, the load balancer will check its state

#        once in a while. Until then all work is redirected to peer

#        worker.

worker.loadbalancer.type=lb

worker.loadbalancer.balanced_workers=tomcat1, tomcat2

#

# END workers.properties

#

That’s it, we’re done with Apache.

Install and Configure the Tomcat Servers

Now let’s suppose that Java 1.4.x is installed under /usr/local/jdk1.4.x/. Create two Tomcat 4.x servers and install them under /usr/local/:

   tar fvxz jakarta-tomcat-4.x.tar.gz

   mv jakarta-tomcat-4.x /usr/local/tomcat1

   cp -R /usr/local/tomcat1 /usr/local/tomcat2

In both /usr/local/tomcat1 and /usr/local/tomcat2, the same files will be modified. I here by present the modifications made to the files contained in the /usr/local/tomcat1 directory tree structure. You should also apply the same changes to the corresponding files located under the /usr/local/tomcat2 directory tree structure.

Modify catalina.sh

We can set the JAVA_HOME and CATALINA_HOME envoirment variables directly in the catalina.sh file.

At line 32, before the “# —– Verify and Set Required Environment Variables ” line, insert the following two lines:

    JAVA_HOME=/usr/local/jdk1.4 ; export JAVA_HOME

    CATALINA_HOME=/usr/local/tomcat1 ; export CATALINA_HOME

(Set CATALINA_HOME  to /usr/local/tomcat2 in  /usr/local/tomcat2/conf/catalina.sh)

Modify conf/server.xml

Add a unique jvmRoute to the Catalina engine

Near line 100, replace:

    <Engine defaultHost=”localhost” debug=”0″>

with:

    <EnginejvmRoute=”tomcat1″name=”Standalone” defaultHost=”localhost” debug=”0″>

For tomcat2, put jvmRoute=”tomcat2″.

Change the control port

At line 13, replace:

    <Server port=”8005″

with:

    <Server port=”8811″

For the tomcat2 server, replace port 8005 with 8812. This will prevent the two servers from conflicting.

Change the AJP13 port

At line 75, in the AJP 13 connector definition, replace:

port=”8009″

with:

    port=”8801″

For the tomcat2 server, replace port 8009 with 8802.

Disable the standalone HTTP port

We don’t want or need our tomcat servers to directly respond to HTTP requests. So we comment out the Http Connector section between lines and 58 in the server.xml file.

Example:

<!– Define a non-SSL HTTP/1.1 Connector on port 8080 –>

<!–

    <Connector className=”org.apache.catalina.connector.http.HttpConnector”

               port=”8080″ minProcessors=”5″ maxProcessors=”75″

               enableLookups=”true” redirectPort=”8443″

               acceptCount=”10″ debug=”0″ connectionTimeout=”60000″/>

–>  

NOTE: If you don’t comment this out, you will need to change the port numbers so they don’t conflict between tomcat instances.

Disable the WARP connector

At line 314, comment out the <Connector…WarpConnector…> tag.

Example:

<Service>

<!–

    <Connector className=”org.apache.catalina.connector.warp.WarpConnector”

     port=”8008″ minProcessors=”5″ maxProcessors=”75″

     enableLookups=”true” appBase=”webapps”

     acceptCount=”10″ debug=”0″/>

–>

Do not forget to do the same thing to tomcat2′s server.xml file.

NOTE: You might want to comment out the entire <Service> element. If so, make sure and remove the comments within it – XML doesn’t like comments within comments.

Create test JSP pages ( index.jsp )

Create a file named index.jsp and put it in the /usr/local/tomcat1/webapps/ROOT directory:

<html>

<body bgcolor=”green”>

<center>

<%= request.getSession().getId() %>

<h1>Tomcat 1</h1>

</body>

</html>

Create a file named index.jsp and put it in the /usr/local/tomcat2/webapps/ROOT directory:

<html>

<body bgcolor=”yellow”>

<center>

<%= request.getSession().getId() %>

<h1>Tomcat 2</h1>

</body>

</html>

Start Tomcat1, Tomcat2 and Apache

    /usr/local/tomcat1/bin/startup.sh

    /usr/local/tomcat2/bin/startup.sh

    /usr/local/apache2/bin/apachectl start

Test your Installation

Now is the time to test your setup. First, verify that Apache serves static content.

Click on: http://localhost/ . You should see the default Apache index.html page.

Now test that tomcat (either Tomcat 1 or Tomcat 2) is serving Java Server Pages.

Click on: http://localhost/index.jsp

If you get a green page, the page was served by the tomcat1 server, and if you get a yellow page, it was served by the tomcat2 server.

Now test that session affinity – also known as sticky sessions – works within the load balancer. Hit the reload button of your web browser several times and verify that the index.jsp page you get is always received from the same tomcat server.

Configuring Private JVMs

If you don’t need load-balancing, but you are interested in configuring Apache/Tomcat for private Tomcat instances, you can add one of the following near the end of httpd.conf:

Name-based (1 IP address or NIC).

NameVirtualHost *

<VirtualHost *>

ServerName localhost1

JkMount /*.jsp tomcat1

JkMount /servlet/* tomcat1

</VirtualHost>

<VirtualHost *>

ServerName localhost2

JkMount /*.jsp tomcat2

JkMount /servlet/* tomcat2

</VirtualHost>

IP-based (different IP for each site).

# First  Virtual Host.

#

<VirtualHost 172.16.19.56:80>

ServerName localhost

JkMount /*.jsp tomcat1

JkMount /servlet/* tomcat1

</VirtualHost>

# Second  Virtual Host.

#

<VirtualHost 172.16.19.58:80>

ServerName localhost2

JkMount /*.jsp tomcat2

JkMount /servlet/* tomcat2

</VirtualHost>

Where the  serverNames are fully-qualified host names in a DNS Server. More information can be found at http://httpd.apache.org/docs-2.0/vhosts/ .

NOTE:

When using SSL with multiple Virtual Hosts, you must use an ip-based configuration. This is because SSL requires you to configure a specific port (443), whereas name-based specifies all ports (*). You might the following error if you try to mix name-based virtual hosts with SSL.

[error] VirtualHost _default_:443 — mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined result.

Apache Virtual Hosting| Virtual Hosting Of Apache

Apache Virtual Hosting| Virtual Hosting Of Apache

Virtual Hosts refers to Apache’s ability to host several websites on the same machine and even on the same IP address. For instance, let’s say that you have a small website, www.yourdomain.com, which also provides free email accounts to your visitors. Of course, you will also have to set up a webmail so your visitors can actually use the email address created on your site. You could very easily set up the webmail to be accessible from the address www.yourdomain.com/webmail, but for both aesthetic and practical reasons, the webmail service could be found at webmail.yourdomain.com. Moreover, you can set up as many virtual hosts as you want, on a single IP address.

- The virtual hosts can be defined and configured in Apache’s config file. This config file can be found in Fedora Core by default in /etc/httpd/conf/httpd.conf but the location of this file may vary on other distributions.

- Once found, open it with your favorite text editor and search for the NameVirtualHost.
Make sure it looks like this (and it’s not commented out):

1px solid #CCC; padding: 0px; “>

CODE

NameVirtualHost *:80

NOTE: The following example will require you to have the main website located in /var/www/htmland the new webmail will be installed in /var/www/webmail. If your locations vary, change the example accordingly, before adding them to httpd.conf.

- To get it up and running quickly, add these lines at the end of httpd.conf:

CODE

<VirtualHost *:80>
ServerName www.yourdomain.com
DocumentRoot /var/www/html/
</VirtualHost>

<VirtualHost *:80>
ServerName webmail.yourdomain.com
DocumentRoot /var/www/webmail
</VirtualHost>

- If you want more advanced virtual host configuration, you can use any of the following directives:

Logging

– By default, Apache will record messages to access_log and error_log files located in /var/log/httpd. However, if you want each virtual host to have its own separate logs, add these directives to the virtual host block:

CODE

ErrorLog /var/log/httpd/website1-error_log common
CustomLog /var/log/httpd/website2-access_log common

For example, if you want your webmail site to record messages to files webmail-access_log and webmail-error_log, then your vhost block for webmail site will look like this:

CODE

<VirtualHost *:80>
ServerName webmail.yourdomain.com
DocumentRoot /var/www/webmail
ErrorLog /var/log/httpd/webmail-error_log common
CustomLog /var/log/httpd/webmail-access_log common
</VirtualHost>

Error Pages

– You can set Apache to serve a custom page when a visitor gets a 404 (not found) or 500 (internal server error) or any other error code, for that matter. For instance, you can redirect a visitor which received a 404 error to the main index file, or to a 404 file you created. For this, you’ll have to add the following directives to the virtual host block, just like in the above example:

CODE

ErrorDocument 404 /index.htm
ErrorDocument 500 /index.htm

NOTE: The error page could be anything; but remember: the location starts with the directory set in DocumentRoot in httpd.conf. For instance, if your DocumentRoot is /var/www/html and the error page is in /var/www/html/messages/404.htm, then you’ll have to append /messages/404.htm to the ErrorDocument directive.

Server Aliases

- If you want to use your virtual host for more than one domain name, you can put ServerAlias directive inside the virtual host block in order to link the two domains together:

CODE

ServerAlias youdomain.com yourseconddomain.com

For Examples:

http://httpd.apache.org/docs/2.2/vhosts/examples.html