Previous Page TOC Next Page



37


Personal Web Server Administration


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:


Being a Webmaster


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.

Webmaster as Web Author


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.

Webmaster as Network Administrator


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.

Combining Both Jobs


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 Support for Webmasters


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."

Configuring the 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.

Settings in the httpd.cnf File


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.

Settings in the srm.cnf File


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.

The mime.typ File


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:

http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html



The access.cnf file


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.

The Basics of Web Server Administration


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.

Administering the Personal Web Server from the Command Line


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.

Table 37.1. Personal Web Server command-line options.

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

Managing and Verifying Links


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.

Verifying Links


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.

Recalculating Links


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.

Getting Started with the Internet Services Administrator


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.

Running the Internet Services Administrator on a Local Machine


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:

  1. Double-click the Personal Web server icon on the taskbar.
  2. Access the Administration tab and click the button labeled Administration..

On the local system, you can use the Internet Services Administrator to administer your web, FTP, and user services.

Running the Internet Services Administrator on a Remote Machine


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:

  1. Entering the URL path to the home page for the Internet Services Administrator, such as http://virtual-press/htmla/htmla.htm.
  2. Authenticating yourself to the server.

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.

Working with the Internet Services Administrator


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.



WWW Administration


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.

Configuring WWW Services

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.

Configuring WWW Directories

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.

Table 37.2. WWW 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.

Configuring WWW Logging

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.

FTP Administration


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.

Configuring FTP Services

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.

Configuring FTP Messages

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.

Configuring FTP Directories

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.

Configuring FTP Logging

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.

Summary


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.

Previous Page Page Top TOC Next Page