If you already have a previous version of the LDM installed and working, then you can probably skip these steps.
Make any necessary changes to the configuration-parameters in the LDM registry.
If this is your first installation, then pay particular attention to the parameters /hostname,
/reconciliation-mode, /queue/size, and /queue/slots. These parameters can be set via the
regutil(1) utility.
If you are upgrading an existing LDM installation or are planning to use the GEMPAK or McIDAS decoders, then make
sure that the data directory printed by the command "regutil
/pqact/datadir-path" is the same as the current working directory assumed by the
scour configuration-file, and the
pqact configuration-file.
Workshop-specific instructions.
First, find out who your upstream feed site(s) will be. If you don't know and you are qualified to participate in the Unidata IDD, then contact the Unidata Program Center at support-idd@unidata.ucar.edu with the following information:
Note that you can (and probably should) have two upstream hosts for any given data-feed.
Ask the administrator of the upstream LDM to add ALLOW entries for your LDM to the upstream LDM's configuration-file, ldmd.conf. For example,
ALLOW UNIDATA your.ldm.host
ALLOW NLDN your.ldm.host
Workshop-specific instructions.
This file tells an LDM what to do on startup. Possibilities include executing programs, requesting data, and authorizing connections. The default file that comes with the distribution contains examples. More information on this configuration-file can be found on the ldmd.conf webpage.
Here are some examples:
REQUEST ANY ".*" host1.site1.edu # initially primary-mode
REQUEST ANY ".*" host2.site2.edu # initially alternate-mode
For a given feedtype and
data-product identifier ERE, you may have
more than one such request. You should ensure, however, that the set of data-products referenced by every
feedtype/pattern pair is either identical to that of other pairs or completely disjoint from them. So, for
example, don't do this:
REQUEST UNIDATA ".*" host1.site1.edu
REQUEST ANY ".*" host2.site2.edu # overlaps previous
or this:
REQUEST IDS|DDPLUS ".*" host1.site1.edu
REQUEST IDS|DDPLUS "^SA" host2.site2.edu # overlaps previous
For a given LDM, a trade-off exists between data-product latency and CPU
load. This trade-off can be controlled to some extent by the number of
REQUEST entries to a given
upstream LDM. For more information, see the
ldmd.conf webpage.
ALLOW ANY-NLDN-WSI-PCWS-NOGAPS \.edu$
ALLOW IDS|DDPLUS \.com$ ^SA ^SAUS
For more information, see the ldmd.conf webpage.
EXEC "pqact"
Note that you might have more than one such EXEC entry if, for example, you
use the pqact configuration-files that come with the
GEMPAK or
McIDAS packages. For example:
# Exec GEMPAK specific pqact(1) processing
EXEC "pqact -f NNEXRAD /usr/local/ldm/etc/GEMPAK/pqact.gempak_nexrad"
EXEC "pqact -f ANY-NNEXRAD /local/ldm/etc/GEMPAK/pqact.gempak_decoders"
Workshop-specific instructions.
This file tells the pqact utility how to locally process various classes of data-products. Processing actions include filing the data-product, executing a local program, and piping the data-product to the standard input of a local program. If you're not going to process data-products locally, then you don't need to edit this file.
More information on this configuration-file.
Workshop-specific instructions.
This file tells the scour utility what old files should be deleted and when to delete them. This is useful if a pqact process is saving data-products as local files; and you want to keep only the most recent files to prevent the file system from becoming full. If you're not doing this, then you probably don't need to edit this file.
More information on this configuration-file.
Workshop-specific instructions.
Edit the crontab file of the LDM-user by, for example, executing the command
crontab -e
as the LDM-user. Then
0 0 * * * bash -l -c 'ldmadmin newlog'
More information on rotating logfiles.
0 1,4,7,10,13,16,19,22 * * * bash -l -c 'ldmadmin scour'
The above runs the scour program to remove too-old files every three hours. You
might choose different times.
* * * * * bash -l -c 'ldmadmin addmetrics'
This entry will accumulate metrics every minute. See
Monitoring the LDM System/Metrics.
0 0 * * 0 bash -l -c 'ldmadmin newmetrics'
This entry will rotate the metrics data files at the beginning of each week. You might choose a different period.
See Monitoring the LDM System/Metrics.
0,15,30,45 * * * * bash -l -c 'ldmadmin check >/dev/null'
This entry will check the LDM system every 15 minutes and send an email to the LDM user if the system isn't OK.
You might choose a different interval. In particular, this entry will notify the LDM user if a data-product
hasn't been received in the past number of seconds given by the /insertion-check-interval parameter in the
LDM registry (to see that value, execute the command
regutil /insertion-check-interval).
NOTE: These examples:
You might have to do something different in order to obtain the same results.
Workshop-specific instructions.
Email for the LDM user can be generated by a crontab(1) entry or by someone trying to contact the LDM administrator at a site. Consequently, you should ensure than any email sent to the LDM user is forwarded to a responsible person. On most UNIX-like systems (on which the sendmail(8) daemon is used to deliver email) this is done by having a line like the following:
user@host
in the file .forward in the LDM user's home-directory.
This file must also be be owned by the LDM user and be world-readable. For security, this file should not be writable by anyone other than the LDM user.
Although boot-time start-up procedures vary amongst operating systems, each can be tailored to start the LDM. It is best to start the LDM as late as possible in the boot process to avoid interfering with processes that could hang the system (e.g., the syslog daemon). One possible LDM script is:
#!/bin/sh
export PATH=/bin:/usr/bin
LDMHOME=/usr/local/ldm
LDMBIN=$LDMHOME/bin
LDMADMIN=$LDMBIN/ldmadmin
PQCHECK=$LDMBIN/pqcheck
PQCAT=$LDMBIN/pqcat
PQ=$LDMHOME/data/ldm.pq
LOG="logger -p local0.err $0:"
case "$1" in
start)
$LOG 'Starting LDM system...'
if [ -x $LDMADMIN ] ; then
if su - ldm -c "$LDMADMIN isrunning"; then
$LOG "LDM system is already running."
else
if [ ! -f $PQ ] ; then
$LOG "Product-queue doesn't exist. Creating..."
if ! su - ldm -c "$LDMADMIN mkqueue"; then
$LOG "Aborting..."
exit 1
fi
else
#
# Test the product-queue for corruption.
#
if ! $PQCHECK -l /dev/null -q $PQ; then
case $? in
1) $LOG "System error checking product-queue. Aborting..."
exit 1
;;
2) $LOG "Adding writer-counter to product-queue..."
if ! $PQCHECK -F -q $PQ; then
$LOG "Aborting..."
exit 1
fi
;;
3) $LOG "Product-queue was incorrectly closed. " \
"Checking..."
if $PQCAT -s -l /dev/null; then
$LOG "Product-queue appears OK. "
$LOG "Clearing writer-counter..."
if ! $PQCHECK -F -q $PQ; then
$LOG "Couldn't clear counter. Aborting..."
exit 1
fi
else
$LOG "Product-queue appears corrupt. Deleting."
rm $PQ
if ! su - ldm -c "$LDMADMIN mkqueue -f"; then
$LOG "Couldn't make new product-queue. Aborting..."
exit 1
fi
fi
;;
4) $LOG "Product-queue is corrupt. Deleting."
rm $PQ
if ! su - ldm -c "$LDMADMIN mkqueue -f"; then
$LOG "Couldn't make new product-queue. Aborting..."
exit 1
fi
;;
esac
fi
fi
su - ldm -c "$LDMADMIN clean"
su - ldm -c "$LDMADMIN start"
fi
fi
;;
stop)
$LOG 'Stopping the LDM system.'
if [ -x $LDMADMIN ] ; then
su - ldm -c "$LDMADMIN stop"
fi
;;
esac
Note that some user-shells do not conform to the the UNIX standard and will not understand the
"if ! ..." expressions in the above (e.g., SunOS 5.8's /bin/sh). You can test
your user-shell with the following command:
if ! false; then echo OK; fi
Instead of using the logger utility as above, you might wish to use something else (e.g., the
echo utility) -- depending on your operating system. Note that the -p option is
system-dependent.
Consult the documentation on your operating system or with your system administrator for details on how to incorporate this script (or something similar) into the boot-time start-up procedure of your system.