IN THIS CHAPTER
Quidquid latine dictum sit, altum viditur.
Before you start putting up your Web server and filling it with content there are a number of things to consider. However, if you're already running Apache you might want to skip this chapter and move on to the next one because this information might not apply to you.
The task of choosing a Web server is not always as simple as choosing the best one available.[1] Other things should be considered, but how important those things are depends entirely on your particular situation.
It is the responsibility of every Web site admin to weigh these considerations, and arrive at the decision that is in the best interests of their Web site, their company, and their customers.
Some of these considerations are discussed here, but there will certainly be others in some situations.
Frequently, you will have to make software choices based on the need to be compatible with existing installed software. For example, if there is a software package that you are required to run that only runs on IIS, then there is no further need to consider other servers.
Although you should never be afraid to learn something new, there is certainly something to be said for sticking to your strengths. If you have people on staff that are already Lotus Domino server experts you might be better off sticking with Domino.
Let's face it. In most companies, the software that you run is what your manager tells you to run. And what his manager tells him, and what her manager told her, and so on. The fact is that a lot of technical decisions are made for very non-technical reasons. Although it is your responsibility to present the pros and cons of various solutions, it's not always going to make a difference.
If you're in a service provider role—either at an ISP or in the IS department of a company—you will frequently be faced with customer demands to run particular software to meet their particular needs. The customer is always right, even when the customer is not right.[2]
Apache has very minimal requirements. If you are running a machine as a server, then it probably already satisfies the minimum requirements for Apache. However, as with any software package, Apache runs better on faster systems with more memory.
Having run Apache on everything from a 486/33 to a Pentium-III 850, and several dual-processor machines along the way, the question of minimal hardware requirements seldom comes up. Apache will run on just about anything.
Apache also runs on just about any operating system that you've ever heard of, and several that you haven't. Anything vaguely Unix-like will almost certainly run Apache, and most Unixes ship with Apache installed in a default configuration.
Apache has been able to run on Microsoft Windows since version 1.3, which was released in 1997. It will run on Windows 9x[3] and Windows NT.[4]
Having said that, the INSTALL documentation that comes with Apache makes the following more specific statements:
You will need at least 12MB of temporary free disk space for the build process. When the installation is completed, it will take up approximately 5MB of drive space. Of course, this number will vary based on which third-party modules that you add to the installation. Also, you will need to take into account the data that you will actually serve from the Web site, which is, of course, not included in that number.
You will need an ANSI-C compiler, such as GCC, for the compilation of the source code. Unless you install one of the binary (precompiled) distributions, in which case you don't need a compiler at all.
A Perl 5 interpreter is recommended, but not required. Several of the utilities that ship with Apache use Perl, but you can make do without these utilities.
Dynamic Shared Object support is also useful to have, but not required. Most modern operating systems support this in some fashion or other, so this is not a very stringent requirement.
If you're going to run a Web server, you probably want a connection to the Internet so people can see your Web site. In order for this to work, you'll need the following:
Internet connectivity: A modem connection is a possible configuration, but if you expect to have more than a handful of people look at your Web site you would be well advised to get a higher-speed connection, such as DSL, cable modem, or some variety of leased-line solution. Your connection needs to be running 24 hours a day, all year long, so that your Web site is accessible whenever someone wants to use it.
Fixed IP address: Although it's possible to play fancy games with DNS (domain name system) to make a dynamically allocated IP address appear to be in the same place all the time, the techniques for doing so are beyond the scope of this book. If you're actually going to run a real Web site you need to have a fixed IP address and a hostname (or more than one) in DNS that resolves to your address. You will need to check with your ISP to find out what your address is, and if you are not running your own DNS server, you will need to arrange to get your name(s) to resolve correctly with whoever is doing so.
An important question to consider is whether you want to host your Web site on your own server, in your own facility, or at someone else's facility, either on one of their servers, or at your own collocated server. This will depend on a number of factors, only a few of which are discussed here.
Can you afford the necessary connectivity? If you put up a Web site that suddenly becomes popular, will you have sufficient bandwidth to service the traffic? If you host it in your own facility, you will be entirely responsible for the cost of that connectivity, and scaling your connectivity to meet the demand can become costly. If you host at an ISP's facility they will likely have more connectivity than you will ever need, and you won't be shouldering the entire cost for all that bandwidth.
Is your connection reliable? If you have a small office, and are considering hosting your Web site on your own Internet connection, you should consider the possibility that your connection might go down occasionally. If this happens, and it stays down for a considerable period of time, you will need to consider alternative ways to provide service to your site's users. On the other hand, if your server is hosted at a remote facility, they will likely have redundant connections to the Internet, so when one goes down, the others will pick up, with no noticeable down time to the users.
What level of access to your servers do you need? If you are running a fairly simple site, on a normal day you might only need to put content on the server. However, if you have a site that relies on a large amount of custom software, or even nonstandard hardware, you might need to have physical access to your server on a regular basis.
If you are running your server on a Windows operating system, or any other operating system for which remote management is problematic, you might not want to have that server very far off site in case you need to do something that requires direct access to the console. (You might also need to consider a remote control application, such as VNC or PC Anywhere, which enables you to export your desktop across the network and work on that machine from anywhere. There are, however, security considerations in doing this.)
If you are running a Unix-like operating system, then you need to make sure that you have as much access to your hosted server as required. If you need daily root access, you need to make sure that your ISP permits this. Some ISPs are reluctant to permit this, because they are then unable to guarantee that the system will stay up.
If you choose to host your Web site at some other facility, rather than having it in house, you need to make sure that you understand your ISP's policies, and make sure that you're getting what you think that you should be.
The following are some of the things that you should ask your ISP, and things that you need to consider yourself, to make sure that there are no unpleasant surprises.
There are a number of different ways to lease space at an ISP. The two primary categories of service are leasing space on a server owned by the ISP, and putting your own server, completely managed by you, at the ISP facility. The latter is referred to as collocation, or a colloc.
If you are leasing space, you need to know to what extent you have control over that machine. Do you have your own server, or are you sharing it with someone else? This knowledge will affect the manner in which you will need to secure your files. If there are other users that will have login privileges on your server, you will need to be much more cautious about files with group and world permissions on them.
Do you have root access to the machine? Normally, if you are not collocating your own server, you will not have root access to the machine. This is necessary for the ISP to have sufficient control over the machine to guarantee its performance. If you do have root access to the machine, it is typical for the ISP to withdraw guarantees of any kind because they no longer have any control over the things they would be guaranteeing.
Is the server monitored by a package such as Watchers (http://www.cre8tivegroup.com/web/watchers.html), which will send notification in the event of system outages? If so, to whom do those notifications go? In the event of a catastrophic system failure (such as a kernel panic on Unix, or a blue screen on Windows, will someone at the ISP be willing to reboot the machine? If not, what is the procedure for getting your server back up?
Do you have an emergency contact number? Will a real person answer it? During what hours is there actually someone in the office that will be able to help you with problems?
Are there any backups run, and if so, how often? Are the backup tapes stored on site, or off site in a safe box? What is the procedure for getting a file restored? How long are backups kept before the tapes are cycled?
If your server is not a dedicated server on which you have root access, then you need to know what the policy is on installing new software. Whether you need the latest Text::Template Perl module installed from CPAN, or you want Majordomo installed, or you want to have the installation of BIND upgraded to fix the latest security alert, you need to know what the procedures are for getting this done, what you can expect for turnaround on installation, and whether they are even willing to do such things. Although some ISPs are very willing to accommodate your whims, others have very strict requirements about what can and cannot be installed.
Small ISPs, such as cre8tivegroup.com, where I host my Web site for example, are often willing to install things for you, make small configuration changes, and keep up to date on the latest security alerts. However, much larger shops tend to be less flexible, insisting that every server have identical loads of software, so that they don't have to do any custom maintenance. Consequently, if there is anything fancy you want to do, such as mod_perl, mailing-list software, or custom Perl modules, you are probably better off going with a smaller ISP that is likely to be more flexible.
After you have your server set up and configured, you'll need a means of providing content to the server. This will ordinarily be done in one of two ways. Either you will log in to the server itself and create content there, or you will create the content somewhere else and copy it to the server machine after it is complete.
Most Web-development professionals agree that it's always a good idea to develop on a machine that is not your production machine, and then copy content to the live server after you have verified that it works. There will, however, frequently be situations where emergency fixes are required, and in those cases, you should work directly on the server.
If you have any Unix experience, you are probably at least somewhat familiar with telnet. You might be unfamiliar with SSH, however. If your experience is primarily on Microsoft operating systems, you might be unfamiliar with both of them. Although a telnet client is provided with most versions of Windows, neither a telnet server nor an ssh server are widely available for Windows.
Telnet is simply a means of logging in to a remote server (that is, not the machine you're sitting at) and getting a command line, just as you would if you were at that machine. The telnet client is part of most modern operating systems. On either a Windows or Unix machine, you'll find a telnet client. This can ordinarily be accessed directly from any command line by typing telnet hostname, where hostname is the network name of the machine to which you want to connect. After you have connected to the remote machine, you will get a login prompt, where you will need to provide a valid username and password for an account on that machine. After you have successfully logged in, a command prompt will appear.
There are a several reasons to use telnet.
Because you are working directly on the live server your changes will be immediately available on the Web site.
Also, you are working in exactly the environment where the Web site is running, so there will not be any strange system dependencies between one machine and another. That is, occasionally you'll find that, for some reason, something that works fine on your test server somehow inexplicably does not work on the live server.
The main disadvantage of editing content directly on the live Web site via a telnet session is the same as what I listed as the first advantage. Because you are working directly on the live server, your changes will be immediately available on the Web site. Consequently, when you mess something up, it will be immediately evident to your viewing public.
SSH (the Secure Shell) is effectively the same thing as telnet, with one important difference. SSH provides you with a connection that is encrypted.
With telnet, your username, password, and all your data, is passed in plain text across the Internet. Anyone with a little bit of knowledge, and the right tools, can intercept this traffic, and either snoop on what you are doing (for example, steal your username and password) or alter the data as it goes past. And, there's very little you can do about this.
With SSH, on the other hand, everything is encrypted, so even if someone does intercept your data, it will be meaningless to them. SSH uses a public/private key system, so that the data can be viewed only by the two endpoints of the conversation. Decrypting this data is extremely difficult and time-consuming.
You can find out more about SSH, and download the free clients and servers for a variety of platforms at www.openssh.org.
If you develop your content on a test server, and then copy it up to your live Web server—which is really what you ought to do—you will probably use FTP or SCP.
Like telnet and SSH, FTP and SCP, respectively, are the insecure and secure versions of file transfer.
FTP, which stands for File Transfer Protocol, is the most common way to copy files around the Internet. It requires an FTP server, which you will connect to with an FTP client, and transfers files from one machine to another. FTP is fairly easy to use, and there are an enormous number of available FTP clients, from standard console (command line) FTP clients to very sophisticated GUI (graphical user interface) FTP clients that make the remote server look like a part of your local file system.
To connect to a remote FTP server with a console FTP client, you will type
ftp remote.host.com
You will be prompted for a username and password, and then you will be logged in. You can navigate around on the remote server with the cd (change directory) command. cd directoryname changes into a particular directory, whereas cd .. moves back up one directory. To move around on your local filesystem while you are logged into the remote server, use the lcd (local change directory) in the same manner.
When you are in the place you want to be, use the put and get commands, respectively, to put and get files.
put index.html get otherfile.html
Two primary disadvantages of using FTP are the clients are insecure, and the servers are insecure.
Due to the nature of FTP, FTP connections are insecure. Like telnet, all data, including your username and password, are passed in the clear across the network, and could be captured as they go across the Internet.
A huge number of the available Unix-security exploits are performed by compromising an FTP server. There are a number of known FTP exploits, and it seems that more of them show up all the time. Although a vigilant system administrator should be able to stay abreast of the latest security exploit, many sysadmins will simply choose to avoid the problem all together.
SCP, which stands for Secure CoPy, can be thought of as an encrypted FTP, although that's not quite accurate. Technically, SCP is file copy tunneled over SSH. Exactly what that means is probably not terribly important for our purposes here. The important thing is that it enables you to copy files across the Internet in a secure manner. Neither your authentication information, nor the data itself, is passed in the clear, and so it cannot be intercepted in a useful manner.
You can find out more about SCP at http://www.openssh.org/, and you'll likely get it when you install SSH.
There are SSH and SCP clients for Windows, the best of them being the ones that come with Cygwin.[5] Cygwin is available from http://cygwin.com/.
Although it is assumed that if you're reading this book, you're already sold on Apache, the decision of which Web server to use must still be carefully considered to make sure that you're making the right choice.
The decision of whether to host your Web site at your own facility or at an ISP, is also an important one, and there are a variety of considerations that you need to think about.
[1] If it were, everyone would be running Apache!
[2] Note that the term “customer” is applied generically, and applies as much to people inside your organization as to those billed for your services.
[3] “Windows 9x” is a generic term which is used to refer to Microsoft Windows 95, Microsoft Windows 98, and Microsoft Windows ME, which share major architectural features, and behave much the same, as far as Apache is concerned.
[4] And “Windows NT” is the generic term used to refer to Windows NT 3.51, Windows NT 4.0, and Windows 2000, which, likewise, share major architectural similarities.
[5] In my humble opinion, anyway