Vet the `ldmadmin` configuration-file (`ldmadmin-pl.conf`)

["To vet" is to examine and possibly modify or correct.]

The perl(1)-script for administering the LDM should have been installed as the file $HOME/ldm-6.8.1/bin/ldmadmin The configuration-file for this script should have been installed as the file $HOME/etc/ ldmadmin-pl.conf, if it didn't already exist. What follows is information on possible modifications to this configuration-file for your site.

If this is your first LDM installation, then you will probably need to manually configure several variables in the ldmadmin configuration-file. Versions 6.1 and earlier of the LDM package did not have this configuration-file. If you have a version 6.1 or earlier installation of the LDM package, then you can use that installation's ldmadmin script to help you determine appropriate values.

Vet the following variables in the ldmadmin configuration-file, $HOME/etc/ ldmadmin-pl.conf:

Variable Meaning

$hostname The fully-qualified name of the host computer on which the LDM will execute. This name must contain periods. If the command uname -n doesn't return such a name, then set the value appropriately.

$pq_size The size, in bytes, of the data portion of the LDM's product-queue. This parameter is used when the product-queue is created. The size should be greater than the desired minimum residency-time for a data-product in the product-queue (e.g., 1 hour) times the maximum rate of data arrival. (e.g., 13.4 MB/h if only the IDS|DDPLUS data-feed is being received). If the value is less than this, then late-arriving data-products that are older than the minimum residency time could, nevertheless, still be inserted into the product-queue because their predecessors will have been purged from the queue.
For convenience, a "K", "M", or "G" suffix can be appended to the numeric specification to mean "kilo", "mega", and "giga", respectively. Thus the specifications "1G" "1000M", "1000000K", and "1000000000", are all equivalent, for example.
The value for this parameter can be fine-tuned by using the pqmon utility.

$pq_slots The number of data-product slots for the LDM product-queue. This is the maximum number of data-products that the product-queue can contain (assuming that the data portion of the product-queue is sufficiently capacious). This parameter is used when the product-queue is created. The number of slots should equal the maximum number of data-products expected over the desired minimum residency-time (e.g., 16000 for one hour of IDS|DDPLUS data, if that is all that's being received). If this parameter is defaulted, then the number of slots will be computed using the size of the data portion of the product-queue and 4096 bytes as the mean data-product size (which is, undoubtably, incorrect).
The value for this parameter can be fine-tuned by using the pqmon utility.

$numlogs The maximum number of LDM logfiles to keep around.

$ip_addr The IP address of the network interface on which the LDM server should listen for connections. This variable doesn't exist in older versions of the configuration-file and may be added manually. Set to "0.0.0.0" if you want the LDM server to listen on all available network interfaces.

$port The port on which the LDM server should listen for connections. This variable doesn't exist in older versions of the configuration-file and may be added manually. If this variable isn't set, then the LDM server will listen on the port that was specified when the package was built.

$max_clients The maximum number of clients allowed to connect to the LDM server before additional connections are rejected.

$netstat The netstat command for printing numeric port numbers of all TCP Internet connections. Two common variations are "netstat -A inet -t -n" and "netstat -f inet -p tcp -n". This command will be used to collect LDM performance metrics.

$metrics_file The pathname of the data-file into which to accumulate performance metrics on the LDM system by the command addmetrics.

$metrics_files The file-pattern for the metrics data-files to be plottted by the command plotmetrics.

$num_metrics The number of metrics data-files to keep around.

$max_latency Maximum latency in seconds. A data-product arriving with a latency greater than this will be rejected by the downstream LDM.

$offset Request time-offset in seconds. Nomally, a downstream LDM will request data starting with just after the last successfully received data-product. If that product doesn't exist in the upstream LDM's product-queue, however, then the downstream LDM will request data starting from this many seconds ago. The need for this parameter can arise if, for example, the downstream LDM has been offline long enough for the last successfully recieved data-product to be purged from the upstream LDM's product-queue. The value must be less than or equal to $max_latency.

$delete_info_files Whether or not to delete the product-information files when the product-queue is deleted (via the delqueue command). If true, then the new product-queue will be initially populated by requests for data that go back $offset seconds in time; otherwise, the requests for data that are the same as before will start with the last successfully-received data-product for each connection. Relay nodes should probably set this variable to true in order to regenerate a buffer of data while leaf nodes should probably set it to false in order to avoid receiving (and processing) duplicate data-products.

$check_time Whether or not to check the accuracy of the system clock. Because accurate time is vital for proper operation of the LDM system, the ldmadmin(1) script will, by default, verify the accuracy of the system clock by executing the ntpdate(1) utility every time the script is executed. Setting this variable to 0 will disable this checking.

$warn_if_check_time_disabled Whether or not to print a warning message if checking the accuracy of the system clock is disabled. If the $check_time variable is non-zero, then a warning message might be printed. Setting this variable to 0 will disable the printing.

$ntpdate Pathname of the ntpdate(1) utility. The pathname may be absolute or relative. If relative, then the utility must be findable via the $PATH environment variable.

$ntpdate_timeout Timeout, in seconds, for the ntpdate(1) utility. The utility will terminate if it hasn't received a response from a time-server in this many seconds.

@time_servers List of NTP(1) time-server candidates for the ntpdate(1) utility to use. If you're on the Unidata IDD and located in North America, then this list is probably adequate. Otherwise, you should modify this list by replacing the entries with accessible time-servers in your vicinity. You might also replace this list if you have fast access to your own NTP(1) time-servers. The elements of the list are accessed in random order to spread the load.

$check_time_limit The maximum time-difference, in seconds, that the system clock may be off before being considered inaccurate. If you're running the ntpd(1) daemon, then you can set this variable to 1.

$abort_if_check_time_failure Whether or not the ldmadmin(1) script should permaturely terminate with an error status if the system clock isn't accurate or can't be determined to be accurate. Set this variable to 0 if you don't wan't the script to abort.

Variable	Meaning
`$hostname`	The fully-qualified name of the host computer on which the LDM will execute. This name must contain periods. If the command `uname -n` doesn't return such a name, then set the value appropriately.
`$pq_size`	The size, in bytes, of the data portion of the LDM's product-queue. This parameter is used when the product-queue is created. The size should be greater than the desired minimum residency-time for a data-product in the product-queue (e.g., 1 hour) times the maximum rate of data arrival. (e.g., 13.4 MB/h if only the `IDS\|DDPLUS` data-feed is being received). If the value is less than this, then late-arriving data-products that are older than the minimum residency time could, nevertheless, still be inserted into the product-queue because their predecessors will have been purged from the queue. For convenience, a "K", "M", or "G" suffix can be appended to the numeric specification to mean "kilo", "mega", and "giga", respectively. Thus the specifications "1G" "1000M", "1000000K", and "1000000000", are all equivalent, for example. The value for this parameter can be fine-tuned by using the pqmon utility.
`$pq_slots`	The number of data-product slots for the LDM product-queue. This is the maximum number of data-products that the product-queue can contain (assuming that the data portion of the product-queue is sufficiently capacious). This parameter is used when the product-queue is created. The number of slots should equal the maximum number of data-products expected over the desired minimum residency-time (e.g., 16000 for one hour of `IDS\|DDPLUS` data, if that is all that's being received). If this parameter is defaulted, then the number of slots will be computed using the size of the data portion of the product-queue and 4096 bytes as the mean data-product size (which is, undoubtably, incorrect). The value for this parameter can be fine-tuned by using the pqmon utility.
`$numlogs`	The maximum number of LDM logfiles to keep around.
`$ip_addr`	The IP address of the network interface on which the LDM server should listen for connections. This variable doesn't exist in older versions of the configuration-file and may be added manually. Set to "0.0.0.0" if you want the LDM server to listen on all available network interfaces.
`$port`	The port on which the LDM server should listen for connections. This variable doesn't exist in older versions of the configuration-file and may be added manually. If this variable isn't set, then the LDM server will listen on the port that was specified when the package was built.
`$max_clients`	The maximum number of clients allowed to connect to the LDM server before additional connections are rejected.
`$netstat`	The `netstat` command for printing numeric port numbers of all TCP Internet connections. Two common variations are `"netstat -A inet -t -n"` and `"netstat -f inet -p tcp -n"`. This command will be used to collect LDM performance metrics.
`$metrics_file`	The pathname of the data-file into which to accumulate performance metrics on the LDM system by the command `addmetrics`.
`$metrics_files`	The file-pattern for the metrics data-files to be plottted by the command `plotmetrics`.
`$num_metrics`	The number of metrics data-files to keep around.
`$max_latency`	Maximum latency in seconds. A data-product arriving with a latency greater than this will be rejected by the downstream LDM.
`$offset`	Request time-offset in seconds. Nomally, a downstream LDM will request data starting with just after the last successfully received data-product. If that product doesn't exist in the upstream LDM's product-queue, however, then the downstream LDM will request data starting from this many seconds ago. The need for this parameter can arise if, for example, the downstream LDM has been offline long enough for the last successfully recieved data-product to be purged from the upstream LDM's product-queue. The value must be less than or equal to `$max_latency`.
`$delete_info_files`	Whether or not to delete the product-information files when the product-queue is deleted (via the `delqueue` command). If true, then the new product-queue will be initially populated by requests for data that go back `$offset` seconds in time; otherwise, the requests for data that are the same as before will start with the last successfully-received data-product for each connection. Relay nodes should probably set this variable to true in order to regenerate a buffer of data while leaf nodes should probably set it to false in order to avoid receiving (and processing) duplicate data-products.
`$check_time`	Whether or not to check the accuracy of the system clock. Because accurate time is vital for proper operation of the LDM system, the ldmadmin(1) script will, by default, verify the accuracy of the system clock by executing the ntpdate(1) utility every time the script is executed. Setting this variable to `0` will disable this checking.
`$warn_if_check_time_disabled`	Whether or not to print a warning message if checking the accuracy of the system clock is disabled. If the `$check_time` variable is non-zero, then a warning message might be printed. Setting this variable to `0` will disable the printing.
`$ntpdate`	Pathname of the ntpdate(1) utility. The pathname may be absolute or relative. If relative, then the utility must be findable via the `$PATH` environment variable.
`$ntpdate_timeout`	Timeout, in seconds, for the ntpdate(1) utility. The utility will terminate if it hasn't received a response from a time-server in this many seconds.
@time_servers	List of NTP(1) time-server candidates for the ntpdate(1) utility to use. If you're on the Unidata IDD and located in North America, then this list is probably adequate. Otherwise, you should modify this list by replacing the entries with accessible time-servers in your vicinity. You might also replace this list if you have fast access to your own NTP(1) time-servers. The elements of the list are accessed in random order to spread the load.
`$check_time_limit`	The maximum time-difference, in seconds, that the system clock may be off before being considered inaccurate. If you're running the ntpd(1) daemon, then you can set this variable to `1`.
`$abort_if_check_time_failure`	Whether or not the ldmadmin(1) script should permaturely terminate with an error status if the system clock isn't accurate or can't be determined to be accurate. Set this variable to `0` if you don't wan't the script to abort.

Workshop-specific instructions.

You can check the configuration of the ldmadmin configuration-file by executing the following command:

$HOME/ldm-6.8.1/bin/ldmadmin config

Vet the ldmadmin configuration-file (ldmadmin-pl.conf)

Vet the `ldmadmin` configuration-file (`ldmadmin-pl.conf`)