Setting Up a Web Server

Jump to:

When you are browsing the Web you see lots of web pages that have features you might think are pretty cool. If you want to do the same kind of stuff, you'll need a web site so any web pages you create can be properly displayed. You can just have your browser open a web page on your computer:
file://some_file
but this only works for very simple, very flat web pages.

If you want the page to be interactive (the user does something like fill out a form and something useful happens) or if you want some razzle dazzle graphics or other effects, this technique probably won't work. Most of the really good stuff will just generate an error. To get a web page to actually do something, it has to be displayed by a web server. Only a web server will know how to make everything work correctly. A web server not only displays web pages, it also knows all about paths to graphics and other pages on the website and can execute scripts.

If you want your web pages to be accessible to people on the Web, your webserver has to be "hosted" (using a technique called, virtual hosting). This means that you pay someone to use their web server to display your pages on the Internet at large. Unless you already have a bunch of web pages written and ready for use, the web host's server starts out with nothing to display. Since there are no web pages, you're paying for a service you can't use. So you write you web pages, upload them to the remote server and then view them with your browser. But what if you misspelled something, or your punctuation is messed up or things don't look quite right? You have to make corrections on your local machine (the one you're using right now) and then upload the corrected files to the web server. This goes on until you are either satisfied or get sick of it.

But wait! There's a better way. Download and install a web server on your home computer (let's call it the local computer and call any other computer "out there" a remote computer). I can recommend two web servers that I've used many times: Xitami and Apache. Xitami is really slick for a quick set up and is a very capable web server. It's a breeze to set up and it works well on every version of Windows I've tried. Apache is what the Big Boys use and it's the most popular web server on the Internet. Odds are most of the web sites you visit are served by Apache. If you contract for web hosting (and you will eventually), they will use Apache (see this). Xitami is great for testing your web pages locally and Apache is the industrial strength option.

By having a web site on your computer, you can fully test all your web pages before you upload them to your "real" web site (the one you're paying for). Since you are running a web site yourself on your own machine, you don't even have to sign on to a web host until you know exactly how all you pages work. Once you're satisfied with the web site you've designed you can sign up with a web host, get your Domain Name and publish your site on the Internet. Since you're already tested all your web pages, you won't to worry about mistakes appearing on the Web.

Again, setting up a web site is not hard. There's really only a few things to do to make it work. If you want to do more, have more capabilities you can of course, but getting started is easy.

Xitami
Let's do Xitmai first. Download the file, xiopen.zip from their web site. You'll have to unzip it (I like peazip). The peazip install will not ask you where to put the peazip files and put it in the C:\ partition without asking. (I hate that. See why here. Unzip the xiopen.zip file you downloaded. Don't ever put a new install of any program in the C: partition if you can avoid it. Extract it to a directory with the same name as the program you're installing (xitami or maybe, webserver). When everything is extracted, use Explorer or the command prompt to get to that directory. Notice I'm assuming you're using MS Windows, most people do, after all.

So, we're almost finished. Get into the xitami directory and find a file named, xitami.aut. Open this file with text editor (notepad will work although there are much better editors (see this. It looks like this:

# This section defines the password for the browser-based administration
# screens. When you install Xitami, the initial password is '-', meaning
# 'no access'. We don't like default passwords. You should change both
# the user name and password to something safe.
#
# Special entries:
# webmask include/exclude specific IP addresses
# realm realm for authentication
# http-put allow HTTP PUT method
# http-delete allow HTTP DELETE method
# all=* allow access to all users
#*END
[/admin]
Admin=- # By default, admin access is disabled
# Admin=LinPopTea
# Webmask=local # <== when 'local', remote access is not allowed

[Private]
Jacky=robusta
Jonas=realtime
Sarah=arabica

[Documentation]
all=*
webmask=local

[Stats]
Admin=QzeCat96
Root=PakYupTon
http-put=1
http-delete=1

Notice the line, Admin=-, this disables access to the server for making changes. Delete the hyphen character (-) and replace it with a password you want for accessing the server configuration. That was the hard part. Xitami can be run as a service under Windows but that really isn't necessary. All that means is that it will run on startup.

Now find the file named, xigui.exe and double-click it to start the server. You should see an X on the task bar over where the time is displayed. Right-click the icon, and click on setup. It will pop up a web page with various options. You can keep the default configurations and it'll work just fine or you can tweak stuff to make it match whatever structure you want on a permanent web site (the one you're going to pay for later). Since most web hosting companies run Apache under Linux, the pages they host will usually be in a directory named, public_html, so you may want to make xitami do the same.

Notice that xitami also provides an ftp server. An ftp (File Transfer Protocol) server is handy since it allows you to copy files from another computer to yours and vice versa (see this). If you're at work and writing web pages instead of working, you can ftp those files to your home computer (see more about that here). Even though you're not really going to host "real" web sites with xitami - you could, so all of this is handy. Poke around the configuration files and try to understand what's going on. Knowing how a web server works is useful if you plan on paying for someone else to host it. It makes it harder for them to excuse their mistakes.

Apache
Apache is the web server most web hosting guys will use and it will usually run under Linux or maybe, UNIX. This usually means heavy duty hardware, full time technical support and significant investment. What matters here is stability and power. Even so, you can run Apache on your home computer. If you're really cool, you might even run Linux (see an introduction to Linux, here). If you want to cover all the bases, dual boot Linux or Windows and configure Apache in both environments. You can get Apache as "a source" file (you compile it yourself, this is for those who want total control and specific features) or a Windows executable (in the form of an msi (Microsoft installer) file). I suggest the installer since it's really easy. If you get ambitious later, try the source install.

Continuing on the assumption you're doing Windows, double-click the apacheXXX.msi file and start the installation. It goes smoothly and all is well. Apache uses a standard directory structure regardless of the operating system it's installed on. Inside the Apache directory are several sub-directories. bin is where the actual executables live, conf is where you find the configuration files (the only one we care care about is httpd.conf, we may care about mime.types. later), logs is where Apache puts information about how things are working (or not). You'll need those logs if you have problems. htdocs is home to all your web pages and where you'll spend most of your time. If you also downloaded the manual, it will be in the manual directory, can be pretty handy at times. the modules and lib directories are static; you should never need to mess with either of them.

Start by editing the httpd.conf file in the conf directory. Notice that any line that begins with a # character is ignored by Apache (it's a comment). There's only a few things to change at first:

ServerRoot "D:/Apache2.2"
Listen 8080
ServerAdmin acme@generic.com
DocumentRoot "D:/Apache2.2/htdocs"
<Directory "D:/Apache2.2/htdocs>"
Options Indexes FollowSymLinks Includes ExecCGI
  • The ServerRoot directive tells Apache where the web server lives so it knows where to look for all its files.
  • The Listen line tells the server which port to pay attention to. Normally a web server will listen on port 80 and all browsers will always try that port on a web server. Since we are behind an ISP's router, we can't use that port (unless we pay for it of course) so we have to use a port the ISP doesn't care about. Port 8080 is a good choice since no regular network services use that port.
  • ServerAdmin is the email address of the webmaster (the person responsible for the web site).
  • DocumentRoot tells the server where all the web pages are located.
  • The <Directory> part tells what is allowed in the named directory (D:/Apache2.2/htdocs in this case). If you want virtual hosts you would need a <Directory> entry for each virtual host enumerating what can or cannot be done inside that host.
  • The Options part is inside a <Directory> container and tells the server how the files in that directory behave. Be aware that the Apache httpd.conf file uses the same tag scheme as an HTML document: <Directory> is in effect until it hits a </Directory> tag. Also notice that Apache uses the UNIX slash character (/) in directory names rather than the Windows backslash (\). You'll have to follow that convention with Apache.

Using php in with Apache
My Apache server differs from the default as follows:

ServerRoot "/usr/local/apache2"
Listen 8080
LoadModule php5_module modules/libphp5.so
ServerAdmin acme@guru.com
DocumentRoot "/usr/local/apache2/htdocs"
<Directory "/usr/local/apache2/htdocs">
Options Indexes FollowSymLinks ExecCGI
<IfModule dir_module>
DirectoryIndex index.html index.php
<IfModule>
ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/"
AddType application/x-httpd-php .php .phtml .html
AddType application/x-httpd-php-source .phps
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddHandler application/x-httpd-php .php
AddHandler application/x-httpd-php-source .phps
This differences are the path information for my setup and enabling php as both a script with a .php extension and as in-line within an .html file. These changes are in the order they exist in the httpd.conf file so just just add or change the entries to match your own Apache configuration.

The PHP Website has all the information you need to install and use php. I prefer the tarball so I can put put everything in /usr/local. If I want to upgrade or re-install my distro later, I make sure not to format /usr/local (or /home) so the configurataions and settings will be avaliable after a new install or upgrade.

While php is enormously useful as stand-alone scripts (files with the .php extension), php can easily be embedded in any .html file to add convenient odds and ends to your page. Here's a php snippet from one of my pages:

<?php
$rserver = $_SERVER["REMOTE_ADDR"];
echo "
<center>
<table width=70%><tr><td valign=\"top\" align=\"center\">
<span style=\"font-family:verdana;font-size=14;color:#222222;\">
Your Real IP Address is: <b>$rserver</b>
</span>
<br>
<a href=\"ip-isp.html\">What Does This Mean?</a><p>
</span>
</td></tr></table>
</center>";
?>
(the backslashes (\) are used to escape the double-quote (") or you can quote the echo'd strings with a single quote to avoid the backslashes. Single quotes have strange effects that may be confusing, so the double quotes and backslashes may be easier to understand if you're just learning php.)

When your browser connects to a webserver, there's an exchange of information between your computer and the server. The server knows things about your computer and the browser you're using. These are stored in variables that you can access and use in your scripts. The php engine knows about these variables and creates a bunch of it's own.

Notice in the script above that the variable, $rserver was set to the value of the webserver variable, $_SERVER["REMOTE_ADDR"]. The $rserver variable is then used later in the script. To see all the variables available, try this:

<?php
phpinfo();
?>
Save the file as phpinfo.php or embed it in an .html file. When the script is run (by the websever) it'll display all kinds of interesting stuff.

These few lines are all you really need to get Apache working. Once the configuration is finished, you can start the actual server program. It's in the bin directory and it's the httpd.exe file. Since Apache is installed from the msi file the actual startup for the server is in the Start -> Programs -> Apache HTTP server - > Control Apache server -> start. I installed the Apache server as a Windows service and it works just fine.

To control a Windows service go to Start -> Settings -> Administrative Tools -> Services. If Apache is installed as a service it should be at or near the top of the list of services. From there you can start, stop or restart Apache.

Under Linux all you need is to have a terminal window open and sudo service httpd start (or stop or restart). You'll need to restart Apache any time you make any changes to httpd.conf or any of the other configuration files before the changes will do anything.

Once you have a real live web server running you can start creating web pages and testing them in your browser. (to add scripts to your website, see this). To see your pages (the server is running, right?), open your browser and go to either localhost:8080 or 127.0.0.1:8080 (if you're behind a router, say a wireless setup, that router will assign an IP address to your computer, usually in the 192.168. class C address range. If so, you can also use that). Notice that the address portion is followed by the colon (:) and the port number. Recall that we have to use a non-standard port number since we're behind the ISP's router. Ordinarily you never add a port number to an address simply because port 80 is assumed and will be used unless you explicitly tell the server to try something else.

Your page should display and look like any other web page on the Net. With xitami, the page that gets displayed is named, default.htm while the Apache server will automatically display the page named index.html. The page that opens when all you specify is the server name (localhost:8080 in our case), should always be index.html. This is the standard and that name ensures consistent results. Windows web pages will be index.htm but that's because Windows didn't used to be able to see more than three characters after a dot. That's no longer true so spell the entire filename: index.html. It will save you some confusion later on.

NOTE:
Be aware that if a directory on your website has no index.html file, the server will display all the files and folders in that directory for anyone to see. Every directory in your public space should have an index.html file to prevent this kind of listing. Either that or you'll have to create a .htaccess file, or its equivalent in the httpd.conf file, for each directory to deny access and that can get tedious. This index.html can be nothing more than a meta refresh tag that redirects to your top index.html file. The page would look like this:

<meta http-equiv="refresh" content="1;url=http://my_website/index.html">

After one second the page loads your top-level index.html file. Get used to putting an index.html file in every directory even if it never gets used.

Virtual Hosts
A reasonably capable web server offers the option to serve multiple completely separate web sites. This means that one server can display web pages for more than one user (paying client). The usual way is to provide what is called, named-based virtual hosts. It's called named-based because all the web sites share just one IP address so all that differentiates them is the name of the web site. http://acme.com and http://generic.com can both live on the same server but the pages displayed are determined by the name used to access them.

This is typically done by putting each web site in a different directory in the server's root directory. A web server on a reasonably robust computer can host a bunch of completely different web sites with no conflicts or loss of performance. Some web hosts can be spread out over many computers and still use the name-based hosting scheme. The web server just points the request for a web page to whichever directory on whichever computer is assigned to the web site's name.

The configuration for all this is not really that difficult but it has to also agree with other configurations like the DNS name service, a firewall, maybe a mail server and some other bits and pieces. If everything is well thought out and properly tweaked, a very stable web hosting service doesn't require deep technical acumen. You can do it all on your home or office computer and actually make it work exactly like a professional web host's server.

Domain name
One of things you have to have to put your pages on the Web is an address for those pages. That address is the URL (Uniform Resource Locator) that people type into their browser. It starts with: http:// followed by your domain name. If your domain is acme.com then your website begins at http://acme.com. When you sign up with a web host, you also get to choose a domain name. If the name you want is taken, try others until you get one that is open for use (all the really cool domain names are long gone of course).

The web host will register that domain name for you so that no one else can use it. It also configures the web host servers to point all requests for pages within your domain to your web site. It's all pretty painless, the web host people will do all the work. You will want the web host to be running the Apache server (at least version 2) and support php (version 5) with the stand-alone and in-line scripting options. Make sure they have competent and responsive technical support in case you have problems with your pages or scripts.

Return to the Contents Page