Managing discussion groups

his chapter describes how to create and manage discussion groups and how to control user access to discussion groups.

How you access these forms depends on who you are:

• If you are the server administrator, you access the discussion group management forms from the Collabra administrative interface.

• If you are a user who has been granted the manager role to a discussion group, you access the discussion group management forms from the Communicator interface.

For purposes of the following discussions, the discussion group hierarchy is shown in Table 4.1

royal.*
royal.dev.*	royal.rec.*	royal.pets.*
royal.dev.server royal.dev.server.collabra royal.dev.server.enterprise royal.dev.server.fasttrack royal.dev.server.proxy royal.dev.client royal.dev.client.nav3 royal.dev.client.comm	royal.rec.fun royal.rec.fun.skydive royal.rec.fun.gliders royal.rec.fun.hangglide royal.rec.fun.race royal.rec.fun.race.f1 royal.rec.fun.race.f3 royal.rec.fun.race.fford royal.rec.boring royal.rec.boring.pinochle royal.rec.boring.bridge royal.rec.boring.knit	royal.pets.dogs royal.pets.dogs.malamutes royal.pets.dogs.rotties royal.pets.dogs.chihs royal.pets.cats royal.pets.cats.persians royal.pets.cats.tabbys royal.pets.cats.strays royal.pets.repts royal.pets.repts.turtles royal.pets.repts.snakes royal.pets.repts.lizards

.

Viewing information about a discussion group

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups. Type the discussion group you want to see and click OK. (All discussion groups (*) is the default.)

   From the Communicator interface, select the discussion group, then choose Edit|Manage Discussion Groups.

2. To view the discussion group hierarchy, use buttons that appear beside the discussion group:

   Plus button. If a discussion group contains other discussion groups, the discussion group name is preceded by the plus button. To view the next level of discussion groups in the discussion group hierarchy, click this button.

   Minus button. To close a discussion group hierarchy, click the minus button.

3. Select the discussion group you want to see information about, then Click General Properties.

About discussion group types. A discussion group type can be standard, categorized, or category. If the discussion group is categorized, all discussion groups within the discussion group hierarchy are categories. Categories are displayed differently in the client interface. See "Creating a discussion group" for more information about categorized discussion groups and categories.

About virtual discussion groups. A virtual discussion group contains articles that are the result of a specified search across discussion groups. If a discussion group is a virtual discussion group, you will see the following text beneath the type of discussion group: This is a virtual discussion group.

Creating a discussion group

Note: To create a discussion group, the server must be running.

New Discussion Group form

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups.

   From the Communicator interface, choose Edit|Manage Discussion Groups.

2. Select the parent discussion group, or to add a top-level discussion group, select the root-level discussion group, then click New.

   For example, to add a lower-level discussion group to the royal.pets.dogs hierarchy, click royal.pets.dogs and then click New.

3. In the Name field, type the name of the discussion group. This name must follow the Internet conventions for newsgroup names. The name cannot include spaces or most special characters. The name cannot include uppercase letters or numbers unless the server administrator specifically configures the server to allow for them. See "Naming your discussion groups" for more information.

4. In the Display Name field, type a descriptive name, which can include spaces, lowercase and uppercase letters, special characters, and so on. The display name is used in the client presentation.

5. In the Description field, type a description of the discussion group. (This field is optional.)

6. Specify the type of discussion group you want: categorized or standard.

   The categorized attribute affects the presentation of the discussion group within the client user interface. A categorized discussion group provides a 3-paned interface in which the user can view:

   • The entire discussion group hierarchy

   • All of the articles within a particular discussion group

   • The text of a particular article

   A standard discussion group provides a 2-paned interface in which the user can view:
   • All of the articles within a particular discussion group

   • The text of a particular article

   In a categorized discussion group, any lower-level discussion group is a category. A categorized discussion group cannot contain another categorized discussion group.
   Note: If the parent discussion group is already categorized, you do not see a choice for the type of discussion group. Instead, the type of the discussion group becomes category discussion group.

7. If you want to specify advanced options for the discussion group, such as type of postings allowed or moderation, go to the Advanced Options section (by scrolling) and continue to step 8.

   If you do not want to specify further options, click Submit now.

   Note: The default options are 1) create the discussion group on all connected servers and 2) local and remote postings to an unmoderated discussion group.

8. You can specify the following information by clicking the associated button:
   • Specify whether to create the discussion group only on the local Collabra Server or on all connected servers. If you specify local, the discussion group is created only on the local Collabra Server. If you specify all connected servers, the request to create the discussion group is also sent to your replication sites.

   • Specify the type of postings allowed for the discussion group. Local postings are articles posted directly to your discussion group by users. Remote postings are articles sent to your discussion group by another news server (discussion group replication).

   • Specify that this discussion group will be moderated and name the moderator. You must include an email address for the moderator. See "Moderating a discussion group" for more information.

   • Specify that the discussion group will be a gateway and select an email address for the mail gateway. Any articles posted to the discussion group will also be sent to the email address.

   • Specify that articles are stored in the spool only until they are sent to other replication sites. Users cannot read the articles from your server.

   • Specify that this discussion group is a referral for another discussion group. Referral discussion groups are most commonly used to obsolete an existing discussion group. See "Modifying attributes of a discussion group" for more information.

9. Click Submit to create the discussion group.

The server administrator receives a notification control message for each discussion group that is created.

Naming your discussion groups

Although it is not recommended, the server administrator can override discussion group name validity checking by changing the REQUIRE_VALID1036_NAMES parameter value in the nsnews.conf file from DO to DONT. If you do change the value, be aware that doing so might cause server problems. For example, if you change the value to DONT on a Unix machine and then create a discussion group that does not comply to the 1036 standards, replicating this discussion group to a machine that does comply to the naming standards will fail.

Controlling access to a discussion group

• View access control for a discussion group

• Grant access to a discussion group

• Delete access to a discussion group

• Modify access to a discussion group

Before users can perform these tasks, however, the server administrator must do the following:

• Create users and user groups and assign roles to the users and user groups

• Manage and define user roles

• Delegate discussion group management tasks to users (if appropriate), and provide the necessary information about roles and associated permissions to the delegated managers

These server administrator tasks are described in Chapter 3, "Controlling access to your server."

Delegating management tasks

Assume you have created the discussion group royal.pets.* And, within the royal.pets.* hierarchy, you have created the following lower-level discussion groups:

royal.pets.cats

royal.pets.repts

You decide to delegate management of these discussion groups, so you name a manager for each discussion group. Robert manages the royal.pets.cats discussion group; and Jules manages the royal.pets.repts discussion group. Robert and Jules can perform the following tasks on the discussion group they manage and on all lower-level discussion groups within the discussion group hierarchy:

• View all discussion groups

• Create new discussion groups

• Remove discussion groups

• Access and change basic information about any discussion group

• Add new access to any discussion group

• Modify the access to any discussion group

• Specify managers and moderators for lower-level discussion groups

• Cancel messages posted by other people

Viewing access control for a discussion group

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups.

   From the Communicator interface, choose Edit|Manage Discussion Groups.

2. Select the discussion group, then click Access Control Rules.

Access Control form

You will see one or more access rules for the discussion group. An access rule maps users and user roles to the discussion group. For lower-level discussion groups, some of these rules are "inherited" from higher-level discussion groups in the discussion group hierarchy.

For example, in Figure 4.2, rule 1 is inherited from the root-level discussion group. Inherited rules are viewable but not selectable. See "Understanding inheritance" for more information.

Note: By default, when the server is first installed, all users inherit the poster role. In the examples in this section, the default rule has been modified so that all users inherit the reader role instead, as shown in rule 1.

The following access rules have been defined for the Pets discussion group:

• The default rule (rule 1) has been modified so that all users inherit the reader role (instead of the poster role).

• Crowe has "absolute" manager rights to the discussion group (rule 2) because the Continue box is not checked. The asterisk (*) in the host field indicates that Crowe can access the discussion group from any host machine.

  An absolute right means that Crowe has manager rights to all lower-level discussion groups in the hierarchy and that this right cannot be revoked by a lower-level rule in the hierarchy. See "Specifying a continued or absolute rule" for more information.

For each access rule, you can view the following information:

• The name of the users (user, user group, host) for whom this rule applies. If one rule contains multiple users, you can view all the users by clicking the Edit button, or for inherited rules, the List button.

• Whether authentication is determined by:
  • default

  • basic

  • certs

  See "Understanding authentication" for more information.

• The role granted to the users (user, user group, host) or the denial of all access to the user.

• Whether this rule is continued or absolute. See "Specifying a continued or absolute rule" for more information.

• If the rule is inherited, the Set from field shows from which discussion group inheritance is set. See "Understanding inheritance" for more information.

You can also include hostnames in the access control rule. The server checks for valid hostnames before checking for valid user or user group names. If the hostname does not match, the server stops checking and the user is denied access.

To specify an access control rule:

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups.

   From the Communicator interface, choose Edit|Manage Discussion Groups.

2. Select the discussion group, then click Access Control Rules.

3. Click New Rule. You will see a new rule with selectable fields appear.

4. You can specify access for a particular user, user group, or host. You must specify a user in at least one of the user fields (user, user group, host). You can specify users in all of the user fields if you want.

   In the User field, type the user ID to which this rule applies. You can specify multiple users by typing multiple user ID's separated by a comma. To specify access for all users in the directory service, type all.

   In the Group field, type the user group ID to which this rule applies. You can specify multiple groups by typing multiple user group ID's separated by a comma.

   The Users and Groups search form. Typically, if you are specifying multiple users and groups, you will want to use the Users and Groups search form. To use this form, click the Edit button. See "Specifying users and groups" for more information.

   Note: After you click OK on the Users and Groups form, the access rule is submitted. Consequently, you should complete steps 5 through 7 before you click OK on the Users and Groups form.

   In the Host field, type the name of the host to which this rule applies. You can specify a hostname or an IP address. To specify all hosts, type an asterisk (*). All hosts is the default.

   Limiting host connections. To limit connections by host machine, you can specify a host in the host box.

   If you specify Ben in the User field and 237.* in the host field, Ben can access this discussion group only from a machine on the 237 domain and only after authenticating.

   If you specify anyone, anyone, 237.*, any user can access this discussion group from a machine on the 237 domain. The user is not required to authenticate.

   Note: If the server administrator has disabled IP address resolution, you cannot specify a hostname; you must specify an IP address. Ask your server administrator for more information.

   Creating a guest rule. You can create a guest rule by specifying the following in the User, Group, and Host fields, respectively: anyone, anyone, *. A guest rule indicates that any host or user (whether defined in the user directory service or not) can access the discussion group without authenticating. You can also specify a guest rule for a particular host by specifying anyone, anyone, hostname. See "Understanding authentication" for more information about authenticating.

   For example, you might create a guest rule that grants reader access to any user.

5. From the Auth by menu, choose the type of authentication that will verify the client user for this discussion group:
   • default. Authentication is determined by the specified system default method. The server administrator specifies the default method by choosing Access Control|Access Control Options.

   • basic. Authentication is determined by client login (user name and password).

   • certs. Authentication is determined by client certificate.

   See "Understanding authentication" for more information.

6. From the Allow Role of menu, choose the role you are allowing the user, or if you want to deny all access, choose Deny. See "Specifying roles" for more information.

   The Deny function. Choosing Deny automatically denies the user all access to the discussion group. You can choose Deny as a quick way of denying all access to the discussion group. After denying all access, you can then choose to grant a particular role to a user.

7. By default, the Continue checkbox is checked. This means that the server continues checking for access control rules that match this user, this discussion group hierarchy, and the current action being attempted. If you want the rule you are specifying to be "absolute"; that is, to apply to this user and all lower-level discussion groups within the hierarchy, make sure the Continue box is not checked. See "Specifying a continued or absolute rule" for more information.

8. The Set from box is informational only. It shows you from which higher-level discussion group a rule is inherited. See "Understanding inheritance" for more information.

9. Click Submit All Changes.

Specifying users and groups

To configure access control for users and groups, follow the general directions for specifying access control. If you click the Edit button, the Users and Groups search form, as shown in Figure 4.3, appears in a separate browser window.

The Users and Groups search form

The following list describes the options available on this form:

• Anyone (No Authentication) means anyone can access the discussion group without having to authenticate. However, the user might be denied access based on other settings, such as hostname or IP address.

• Authenticated users/groups only is the default. All users and user groups will have to authenticate before getting access to the discussion group.
  • All users and groups in authentication database means all users and groups in the directory service can access the discussion group after they authenticate.

  • Only the following users and groups means only the users and groups that you specify can access the discussion group after they authenticate.

1. In the Add Users or Groups form, type a string and click Find.

   You can choose users or user groups from the search results and add them to the List of Users or List of Groups.

2. Click OK to update the access control rule on the main form and submit the access control rule.

   Note: Because OK creates the access control rule, you should complete all other fields on the main access control form before you click OK on the Users and Groups search form.

If you are a server administrator, you can get this information by accessing the Roles form (Access Control|Manage Roles) via the Collabra Server interface.

If you are a user managing discussion groups from the Communicator interface, your server administrator must provide you with the necessary information about the roles and their associated permissions to enable you to manage discussion groups effectively.

Understanding inheritance

For example, assume any user has reader access (read permission) to royal.pets.snakes. This rule is inherited from the root level, as shown in Figure 4.4, rule 1. Consequently, all lower-level discussion groups, including the Snakes discussion group, inherit this rule for all users--unless the rule is specifically overridden by creating a new rule for a particular user.

Assume that Jules, who manages the Snakes discussion group (rule 3), does not want all users to have reader access to the group. So he creates a rule (rule 4) that denies all users access to the Snakes discussion group. He then grants access to specific users. For example, Gena, John, Ben, and Brian have poster rights to the discussion group (rule 5); they can view the discussion group, read messages in the discussion group, and post messages. Raghu, however, can only read messages in the discussion group (rule 6); he cannot post messages to the discussion group.

Access control for Snakes

Jules' strategy works BECAUSE RULE 1 IS A CONTINUED RULE. If rule 1 were not continued, Jules could not override the rule, as he's done in Rule 4. (See "Specifying a continued or absolute rule" for more information.) Only a manager of the discussion group from which a rule is inherited can change the Continue attribute for that rule.

You can specify new rules that override an inherited rule (that is not continued), but you cannot modify the inherited rule unless you have manager access to the higher-level discussion group. For example, only the server administrator, by default, can modify rule 1. And only the server administrator and Crowe, who manages the Pets discussion group (rule 2), can modify rule 2.

Note: If you are granting the same role to multiple users, you should specify one rule with multiple users listed, as shown in Figure 4.4, rule 5. For purposes of visual clarity, some of the examples in this section show a single user per rule. Keep in mind that, for performance reasons, the example shown in rule 5 is the recommended way for specifying multiple users.

Note: If you are denying access, be careful that you do not deny yourself access to the discussion group. For example, if you are granting manager privileges to yourself, be sure to do this before you deny all access. If you do deny yourself access, you'll need to contact your server administrator to fix the problem.

Specifying a continued or absolute rule

You should check Continue if you want the server to continue checking for other access control rules that match this user and this discussion group, and that contain a role that has the permissions necessary for the current action.

If you want the rule you are specifying for this user and this discussion group to be absolute; that is, to apply to this user and all lower-level discussion groups within the hierarchy as well, you should uncheck the Continue checkbox.

For example, if Crowe has absolute manager rights to royal.pets, the server automatically grants Crowe manager rights to royal.pets.dogs and any lower-level discussion groups in the royal.pets.dogs hierarchy. Figure 4.5 shows that Crowe has inherited manager rights to the royal.pets.dogs.rotties discussion group (rule 2).

Consequently, although JMacho, who manages the Rottweilers discussion group, has tried to deny Crowe all rights to royal.pets.dogs.rotties (rule 5), Crowe still has inherited manager rights to the discussion group.

Access control for Rottweilers

In Figure 4.6, JMacho has inherited reader rights to royal.pets.dogs (rule 1), but his rights are not absolute. Consequently, Daphne, who manages the Chihuahuas discussion group (rule 3), can deny JMacho all rights to royal.pets.dogs.chihs, as she has done in rule 8. She then has second thoughts and decides to grant JMacho reader rights to the Chihuahuas discussion group (rule 9). Now, JMacho can read messages in the discussion group, but he cannot post to the discussion group. (Alternatively, Daphne could have deleted rules 8 and 9.)

Access control for Chihuahuas

Robert, who manages the Cats discussion group, decides that JMacho should have no access to the Cats discussion group, so he revokes all of JMacho's permissions to the group, as shown in Figure 4.7 (rule 11). Furthermore, Robert decides that JMacho should have no access to any lower-level discussion groups in the Cats hierarchy, so he decides to make the rule an absolute rule by unchecking the Continue checkbox.

Access control for Cats

Understanding authentication

When you specify access control for a discussion group, you can specify the type of authentication you allow by choosing one of the following options from the Auth by menu:

• default. Authentication by default means that the default authentication method is used to control access to the discussion group. The default authentication method is set by your server administrator (Access Control|Access Control Options).

• basic. Authentication by login requires the user to specify a user name and password. The user name and password are stored in the directory service. Keep in mind that users can lose, or share, their user name and password. Any user with access to a valid user name and password can access your discussion group from any machine that can access your discussion group.

• certs. Authentication by certificate provides stricter access control. Only machines with a valid certificate can access your discussion group. If the user has a valid client certificate, they need not login when they access the discussion group. Authentication by certificate requires a secure Collabra Server. If you do not know if your server is secure, ask your server administrator.

If you specify authentication by certificate in any access control rule for a discussion group, all users will be asked to authenticate by certificate-- regardless of the authentication methods specified in later rules for a particular user. (The server must prompt for the certificate to determine if later rules specify this user and authentication by basic.) If the user does not have a certificate, the user can still authenticate by user name and password.

If you specify this option, you will want to notify your clients that they must get a client certificate before they can access your discussion group.

Understanding access control for a virtual discussion group

• When a user creates a search profile for a virtual discussion group, the results of the search depend on the access privileges of the creator. If the creator does not have access to a discussion group, articles from that group are not returned in the virtual discussion group.

• By default, only the creator can read the virtual discussion group.

  (The server automatically adds an access control rule for the creator of the virtual discussion group.)

• For the following reasons, Netscape does not recommend that you change the default access control for a virtual discussion group. If you do change the default access control, be aware that:
  • The search results are always based on the creator's access privileges.

  • Caution: If another user has access to the virtual discussion group, but not to one of the source discussion groups, the user cannot view the text of the article, but can view the headers, including the subject line, of the article.

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups.

   From the Communicator interface, choose Edit|Manage Discussion Groups.

2. Select the discussion, then click Access Control.

3. In the Access Control form, select the rule you wish to delete and click the corresponding Delete key (the trash-can icon at the end of the rule).

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups.

   From the Communicator interface, choose Edit|Manage Discussion Groups.

2. Select the discussion group, then click Access Control.

3. In the Access Control form, select the rule you wish to modify.

4. You can make changes by modifying the fields on the main form. You can also make changes to users and groups by clicking Edit to access the Users and Groups search form.

5. After you've made all your changes, click Submit All Changes on the main access control form or, if you've used the Users and Groups search form, click OK on the search form.

Removing a discussion group

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups.

   From the Communicator interface, choose Edit|Manage Discussion Groups.

2. Select the discussion group, then click Remove.

3. Specify whether to remove the discussion group from the local Collabra Server or from all connected servers. (The default is the local Collabra Server.)

   Note: If you are using the Netscape Directory Server and you choose to remove the discussion group from the local Collabra Server only, the discussion group and its access control rules are not removed from the Directory Server.

The server administrator receives a notification control message for each discussion group that is removed. (That is, one notification message for the removal of a discussion group and all lower-level discussion groups in the hierarchy.)

Modifying attributes of a discussion group

1. From the administrative interface, choose Discussion Groups|Manage Discussion Groups.

   From the Communicator interface, choose Edit|Manage Discussion Group.

2. Select the discussion group, and then click General Properties. From the General Properties form, you can:
   • Modify the display name.

   • Add or modify the description of the discussion group.

   • Modify the type of the discussion group: standard or categorized. (If the parent discussion group is already categorized, you will not see a choice for the type of discussion group. Instead, the type of the discussion group becomes category discussion group.)

   • Specify whether to allow either local and remote postings or remote postings only.

   • Specify that the discussion group will be moderated and name the moderator.

   • Specify an email address for the mail gateway.

   • Specify that articles will not be stored on your server, but passed to other news servers.

   • Specify that this discussion group is a referral for another discussion group. For example, suppose you want to obsolete discussiona and point users to discussionb, so you specify discussionb in the referral field. When users post to discussiona, they will get a message to post to discussionb.

     See "Creating a discussion group" for more information about the fields on the form.

3. Click OK.

Moderating a discussion group

• Reviews submitted messages

• Specifies which messages can be posted and not posted

• Sends mail to the author of the denied messages

• Forwards accepted messages to the discussion

For example, assume the royal.pets.dogs.chihs (Chihuahuas) discussion group is open to all users. The purpose of the discussion group is to share information about the care, breeding, and showing of chihuahuas. Some chihuahua fans, however, are annoyed at some of the messages posted to the discussion group. In particular, a few users who own Rottweilers have been posting less-than-flattering messages about chihuahuas to the discussion group.

As the server administrator, you decide to end this bickering and designate a moderator. The moderator will filter the messages posted to royal.pets.dogs.chihs and forward only those messages that meet the discussion criteria. After the moderator becomes familiar with the content of JMacho's messages to the chihuahua discussion group, for example, the moderator might automatically deny messages posted by JMacho.

How to post moderated articles

To approve an article, the moderator uses inews, a program that comes with the Collabra Server. The inews program and the Collabra Server must run on the same operating system. Consequently, to enable moderation, you must provide your moderators with the following:

• A copy of the inews program

• A copy of the nsnews.conf file

When moderators receive a message for approval, they can save the message to a file, and edit the message to remove the moderator header information.

To approve an article, the moderator runs the inews command on the article, as shown in the following example:

inews -h -a moderuser@champagne.royal.com filename_article

To reject an article, the moderator simply does not forward the message to the discussion. The moderator should, however, send an email to the poster and explain why the message was rejected.

If access control is enabled

• You must grant the moderator role to the moderator.

• You must specify in the moderator's access control rule that authentication is by basic.

• The moderator must specify a user name and password when running the inews program, as shown in the following example:

  inews -h -a moderuser@champagne.royal.com -u mewing -w passwd filename_article

For more information

Importing discussion groups

Note: This task is not accessible to users from the Communicator interface.

To host the same discussion groups on your server that are being sent by another server, you should obtain that server's active file and import the desired discussion groups into your server's active file.

The importing can take several seconds, even minutes, depending on the size of the active file being imported.

To import a discussion group:

1. Choose Discussion Groups|Import Discussion Groups.

2. Click one of the following options:
   • Active file to import discussion groups from

   • Remote host to import discussion groups from

3. In the Import discussion groups matching field, type the text for the discussion groups you want to import. You can type a wildcard pattern to specify the discussion groups.

4. The Discussion group creator field is informational only and displays the name of the user who created the discussion group.

5. Click OK. You'll get a confirmation message.

Note: If you are importing an active file from a remote server, be sure your server and the remote server are listening to the same port number.

For more information about setting up discussion group replication with another news server, see Chapter 5, "Managing replication of articles."

Warning!

By default, indexing is turned off. Indexing is automatically turned on when you create an indexer. You create an indexer by giving it a name and specifying which discussion groups the server should index. After articles are indexed, they are available for searching and profiling. (Search results are limited to 200 articles.) For information about enabling searching and profiling, see Chapter 2, "Specifying search options."

To specify indexing information for searches:

1. Choose Discussion Groups|Full Text Indexing.

2. In the Indexer identifier field, type the name of the indexer.

3. From the pull-down menu, choose which discussion groups you want to index:
   • All discussion groups

   • Specified discussion groups

   • All but specified discussion group

4. If you choose Specified discussion groups or All but specified discussion groups, in the Discussion groups field, type the discussion group names.

5. Click OK.

The batch file for each indexer is created by the innd process. The batch file contains the list of articles to be indexed. By default, the batch file is processed every 15 minutes. (You can determine how often the batch files are processed by choosing Server Preferences|Technical Settings. See "Specifying technical settings" in Chapter 2 for more information.)

In general, you will need only one indexer. It is possible, however, to create multiple indexers with different configurations. For example, you might want to configure multiple indexers if you think you need different batch sizes for each indexer. If you expect an indexer to receive more than 1000 articles every 15 minutes, you might want to change the batch file size for performance reasons.

Note: The batch size is determined by a parameter in the indexsend.ctl file. You must contact Netscape technical support before you modify any of the configuration files.

After you create an indexer, it appears in the list of indexers at the bottom of the Full Text Indexing form. All indexer names are preceded by the word indexer. From this form, you also have the option of editing or removing an index.

Editing an indexer

Removing an indexer

• All configuration files for the indexer are removed

• No more articles are indexed for this particular indexer

• Existing articles remain in the index until they expire