Fedora Core 2, Apache and FPSE Name Based Virtual Servers

Contents

Introduction

Overview

Obtaining httpd-devel

File Editing and Permissions

Editing httpd.conf AllowOverride Settings

Changing the permissions of /var/log/httpd

Editing the HTTP_UNAUTHORIZED.html.var file

Username Information

Obtaining the FPSE Software

Testing the Apache Web Server

Enabling the httpd service to start when the Computer starts

DNS

The Test network

Name based Virtual Hosts

Configuring httpd.conf for Name Based Virtual Hosts

Adding Virtual Hosts to httpd.conf

Adding the Server to DNS

Browsing the Individual Sites

Installing FPSE for the Virtual Servers

Setting the Admin Port for FPSE

Further Editing of httpd.conf

Logging onto the Admin pages

Summary

Introduction

As the earlier tutorials on this subject have attracted a lot of interest from all over the planet, I finally got around to creating a time window to research and write another tutorial on the FrontPage Server Extensions. Actually doing the testing and configuration and making notes is what takes the time.

I suggest that you also read the FPSE Apache Tutorial along with this one as I refer to it on occasion. I will add hyperlinks as appropriate to any references as needed. You can then use your browsers back button to return to this page. As always you can send feedback to loopback0@hotmail.com

Overview

I have built a test server to test name based virtual servers with FrontPage Server Extensions. As part of this I have used my own earlier tutorial to check compatibility with Fedora Core 2. If you do not need to use virtual servers use this tutorial in conjunction with FPSE Apache Tutorial and you will be able to get FC2 working with FPSE.

This one covers configuring the FrontPage Server Extensions for Name Based Virtual Servers, but the same procedure should work also for IP based Virtual Servers without too much trouble. It also has been tested with a later version of the FPSE from Ready to Run Software FPSE_SR1.2. The earlier tutorial was performed with Red Hat 9 and FPSE_SR1.1.

Good News, also this tutorial was prepared on a fresh stock Server install of Fedora Core 2. So one or two things that I have read on the web that the extensions do not work on FC2 are quite simply incorrect. I also see no reason why this procedure should not also work with later Red Hat Variants.

Also I will need to set up an Internal DNS server on my internal LAN for test purposes. The test LAN will be described below.

Obtaining httpd-devel

First step is to check for and obtain httpd-devel (See here for description)

As it is not installed I used apt to obtain httpd-devel. Note some extra packages are being installed compared to my RH9 tutorial. These are needed in order to satisfy dependencies. That is why apt is such a cool tool. See the apt tutorial.

So far so good. Onward...

File Editing and Permissions

Lets check httpd.conf is in the same location as Red Hat 9, and if so make a copy called httpd.conf.original before we edit it. Always a good idea to make a back up of original files before editing.
 

Up to here everything is going well...

Editing  httpd.conf AllowOverride Settings

AllowOverride settings are changed as before from None to All. See here for reference.

Use the replace function of gedit or your text editor. Six Occurrences as before.

Changing the permissions of /var/log/httpd

It is necessary to change the permissions of /var/log/httpd. This is quite straightforward.
 

Editing the HTTP_UNAUTHORIZED.html.var file

Used search and replace in gedit (Text editor) 9 occurrences for different languages were found. Change the content type as shown.

• Search for Content-type: application/text and

• Replace with Content-type: application/x-httpd-cgi

The parts you are looking for are as follows, the Content-type is probably application/text, it must be changed as follows for each language that the server will support. If in doubt change them all. Use the search and replace function of gedit.

Username Information

This information is quite important to understand which is why I provide you with this link to read this section on my Red Hat 9 FPSE tutorial and then click your browsers back button to return to here.

It covers the difference between FrontPage accounts and Unix accounts. So unless you already know this it is worth spending five minutes to read it. The information is exactly the same for RH9 and FC2 in this regard.

Obtaining the FPSE Software

Next I went to RTR software.

The original RH9 Tutorial used FPSE_SR1.1. A later version of the server extensions, FPSE_SR1.2, was available and is used in this tutorial.

http://www.rtr.com/fpsupport/FPSE_SR1.2.htm

Download the following items:-

The install script can be found at this link.

ftp://ftp.rtr.com/pub/fp_install.sh.gz

There is a License Agreement that you will have to agree to at the below link but then you can download the extensions.

http://www.rtr.com/fpsupport/fp2002sr1_download.htm

Download fp50.linux.tar.gz which is for Linux 8.0, 9.0 (Red Hat Software) but is the closest to Fedora.

Once downloaded I checked the md5sum against that provided on the download page of RTR Software.

The file was good so no need to download it again...
For reference this was my software download location.

Testing  the Apache Web Server

Now normally I would run the install script, but at this point I need to stop and check the server is working in terms of Apache. I am also going to create name based virtual servers to demonstrate the FPSE working with those as well.

Also I need to create a DNS server on my LAN, configuring DNS is outside the scope of this tutorial. Perhaps I may write a DNS Tutorial in the future. So watch this space.

Start the Web Server

After opening up a page to my server located on the test LAN at httpd://192.168.1.95 I did not see the normal default Apache page.

Checked in the DocumentRoot /var/www/html and there were no existing test pages, this is normal and we should in any case see an Apache test page when browsing a site with unpublished content.

I checked IP connectivity to the Web Server with ping  that proves the IP layer is working and this was OK so I suspected a firewall issue preventing the web page being viewed on TCP port 80. TCP runs over the IP layer.

This was solved by going to Main Menu>System Settings>Security Level on the desktop (Main Menu is the Fedora Hat in the bottom left hand corner of the desktop). Click the checkbox for www/http, click ok, click yes to confirm. The Firewall if enabled is locked down quite tight in Fedora Core 2, which is as it should be for a server, and you need to open it up for the services that you intend to use.

I refreshed my browser and at once I was in business.

I put a quick html test page together and saved it as index.html in /var/www/html and I was then able to view my published content...so this proves the web server is working. By the way index.htm will not work as httpd.conf is not configured in FC2 to recognize that file extension for the default page. It can be tuned to do so, but if you stick with the .html extension you will have no problems.
 

Enabling the httpd service to start when the Computer starts

You can either start the Apache httpd daemon manually with the command apachectl start or go to Main Menu>system settings>server settings>services and click the checkbox for httpd in the Service Configuration Window. Click Save and next time you boot up the server httpd will start up as a service. Note you can also start, stop and restart services from the same location. You probably also saw under server settings a httpd tool. This is a gui tool for configuring httpd.conf, do not use it as it changes your httpd.conf file quite a lot and not always how we would want.

DNS

At this point we can assume the DNS server is built. This is needed for testing if Name based servers running on the same IP address are working correctly. To test name based virtual servers we must be able to browse to them by name and not IP address, it is vital therefore for this to be tested effectively that we can resolve names to IP addresses using DNS. I will do this in a private test environment so as not to create any problems out on the Internet. For a live setup you need DNS set up in the correct manner either on your own or your hosting providers DNS server set up. If you need a quick refresher on DNS read on otherwise skip ahead.

DNS (Domain Name System) This is the service that is responsible for converting names like www.loony.toon to a public IP address. IP addresses look like 192.168.1.1 except this example address is not allowed to be used on the public Internet per RFC1918*. Unique Public IP numerical addresses identify individual computers and are also used by Routers to get things like web pages, e mails and other groovy stuff back and forth across the world. But people remember names more easily so when you type in your browser www.loony.toon your computer asks a DNS server, "For me to reach www.loony.toon what numerical IP address do I need to address my request for web pages to". The DNS server will then send back the IP address of www.loony.toon to your computer. So DNS Servers have a record of which IP address maps to which name. This is just an overview as DNS is a large subject.

*RFC1918. RFC (Request For Comments) are Internet Standards. RFC 1918 basically reserves some addresses for use in private networks. 10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255 and 192.168.0.0 - 192.168.255.255 are the ranges you can use in a private network at your discretion but not on the public Internet where each address is assigned and must be unique.  Some people call these private addresses non routable, this is not strictly true as routers can indeed route these addresses. The point is that they are not allowed to be routed on the public Internet because I could be using the same range on my private LAN as you are on yours. Imagine the confusion that would arise if an Internet Router thought network 10.0.0.0 was in New York, Amsterdam and Sydney at the same time. With private addresses though, network 10.0.0.0 can be in lots of different places, but they can not talk to each other across the Internet. All ISPs should block these private addresses from leaking onto the Internet. Most companies routers or firewalls can convert the private addresses to a public address using NAT (Network Address Translation). All public addresses are unique and can of course be routed on the public Internet. These practices also conserve IP addresses whose number is finite. It also helps to hide Internal Networks from the Public Internet.
 

The Test network

The test network consists of a Fedora Core 2 Web Server running Apache as discussed above. A separate DNS server is setup pointing three fictitious domains web servers to the Fedora Web Server.

A client Windows 2000 Professional machine is being used to test browsing the pages.

IP scheme

• Network 192.168.1.0 Mask 255.255.255.0

• Windows 2000 Host 192.168.1.105 via DHCP Server resolving DNS via DNS Server

• Fedora Core 2 Web Server Static IP address 192.168.1.95

• DNS Server Static IP address 192.168.1.92

• DHCP Server 192.168.1.1 (DHCP, Dynamic Host Configuration Protocol enables PCs to learn an IP address from a server. DNS is separate to DHCP however DHCP can also tell the PC which IP address to use to find the DNS server.

The DNS server has been configured to support three non existent fictitious domains (at least in the real world. There is a real bugsbunny.com for example but .toon is not a real Top Level Domain like .com)

• bugsbunny.toon

• goofy.toon

• batman.toon

The hosts www.bugsbunny.toon, www.goofy.toon and www.batman.toon have all been configured in DNS to point to our Fedora Web Server at 192.168.1.95. So we have three web sites now on the same server using the same IP address.

After this was set up from the Windows client I used Internet Explorer to browse to the following sites www.bugsbunny.toon, www.goofy.toon and www.batman.toon. At this point I see the same test web page of index.html that I put in /var/www/html. We can not see any individual sites yet.

Later when we have configured name based virtual hosts each with their own document root, we will see separate web sites even though they are on the same machine using the same IP address. ISPs sell this type of Service as Shared Hosting where your web site is on a server along with other peoples web sites. Of course if you have a dedicated server all to yourself you would pay more for it.

Name based Virtual Hosts

In a network similar to the test one above you could use a single IP address to support many web sites on the same server. This conserves IP addresses and is supported on most browsers nowadays. It also conserves Servers. It is a good solution if you are running a web server at home and only have a single IP address, but then you can support something like www.mypersonalpages.com, www.mychurch.com and www.myhobbies.com. It works because in later versions of html, the html request sent to the server specifies the name of the site that is being requested, the server can then send back the correct content. Quite a nice solution and as long as you do not plan for each site to be the next Amazon.com you should be ok. You could perhaps migrate your site later if it becomes mega successful to a dedicated server or servers. It is also possible to have IP based virtual hosts but for that you need more public IP addresses running again on the same physical server.

One drawback of a name based virtual host is that you can not easily support SSL used by Secure Web Servers. This is due to how the SSL (Secure Socket Layer) protocol works.

It is also possible to use a combination of IP and name based virtual hosts on the same server.

Configuring httpd.conf for Name Based Virtual Hosts

I feel that it will be better to create some name based Virtual Hosts before installing the FrontPage Server Extensions. However it should be possible to do afterwards as well. But I want to get the name based hosts proved to be working before adding the extensions. This is always a good idea to get the basics working and add to it, that way if a problem occurs you have a fairly good idea of what caused it. Work methodically.

In httpd.conf check for NameVirtualHost *:80 you will probably have to remove the comment #.

This configures Apache to listen on all IP addresses at port 80

This could be tuned for example to :-

In which case also check that the Listen directive is

Obviously, adjust the IP addresses for your own set up.

In this example I will use the specific IP address for Listen and NameVirtualHost rather than the * wildcard.

Note: If you are adding hosts to an existing web server you need to create a Virtual Host for the existing host referenced in the main part of httpd.conf, as this will no longer be referenced when adding virtual hosts. If placed first in the virtual hosts list it will act as the default host.

Adding Virtual Hosts to httpd.conf

We need to create in httpd.conf a DocumentRoot for each Virtual Host to use.

• www.goofy.toon will use /var/www/goofy

• www.batman.toon will use /var/www/batman

• www.bugsbunny.toon however will reference the existing DocumentRoot, /var/www/html. This is for example to show creating a virtual host pointing to the current document root used originally by the main section of httpd.conf. See Note

So first open a command shell to create the two extra directories and check the permissions are the same as the original DocumentRoot, /var/www/html. The files belong to root and if needed the permissions would be set with the command: chmod 755 /var/www/directoryname. The files were created with the needed permissions so this step was not needed.

Just after the NameVirtualHost directive in httpd.conf you will see a Virtual Host example commented out with # at the start of each line.

Next I added the following virtual hosts with the minimum configuration required at the bottom of httpd.conf. You can add other parameters later if you wish. check www.apache.org for documentation.

Restart Apache so the httpd.conf file is reread.

No errors. So lets move on and solve the problem that the server's fully qualified domain name can not be determined.
 

Adding the Server to DNS

At this point I added the Fedora Server to DNS. The Servers host name is elendil in the bugsbunny.toon domain.

Add this directive to httpd.conf

Restart the web server again.

We can check the entry in DNS like this:-

Notice the above information is retrieved from the DNS Server at 192.168.1.92.

Browsing the Individual Sites

Browse to the .toon web sites from the Windows client and refresh the browser so it reads the web pages from the Web Server and not its cache.

In the example www.bugsbunny.toon showed my sample index.html in /var/www/html

However www.goofy.toon and www.batman.toon showed the default Apache page as no content at this point had been published in their respective document roots.

After manually adding a new separate index.html into each document root. I was able to view separate content on each Virtual Host.

Here you can see screen dumps of sites and nslookup ran from the Windows 2000 client. Click on the thumbnail images to see a full image.

Command Prompt on Windows 2000 client This shows nslookup resolving the IP addresses for the Virtual Hosts by querying the DNS server golem at 192.168.1.92. Notice that each site is to be found at 192.168.1.95	www.bugsbunny.toon homepage The sample index.html for www.bugsbunny.toon	www.goofy.toon homepage The sample index.html for www.goofy.toon	www.batman.toon homepage The sample index.html for www.batman.toon

At this point we have proved our virtual servers are working and serving individual content.

The next step will be adding the FrontPage Server Extensions to the Virtual Hosts.

Installing FPSE for the Virtual Servers

Download the extensions if you have not already done so. If you are installing on Fedora Core 2 and do not need to use Virtual Servers follow the steps in my older tutorial.

Before installing at this point lets make a backup of httpd.conf to the point reached so far.

By making a copy at this stage if we have a problem when installing our FPSE we can get httpd.conf restored to a known good point.

We can now run the install script. Change to the directory where you downloaded the FPSE and install script and then run the script. I would suggest you read and understand this whole section before running the script so you save yourself some possible frustration.

The script will then ask you some questions, you can accept the defaults by pressing enter, but you will need to give answers to some of the questions. Use the space bar to scroll through the license agreement. Note some output has been omitted for clarity.

The next thing we will be asked is if we want to install a root web. In this case for Virtual Servers the answer is no. We then see the script do the following.

In the output above we have answered no to installing a root web and no to new sub/per-user webs. The script then asks where httpd.conf is and installs the Virtual Webs, and we are given a list of Virtual Hosts found in httpd.conf you need to select the number of the site you wish to install to, in the example we will go through 1, 2 and then 3 to install the extensions and when we are finished you press the CTRL and D key at the same time to finish.

In the next output you can see the install for www.bugsbunny.toon

Notice in the above output, we enter a non login unix username and group for the user, in the example I use the default of apache. I then give an Administrators username for this virtual site and a password. We are then asked again about sub/per-user webs, if we answer no we are returned to our list of Virtual Webs. We can then repeat the process for each web that we choose. Here is a file showing most of the output.

When you have finished restart the Web Server.

Setting the Admin Port for FPSE

It could look as if for each virtual web that we will need a separate instance of this for each of the virtual FrontPage Admins created for each Virtual Host but this is not the case.

We need an all powerful FrontPage Admin that can look after the FPSE, here I have made the admin user, toongod known as the globalAdmin.

This adds another virtual server at the bottom of httpd.conf used by the Extensions for the FrontPage globalAdmin.

Further Editing of httpd.conf

For more information on this section read here from the earlier tutorial and then return here with your browsers back button.

Mime magic needs to be edited the same as the earlier tutorial in httpd.conf as follows:-

No editing of LoadModule is needed this time however as the changes needed for RH9 and FPSE_SR1.1 are not an issue with this version.

Restart the Web Server

Logging onto the Admin pages

I can now log onto the FrontPage globalAdmin pages at http://192.168.1.195:8088
I first had to open up the server security for tcp port 8088, this is the port number that was made with the owsadmn command earlier. This port would probably be not reachable by the whole world via an external firewall for Security reasons, so even though it is open on the Server does not mean that the whole world has to reach it. For example an ISPs admin could reach it from a specified source but others would not be able to.
 

Password Prompt dialog box Password Prompt dialog displayed when logging onto the globalAdmin pages	globalAdmin homepage The globalAdmin homepage in Internet Explorer from a Windows 2000 client

From there you can get the administration links to the different sites. Each of the sites has its own admin, e.g www.batman.toon admin is alfred and the password robin. These admin pages for the individual sites are available via port 80. Which means remote customers can log on through the same port as the server is using for Web pages. Which means that the external firewalls can be kept fairly tight and the external admins can reach their own admin pages for the FrontPage Extensions.

For example an ISP could give the admin of www.batman.toon the exact URL to his admin pages, this is found in the link Administration for each virtual site on the globalAdmin page. This way the globalAdmin port is not exposed and no one else but the globalAdmin needs to know the log on details for the Global page.

I added alfred as an Advanced Author and published from FrontPage without an issue.

I also logged onto http://www.bugsbunny.toon and modified pages as the Administrator. No Advanced author had been added for this site.

Note FrontPage requires the full URL to Open a site
http://www.bugsbunny.toon is good but www.bugsbunny.toon will not work.

Summary

Configuring Virtual Servers on a Fedora Core 2 Apache Web Server was covered along with installing FrontPage Server Extensions for name based Virtual Servers.

Err, I have to say it...That's all folks.

Top of Page