You should also read the discussion on editing ldmd.conf when configuring an LDM installation.
The LDM configuration-file, ldmd.conf, provides information to the top-level ldmd and contains the following types of entries:
This file normally resides in the etc/ subdirectory of the LDM installation.
- Execute programs as child processes on startup
- Connect to upstream LDMs to request data-products
- Allow certain downstream LDMs to connect and to receive certain data-products
- Allow certain upstream LDMs to send certain unrequested data-products
- Include another configuration-file
An EXEC entry tells the top-level ldmd to execute a program on startup. The programs most typically executed are pqact and rtstats (for IDD gateway LDMs).
The syntax of an EXEC entry is
where the quotation marks are mandatory if command contains whitespace (including newlines). Escape quotation marks in command with a backslash (\"). Each pair of backslashes is replaced with a single backslash.
The command strings of EXEC entries are executed via the execvp() function when the top-level ldmd program is started.
A REQUEST entry tells the top-level ldmd to start a downstream LDM child process.
The syntax of a REQUEST entry is
REQUEST feedtype prodIdEre hostId[:port]
When the top-level ldmd is started, it creates a downstream LDM child process for every REQUEST entry. The downstream LDM connects to the upstream LDM on the specified host. The specified port is used if it exists; otherwise, the default port is used. The downstream LDM requests the specified class of data-products. If there are multiple request-entries with the same feedtype and prodIdEre combination, then the downstream LDM corresponding to the first such entry in the file will use the primary transfer-mode and all others will use the alternate transfer-mode.
The behavior of the LDM is unspecified if multiple REQUEST entries exist for the same upstream LDM and the feedtypes in the entries are not disjoint.
An ALLOW entry tells the top-level ldmd what downstream LDMs are allowed to connect and what class of data-product they are allowed to receive.
The syntax of an ALLOW entry is
ALLOW feedtype hostIdEre [OK_pattern [NOT_pattern]]
where the square brackets denote optional fields and are not part of the syntax.
When a downstream LDM connects, its host identifier is checked against the set of ALLOW entries. If nothing matches the host identifier, then the downstream LDM is disconnected. The feedtype of the matching entry specifies the type of data-products the downstream LDM is allowed to receive. If the host identifier and feedtype in the incoming request match multiple ALLOW entries and the feedtypes of the entries are not disjoint, then the behavior of the upstream LDM is determined by the first matching entry.
Besides matching the data-product selection-criteria specified by the downstream LDM, the data-product identifier must also match the optional OK_pattern and not match the optional NOT_pattern in order to be transmitted. The default for the OK-pattern is ".*" and the default for the NOT-pattern is to not perform that test. These two patterns allow an upstream LDM to fine-tune the products that a downstream LDM receives. For example, the following entry will allow a downstream LDM on host ldm.downstream.site to receive all data-products except those that begin with "TEST"
ALLOW ANY ^ldm\.downstream\.site$ .* ^TEST
The configuration-file should always have the following entries:
The first entry allows the LDM to request data from itself and is necessary for proper operation. The second entry allows the Unidata Program Center to monitor the LDM.ALLOW ANY ^(localhost|loopback)|(127\.0\.0\.1\.?$) ALLOW ANY ^([a-z].*\.unidata\.ucar\.edu\.?$)
An ACCEPT entry tells the top-level ldmd what unrequested upstream LDMs are allowed to connect and what class of data-product they are allowed to send.
The syntax of an ACCEPT entry is
ACCEPT feedtype prodIdEre hostIdEre
When an upstream LDM connects using the HIYA message, its host identifier is checked against the set of ACCEPT entries. If nothing matches the host identifier, then the upstream LDM is disconnected. The feedtype and prodIdEre of the first matching entry specifies the type of data-products the upstream LDM is allowed to send.
This entry was primarily used for receiving (unREQUESTed) radar data from WSI Corporation and is now primarily used to receive statistics from the rtstats(1) utility, which are formatted as data-products.
An INCLUDE entry tells the top-level ldmd to temporarily suspend processing of the current configuration-file and to process another configuration-file instead. Processing of the current configuration-file resumes when the end of the other configuration-file is reached.
The syntax of an INCLUDE entry is
INCLUDE "pathname with spaces"
A non-absolute pathname is relative to the directory that contains the configuration-file being processed.