Using Netscape Enterprise Server 3.0

his document is a supplement to the Netscape Enterprise Server Administrator's Guide. The following sections are discussed in this document:

Controlling access to your server

You can restrict access to your entire server or any part of it. You can specify that only certain people can see certain files, or that everyone except certain hosts can see certain files. Note that this access restriction applies only to files and directories that your server can send to a client. It does not have anything to do with allowing people to administer your server.

For example, suppose you keep confidential employee records on your server, and you want to allow only the Personnel department to see them. You could keep all these records in a directory called records and specify that only a group of people you call Personnel can see the files in that directory. When users try to access a restricted document, they are prompted for a name and password. If they enter a name and password that correspond to a name-password pair in your private list of people in Personnel, they are allowed to see the requested document. Otherwise, they are told they didn't enter a valid name or password.

If your server has SSL enabled, the user's name and password are sent encrypted. Otherwise, names and passwords are sent openly, and can be intercepted.

For this beta version of Netscape Enterprise Server 3.0, you first need to choose where information about users and groups should exist. You can choose one of the following methods:

Using existing 2.0 user databases

If you do not need to modify existing 2.0 user database information, you can continue to use these databases and Server Manager forms to restrict access to your 3.0 server.

To use existing a 2.0 user database, copy the 2.0 user database to the authdb directory in your 3.0 server root directory. Also copy your ACL file(s) to the httpacl directory in your 3.0 server root directory. Make sure that the ACLFile directive reflects your ACL file's name. By default, the ACL file's name in magnus.conf will be generated.https-[server_name].acl. If you created several ACL files, make sure you add ACLFile directives to include your other ACL files. Now you can use the Server Manager Restrict Access form to restrict access to your server's resources.

You can use the following forms to manage your 2.0 user databases and restrict access to your server resources:

Use these forms as you did for 2.0. For context-sensitive information, click Help on any of these forms.

Converting existing 2.0 user databases

If you created user databases for access control using Netscape Enterprise Server 2.0 and want to be able to add new users and groups to the existing databases, you must convert them to Enterprise Server 3.0 format.

To convert a user database:

  1. Copy your 2.0 database to the authdb directory in the Enterprise Server 3.0 server root directory.
  2. Choose Access Control|Convert 2.0 Database.
  3. Choose the 2.0 database you want to convert from the drop-down list.
  4. Click OK.
  5. From the command prompt, go to [ServerRoot]/authdb.
  6. Type the following:
    ./importdb userdb_name
    
Now that you've converted your existing user database, you need to choose whether you want to continue using your 2.0 ACL file, or convert it to the 3.0 format. If you choose to continue using your 2.0 ACL file, copy the file to the httpacl directory in your server root directory. Make sure that the ACLFile directive reflects your ACL file's name. By default, the ACL file's name in magnus.conf will be generated.https-[server_name].acl. If you created several ACL files, make sure you add ACLFile directives to include your other ACL files. Now you can use the Server Manager Restrict Access form to restrict access to your server's resources.

If you continue using your 2.0 ACL file, you can continue using the following Server Manager forms:

Use these forms as you did for 2.0. For context-sensitive information, click Help on any of these forms.

To convert a 2.0 ACL file, see the following section, "Converting 2.0 ACL files."

Converting 2.0 ACL files

Currently, there are no forms that allow you to edit a 3.0 ACL file; you must edit the file by using a text editor after the conversion.

To convert 2.0 ACL files:

  1. Choose Access Control|Convert 2.0 ACL File.
  2. Click OK.
  3. Restart the web server. (From the Server Manager, choose System Settings|On/Off; then click Server On to restart the web server.)
To make changes to your ACL file, you must edit the file using a text editor. You must use the 3.0 ACL syntax when making additions to the file. After editing the ACL file, you need to edit your obj.conf file in order to bind the access control restrictions to your server's resources. An example of what you might add to your obj.conf file if you wanted to restrict access to a directory called test in your primary document root directory follows:

<Object ppath="/usr/ns-homeC:/Netscape/Server/docs/test/*">
PathCheck fn="check-acl" acl="testacl"
</Object>
In the previous example, the first line is the object that states which server resource you want to restrict access to. The second line is the PathCheck directive that uses the check-acl function, which binds the ACL file to the object in which the directive appears; the name of the ACL file is testacl.

Using LDAP management to create users and groups

Netscape Enterprise Server 3.0 allows you to manage the users and groups that access your server. User and group information can be stored in a local database that mimics a directory service, or you can configure the administration server to connect to an LDAP server to provide directory service.

Information about managing users and groups is in "Managing users and groups"

ACL syntax

An ACL file contains a list of ACLs, which must adhere to proper syntax. The following is an example of an ACL using 3.0 syntax:

version 3.0;
acl sampleacl;
authenticate (user, group){
     method = ssl;
};
allow (read) user=all;
allow (write) group="*";

General syntax items

Input strings can contain the following characters:

If you use any other characters, you need to use quotation marks ("") around the characters.

A single statement can be placed on its own line and be terminated with a semicolon. Multiple statements are places within braces--{ }. A list of items must be separated by commas and enclosed in quotation marks ("").

Add comments to the ACL file by using starting the comment line with #. Any text in the comment line is ignored.

ACL elements

ACLs must begin the following statement:

version 3.0;
ACLs must be named. The ACL must include the following line:

acl acl_name;
Authentication statements
ACLs can specify which authentication method to be used. One method is the basic method, which requires users to provide a username and password before accessing a restricted server area. You can also use SSL authentication.

For example, the following authentication statement specifies basic authentication for users:

authenticate (user) { 
     method = basic;
};
The following example uses SSL as the authentication method for users and groups:

authenticate (user, group) { 
     method = ssl;
};
Authorization statements
Authorization statements specify who is allowed or denied access to a server resource.

Use the following syntax when writing authorization statements:

allow|deny [absolute] (right[,right...]) attribute qualifier expression;
allow|deny--Use allow to allow users and groups access; use deny to deny users and groups access.

absolute--The result of this statement cannot be overridden by any succeeding statment. ACL evaluation ends, and the allow or deny is applied.

You can restrict access to your server by time of day (based on the local time on the server) by using the timeofday attribute qualifier. For example, you can use the timeofday attribute qualifier to restrict access to certain users during specific hours.

Use military-style, 24-hour time to specify times (for example, use 0400 to specify 4 a.m. or 2230 for 10:15 p.m.).

The following example restricts access to a group of users called guests between 8 a.m. and 4:59 pm.

allow (read)
     (group=guests) and
     (timeofday<800 or timeofday>=1700);
You can also restrict access by day of the week. Use the following three-letter abbreviations to specify days of the week: Sun, Mon, Tue, Wed Thu, Fri, and Sat.

The following example controls access for premium customers (any day, any time) and Discount customers (all day weekends and weekdays anytime except 8am-4:59pm):

allow (read) (group=discount and dayofweek=SatSun) or 
(group=discount and (dayofweek="mon,tue,wed,thu,fri" and
(timeofday<0800 or timeofday>=1700)))
or
(group=premium);

Configuring agents

Enterprise Server agents provide a unique and highly valuable service to users. Agents act as watchdogs for clients and perform a user-specified task when a specific event occurs. Agents consist of an event description and an action that the client would like the agent to perform when the event occurs. For example, a client might request an agent to notify them when a specific URL has been updated. The client could have the agent notify them by sending an email message. An event can be repeating, such as every Tuesday at 9:30 AM.

An agent is stored on the server and only requires that the client be connected to the server when the client submits the agent. After an agent is submitted, it resides on the server until it is deleted or completes the assigned task. Agents are subject to ACLs; only users that have been created in the server's access control databases can work with agents. Agents can only perform operations that the client is allowed to perform.

Agent events

Each server publishes a list of agent events that clients can use with that server. The server administrator has control over which events are published for client use. Agent events are subject to ACLs and will only allow clients with the proper permissions to see certain events. Events can be broken down into the following:

Time-related events

Time related events occur as a result of the date or time. A client may submit an agent to trigger when, for example:

Document-related events

Document related events occur when something has occurred to a document on the server. Some examples are:

Agent actions

When an event occurs that an agent is watching, the agent is triggered; that is, the agent begins to perform the specified action that it was assigned. Agent actions are restricted by ACLs and the server administrator who defines what actions are supported by the server. For example, some agent actions include:

Clients choose which actions they desire an agent to perform when an event occurs. An agent can perform multiple actions as a result of an event.

Enabling agents on the server

Only users that have been created and added to an access-control database can use agents. Use the Users&Groups button in the administration server to create users and groups. As server administrator, you must first enable and configure agents, using the Server Manager, before these users can create and manage agents.

To enable and configure agents:

  1. Choose Programs|Agent Management.
  2. Click Yes in response to "Enable Agent Services."
  3. Type the full path of the agent directory, which is where files containing information about agents are kept. The default is [server_root]/plugins/agents/db. If you want to specify a different directory, make sure you include a full path.
    Note
    If you delete or modify agent files, the agents will no longer work.

  4. Type the maximum number of agents for all users that are allowed on your server. The number you specify must be an integer.
  5. Type the maximum number of agents an individual user can have. The number you specify must be an integer.
  6. Type the maximum number of document agents allowed. The number you specify must be an integer.
  7. Type the name of your outgoing mail server.
  8. Click OK.
  9. Click Save and apply to apply your changes.
After you have completed these steps, users can create and manage agents by accessing the agent home page (http://[server_name]/Agents). For example, if your server's name is server1, then clients would access your agent home page by using http://server1/Agents/ as the URL.

More information on how to use agents is in the"User's Guide", which is located in your server root directory, in the /bin/https/admin/html/manual/beta directory.

Configuring web publishing

Netscape Web Publishing System includes document management controls to allow you as a server administrator and end users who have proper permissions to:

Netscape Web Publishing System manages all of the version numbers, access controls, links, and more for each document. The document management capabilities of web publishing give client-based web users the ability to easily publish and manage web documents by using the web publishing control panel.

The following features are also a part of what Netscape Web Publishing System offers:

During installation, all the necessary web publishing files are installed in the primary document directory. Users access the web publishing control panel, which is a Java applet, in order to manage their files and publish them to the web server. Users who want to publish content to the web server need a Netscape Navigator plug-in in order to publish their local files to the server. As a starting point, users can access a web publishing home page on your web server to access the web publishing control panel and install the plug-in. To access the web publishing home page, type the following:

http://[server_name]/WebPub/WPIntro.html/
For example, if your web server's name is www.acmecorp.com, you'd type http://www.acmecorp.com/WebPub/WPIntro.html/ to access the web publishing home page.

More information on how to use web publishing is in the"User's Guide", which is located in your server root directory, in the /bin/https/admin/html/manual/beta directory.

Setting up version control

Use the version control feature in Netscape Enterprise Server to provide check-in, and check-out capabilities to groups of people working on the same set documents. As a default, version control is enabled for your server. To disable version control, delete or comment out references to ContentMgr in obj.conf, which is in [server_root]/https-[server_name]/config.

Only users and groups that have been created using the Users&Groups forms in the administration server will have access to files placed under version control. For more information about creating users and groups, see "Configuring the administration server", which is located in your server root directory, in the /bin/https/admin/html/manual/beta directory.

To change the version control archive directory:

  1. Choose Web Publishing|Version Control.
  2. Type the full path for the archive directory. The default is [server_root]/plugins/content_mgr/archive. All archives are placed in this directory using the complete path; for example, the exact directory structure for a file is mimicked in the archive directory.
  3. Click OK.
More information on how to use agents is in the"User's Guide", which is located in your server root directory, in the /bin/https/admin/html/manual/beta directory.

Adding metadata properties

As server administrator, you can add properties for metadata.

To add properties:

  1. Choose Web Publishing|Add Attributes.
  2. Type the name for the property. The property name cannot exceed 128 characters and cannot contain spaces.
  3. Type the default value for the property.
  4. Choose the type for the property you are adding. You can choose one of the following:
  5. Choose whether the property should be indexed for searching. Note that for this beta, every property is indexed.
  6. Choose whether the property will be read-only.
  7. Choose whether this property will be visible to the user.
  8. Choose the object type, which specifies whether the property refers to a directory or a file. Note that this feature is not enabled in this beta.
  9. Choose whether to extract metatags.
  10. Click OK.

Managing properties

After you have added metadata properties, you can list all the metadata properties that have been created.

To list all the metadata properties that have been created, choose Web Publishing|Manage Attributes. A list of the properties appears, including property name, type, default value, key type, read-only status, visibility status, and metatag extraction status.

Creating a text search interface

As with Netscape Enterprise Server 2.0, you can create and maintain an end-user text search interface that allows clients to search your Web site. Included with Netscape Enterprise Server are the components you can work with to customize a text search interface that's tailored to your user community's needs.

The following outlines what you need to do in order to create a text search interface:

Creating a new collection

Before creating a collection, you need to create the URL mapping for the directory that contains the documents you want to index. From the Server Manager, choose Content Mgmt|Additional Document Directories to create URL mappings. To create a new collection:

  1. Choose Index Documents|New Collection.
  2. Type a name for the collection. Use alphanumeric characters; the name should contain no spaces and follow the standard file-naming conventions for your operating system. The collection name will be used for collection maintenance and is what end users see when they use the text search interface. Make your collection names as descriptive and relevant to its files as possible.

  3. Type a description for the collection.
  4. Type the absolute path of the directory that contains the original files you want to index for the collection. The search engine will go to this directory for searching and retrieval.
    Caution!
    If you have sensitive documents in the collection directory that are protected by access control, you should store them in another directory. Although protected documents can be searched, and any matches in them to user-specified criteria will be listed in the search results, users cannot access any protected documents unless they enter a valid user name and password.

  5. Select whether to include the subdirectories for the directory that will be indexed.
  6. Select the type of file the collection will contain (ASCII or HTML). A collection can only contain one type of file.
  7. Type the name of a file (or wildcards, such as *.html) or a directory containing the files you want to add to the collection. If you enter a directory, make sure that it is relative to the directory you entered in Step 4.
  8. Click OK.
When you create a collection, URL mappings for the search CGI binaries are automatically added to the obj.conf file. If you install another server in an existing server root directory, the new server can also edit and manage any existing collections created with the original server. The following is added to the server's obj.conf file during installation.

Add the following lines to the default object in your obj.conf file:

NameTrans from="/ns-search" fn="search-find"
NameTrans from="/search" fn="pfx2dir" dir="[ServerRoot]/plugins/search/vsearch" name="cgi"
NameTrans from="/ui" fn="pfx2dir" dir="[ServerRoot]/plugins/search/ui"
Service fn="search-service"cgi-path="[ServerRoot]/plugins/search/vsearch/iareco rd.exe" type="magnus-internal/search"
Note
When adding the previous lines to your obj.conf file, substitute [ServerRoot] with your server root directory. Place the NameTrans directives with the existing NameTrans directives; place the Service directive with the existing Service directives.

Managing collections

Periodically, you'll need to manage collections. You can perform the following collection management tasks:

To perform any of the previous collection management tasks:

  1. Choose Index Documents|Manage Collection.
  2. Select the collection you want to manage from the drop-down list. Information about the collection you selected appears.

  3. To optimize your collection, click Optimize. To remove your collection, click Remove.

Configuring search result parameters

As server administrator, you can set the default parameters users see when they get search results.

To configure search parameters:

  1. Choose Index Documents|Search Configuration.
  2. Type the default maximum number of items in the result set clients will see after performing a search. The default is 30. For example, if you type 20 as the value, users would see a default maximum of 20 possible search matches (if there are that many).
  3. Type the maximum number of items in a result set. The default is 2000. For example, if you type 500 as the value, users would only be able to see a maximum of 500 search matches.
  4. Type the format of the date/time string in Posix format. The format you type is what people using the search engine see when viewing their search results. For example, typing %A, %B %d, %Y %H:%M produces a format like this: Thursday, December 5, 1996 14:24.
  5. Type a default HTML title for the document if the document's author has not specified a title.
  6. Choose whether you want permissions to be checked before allowing users to view a document by clicking Ignore Pathcheck Yes or No.
  7. Choose whether you want to record search-engine performance statistics. View performance statistics in the error log.
  8. Click OK.
  9. Click Save and Apply.

Modifying pattern file location for multi-collection searching

When end users search for documents on your server, they see a page listing the documents found matching the search parameters. Headers and footers on the search results page are provided by pattern files. When users search multiple collections, only one header pattern file and one footer pattern are shown. You can specify which pattern files are shown for multi-collection searching.

  1. Choose Index Documents|Search Pattern Files.
  2. Type the absolute path for the userdefs.ini file.
  3. Type the absolute path for the pattern file directory.
  4. Type the header pattern file you want shown for a multi-collection search results page. Specify the path relative to the pattern file directory specified in step 3.
  5. Type the footer pattern file you want to shown for a multi-collection search results page. Specify the path relative to the pattern file directory specified in step 3.
  6. Specify the pattern file you want shown for the search query page.
  7. Click OK.

Using text search

End users can access text search by typing http://[yourserver]/ns-search/, which takes them to the search query page.

Using the search engine, users can search collections that you've created using the Server Manager. There are two sample search forms available: simple search and advanced search. Users can use the advanced search features to narrow and refine their search criteria.

Sample simple text search

The sample simple text search form allows you to search one collection at a time for information using free text search, which has no explicit syntax; that is, you can enter blocks of text to search, and the search engine will retrieve documents with similar style or content. Results are measured by document scores; the higher the score, the more likely the document will match the specified search criteria.

Sample advanced searching

The sample advanced searching form allows users to search one or more collections simultaneously using free text (literal) or Boolean searching to refine their search criteria (using the AND, OR, and NOT operators).

To use advanced searching:

  1. In the text search window, click on the Advanced Search link.
  2. Select the collection(s) you want to search from the Subject list box.
  3. Enter a word, words, or a phrase in the Search field.
  4. Choose whether you want to perform a literal (free text) or Boolean search. A literal (free text) search will find documents most similar to what you entered in Step 3. A Boolean search allows you to use operators such as AND, OR, and NOT for exact match searching.

  5. Enter the maximum number of documents you want returned from your query. (This is optional.)
  6. Click Search.