The platform on which the LDM package is to be installed must be prepared in advance prior to the installation. If your platform already has an LDM installation, then, in all likelihood, the preinstallation steps have already been completed. If you are installing the first LDM package on your platform, however, then the steps described here should be done before the LDM distribution is unpacked.
rootThis is, necessarily, a system-dependent operation. Consult with your system's administrator, if necessary.
Keep the following in mind when creating the account:
The name of the user should be "ldm".
Conventionally, the LDM
user's home-directory is /usr/local/ldm. This pathname
is compiled into the binary distributions, so when installing from
a binary distribution you should either specify that directory as
the LDM user's home-directory, or do one of the following:
Use a group ID that allows other non-LDM processes to write files (decoders, etc.). The McIDAS and GEMPAK users are often members of this group.
Workshop-specific instructions.
/etc/servicesAdd the following line:
ldm 388/tcp ldmd # UCAR Unidata LDMThis allows programs such as netstat(1) to
use "ldm" and "ldmd" instead of "388"
(the LDM port number).
Workshop-specific instructions.
/etc/rpcAdd the following line:
ldm 300029 ldmdThis allows programs such as rpcinfo(1) to
use "ldm" and "ldmd" instead of "300029"
(the LDM program number for RPC).
Workshop-specific instructions.
/etc/syslog.confThe LDM
uses the system logging daemon, syslogd(8), to write
error messages using the localn
logging facility Such messages should end up in the LDM
logfile.
Add the following entry to file
/etc/syslog.conf
(or /etc/rsyslog.conf, depending on your
operating system).
localn.debug /usr/local/ldm/logs/ldmd.logwhere localn
is the logging facility that the LDM
will use. Note that you might have to adjust the pathname of the
log-file.
Add the string localn
to entries like the following so that LDM messages will not be
written to the console (Note: entries might not be exactly like
these, but they should be similar):
*.err;kern.notice;auth.notice;user.none;localn.none /dev/console
*.err;kern.debug;daemon.notice;mail.crit;user.none;localn.none /var/adm/messagesIf the operating system is Linux and the file
/etc/selinux/config exists and contains the
variable SELINUX, then that variable must be
set to disabled in order to allow the syslog(8)
daemon to write log messages to the LDM logfile.
The computer must be rebooted for this change to take
effect.
Workshop-specific instructions.
If the computer on which the LDM runs has firewall (alias, packet filtering) rules, then these rules must be configured to allow connections to and from the LDM. How this is done is operating-system specific, so you might have to consult with your system or network administrator.
In order for the LDM system to send data to a downstream LDM, the firewall rules must allow incoming TCP connections to the port on which the LDM server is listening (the default is 388). An example of ensuring this for firewall rules based on iptables(8) is the command
iptables -A INPUT -p tcp --dport 388 -j ACCEPT
Similarly, in order for the LDM to receive data from an upstream LDM, the firewall rules must allow outgoing TCP connections to the port on which the upstream LDM server is listening (the default is 388). Because most sites don't bother filtering outgoing connections, this configuration step is usually not necessary.
Workshop-specific instructions.
For example:
su - ldm
The "-" option guarantees that the current working directory is the LDM user's home-directory. Alternatively, just log-out and log back in as the LDM user.
Workshop-specific instructions.
Add the following lines to the appropriate login profile-file of the LDM user's user-shell. The profile-file should be the one that the user-shell reads when it's a login shell (e.g., .bash_profile, .login).
If more than one person might manage the LDM, then it's a good idea to add both of the following snippets in case the other person prefers a different user-shell.
Standard user-shell (e.g. sh, ksh, bash):
csh-like user-shell (e.g. csh, tcsh):
Required
setenv LDMHOME $HOME
set path=($HOME/decoders $HOME/util $HOME/bin $path)
setenv MANPATH $HOME/man:SysManPathOptional
# Example pathname of UDUNITS(3) database
setenv
UDUNITS_PATH $HOME/etc/udunits.dat
SysManPath is the pathname for the manual-pages of the operating system (e.g., /usr/man or /usr/share/man). The MANPATH environment variable might already contain this path.
The UDUNITS_PATH environment variable conains
the pathname of the database of the UDUNITS package. It should only
be necessary to define this variable if your LDM
system will decode incoming products using the gribtonc(1)
utility (i.e. if an exec
entry that uses gribtonc exists in a pqact
configuration-file).
If necessary, modify the setting of the PATH environment variable above to ensure that the necessary build utilities can be found.
Don't forget to source the profile-file so that the modifications take effect. For example:
Standard user-shell (e.g. sh, ksh, bash):
. .bash_profile
csh-like user-shell (e.g. csh, tcsh):
source .login