by John Jung and William Robert Stanek
The inclusion of the Personal Web Server with FrontPage raises a number of issues. These aren't new issues, just issues that many people haven't had to deal with before. Because FrontPage has both a Web server and an HTML editor, it becomes very easy
to set up a Web page. Consequently, many people who've never had a chance to be a Webmaster can now be one.
In this chapter, you learn the following:
The word Webmaster means different things to different people. The role of a Webmaster is rather nebulous and unclear. Before you can understand what FrontPage lets you do as a Webmaster, you need to understand the various aspects of being a
Webmaster.
Probably the most traditional definition of a Webmaster is the person who's in charge of Web page design. She knows HTML codes inside and out and can whip out scripts in no time. Most people think of her as the person who develops the organization's
main Web page. Oftentimes, she's put in charge of the machine that's running the Web server software. This kind of Webmaster might also be able to use paint programs to create fancy images for Web pages.
She also probably knows some technical aspects of the Web server. This knowledge enables her to answer commonly asked questions, such as how image map definition files should be formatted. She might also be in charge of the Web server hardware and
software itself, but it's unlikely that she is asked to deal with any computers beyond the Web server.
A lesser-known definition of the Webmaster is a network administrator. Because the Web server must be able to talk to other computers on the network, certain networking issues relate to managing the Web server. For Web servers that sit on the Internet,
the Webmaster has a number of things to worry about. The most obvious is the security of the Web server software and computer itself. The Webmaster must ensure that scripts aren't malicious or can't be manipulated by others to become dangerous.
Another concern for this sort of Webmaster is making sure the computer can talk to other computers. Because the Web server sits on the Internet, it must be able to correctly resolve host names and perform similar tasks. In large companies, this isn't
usually a concern because this sort of task should already be done by the network administrator. However, many small companies use one computer to perform multiple tasks. It's not uncommon for a small company to have one system serve as the e-mail server,
domain name server, FTP server, and Web server. Consequently, if the system is moved, or its functions broken up, the network connection must be maintained.
Web servers that sit on intranets involve different concerns. Because they're outside the realm of outside systems, Webmasters don't have to worry about security as much. In large companies, intranet Web server security takes the form of restricting
information to only designated people. For example, the research and development group might want to keep the latest specifications under wraps. This secrecy prevents the sales and marketing group from prematurely releasing untested, or unimplemented,
features or functionality.
For small- and medium-sized companies, a Webmaster is both a Web author and a network administrator. Because the company's network isn't particularly large, it's still probably managed by one person. Consequently, the company probably doesn't have a
budget for two people. Instead, such companies opt to have the systems and network administrator learn HTML. This person is then put in charge of creating Web pages and maintaining the Web server hardware and software.
Larger companies usually divide Webmaster tasks between two or more people. The network administrator often has a number of ongoing issues that he deals with regularly, such as Internet connectivity, intranet connectivity, and network security. He's
got a full load of things to do as it is and doesn't have time for Web page design. Consequently, the company would much rather get an HTML expert and make him a Webmaster.
FrontPage's Personal Web Server is primarily aimed at Webmasters who are Web authors. All the configuration and variables that the Personal Web Server allows are related to the server itself. There are some settings that relate to the network but few
things of great technical detail. There are no provisions for setting up routing tables and the like.
FrontPage's Web server also lets you control user access. You can define other webs underneath the top-level web for your site. This root web is what all other sub-webs are connected to. As Webmaster, you can decide which users get access to which
webs. You assign usernames and passwords. You can even create lower-level Webmasters by assigning people in charge of their group's web page Webmaster-like privileges. These privileges extend only to the webs you specifically designate. This capability
enables you to distribute your Webmastering authority to others, who know better what they need. All these user-access features are covered in detail in the Chapter 38, "Managing Security for the Personal Web Server."
In most installations, there is no need to change the configuration of your server. If you have installed the server properly and you are able to browse its contents using Internet Explorer, the server is running. Sometimes you might need to change the
server from its default operation. You might need to run the server on a different port, for example. You might need to add a new MIME type to serve a new data type or add access restrictions to a portion of your web.
You can do each of these tasks in FrontPage by directly editing the server configuration files. If you accept the installation defaults, the server's configuration and access information is located in the C:\FrontPage Webs\Server\conf folder. The four main configuration files are called httpd.cnf, srm.cnf, mime.typ, and access.cnf.
If you are familiar with the UNIX NCSA servers, you recognize three of those names as similar to the configuration files for those servers, which are named with a four letter extension of .conf. The contents of these files are
very similar as well, and Microsoft even points you to http://hoohoo.ncsa.uiuc.edu/ for more details on the configuration. The mime.typ file details the MIME types that the server
recognizes.
NOTE
In the configuration folder, you also find several password-related files. These files include authgrp.pwd, authusr.pwd, and empty.pwd. Because editing these files directly scrambles your password tables for users and groups, you should never edit any of these files.
The following sections look at each of the configuration files in turn to see what settings might commonly need changing. The first three are discussed as configuration files, and the access.cnf file is discussed in the
section on access control.
The httpd.cnf file is the main configuration file for your Personal Web Server. This file contains the location of the server root, which is the location of the vhttpd32.exe server executable
file. The httpd.cnf file is also where you find the port number on which the server listens for HTTP requests. Listing 37.1 shows a portion of this file.
Listing 37.1. Partial listing of the httpd.cnf file.
# ServerRoot: The directory the server's config, error, and log files # are kept in. This should be specified on the startup command line. # # Format: ServerRoot <path> # ServerRoot e:/frontpage\ webs/server/ # Port: The port the standalone listens to. 80 is the network standard. # Port 80
You will probably never need to change any of these settings. If you manually moved the server files from the e drive to another drive, for example, you could change the ServerRoot directive to the new location to allow the
server to run and find its other files. The other configuration files use the ServerRoot as the default starting location for their files, so when you change this one directive, you do not need to change the other files.
Another common reason to change this file is if you wanted to run the server on a different port from the default port 80. You might already have another Web server installed on port 80, and you just want to install the Personal Web Server for testing
purposes. You could change the Port directive line to read something like the following, which causes the server to listen to port 8080 instead of port 80:
Port 8080
NOTE
You might have encountered a location on the Web with an URL such as http://www.someplace.com:8080/. This URL shows that the server is running on port 8080, a common alternative to port 80. Also note that without the :8080 portion of the URL, a client browser will fail to connect to the server.
After you make any changes to this or the other configuration files, you must stop and restart the Personal Web Server for the changes to take effect. It is always a good idea to make a copy of these files before you make any changes! FrontPage already
ships an original unedited version of these files named with an .org extension, as in httpd.org, but you still should make sure that you have a backup copy of these files for safety's sake.
The Server Resource file (srm.cnf)contains settings that control the document layout for your server and the file and folder names that a client is allowed to see. This file defines the location of your DocumentRoot, which is the location for the content of your web. As you see in Listing 37.2, this file also determines the default directory index file, which is the file that the server attempts to load when an URL ends without a
filename, as in http://www.where.com/.
Listing 37.2. Partial listing of the srm.cnf file.
# DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # aliases may be used to point to other locations. # DocumentRoot e:/frontpage\ webs/content # DirectoryIndex: Name of the file to use as a pre-written HTML # directory index. This document, if present, will be opened when the # server receives a request containing a URL for the directory, instead # of generating a directory index. # DirectoryIndex index.htm # AccessFileName: The name of the file to look for in each directory # for access control information. This file should have a name which is # blocked from appearing in server-generated indexes! # AccessFileName #haccess.ctl
As you can see from this listing, the DocumentRoot for this server is at e:\frontpage webs\content, but notice also that instead of normal \ (backslash) path
delimiters you would expect in Windows NT or Windows 95, the srm.cnf file uses the UNIX / (forward slash) character. This character reveals the UNIX roots of the Personal Web Server and is the way
paths are delimited throughout all the configuration files. As with the httpd.cnf file, you usually don't have a reason to change the settings in the srm.cnf file. If you already were using the
popular EMWAC HTTPS Web server for NT whose default directory index filename is default.htm, for instance, you could change the DirectoryIndex line so that you could easily use your existing files
without renaming them.
NOTE
The European Microsoft Windows Academic Consortium (EMWAC) created the first popular HTTP server for Windows NT; this server is still easy to use and configure. Dr. Chris Adie was the author of this server and is also responsible for many of the other tools that are available from the EMWAC server at http://emwac.ed.ac.uk/. This same server was eventually shipped by Microsoft as part of the Windows NT Resource Kit and was also the base for the commercial Purveyor Web server from Process Software.
Listing 37.3 shows another section of the srm.cnf file that might interest you.
Listing 37.3. Another section of the srm.cnf file.
# AUTOMATIC DIRECTORY INDEXING # ============================ # The server generates a directory index if there is no file in the # directory whose name matches DirectoryIndex. # FancyIndexing: Whether you want fancy directory indexing or standard # FancyIndexing off # IconsAreLinks: Whether the icons in a fancy index are links as # well as the file names. IconsAreLinks off # AddIcon tells the server which icon to show for different files or filename # extensions. In preparation for the upcoming Chicago version, you should # include explicit 3 character truncations for 4-character endings. Don't # rely on the DOS underpinnings to silently truncate for you. AddIcon /icons/text.gif .html .htm .txt .ini AddIcon /icons/image.gif .gif .jpg .jpe .jpeg .xbm .tiff ¬.tif .pic .pict .bmp AddIcon /icons/sound.gif .au .wav .snd AddIcon /icons/movie.gif .mpg .mpe .mpeg AddIcon /icons/binary.gif .bin .exe .bat .dll AddIcon /icons/back.gif .. AddIcon /icons/menu.gif ^^DIRECTORY^^ AddIcon /icons/dblank.gif ^^BLANKICON^^ # DefaultIcon is which icon to show for files which do not have an icon # explicitly set. DefaultIcon /icons/unknown.gif
If you are familiar with directory indexing, you might be able to figure out what the settings in this section are used for. Most Web servers have the capability to show you a file directory when a default document is not found. This capability has
become a common alternative to an FTP server. If FancyIndexing is turned off, and you access a folder that doesn't have a default document, the server generates a display like that shown in Figure 37.1. If you turn on FancyIndexing, you see a display similar to that in Figure 37.2. Another change you can make is to enable IconsAreLinks so that the icons that are shown in these server-generated listings (see Figure
37.3) are links to the files as well as the filenames.
Figure 37.1. When the FancyIndexing directive in the srm.cnf file is set to off, a
simple directory listing is automatically generated.
Figure 37.2. When the FancyIndexing directive in the srm.cnf file is set to on, a
fancy directory listing is generated.
Figure 37.3. When you also set the IconsAreLinks directive in the srm.cnf file to on, the fancy directory listing adds the icons as file links in addition to the filenames.
You could also create custom icons to use in place of the default icons to represent the types of files you have in these directories. These icons are specified using an AddIcon directive as in the following line:
AddIcon /icons/text.gif .html .htm .txt .ini
Note that you specify an icon to represent a specific file extension and that you can have a single icon represent multiple file types. If you are going to use this feature a lot and plan on creating multiple icons for different file types, use the
default icons as samples so that your icons are the same size. Having icons of the same size provides a uniform display.
A Web server is essentially a file pump. It sends a file to the client when requested. This file can be any type of file; the server doesn't care. Without the existence of MIME types, a Web server and client would have a hard time deciding the content
of files. MIME types define the content of files so that the Web server and client can communicate consistently. Listing 37.4 is a partial listing of the mime.typ file that ships with FrontPage. If you need to add a content
type to your Web, you add a line to this file.
Listing 37.4. Partial listing of the mime.typ file.
text/html html htm text/plain txt application/octet-stream bin exe application/oda oda application/pdf pdf application/postscript ai eps ps audio/basic au snd audio/x-aiff aif aiff aifc audio/wav wav image/gif gif image/ief ief image/jpeg jpeg jpg jpe image/tiff tiff tif application/zip zip # Microsoft types application/msword doc dot application/ms-access mdb application/ms-excel xls application/ms-powerpoint ppt application/ms-project mpp application/ms-publisher pub application/ms-schedule scd
This example shows several common file types that you are probably familiar with. MIME types are listed as type/subtype, and the most common types are text, application, and audio. When the server gets a request for a specific URL, it parses the URL,
and if the request resolves to one of the MIME types file, the server sends a Content header to the client defining the data that will follow. The content is then sent to the client, who knows what kind of data to expect.
Remember that undefined MIME types should not be arbitrarily assigned. The MIME RFC1521 specifically requires that undefined types be preceded with an x- to signify the type. If you have an application called myapp that creates .myf files that are currently undefined, you need to use a MIME type similar to application/x-myfile myf to specify that the content type is not currently
accepted as a standard MIME type.
TIP
For more information n MIME types, check out the hypertext version of RFC1521 at the following URL:
The access.cnf file controls who can access all the files on the server. You can use the contents of this file to restrict access to individual directories on your server. You can restrict access based on host name or IP
addresses so that only clients from certain locations can access your content.
Usually, the settings in this file should only be changed if you want to institute server-wide access restrictions. If you want to restrict access to individual directories, you can use #htaccess.ctl files, which you might
have noticed earlier in Listing 37.2. The content of these files is similar to the format used in the access.cnf file and allows a very fine granularity to the authentication that the Personal Web Server supports. Look at the
access.cnf file in Listing 37.5 to understand the format of this file.
NOTE
An alternate to editing this access control file directly is to use the Permissions dialog box accessed from the FrontPage Explorer. You'll learn more about setting permissions using the dialog box in Chapter 38, "Managing Security for the Personal Web Server."
Listing 37.5. Partial listing of the access.cnf file.
# The following access configuration establishes unrestricted access # to the server's document tree. There is no default access config, so # _something_ must be present and correct for the server to operate. # This should be changed to whatever you set ServerRoot to. <Directory e:/frontpage\ webs/server> Options Indexes </Directory> ## This should be changed to whatever you set DocumentRoot to. #<Directory e:/frontpage\ webs/content/> ## This may also be "None", "All", or "Indexes" #Options Indexes ## This controls which options the #HACCESS.CTL files in directories can ## override. Can also be "None", or any combination of "Options", "FileInfo", ## "AuthConfig", and "Limit" #AllowOverride All ## Controls who can get stuff from this server. #<Limit GET> #order allow,deny #allow from all #</Limit> #</Directory> # You may place any other directories you wish to have access # information for after this one.
To understand the format of this file, you need to understand the original NCSA HTTPD server that it is based on. The structure is based on concepts originally developed for a UNIX environment. The file is a simple sequential list of access directives.
Because the file is sequentially read when the server starts, the order of the directives in this file is important. If you want to deny unrestricted access to only single folder on your server, it is best to add that directive at the end of the access.cnf file rather than at the beginning. If you changed the above <Directory...> section in Listing 37.5 to read the following, you would lock out all accesses to your server!
<Directory e:/frontpage\ webs/server> <Limit GET> deny from all </Limit> </Directory>
If you are going to require access authentication on your server, you need to think it through before you implement it. There are generally three ways of thinking when it comes to access restrictions for a site. One is the wide open "allow
all" approach. Any and all accesses are allowed. The opposite is what you just read with a significant change. The change is to limit access to everyone except certain people. Instead of totally closing the site, you can open the site to
certain host names using a format such as this:
<Directory e:/frontpage\ webs/server> <Limit GET> order deny, allow deny from all allow from *.ingr.com </Limit> </Directory>
Remember that the file is read sequentially. Here, you've told the server to deny everybody first then allow those from any host name that has the string ".ingr.com" in the host name. This results in everyone
except those from the ingr.com domain being denied access to this server. If you reverse the directives in the order deny, allow line to read order allow, deny instead,
the file is processed in such a manner that the deny from all is the last directive, and again, no access is allowed.
The third way that access restrictions are usually used is kind of a hybrid approach. You start with a wide-open server and add access restrictions on a single directory basis using #htaccess.ctl files. If you are not
careful, this scheme can become very difficult to keep track of. You might intend to restrict access to a specific subfolder, and place the #htaccess.ctl file in the wrong location and therefore lock out a section of the server
that you weren't intending. The default #htaccess.ctl file is shown in Listing 37.6.
Listing 37.6. Listing of the default #htaccess.ctl file.
# -FrontPage- IndexIgnore #haccess.ctl */.??* *~ *# */HEADER* */README* */_vti* <Limit GET> order deny,allow deny from all allow from all </Limit> <Limit POST PUT> order deny,allow deny from all </Limit> AuthName default_realm AuthUserFile e:/frontpage\ webs/content/_vti_pvt/service.pwd AuthGroupFile e:/frontpage\ webs/content/_vti_pvt/service.grp
The #htaccess.ctl file is a very powerful tool. As you can see from this listing, you can put any directives in this file to modify the standard settings of the server. Because configuration files are read sequentially,
settings in this file are loaded when an attempt is made to get a file from the folder that this file resides in.
You can place a copy of this file in any folder to restrict access on a folder and subfolder level. I mentioned that you could also use this file to add or change MIME types on the fly in a given folder. If you want to serve self-extracting archive
files from a certain folder, you might need to change the MIME type from the usual application/octet-stream to something such as application/x-sfx-archive so that the Internet Explorer offers the
File | Save As dialog for files of this unknown type. To change a MIME type on the fly like this, you need to place in the folder where you want to change the defaults an #htaccess.ctl file with the single line:
AddType application/x-sfx-archive exe
Then, any time a client clicks a link in this folder with an .exe file extension, the server sends the file with a content type of application/x-sfx-archive.
As a Webmaster, you have a number of issues to contend with. In addition to creating new webs under your root web, you have to work with users. You have to create user accounts and enable whatever privileges you want to grant them. You're also
responsible for helping other people when they're having problems with their Web pages. Many UNIX Web servers have built-in facilities, through UNIX itself, to help you handle these tasks. Because FrontPage can run on Windows 95, you must program these
capabilities into the Personal Web Server.
You can do most of the day-to-day Webmaster activities from the FrontPage Explorer. Most of the time, you want to change individual Webs, not the entire server. The only time you should access the Internet Services Administrator program is when you're
affecting the entire Web site by doing such things as changing authentication procedures or logging file access.
You can define administrators that manage individual webs or define another Web site Webmaster, such as yourself. Administrators have other abilities in addition to being able to create Web pages for their particular web. For example, an administrator
can manage and verify links every page in their Web calls (see "Managing and Verifying Links," later in this chapter). Administrators can also determine whether they want to make their particular webs password-protected.
Along with such routine abilities, each administrator can create accounts. These can be accounts for other administrators or Web authors. A Web author is someone who has access to FrontPage, and his sole responsibility is to create Web pages. These
accounts enable people with access to FrontPage to focus on their tasks. The Webmaster can deal with issues that relate to the entire web, such as creating new webs. The administrators for each web can watch over the content and integrity of their web.
Finally, authors focus on creating content for the webs they have access to. Chapter 38, "Managing Security for the Personal Web Server," talks about creating administrator and author accounts.
Sometimes you might want to run the Personal Web Server from the command line. You might need to do this when you're logged in from a remote machine onto a Windows NT computer. Perhaps you want to set up a batch file that maintains a Web server.
Whatever the case may be, you need to manage the Personal Web Server from the command line. You have to start the FrontPage Personal Web Server Administrator program (\Microsoft FrontPage\bin\fpsrvadm.exe) with a set of command-line options. Table 37.1 gives you a complete list of the available options, their arguments, and their functions.
Switch | Parameter | Function |
-o, -operation | operation_type (install, upgrade, uninstall, check, recalc, enable, disable, security, putfile, or recalcfile) | The specified option is performed. |
-p, -port | port_number | The port_number indicates what port number is to be used for the specified operation. |
-w, -web | webname | This option specifies the name of the Web. To specify the <Root Web>, use "". |
-r, -root | front_page_root_dir | This option specifies the directory where the FrontPage extensions are installed. |
-t, -type | server_type (ncsa, ncsa-manual-restart, apache, apache-manual-restart, cern, cern-manual-restart, netscape, netscape-manual-restart, or omi) | This option specifies the server type. |
-s, -servconf | server_config_file | This option is the filename of the server configuration file. By default, the server configuration file is located under the directory where the server is installed. |
-m, -multihost | hostname | This option is the host name for the multihosting server configuration. |
-u, -username | username | This option is the administrator's username. This option is required in install and security operations. |
-pw, -password | password | This option is the administrator's password. This option is required in install and security operations. |
-i, -ipaddress | internet_address | This option defines the allowable Internet addresses for a Web administrator. This option follows the standard four-part IP numbering scheme. |
-d, -destination | destination_URL | This option specifies the destination URL for a document specified by the -w machine. |
-f, -filename | filename | This option is the full path name for a file on the Web server. |
Some examples might help you understand how to use these command-line options. If you want to create the new web Corporate for an existing
<Root Web> that's running on port 80, you type the following:
fpsrvadm -o install -p 80 -w Corporate
To create an administrator for this new web, type the following line:
fpsrvadm -o security -p 80 -u Corpadm -pw Corpadm -w Corporate
Eventually, after each of your webs has been updated and changed numerous times, you'll have broken links. Fixing these links can be a rather daunting task for anybody, especially on large sites. Before FrontPage, there was no easy way to make sure
that links in an entire Web site were valid. The best way that a Webmaster could check the links was to follow them by hand. A less tedious method of checking the validity of your links was to wait until someone complained and then fix the broken link.
Fortunately, FrontPage makes link management much easier.
FrontPage can automatically check and verify each link in an entire Web. To use this feature, you must load a particular web as the Web's administrator or the site's Webmaster. Next, select Tools | Verify Hyperlinks to display the Verify Hyperlinks
dialog box (see Figure 37.4). This dialog box has a complete list of all links that point outside the current web. Even links to webs in another part of the same Web site are considered an outside link. You can use the scroll bar at the bottom of the
dialog box to see more information about a particular link.
Figure 37.4. FrontPage gives you a list of all the links that it's going to verify.
To have FrontPage check and verify the links, click the Verify button. As it's checking links, FrontPage updates each entry it has checked. You can stop the verification process at any time by clicking the Stop button. To resume a stopped verification
procedure, click the Resume button.
By default, any link that FrontPage hasn't been able to verify as valid or invalid has a yellow dot and a question mark next to it. This mark indicates that the status of the link is uncertain and should be checked. After a link has been verified, a
green dot and the word OK show up next to its entry. Any links that can't be verified because they don't exist or the network connection times out have a red dot and the word Broken next to their entries. Figure 37.5 gives you an example of
three links and their status. You can modify a particular link by selecting it and clicking the Edit Link button. Similarly, you can modify the page with the link by highlighting the link and clicking Edit Page. You can add a broken link to your To Do list
by selecting it and clicking Add Task.
Figure 37.5. As the links are verified, FrontPage updates the status of each link.
Because FrontPage allows multiple authors to work on multiple links, you might need to check out the links from time to time. FrontPage's recalculate link feature updates all the views for the currently selected web. What this feature enables you to do
is see the changes that another author has recently put in.
The recalculate link feature also re-creates all WebBots being used in the current web. If that weren't enough, the recalculate link feature also updates the text index that the Search WebBot uses. Because the recalculate link feature does so many
things, it can take quite a long time to finish, especially for large webs. When you're in the FrontPage Explorer and select Tools | Recalculate Hyperlinks, you're asked to confirm the procedure (see Figure 37.6).
Figure 37.6. Because recalculating all the links in a web can take a while, FrontPage wants to make sure you want to proceed.
The Internet Services Administrator is a terrific tool that makes the life of Webmasters easier and less frustrating. Because this tool is designed to be used both locally and remotely, the developers created it as a Web-based application that can be
directly access via a browser.
Anyone currently logged in who has administrator permissions can run the Internet Services Administrator. To access the Internet Services Administrator on a local machine, perform the following:
On the local system, you can use the Internet Services Administrator to administer your web, FTP, and user services.
Before the Internet Services Administrator can be accessed from a remote host, you must configure your system for remote access. The first step is to set the Passwords property of the Control Panel. On most Windows 95 systems, the Control Panel is a
folder within the My Computer folder. When you open the Control Panel by double-clicking it, you see the icon for the Password property.
In the Passwords Properties dialog box shown in Figure 37.7, select the checkbox labeled Enable Remote Administration of This Server. Then click the Add button. You can add administrators by username or group. Each user and group registered using the
Local User Administration option of the Internet Services Administrator has an entry in this dialog box. In the example shown in Figure 37.8, the three entries are The World, Test, and Wrstane.
Figure 37.7. Use the Passwords Properties dialog box to enable remote administration.
Figure 37.8. Choose administrators by username or group.
The World is a global entry that allows all users to remotely access and administer the server. Allowing global access to your server is a poor security practice and a catastrophe waiting to happen. Only within a strictly controlled intranet should you
ever even consider giving global access.
You can tell the Test entry is a group entry because of the icon depicting two people. If you add this entry to the list, all users in the group can administer the server remotely.
TIP
In a large networked environment where you have many administrators, you probably want to create a group called RemoteAdmin using the Local User Administration facilities of the Internet Services Administration and then give this group access to the server via the Passwords Properties dialog box. In this way, you can easily add to or delete from the list of administrators with remote access using the Internet Services Administrator without accessing the Passwords Properties dialog box. For more information on creating users and groups, see Chapter 38, "Managing Security for the Personal Web Server."
You can tell the Wrstane entry is a user entry because of the icon depicting a single person. If you add this entry to the list, the user with the username Wrstane can access the server remotely.
To grant remote access to anyone listed in the Choose Administrators dialog box, select the entry by clicking it and then click the Add button. Repeat this process to add other users and groups. When you are finished, click the OK button.
Once the server is configured for remote access, you can open the Internet Services Administrator on a remote machine by doing the following:
For security reasons, you are not allowed to access user services remotely. On a remote system, you can use the Internet Services Administrator to administer only Web and FTP services.
When you start the Internet Services Administrator, you see a startup page similar to the one shown in Figure 37.9. From this page, you can access Personal Web Server services and related resources. Services you can administer include Web, FTP, and
user services. Resources you can access are external resources located on Microsoft's Web site.
Figure 37.9. Quick access to services and resources.
NOTE
You can add or edit the list of resources by accessing the Internet Services Administrator's startup page in the FrontPage Editor. Although it is a great idea to put additional resources at your administrator's fingertips, you should not alter the entries for the Personal Web Server services.
Administering your Web services with the Internet Service Administrator is fairly easy. To get started, click the key words WWW Administration from the startup page shown in Figure 37.9. The WWW administration page has
three tabs: Service, Directories, and Logging. You use these tabs to change and update your Web services. When you make changes in the WWW Administrator, be sure to click the OK button so your changes take effect.
As shown in Figure 37.10, the Service tab of the WWW Administrator allows you to configure basic service options for Connection Timeout, Maximum Connections, and Password Authentication.
Figure 37.10. Working with WWW services.
In the Connection Timeout field, you can enter the amount of time the server waits to time out network connections. This timeout value affects all network operations that send and receive data. It is also the maximum time for a CGI script to finish
executing and respond. The default is 10 minutes (600 seconds).
You enter your new timeout value in seconds. Generally, you should not change the default value unless you notice performance problems. On a slow network with frequent timeouts, you might want to increase the timeout value. When you have problems with
the execution of scripts or users complaining of long delays, you might want to decrease the timeout value.
You use the Maximum Connections field to set the maximum number of simultaneous connections to the server. On a slow network, you can improve response times by decreasing the allowable number of connections. However, keep in mind that there is a
trade-off between performance and denial of service. By decreasing the maximum allowable connections, you provide more bandwidth to fewer users. On a fast network, you can let more users access the server simultaneously by increasing the maximum number of
connections.
With password authentication, you can control access to your Web server. By allowing anonymous connections to the server, you allow anyone to access Web pages at your site. By selecting Basic password authentication, you control access to secure areas
of your Web site. You can combine anonymous connections with access control. You can also require all users to authenticate themselves by deselecting the Allow anonymous connections option.
With Basic authentication, username and password information is not encrypted during transmission. To provide stricter authentication procedures for secure folders, you can use the Windows NT challenge/response authentication, which ensures username
and password information is encrypted during transmission. The downside to the Windows NT challenge/response authentication is that it has limited support. The only browser to support it is the Internet Explorer version 3.0 or later.
You can enable both Basic and Windows NT challenge/response authentication. This allows users whose browser supports the more strict Windows NT challenge/response authentication to use it and requires that other browsers use at least Basic
authentication.
Using the Directories tab of the WWW Administrator, you can determine how the Web server uses directories (see Figure 37.11). Five directories are configured for use with Web services when you install the Personal Web Server. These directories and
their uses are summarized in Table 37.2.
Figure 37.11. Working with Web directories.
Directory | Alias | Purpose |
C:\WebShare\WWWRoot | <Home> | The home root directory where all Web files are stored. |
C:\Program Files\WebSvr\Docs | /DOCS | Directory for documentation. |
C:\Program Files\WebSvr\HTMLA | /HTMLA | The main directory for the Internet Services Administrator. |
C:\Program Files\WebSvr\HTMLAScr | /HTMLASCRIPTS | Directory containing scripts used by the Internet Services Administrator. |
C:\Program Files\WebSvr\Scripts | /SCRIPTS | Directory where FrontPage stores your scripts and where you can store your scripts. |
Directory aliases allow you to easily reference server directories in your page URLs. Instead of referencing C:\Program
Files\WebSvr\Docs\admin.htm, you simply reference /DOCS/admin.htm.
Using the Add feature, you can alias additional directories on your file system. This gives you control over where Web-related files are stored. Although the WWW Administrator gives you the option of deleting any of the five original directories, you
generally should not do so. Instead, I recommend that you only delete directories that you have personally configured.
Other options on this page allow you to enable and name the default document for server directories. Enabling a default document for directories is a good idea, especially because it allows you to use and users to reference shorter URLs. With default
document handling enabled, you don't have to type the full URL to the index page.
Although it is a good idea to place a default document in all the directories you plan to use with your Web server, you can also allow directory browsing. When you enter the path to a directory without a default document, the directory browsing feature
tells the server to display a list of all files and subdirectories in the directory. Directory browsing works well in open environments. However, you should not enable directory browsing if you have files you don't want others to see without taking
precautions. One of those precautions is to move private files to a restricted access directory.
Logging allows you to track who accessed what files. As you can see from Figure 37.12, the Internet Services Administrator provides fair control over logging file access. When security is a consideration, you should create logs and regularly check
them. Beyond security considerations, logs are also useful in tracking how long users visit your site, how many hits you get, and where users visit from.
Figure 37.12. Creating logs to track file access.
A sample log is shown in Listing 37.7. If you examine this listing, you can break the log into comma-separated fields. The first and seventh field tell you the source and destination IP address. The third and fourth field tell you the date and time of
the access. The next to last field tells you the file accessed.
Listing 37.7. A sample log file.
207.147.141.36, -, 10/5/96, 13:02:46, W3SVC, VIRTUAL_PRESS, 207.147.141.36, ¬725, 358, 72, 304, 0, GET, /htmla/htmla.htm, -, 207.147.141.36, -, 10/5/96, 13:02:50, W3SVC, VIRTUAL_PRESS, 207.147.141.36, ¬370, 417, 72, 304, 0, GET, /htmla/spec1.gif, -, 207.147.141.36, -, 10/5/96, 13:02:51, W3SVC, VIRTUAL_PRESS, 207.147.141.36, ¬362, 418, 72, 304, 0, GET, /htmla/iis2_t.gif, -, 207.147.141.36, -, 10/5/96, 13:02:52, W3SVC, VIRTUAL_PRESS, 207.147.141.36, ¬343, 414, 72, 304, 0, GET, /htmla/www.gif, -, 207.147.141.36, -, 10/5/96, 13:02:52, W3SVC, VIRTUAL_PRESS, 207.147.141.36, ¬345, 414, 72, 304, 0, GET, /htmla/ftp.gif, -, 207.147.141.36, -, 10/5/96, 13:02:52, W3SVC, VIRTUAL_PRESS, 207.147.141.36, ¬202, 419, 72, 304, 0, GET, /htmla/world_t.gif, -, 207.147.141.36, -, 10/5/96, 13:02:52, W3SVC, VIRTUAL_PRESS, 207.147.141.36, ¬242, 416, 72, 304, 0, GET, /htmla/bolt.gif, -,
When you install the Personal Web Server, the server is configured to automatically create a log file in the C:\Windows directory. Because this is not a really good place to keep log files for a server, you should consider
creating a directory for your server logs. A good directory is C:\Program Files\WebSvr\Logs.
The Personal Web Server creates logs with a .log extension. Log files are named using a date stamp that matches how you create logs. You can create logs daily, weekly, monthly, or when the size of the log reaches a specific
byte size. You should balance your logging style based on your need to check logs and the activity level of the site. If you rarely want to check logs and the activity level at your site is less than a few thousands hits a day, you might want to create
logs monthly. On a busier site or if you plan to check logs regularly, you might want to create logs daily or weekly.
NOTE
Every file access on the server is logged no matter if the file is a graphic used in a page or a HTML document. This means that if a user accesses a page with ten images, eleven lines of information is entered into your log. On a busy site, logs files can quickly eat up megabytes of disk space.
Generally, you want to check both the Enable Logging and Automatically Open New Log options. This ensures that file access is logged and that a new log file is created when the specified time period has elapsed.
Administering FTP services is very similar to administering WWW services. The first step is to access the FTP area of the Internet Services Administrator. To do this, click the key words FTP Administration from the startup
page shown in Figure 37.9. The FTP administration page has four tabs: Service, Messages, Directories, and Logging. You can use these tabs to change or update your FTP services. When you make changes in the FTP Administrator, be sure to click the OK button
so your changes take effect.
The Service tab of the FTP Administrator lets you configure basic service options for your FTP server (see Figure 37.13). These options include Connection Timeout, Maximum Connections, and Access Control.
Figure 37.13. Working with FTP services.
Because FTP connections are generally made for longer duration than Web connections, the default timeout value is around 14 minutes. Although this value works fine most of the time, you might need to change this value to suit your network. File size is
the biggest problem for FTP services. Large files take a long time to transfer, especially if users download files from a dial-up connection. If users complain about disconnects during transfers, you might want to increase the timeout setting.
The Maximum Connections field sets the maximum number of simultaneous connections to the server. Because FTP connections generally require significantly more system resources than Web connections, the maximum number of allowable connections is set very
low. Generally, you rarely want to increase this value unless you have a dedicated high-performance workstation. If you see noticeable degradation of system performance when multiple users are connected via FTP, you want to seriously consider lowering the
number of allowable connections. To see how many users are currently connected via FTP, click Show Current Sessions.
You can control access to the FTP server by allowing anonymous connections, allowing only anonymous connections or allowing only authenticated connections. If you deselect both the Allow Anonymous Connections and the Allow Only Anonymous Connections
checkboxes, only users with remote access can use the FTP server.
The Messages page allows you to set three default messages seen by users who visit your FTP site: a Welcome message, an Exit message, and a Maximum Connection message.
When anyone connects to the FTP server, the first thing they see is the Welcome message. As you can from Figure 37.14, the default welcome message doesn't tell users much about your site. When you set up FTP services, one of the first things you should
do is to create a new welcome message. This message should tell users what site they've logged into, who runs the site, how to contact the administrator, and what the basic rules are and possibly give them a brief rundown of directories and what those
directories contain.
Figure 37.14. Creating messages for FTP services.
The Exit message is the message displayed to users who properly terminate a session with your server. This message is not as important as the welcome message and the default is probably just fine.
On the other hand, the Maximum Connection message is very important. This message tells users why they can't log in when the number of maximum connections is exceeded. Ideally, this message should tell users that the maximum connection limit has been
reached and that they should try back later. You might also want to provide users with an alternate server to visit.
Using the Directories tab of the FTP Administrator, you can determine how the FTP server uses directories (see Figure 37.15). When you install the Personal Web Server, only one directory called the FTP home root is defined. When users log in to your
FTP server, the FTP home root is the directory they enter. Using the interface provided, you can add additional directories, edit existing directory paths, or delete directories. Just as Web directories are aliases, so are FTP directories.
Figure 37.15. Working with FTP directories.
This page also allows you to select the style of the directory listing. By default, the directory listing style is MS-DOS. You can change this to UNIX by selecting the appropriate radio button.
As you can see from Figure 37.16, logging accesses to FTP files works exactly the same as the logging Web file accesses. You should refer to the section "Configuring WWW Logging" for details on handling logs. Note also that the server is
configured to automatically create a log file in the C:\Windows directory. Once again, this is not a really good place to keep log files for a server. You should consider creating a directory for your server logs. A good
directory is C:\Program Files\FTPSvr\Logs.
Figure 37.16. Tracking access to files via FTP.
Just because you have a Web server doesn't mean you'll necessarily know what to do with it. Most of the fine-tuning aspects of the Personal Web Server are buried under configuration files. If you've worked on other Web servers, these
files are probably very similar.
There's a lot more to being a Webmaster than simply configuring a Web server. As much fun as that might be, you, the Webmaster, has to make sure that the server continues to run fine. To this end, FrontPage gives you a number of useful tools to help
you keep your Web server working. You can verify hypertext links, take a look at any given web at any time, and run the server from the command line. The command-line options let you run the server remotely or through a series of batch files.