The LDM Configuration-File, ldmd.conf

You should also read the discussion on editing ldmd.conf when configuring an LDM installation.

Contents

Introduction

The LDM configuration-file, ldmd.conf, provides information to the top-level ldmd and contains the following types of entries:

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
INCLUDE
Include another configuration-file

This file normally resides in the etc/ subdirectory of the LDM installation.

EXEC Entry

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

      EXEC "command"
    

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.

REQUEST Entry

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.

ALLOW Entry

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:

      ALLOW   ANY ^(localhost|loopback)|(127\.0\.0\.1\.?$)
      ALLOW   ANY ^([a-z].*\.unidata\.ucar\.edu\.?$)
    

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.

ACCEPT Entry

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.

INCLUDE Entry

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
    

or

      INCLUDE "pathname with spaces"
    

A non-absolute pathname is relative to the directory that contains the configuration-file being processed.

Key

feedtype
A feedtype (e.g., WMO, IDS|DDPLUS, 3).
hostId
An identifier for a host. It may be either a fully-qualified hostname (e.g., thelma.ucar.edu) or an IP address in dotted-quad notation (e.g., 192.52.106.21).
hostIdEre
An ERE for matching a hostId. It must not contain whitespace and must not be enclosed in quotation marks.
prodIdEre
An ERE for matching data-product identifiers. If it contains whitespace, then it must be enclosed in quotation marks (") and any internal quotation marks must be escaped with a backslash (\"). Each pair of backslashes is replaced with a single backslash.
OK_pattern
An ERE that data-product identifiers must match in order for the data-product to be transmitted. If it contains whitespace, then it must be enclosed in quotation marks (") and any internal quotation marks must be escaped with a backslash (\"). Each pair of backslashes is replaced with a single backslash.
NOT_pattern
An ERE that data-product identifiers must not match in order for the data-product to be transmitted. If it contains whitespace, then it must be enclosed in quotation marks (") and any internal quotation marks must be escaped with a backslash (\"). Each pair of backslashes is replaced with a single backslash.