Previous | Next | Contents | Index |
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 |
# pmdf restart smtp |
C:\> pmdf restart dispatcher |
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 31 and
Chapter 32, 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 |
# pmdf crdb input-file-spec PMDF_DOMAIN_DATABASE |
C:\> pmdf crdb input-file-spec PMDF_DOMAIN_DATABASE |
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 |
# pmdf crdb -long_records input-file-spec PMDF_DOMAIN_DATABASE |
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 |
$ PMDF CRDB/DUPLICATES bitnet.rules PMDF_TABLE:domain.tmp $ RENAME PMDF_TABLE:domain.tmp PMDF_DOMAIN_DATABASE |
c On OpenVMS systems this database is
the file pointed at by the PMDF_DOMAIN_DATABASE logical, usually the
file
|
Previous | Next | Contents | Index |