PMDF System Manager's Guide

PMDF always reads in all the rewrite rules from the configuration file and stores them in memory in a hash table. Use of a compiled configuration merely bypasses the overhead associated with reading the configuration file each and every time the information is needed; a hash table is still used to store all of the rewrite rules in memory. This scheme is adequate for small to medium numbers of rewrite rules. However, some applications may require as many as 10,000 rewrite rules or more, which may consume prohibitive amounts of memory. (Applications which need many rewrite rules are channels like the ones for BITNET and UUCP: BITNET interconnects about 1,500 different systems and there are over 8,000 systems on the current UUCP map. Each of these systems needs at least one rewrite rule.)

PMDF solves this problem by providing an optional facility for storing large numbers of rewrite rules in an ancillary indexed data file. Whenever the regular configuration file is read, PMDF checks for the existence of the domain database, PMDF_DOMAIN_DATABASE.^c If this database exists, it is opened and consulted whenever an attempted match fails on the rules found in the configuration file. The domain database is only checked if a given rule is not found in the configuration file, so rules can always be added to the configuration file to override those in the database.

Duplicate entries are allowed in the database only if specifically requested via CRDB/DUPLICATES (OpenVMS) or crdb -duplicates (UNIX and NT), at the time the database is created. (Duplicate rewrites are allowed unconditionally in the configuration file.) Entries in the database treat upper and lower case just the same way as the configuration file does; i.e., patterns (left hand sides) are case insensitive, but templates (right hand sides) preserve case. Patterns in the database are limited to 32 characters and templates are limited to 80 characters unless a "long" database is built. The limits on a long database are, respectively, 80 and 256 characters.

The mere presence of the database file is enough to activate this database facility in PMDF: it is not necessary to recompile your compiled configuration. However, if you have any resident PMDF processes that need to know about this configuration change, e.g., the multithreaded SMTP server, then you must restart such proceses so that they recheck PMDF configuration information and notice the new domain database. For instance, to restart the multithreaded SMTP server on OpenVMS, use the command

$ PMDF RESTART SMTP

or on UNIX, use the command

# pmdf restart smtp

The use of the domain database can be disabled with the PMDF option USE_DOMAIN_DATABASE described in Chapter 7.

The domain database should be world readable. Failure to protect the database in this fashion will make address rewriting very erratic.

A utility is provided that can create and manipulate the domain database: CRDB (OpenVMS) or crdb (UNIX and NT) takes a list of rewrite rules in the same format as they appear in the configuration file and either creates a new database containing these rules or adds them to an existing database. (See Chapter 29 and Chapter 30, respectively, for full descriptions of these commands.) OpenVMS commands of the form

$ PMDF CRDB input-file-spec PMDF_TABLE:domain.tmp $ RENAME PMDF_TABLE:domain.tmp PMDF_DOMAIN_DATABASE

or UNIX commands

# pmdf crdb input-file-spec PMDF_DOMAIN_DATABASE

or NT commands

C:\> pmdf crdb input-file-spec PMDF_DOMAIN_DATABASE

are used to read the input file, input-file-spec, and create a new output database. Normally, if there are rules with identical left hand sides in the input file, the first instance of such a rule will be used. CRDB or crdb counts such duplicates as exceptions and reports how many exceptions occurred as it exits. This behavior may be changed by specifying CRDB/DUPLICATES (OpenVMS) or crdb -duplicates (UNIX and NT), which causes it to create a database that allows duplicate entries.

Use the /APPEND qualifier (OpenVMS) or -append qualifier (UNIX and NT) to add rules to an existing domain database. When additional rules are added to an existing database in this way any duplicates will override the original rules in the existing database. CRDB or crdb prints a warning message when this happens.

A "long" database, as needed if the left hand sides are over 32 characters long or if the right hand sides are over 80 characters long, can be created with the OpenVMS commands

$ PMDF CRDB/LONG_RECORDS input-file-spec PMDF_TABLE:domain.tmp $ RENAME PMDF_TABLE:domain.tmp PMDF_DOMAIN_DATABASE

or UNIX commands

# pmdf crdb -long_records input-file-spec PMDF_DOMAIN_DATABASE

or NT commands

C:\> pmdf crdb -long_records input-file-spec PMDF_DOMAIN_DATABASE

As an example, consider an input file named bitnet.rules whose first few lines might appear as

AACC $U%$H.BITNET AACC.BITNET $E$F$U%$D@JNET-DAEMON AACC.BITNET $S$U@$D@example.com$Qtcp_local AACC.BITNET $U$%$D@example.com$Qtcp_local AACC.BITNET $U%$D@JNET-DAEMON

This file may be converted to a domain database with the OpenVMS commands

$ PMDF CRDB/DUPLICATES bitnet.rules PMDF_TABLE:domain.tmp $ RENAME PMDF_TABLE:domain.tmp PMDF_DOMAIN_DATABASE

A temporary file is used so as to eliminate any window of time during which the domain database is in a mixed state or not fully generated.