Running web and FTP servers: part two
Last month, we showed you how it’s possible to run many types of Internet server application directly from your own PC using a common broadband connection. We’ve also looked at the steps you’ll need to secure your PC from unwanted intrusion. This is vitally important, and so much so, that we recommend you read last month’s Masterclass once again before you follow this month’s. This issue, we concentrate on setting up your very own web server.
One of the first questions you should ask yourself before following this month’s Masterclass is a simple one – why? If you’re asking this very question already, it’s a good sign. The most obvious answer is control – or rather, the lack of control you get with most free and cheap web server offers. Free servers in particular tend to come in two forms – ad-sponsored and ISP provided.
Ads included
The former is offered by many companies – try typing ‘free webspace’ into Google and see how many results you get. The snag with ad-sponsored web services is obvious – the ads. Some have quite small banner ads implanted into every page you add to your site, but others are extremely intrusive. ISP space is what you get when you sign up to a particular Internet provider, and is almost always ad-free. You’re free to host pages on almost any subject, assuming you adhere to your ISP’s terms and conditions. The snag with ISP space is usually bandwidth-related, though. You’re given a set amount of useable bandwidth per month, and exceeding that usually leads to your site being disabled for a while.
Really though, the best reasons of all for running your own servers involve the simple satisfaction of doing something for yourself rather than relying on other people, and the amount of control you get over the process. Ignoring the first issue since your mileage here will vary according to how much you like to tinker with advanced software, let’s concentrate for a moment on the second reason.
Control freak
Very few low-budget webspace providers offer you any degree of control. You have a basic site to play with, and more advanced features are out of the window before you even ask. Want to run your own PHP-based discussion forum? No can do, since most providers won’t allow you to install and execute your own CGI scripts. Many advanced server features are locked out, since much of the less basic content on many web sites is driven by some sort of CGI routine. With your own server, you’re free to install what you want, with no restrictions on what you can and can’t do – it’s your machine, after all.
If you have a more technical and curious personality, you may well have investigated all sorts of web servers, in which case you’ll have come to one conclusion above all others – Apache is king. If you were able to interrogate every server running right now, you’d see that word appear more often than any other. Put simply, Apache is the most popular web server money can’t buy – it’s completely free, after all. While Apache began life as a UNIX and therefore Linux application, there’s a perfectly credible Windows version available totally free of charge. You can find out more at the Apache web site (see Going Further), and you’ll also find the latest build on this month’s CD and DVD.
Installing Apache
Firstly, you need to install Apache itself. When you come to choose the location, think carefully. While the obvious and default route is to use the normal Program Files directory offered by Windows, you may want to rethink this. By default, Apache stores the web documents it serves inside its own program directory. Unless you want to get your fingers dirty and edit the configuration files yourself, you’ll need to install Apache to a drive with enough space to hold your site as it grows.
During the installation phase, Apache will ask for some domain details, including the server name and the email address of the administrator – you, in this case. Don’t agonise over this, as you can actually whack in anything you like here and Apache will function just fine. Add the details according to the virtual domain name you registered last issue and you should be fine.
Once installed, Apache will begin serving pages right away. To test it, open a web browser and type in http:// localhost. If Apache is running, you’ll see the basic test page designed as a placeholder. Ensure the dynamic domain you created last month is set to your current IP address, and type the full domain name into a web browser. While the localhost option simply serves straight from Apache to your local browser, this one will test that incoming connections are being accepted by the server. If this fails, you may need to go back over last month’s Masterclass and re-read the sections on opening port 80 in your firewall to allow incoming HTTP connections.
Basic configuration
Since Apache for Windows shares roots with the UNIX version, it also shares the same file and folder structure. The test page you see is stored within the Apache directory itself, inside a subfolder called htdocs. Open this and you’ll see lots of files for one small page. This is because Apache can determine a browser’s language settings and serve the page in the right language. You can ignore this for now and delete everything in here, replacing it with your own content.
Unless specifically given a page name to serve, Apache will send the page index.html by default. While you can observe this non-Windows file extension, many web authoring packages including Microsoft’s FrontPage output files with the .htm extension. Apache won’t find these, so you’ll need to make a tweak or two. Move out of the htdocs folder, and open the conf directory. Open httpd.conf in any plain text editor – this is the server’s configuration file, so create a back-up before you edit anything. Scroll about two-thirds down, and locate the line, which begins with DirectoryIndex. Change the default filename to index.htm, and Apache will serve pages constructed by Windows authoring packages with no problems.
Finally, if you want to move the main document path to another drive, scroll back up until you find the entry labelled DocumentRoot and change the path. You’ll need to find and change a line further down which reads Directory “C:/ProgramFiles/Apache Group/Apache2/htdocs” to this same new path.
Apache keeps logs of everything it does. You’ll find them inside the Apache home directory in the logs subfolder. Of the three logs here, you can ignore install.log – it was created when Apache was installed. The other two are very important, though. error.log holds a lot of information about the workings of assorted parts of Apache, which you don’t need to read. Hidden away inside here are error messages generated when remote browsers attempt to open incorrect or missing pages, for example – and these help you nail down any problems with your site.
The other file is access.log, which holds detailed information about every document requested and served by Apache. Like the error log, it’s pretty much impenetrable to the human eye, but well worth reading. This is where log analysis tools come in – applications which take the cryptic Apache logs and make them easier on the eye, not to mention understandable. These programs parse the rather cryptic log format and produce sensible reports, although you may find you need to use more than one in tandem to get the results you want. A quick search on Google reveals that most are command-line tools for the UNIX and Linux operating systems, but there are one or two interesting tools available for Windows, and many are freeware. According to the web page the most popular log analyser in the world is called Analog, which you’ll find on this month’s CD and DVD.
Analog is simple to use, since it requires no installation and almost zero configuration. The only thing you do need to change initially is the name of your site, which is displayed at the top of the finished report. Open analog. cfg and edit the line near the top which begins with HOSTNAME. Analog produces a file called report. html that you can view in any browser, and is more readable than the standard Apache logs.