| • |
|
|
|
|||
|
||||
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 rpc.ldmd and contains the following types of entries:
This file normally resides in the etc/ subdirectory of the LDM installation.
- EXEC
- Execute programs as child processes on startup
- REQUEST
- Connect to upstream LDMs to request data-products
- ALLOW
- Allow certain downstream LDMs to connect and to receive certain data-products
- ACCEPT
- Allow certain upstream LDMs to send certain unrequested data-products
An EXEC entry tells the top-level rpc.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
EXEC "command"
where the quotation marks are mandatory and command is a string that may contain newlines. Escape quotation marks in command with a backslash (\").
The command strings of EXEC entries are executed via the execvp() function when the top-level rpc.ldmd program is started.
A REQUEST entry tells the top-level rpc.ldmd to start a downstream LDM child process.
The syntax of a REQUEST entry is
REQUEST feedtype prodIdEre hostId[:port]
When the top-level rpc.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 rpc.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]]
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.
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 rpc.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.
| Contact Us • Site Map • Search • Terms and Conditions • Privacy Policy • Participation Policy | ||||||
|
||||||
