Go to Home Page Reference Manual
  Go to Home Page
 All Products Index   CyberTeams Customers   CyberTeams Partners   How to Contact CyberTeams   About CyberTeams 
 
This manual provides directory, file and user information that will help you plan your installation of  WebSite Director Lite (WSD). You will find descriptions of each directory accessed by WSD and examples of where they are usually defined. 

During installation, the CyberTeams WebSite Director Software Installation form will prompt you for this information in the order it is provided below. An Installation Planning Form is available for you to print and use during your planning.

The Installation Guide for your specific server platform is provided on the WSD download page. After your installation is completed, WSD provides Tutorials on the following subjects: 

    • Adding and Maintaining Users
    • Directory Maintenance
    • Document Processing Overview
    • Security Environments and UNIX File Permissions 
These tutorials can be accessed from the installation guides, and by clicking Help, then Index from any WSD screen. 

This manual provides detailed information about the directories, files and user information you will be required to enter during the installation of WSD.


During installation, WSD retrieves the current Server Root and Document Root values from the web server. The installation program creates any directories that don't already exist and provides default directory names if you don't already have existing directories created. Unless you are installing WSD for a different web server than the one you are using for the installation, you should leave these configuration options at their current settings.

Note: On some web servers, the Server Root and Document Root directories will be the same. On others, the Document Root directory may be a subdirectory of the Server Root directory. 

Full Directory Paths

Installation Directory - This is the directory where WSD is/will be installed. The default is the directory from which you run the Installation program. The first part of this directory must match the Server Root directory (see below). If you elect to change the default directory name to a different directory under the Server Root directory, you must change any other reference to the default directory to the new directory name. 
 

The following instructions are specific to O'Reilly WebSite Server Mapping
    The O'Reilly WebSite server has a built-in CGI application directory - \cgi-shl\ -  under the directory in which your O'Reilly WebSite server was installed. That directory is automatically mapped to the URL Path /cgi-bin/. 
    To install WSD under the \cgi-shl\ directory, you do not need to configure an additional CGI directory. 
    To install WSD under another directory, use the following steps in the O'Reilly WebSite Server "Server Properties" application to configure that new directory as a CGI application directory. 
    1. Click the Mapping Tab 
    2. In the List Selector section, select the Standard CGI radio button 
      • To change the mapping for the /cgi-bin/ URL Path,
        • select that path in the list near the top of the window, 
        • enter a new physical directory in the Directory field and 
        • click [Replace]
      • To configure a new URL Path, 
        • enter a new path in the URL Path field, 
        • enter the physical directory in the Directory field, and 

        • click [Add]

Server Root - This is the directory where the web server (not the web documents) is installed. 

  • Unless you are installing WSD for a different web server than the one you are currently using, you should use the default directory, which is the correct value for your current web server.
  • On many ISP-based shared web servers, the Server Root directory is the same as the Document Root directory - in the public_html directory of the user's home directory.
  • Most Server Root directories will have a cgi-bin sub-directory, where most CGI scripts or programs are installed.
    • Note: Some web servers will only allow CGI scripts or programs to be run from the cgi-bin directory. If your web server is configured in such a way, you need to install WSD in or under the cgi-bin directory.
Document Root - This is the root directory where all of the server's web pages are stored. 
  • Unless you are installing WSD for a different web server than the one you are currently using, you should use the default directory, which is the correct value for your current web server.
  • On many ISP-based shared web servers, the Document Root directory is a directory called "public_html" in the user's home directory.
  • Most web servers will only allow public access to web pages in and under the Document Root directory.
    • Note: For this reason the WSD Support directory, which contains the header and button image files and help pages used in most WSD screens, must be a sub-directory of the Document Root directory.
Directories Under the Document Root Directory - The following directories are located under the directory specified in the Document Root Directory field. During installation, do not include the Document Root directory as part of the entry value for these directories. 

Working Directory - The Working Directory is the root directory of that portion of the web server documents that WSD will maintain. The directory name is used to construct URLs to access your documents. 

  • If WSD has been installed to maintain your entire web site, the Working Directory displays on WSD screens as a slash ("/" or "\", depending on the server operating environment).
  • If your WSD installation will have control of only a portion of a web site, the Working Directory will be the name of the root directory for that portion of the web site controlled by your WSD installation (for example: "/marketing").
If the directory does not already exist, it will be created. 

In constructing the URL for a web page maintained by WSD, the Working Directory name immediately follows the site URL (for example: "http://www.mycompany.com") and is in turn followed by the subdirectory(s) and filename of your document. 

For example, 

Your company's URL is: "http://www.mycompany.com" 
(and) your WSD installation maintains a subset of the site designated for "Marketing:" documents 
(and) your Working Directory: is "/marketing" 
(and) you created a document named "my_page.html" in a subdirectory named "/tv_spots" 
(then) the complete URL for your web page is: "http://www.mycompany.com/marketing/tv_spots/my_page.html"
Support Directory - This directory is the top-level directory where all of the support files used by WSD are stored. It is located under the Document Root directory, and the paths specified during installation are relative to the Document Root directory. Do not include the Document Root directory as part of the entry value for this directory. 
  • This directory should not contain any files other than the WSD support files.
  • If the directory does not already exist, it will be created by WSD.
Files under the Server Root Directory - These files are normally located under the directory specified in the Server Root Directory field (see above), and the path is assumed to be under that Server Root directory. During installation, the Server Root directory should not be included as part of the entry value for these files. 
    Note: If the path entered during installation begins with a slash, or a drive letter and colon, the path is assumed to be an absolute path. 
     
  • Access Control File - (Any web server except Netscape) This file controls user access to WSD. It should be in the same directory as the WSD executables to properly control access to WSD. If the Secure Working directory option is turned on (see below), a copy of this file will be placed in the Working Directory.
    • Servers other than the Netscape Server: usually .htaccess
    • Netscape Server: .htaccess, .nsconfig, or blank
  • Password File - This file contains the user names and passwords for users validated to use WSD.
    • Note: To prevent direct access to the file by a web browser, this file should be in or under the web server's cgi-bin directory.
  • MIME Types File - This file contains the list of valid MIME types and the associated file extensions for the web server. You can either use the default file that is included with WSD, or you can change it to point to the MIME Types file that is configured for your web server.
  • Activity Log File - This file is used to log all activity that occurs in WSD. The log entries include the following:
    • date and time of the activity
    • the username of the user who performed the activity
    • a brief description of the activity
    Note: To prevent direct access to the file by a web browser, this file should be in or under the web server's cgi-bin directory. 
User Prefix - Some installations, specifically many Internet Service Provider (ISP) installations, place the Document Root Directory under a user home directory as a method of separating access to each user's web content from that of other users. to access files in that home directory, a URL prefix (such as /~username or /username) is sometimes required at the beginning of every URL. Since WSD generates URLs to access its support files, this field should be set to any URL Prefix (without a trailing "/") neede to access documents under the User Home Directory. If no URL Prefix is needed,  this field should be left blank. 

Initial User Name and Password - This user name identifies the initial user who is validated to use WSD. This user is also given User Administration permissions to add new users, delete users, and change the passwords for all users. 

Proxy User and Password (Microsoft Internet Information Server) - If your Microsoft Internet Information Server is configured to allow anonymous access, leave these fields blank. If it is not configured to allow anonymous access, you must enter a valid Windows NT Server username and password for the Proxy User for WSD to use when logging in. 

File Permissions for new files (UNIX Only) - WSD will create new files using the following three permission settings: Owner Read or Write, Group Read or Write, Other Read or Write. New files created by WSD will be owned by the web server login userid unless a different userid is specified for WSD using CGIWrap or setuid permissions. If you want to provide other login userids (oter than the userid WSD uses) with the ability to update files outside of WSD, you must assign write permissions to the "Group" and/or "Other" categories by clicking the appropriate checkbox(es).

Secure Working Directory - If you want to control access to the Working Directory using the same Password file that will be used to control access to WSD, set this option to YES when prompted during installation. A copy of the Access Control File will be placed in the Working Directory. 
 

Section 2 - WSD Architecture

WSD is a "server-based" application that runs only on web servers. Almost any web browser, like Netscape Navigator or Microsoft Internet Explorer, may be used as the client application to access WSD. 

The entire User Interface for WSD is implemented using HTML forms and HTML pages that are dynamically generated by WSD. These forms and pages are functionally identical to application "screens" in traditional desktop applications. WSD will use some Javascript code to simplify navigation when the browser used to access WSD supports Javascript and has it enabled. 

WSD is a Common Gateway Interface (CGI) program that runs on the web server. This CGI program is short-lived. A request from the web browser (usually initiated by clicking a button) will cause the web server to start up a new copy of the CGI program. When the program is finished processing the request (usually by generating a new screen), the CGI program terminates. 

When using the CGI interface, information between application screens can only be retained by storing information as "hidden" fields in each successive screen, or by storing information in a database on the web server. WSD uses the first method to maximize application performance. 
 

 All Products Index   CyberTeams Customers   CyberTeams Partners   How to Contact CyberTeams   About CyberTeams 
Go to Home Page  
Copyright © 1997-2005 CyberTeams, Inc. All rights reserved.
Maintained with WebSite Director® by CyberTeams®.

Updated Wed, Nov 15, 2000.