by Rob Falla and Mark R. Brown
Before you publish your Web site to the Internet you should consider the options available; your choice depends on your individual situation. Read this section to gain a better understanding of the two Web-site publishing options--your own server versus having your site hosted by an Internet Service Provider--and select the one that best suits your needs.
The most common choice--considering the initial cash outlay required to set up and run your own server--is to let someone else worry about the equipment upkeep. Unless you're developing a complete Internet solution for a large company, one that makes use of other Internet features such as FTP (file downloading), e-mail, and possibly a database, you probably do not require your own server. Make a few phone calls, do a price and service comparison, have you site hosted by one of your local Internet Service Providers (ISPs).
The focus of this chapter is getting your Web site published on someone else's system. Considering the differences between the policies of the various ISPs, you should look for certain features before signing on with any particular ISP. In addition to a standard dial-up account with e-mail, you need a shell and an FTP account. It is only common sense that you have easy access to your Web files.
This is the easiest method if you can find an ISP that offers shell accounts and FTP (not a requirement, but makes it much easier). If you plan to make frequent modifications to the content of your site, having UNIX shell and FTP (File Transfer Protocol) access means you can quickly add and remove files, add new subdirectories, and include server-side scripts (depending on the ISP), among other benefits like using the UNIX mail to sort your e-mail.
This option is not for everyone--it needs to be considered very carefully. The initial cash layout for the appropriate telephone line service and modem is in excess of $1,000--not a commitment to be taken lightly. In addition to purchasing the digital telephone line service and the digital modems, you also need a computer to act as the server. You do not want your accounting files and sales strategy on the same machine the world is connected to.
Both options achieve the same goal of making the data on the Web site available to anyone on the Internet with a Web-client application (browser). The delivery methods are the same as well. The only difference is that you are burdened with maintenance of the networked system--which can become an enormous task if any major problems arise.
Running your own server means you have total control over who sees your Web site and what kinds of content you can include with your Web site. You can make sections of the site available to anyone with a browser and restrict other parts of your Web site so only authorized users can access it. You own the Web site, and you own the space on the Internet that the Web site is occupying. This option is usually only available if you have a direct connection to the Internet.
TIP: You can run a server off your hard drive through a dial-up account, but the Web site would only be available when you are logged on. Also, you would have to make arrangements with your ISP to make sure you had the same IP address each time you log in.
Uploading to an ISP is actually like renting space in which to store your Web site files. Along with the many benefits, saving money being the biggest, there are a few drawbacks. For one, you have very little control over who can actually access the site. You can't include server-side script files unless arrangements have been made with the administrator (often requiring no more than a call to the ISP).
TIP: Talk to your ISP if you want to use CGI Script or server-side Java and JavaScript.
The benefits to using someone else's system include not having to put out the cash to upgrade to a server grade computer, not being responsible for ensuring the system is always operating, and avoiding the monthly bill for having dedicated Internet access.
It is important to determine the resources available to you (see Table 3.1).
| Requirement | Own Server | ISP |
| Dedicated access | 3 |
|
| Dial-up access |
|
3 |
| System monitoring | 3 |
|
| System maintenance | 3 |
|
It's not that difficult to choose the appropriate publishing method once you have determined the resources available to you. Answer the following questions about your operation and Web site:
If you answered "yes" to the above questions, you probably want to run your own server. You are not required to, but it would be to your benefit. If you answered "no" to the first two questions and "yes" to the others, you may want to have a discussion with your ISP about your needs. He may have a reasonably priced solution for someone in your situation; if he can't help you, shop around. Many ISPs will try to accommodate your needs; be prepared to pay.
Do you already have the money, the equipment, and the dedicated access to the Internet? Your choice is obvious. You should look over the information about servers in the Web Servers section of this chapter and go with the one that best matches your requirements. Not much of a decision if you're already set up for it.
NOTE: Still think you need the power of running your own server, but you do not have the resources or the dedicated account? There is still a chance that you can run a server (like Microsoft's Personal Web Server) from your local computer.
Your Web site would only be accessible while you were online. The rest of the time the user would get a File not found error.
It is beyond the scope of this book to get into the particulars of this option. If you want to find out more, talk to your ISP.
Everyone else will be uploading to the ISP. This choice still offers a range of options for dynamic content inclusions. Many ISPs will put your CGI script on their system to work with your order form, guestbook, or for whatever else you may need a CGI script.
TIP: There will most likely be a fee for putting your custom CGI script on the system. The ISP has to test the script first, to make sure it isn't going to mess up the system by inadvertently allowing someone access to the system. If it passes the test, it is put on the system. If it poses a security threat, it's not likely to be on the system until the threat is eliminated.
There's the obvious benefit of not having to worry about monitoring the system. If there are any problems, the administrator will fix it. You can concentrate on producing the Web site and let someone else worry about keeping the system alive.
Carefully consider the next two sections of this chapter when deciding which option to go with. The first, "Uploading to an ISP," takes you through the steps to publish your Web site on someone else's server. The next section, "Preparing Your Site," discusses running your own server and talks about the requirements of running it.
Uploading to the ISP is relatively easy. All you have to do is follow the steps outlined in this section. This section is a generic set of instructions based on a UNIX account. Check with your ISP to see if there is any special procedure that must be followed on that system.
TIP: Some ISPs require you to e-mail the HTML files to them. They place the files in a directory area designated for your Web site. These ISPs charge a fee for putting the files on, and they charge a fee for any updates to your Web site. If the ISP you are dealing with works like that, shop around. It could quickly become very expensive to keep your content fresh in such a situation.
As you progress through this section, notice the following steps:
Make yourself a checklist of all the required steps. When it's time to put your files online, refer to the checklist to ensure you do not make any mistakes or forget any steps.
The first thing you must do when putting a new Web site on the Internet is prepare the home on the networked computer in which the files will reside while they are on the Internet.
TIP: Check with your ISP before you attempt to put a Web site on their network. They may not allow UNIX Telnet sessions, or they may complete the following steps for you.
NOTE: As stated at the beginning of this chapter, you should have an account with an ISP that offers shell account access. This section assumes you have the shell account.
You have to be online first. Once you are online, initiate a Telnet session. (If you aren't allowed to Telnet, you'll have to have your ISP do your setup for you.) The Telnet client will communicate with the remote system requesting Telnet access. The Telnet session goes like this:
NOTE: Microsoft Windows 95 includes a Telnet client. To use the Telnet client, click the MSDOS prompt icon. At the DOS prompt, type telnet <host address>.
Now you have initiated a Telnet session. The default directory when you Telnet into the ISP system is always your user directory.
Figure 3.1 shows what the screen looks like when you log in. Call your ISP if you are having trouble establishing a Telnet session.
On your first Telnet session you should take a few minutes to familiarize yourself with your surroundings. There are a few commands that will become useful during this and any future Telnet session.
FIG. 3.1
Here's a new Telnet connection.
| ls | List. Shows files and directories stored in the current directory that are not hidden. |
| la | List All. An alias for ls -a. Shows you all the files (including hidden files) and directories stored in the current directory (see Figure 3.2). |
| mkdir | Make Directory. Creates directories and subdirectories in the current directory. |
| rm | Remove. Deletes files stored in the current directory. |
| rmdir | Remove Directory. Deletes directories and subdirectories from the current directory. |
| man <topic> | UNIX manual. Displays the help files on the topic. man mail will provide the help files on the UNIX mail program. |
| cd <directory> | Change Directory. Change the current directory to another directory. To go up in the directory tree and simply type `cd ..'. |
TIP: If you want more information on the UNIX online manuals type man man.
The Web site files must be placed in a subdirectory of your home directory, specified by the ISP and usually called public_html. The public_html subdirectory is the default location the browser looks in, for all Web files, when it attempts to retrieve a Web page from your account. If there is no public_html subdirectory, the complete path for the Web site files must be supplied.
In addition, the access permission level for the public_html subdirectory must be set to allow read-only access for everyone. Once the access permission for the public_html subdirectory is set, all subdirectories of public_html share the same permissions as the public_html parent directory.
FIG. 3.2
la will list all the contents of the current directory, including hidden
system files, which have a dot as the first character.
Not every BSD UNIX Operating System is the same. The steps outlined in the following list are based on the BSDI 2.0.1 Operating System. Some of the other BSDOS systems do not inherit the permissions set for the directory. The best way to determine the requirements for any system is to ask your ISP.
Follow these steps to create the public_html subdirectory and set the appropriate access permissions.
TIP: Steps 3 and 4 can be combined into a single step by typing chmod 755 public_html or chmod 644 public_html from the user directory.
| alpha permission | numeric | for... |
| chmod u+rwx,go+rx public_html | chmod 755 | read and execute |
| chmod u+rw,go+r * | chmod 644 | read only |
The directory is ready for your Web files. You have created the directory to store the Web files, you created subdirectories as needed, and you set the access permissions for all directories. The only thing left for your Telnet session is to end it.
To end the Telnet session, type exit or logout at the prompt. That is all there is to it--not so bad, eh?
The next step to getting your Web site published is to put the files in the proper directories. If you have already organized your files by type on your hard drive, you can move right into the next stage, transferring or uploading with an FTP client all the files needed by your Web site.
TIP: There are some ISPs that have accounts that do not have shell access, and everything (including creating subdirectories and giving them the correct permission) will be done using FTP.
Open your FTP client and follow these instructions to connect to your ISP. As with the Telnet client, your home directory is the default directory you will be taken to with the FTP client.
NOTE: The following is based on using the shareware FTP client application WS_FTP (included on the CD). If you are using another FTP client application, the steps may be slightly different.
FIG. 3.3
Setting up a new profile with WS_FTP.
Once you are connected to the remote host, you see a split directory window. On the left side is the local (your computer) directory tree; on the right you see the remote host's directory tree.
Both directory trees are broken up into three sections. The section nearest the top contains the path of the current directory. There is a separate path on both sides, the left representing your local system, the right representing the remote host.
The midsection contains the directory tree. The current directory is the highest on the tree and any subdirectories are placed under the current directory.
The bottom section contains the files that can be found in the current directory. The one on the left shows (by default) the files in the wsftp directory on your system. The right panel should show any files present in the current directory of the remote host.
Follow these instructions to upload your Web site files to your public_html directory and the pics subdirectory on your ISP's system:
TIP: Make sure the Binary radio button is selected. Although you can use ASCII for transferring text files, it is much faster to leave the setting to Binary and transfer files of all types at the same time (bulk transfer).
While still in the FTP client, you can perform any file required management tasks. Depending on how you coded your files, you may want to change the extensions of all your files to .HTML.
TIP: In most cases, there must be an index.HTML file for the Web site. If there is not, the user must specify your home page's exact name in the URL: www.yourco.com/~yourid/pageone.html. If there is an index.html, the user can simply put your Web server's domain and username, such as www.yourco.com/~yourid.
You're finished! Using your favorite browser, test the URL for you Web site. If it comes up properly, you can begin testing all the links on your pages to make sure your visitors don't end up clicking a dead end link.
FIG. 3.4
Select the files you want transferred and the button indicating in which direction
(remote-to-host or host-to-remote) you want them to go.
Now go out and announce your new site by using an announce service such as Yahoo!. See Chapter 40, "Listing Your Web Site in the Search Tools," for the lowdown on how to list your site effectively.
The HyperText Transfer Protocol (HTTP) is the defined protocol for delivering Web page content over the Internet. Web server computers use HTTP to send packets of Web page data over the Internet to a user's Web browser program, which then interprets and displays that data as Web pages.
Under HTTP, each separate block of data is invisibly preceded by a text block defining its MIME type. The browser program uses this MIME-type definition to determine how to interpret the subsequent block of data. If, for example, a plug-in has been defined to handle the data type indicated in the MIME-type definition, the browser launches the appropriate plug-in before trying to display the data.
Therefore, you must configure a server to know and send the proper MIME type before it can send plug-in-compatible data. For example, if your Web site is going to include MIDI music files, you must set up your Web server to send the proper MIME-type header before delivering the actual MIDI file. Otherwise, your viewers' browser programs don't know when to launch their MIDI plug-in.
Here's a typical Web server setting for delivering MIDI content files:
MIME type = audio/midi or audio/x-midi or application/x-midi or
audio/x-mid
action = binary
suffix = .mid
type = midi
This particular example defines four MIME types: audio/midi, audio/x-midi, application/x-midi, and audio/x-mid. The file name extension that the example defines for MIDI files is MID. Whenever a Web page this server delivers embeds a file type with the filename extension MID, the Web server sends a MIME type header that contains the four MIME types defined for MIDI files. The browser on the other end must use this MIME type header to determine which plug-in that it must use to play the data that the associated MID file contains.
You have to include this information in your Web server software's setup file for MIME-type information. How you do so depends on the specific server software you are using.
NOTE: When the user installs a plug-in, the browser program automatically determines which plug-in is associated with which MIME type. If you choose Help, About Plug-Ins from the Netscape Navigator menu, for example, you see a page that shows you which MIME types are set up to launch which plug-ins.
When you set up your Web site--whether through an Internet service provider (ISP) or on your own server--you must tell your server software that you want to deliver content of a certain type or types. To do this, you provide a MIME configuration file for the Web server.
If your company or institution runs its own server, you must contact your system administrator to set up the MIME types for you. If you run your own Web server, you must set them up yourself. Netscape Communications Corporation offers extensive online documentation to assist you in setting MIME types for their servers. You can find this documentation at http://home.netscape.com/comprod/server_central/support/index.html.
Consider the real-world example of setting up the MIME type in the Netscape Communications Server to deliver RealAudio files. First, you would edit Netscape Communications Server's MIME.TYPES file by adding the following line:
type=audio/x-pn-realaudio exts=ra,ram
To the Communications Server's main configuration file (MAGNUS.CONF in the examples provided in the Netscape Communication Server's documentation), you add the following line:
Init fn=load-types mime-types=mime.types
After changing both files, you reinitialize the Web server to activate the changes.
In any case, each plug-in includes documentation that specifies the MIME-type definition for the type of content with which it deals. You must define that MIME type for your Web server software.
The procedure for defining MIME types for any particular Web server is explained in the server's documentation. Specific information on the steps involved in setting up MIME types for every available server is beyond this book's scope. Refer to your Web server documentation for an explanation of how to set up specific MIME types for your particular brand of Web server software.
Microsoft's Web Publishing Wizard (see Figure 3.5) represents an effort by Microsoft to make uploading your pages to an Internet service provider quicker and easier. It's free and you can download it from their Web site at http://www.microsoft.com/windows/software/webpost/.
FIG. 3.5
Microsoft's Web Publishing Wizard can make the process of uploading your Web pages
to an ISP quite painless.
For Windows NT and Windows 95, the Web Publishing Wizard (formerly WebPost) works with most Web servers. It comes preconfigured to work with many of the big services like CompuServe, GNN, and Sprynet. If your ISP has installed a special configuration file, the Wizard is guaranteed to work smoothly. The odds are good, however, that the Web Publishing Wizard will work with your ISP whether they have or not. The program can also be used to upload your pages from your computer to an intranet.
To use the Web Publishing Wizard, you create your pages using the tools of your choice and organize them into folders just as they'll be organized online. If you can load and view your pages trouble-free from your own computer, the Web Publishing Wizard should be able to transfer them to your ISP without a hitch.
If your ISP's server can handle FrontPage Extended Web, FTP, HTTP Post, or Microsoft Content Replication System data transfers, your upload should work.
The actual process consists of just a few simple steps. You launch the Web Publishing Wizard, find the file or folder you want to post, and find your ISP's name on the program's built-in list. If your ISP isn't listed, you answer a short series of questions about your ISP (URL, file transfer method, and the like); then you give the program your Web server's name, click the Finish button, and everything is transferred automatically. Your folder structure is intact--what's on your ISP's server should be a mirror image of what's on your local drive.
If you are in a situation where you need to run your own server and you have the resources to do it, then you need to choose the right server for your operating system. You should also take your unique situation into consideration.
Selecting the right server for your corporate or organizational Web is extremely important. You do not want one that is too complicated or doesn't perform your requirements.
Take a few minutes to draw up a requirements outline. It should contain information about capacity and speed expectations, whether or not you need a secure server, script language requirements, and so on.
You should visit the Web sites of the various server manufacturers discussed in this chapter and read all the relevant Web pages to determine if the server meets the minimum set of requirements you have outlined.
Change the outline as often as is required until it describes your server requirements in a clear and concise manner. As you read the product information pages, you may come across something that you hadn't thought of. You should most definitely add those items to your requirements outline.
Once you have narrowed the candidates to two or three possible servers, find out if you can download a trial version to test evaluate. Run each server through a vigorous evaluation procedure to see how well it performs in certain areas.
Your evaluation should include, in addition to anything you consider important for your circumstances, the following:
If you invest the time finding the right server, you will avoid many of the problems associated with getting the wrong server. A few days to a week spent investigating servers is worth many days, or even weeks, worth of headaches in the future.
NOTE: For more information about server software, refer to one of the following Que books: Running a Perfect Netscape Site, Special Edition Using Microsoft Internet Information Server 2, and Special Edition Using Netscape LiveWire Pro.
When you are running your own Web server, the steps for publishing the Web site are slightly different. The biggest difference is you don't make a Telnet or FTP connection because the server is the local host. The following takes you through the steps of publishing your Web site on your own UNIX server.
When you are running your own server you have a few additional options to consider:
Each of the three items in the list consist of many additional steps and procedures that must be followed. Don't be fooled by the brevity of the steps in publishing a Web site on your own server.
There are also maintenance procedures that are required on a Web server monthly, as well as many other (log report analysis, visitor count analysis, and so on) functions a server administrator must perform.
In the next section, you'll take a look at some of the Web servers that are presently available. This gives you a good starting point for finding and running the server that most meets your individual requirements.
Use the following section to help narrow your search for an appropriate Web server. Each Web server is presented with an introductory paragraph.
Microsoft IIS is the Web server that comes bundled with the Windows NT operating system (see Table 3.2). IIS has been reviewed favorably by many Internet trade mags. If Windows NT is your operating system then you should give this server serious consideration. It's free anyway.
| Item | Description |
| Product | Microsoft Internet Information Server |
| Web Address | http://www.microsoft.com/iis/default.asp |
| Platform | Windows NT |
| Address | One Microsoft Way, Redmond, WA 98052-6399 |
| Telephone | (206) 882-8080 |
Microsoft Internet Information Server (MIIS) is a fairly complete Web server suite. There are no installation problems with this server, in part because you can choose to have it automatically installed when you install Windows NT 4.0.
Although it performs superbly on the Windows NT platform, that is the only platform it is available on, at present. This platform limitation automatically eliminates many potential customers for Microsoft.
The MIIS comes bundled with an FTP server, WWW server, Gopher server, and the WAIS server. In addition, MIIS also includes an HTML editor to assist authoring of HTML documents, a slew of APIs, and SSL security support.
Another feature of the MIIS package is the inclusion of the FrontPage HTML authoring application. FrontPage is an excellent authoring application for all Web developers, either new to the Net or veteran Web developers. You will have a Web site up and running in only a few short hours using FrontPage.
The people from Luckman are not new to the Internet. In fact, they have developed an array of Internet-related applications (see Table 3.3), many of which are included in this package.
| Item | Description |
| Company | Luckman Interactive |
| Web Address | http://www.luckman.com |
| Platform | Windows NT & Windows 95 |
| Address | 1055 W. 7th Street, Suite 2580, Los Angeles, CA 90017 |
| Telephone | (213) 614-0966 |
Web Commander provides a complete Internet server solution package. From the time you remove the shrink-wrap to having the package fully installed on your system takes about an hour. There is helpful documentation included with the package to help you get everything running without a hitch.
The Server software is only one component of the Web Commander package. Also included in the package are HTML authoring tools, secure-server applications, ODBC database support, WAIS Toolkit, Netscape Navigator, and Perl 5.
Where MIIS is limited to operating on Windows NT, Web Commander works with both Windows NT and 95, making it accessible to a wider group of information providers than MIIS. In addition to working on both operating systems, Web Commander has a much better monitoring and logging program than MIIS.
In keeping with their reputation for providing high-quality products, O'Reilly has produced the WebSite Professional (see Table 3.4).
| Item | Description |
| Company | O'Reilly & Associates |
| Web Address | http://www.ora.com |
| Platform | Windows NT & Windows 95 |
| Address | 101 Morris Street, Sebastopol, CA 95472 |
| Telephone | (707) 829-0515 |
Is security important to you? How about database connectivity? WebSite Professional provides excellent support for both, as well as a complete, GUI-based diagnostics application.
The documentation and manuals included with WebSite Professional are well written and easy to use, making installation and administration of your new server as easy as possible. There are no quick solutions to the problem of not understanding the technology.
Like MIIS and Web Commander, WebSite Professional is loaded with additional components. HTML authoring tools include SSIs, Hot Dog, WSAPI, and the Netscape Gold browser/editor.
Netscape's SuiteSpot servers are comprehensive, powerful, complex, and expensive. Sure, SuiteSpot provides a complete set of servers and tools for managing a large site, but what if you're an individual or small company that doesn't need (or can't afford) all that horsepower? Well, that's why Netscape created the FastTrack Server. An all-in-one Web server, FastTrack Server is available for Win95, NT, or UNIX for only $295, complete. You can even download a free 60-day trial version from Netscape's site at http://home.netscape.com/comprod/mirror/server_download.html.
As the only Netscape server that can run under Windows 95, it's pretty obvious that Netscape had the individual and small business owner in mind when this was designed. It's also easy to use, with a graphical user interface that controls all its setup and functions.
FastTrack is an HTML document server intended primarily for use as a Web server, though it could certainly handle a small intranet, as well. It's fully compatible with Enterprise Server, so you can start small and grow as needs dictate.
An Installation Wizard makes installing FastTrack a simple process of answering a few setup questions and pressing a few buttons. A configuration agent automatically detects network settings and configures FastTrack to work properly with them. If you get stuck in the installation process or any time during future system administration, built-in context-sensitive help is just a keystroke away.
SSL security, full reporting capabilities for Web stats, and performance optimization mean that FastTrack is suitable for real-world Web applications. There's even support for server-side Java, JavaScript, and CGI applications, as well as the ability to run applications created using Netscape ONE tools. Remote management means you can administer the server from anywhere on the network.
ON THE WEB: http://home.netscape.com/comprod/server_central/product/fast_track/index.html You can find out more about FastTrack at this site.
© Copyright, Macmillan Computer Publishing. All rights reserved.