The following assumes that you are familiar with both the LDM system and with autoconf-based package-installation. If you're not, then follow the long installation instructions in the next section.
First, enable a 64-bit environment if possible. Then, do the following:
su - ldm
wget ftp://ftp.unidata.ucar.edu/pub/ldm/ldm-6.13.13.tar.gz
gunzip -c ldm-6.13.13.tar.gz | pax -r '-s:/:/src/:'
rm ldm-6.13.13.tar.gz # optional
cd ldm-6.13.13/src
export PATH=... # if necessary
./configure [--enable-logging=localn] [--localstatedir=volatile_dir] [--disable-max-size] [--with-noaaport] [--with-gribinsert] [CC=...] [CFLAGS=...] >configure.log 2>&1
Password: ...
make install >make.log 2>&1
make clean # optional
NOTE: If you don't have the pax(1) utility, then replace the gunzip(1) command-line with the following:
gunzip -c ldm-6.13.13.tar.gz | (mkdir -p ldm-6.13.13 &&
cd ldm-6.13.13 && tar -xf - && mv ldm-6.13.13 src)
The root of the installation tree will be $HOME/ldm-6.13.13
for the version-dependent files.
If you encounter problems, then follow the long installation instructions in the next section.
Follow this advice on becoming the LDM user.
The LDM source-distribution can be obtained via the command
or by clicking on the appropriate link in the LDM download page. Download the file into the LDM user's home directory.wget ftp://ftp.unidata.ucar.edu/pub/ldm/ldm-6.13.13.tar.gz
The remaining instructions assume that the distribution was downloaded into the LDM user's home-directory.
Unpack the distribution in the
LDM user's home directory into the
directory ldm-6.13.13/src
using the gunzip(1) and pax(1)
utilities.
For example:
NOTE: If you don't have the pax(1) utility, then replace the gunzip(1) command-line with the following:cd # go to the LDM user's home-directory gunzip -c ldm-6.13.13.tar.gz | pax -r '-s:/:/src/:' # unpack the distribution
gunzip -c ldm-6.13.13.tar.gz | (mkdir -p ldm-6.13.13 &&
cd ldm-6.13.13 && tar -xf - && mv ldm-6.13.13 src)
The reason for creating the additional src/ subdirectory is
to allow for reversible upgrading of the LDM. The section on
activating the LDM installation
provides an example.
Go to the top-level directory of the just-unpacked package. For example
cd $HOME/ldm-6.13.13/src
If you need to clean-up from a previous build attempt, then
use the make(1) utility to return the
distribution to a pristine state:
Don't worry if this command fails or even fails to execute.make distclean
(Optional) If necessary, adjust the PATH environment variable to obtain the necessary utilities. This step can be necessary due to the vagaries of build environments. Note that some computer systems can build both a 32-bit and a 64-bit LDM system. We strongly recommend that you choose a 64-bit build environment whenever possible so that the product-queue isn't unnecessarilly restricted to small sizes only.
How to set an environment variable depends on your user-shell. For example:
User Shell Example Standard UNIX� (e.g. sh, ksh, bash)export PATH=/usr/gnu/bin:/usr/bin:/bincsh-like (e.g.csh, tcsh)setenv PATH /usr/gnu/bin:/usr/bin:/bin
Execute the configure script to customize the
installation process for your particular system. You may use the following
options and arguments, when and if appropriate:
--disable-root-actions- Neither the configure script nor the command make install will not ask you for the superuser's (i.e., root's) password or the LDM user's password; consequently, the installation procedure will be incomplete until the superuser executes the command make root-actions.
--with-ulog- Use the
uloglogging module that was standard prior to LDM version 6.12.15. When appropriate, theulogmodule writes log messages to the system logging daemon. Because enabling such use was the single greatest impediment to correctly using the LDM (and for other reasons), theulogmodule has been replaced by one that writes directly into the LDM log file when appropriate, yet still supports LDM log file rotation.--enable-logging=localn- Configures the LDM to use the localn facility when logging messages to the system logging daemon. If you have a previous LDM installation, then you should use the same facility. The default is
local0. Note that, by default, log messages will be written directly into the LDM log file, when appropriate, unless the previous option is specified.--localstatedir=volatile_dir- Configures the LDM to use volatile_dir (e.g.,
/var/ldm) as the root directory for highly volatile files such as the LDM product-queue, LDM logfile, and LDM metrics files. In general, such files should not be backed-up because of their volatility, so having the root-directory for such files reside in a disk partition that's not backed-up is a good idea. Be aware, however, that this directory must be on a locally mounted disk because the LDM product-queue is memory-mapped, file-locked, and is accessed more often than free beer at a frat party. The default is$HOME/var. NOTE: This option will not work if a pre-6.9 version of the LDM has been installed because then this version wouldn't use the product-queue that already exists.--disable-max-size- By default, if the C compiler is c89(1) or c99(1), then the configure(1) script will attempt to obtain as large a programming environment as possible in order to support a product-queue that is larger than 2^31 bytes in size. This option disables that attempt so that the CC, CPPFLAGS, CFLAGS, and LDFLAGS variables are used verbatim.
--disable-setpgid-exec- By default, every process created by a pqact(1) EXEC action will be made a process group leader so that it will not receive signals sent to the LDM's process group. This is done because the process is likely not prepared to handle such signals. Disabling this feature will cause those processes to receive those signals.
--with-noaaport- Include support for ingesting data-products from a NOAAPORT receiver. This option is disabled by default because most sites don't have a NOAAPORT receiver. NOAAPORT ingestion webpages.
--with-gribinsert- Include support for converting GRIB2 messages in a file into LDM data-products and inserting them into an LDM product-queue. This option is disabled by default because most sites don't need this capability.
CC=path- Configures the build process to use path as the pathname of the C compiler (e.g.,
CC=/usr/gnu/bin/gcc).CPPFLAGS=...- C preprocessor options used by the build process (e.g.,
CPPFLAGS=-UNDEBUG).CFLAGS=...- C options used by the build process (e.g.,
CFLAGS=-g).LIBS=...- Additional libraries used by the build process (e.g.,
LIBS="-L/opt/lib -lrpcsoc").
Use of the above can be necessary due to the vagaries of build environments. Note that some of the computer systems can build both a 32-bit and a 64-bit LDM system. We strongly recommend that you choose a 64-bit build environment whenever possible so that the product-queue isn't unnecessarily restricted to small sizes only. Note that, by default, the configure(1) script will attempt to support a large product-queue if the C compiler is c89(1) or c99(1)).
When executing the configure script, redirect both the
standard output and standard error streams to the file
configure.log. The relevant command depends on your user-shell.
For example:
Where "
User Shell Example Standard UNIX� (e.g. sh, ksh, bash)./configure ... >configure.log 2>&1
csh-like (e.g.csh, tcsh)./configure ... >&! configure.log
..." represents installation-specific arguments and should
not be entered literally.
Because certain aspects of the LDM require root privileges (e.g., listening on port 388, using the system logging daemon), the configure script will ascertain if you can access those privileges. The script will ask you for your password and, possibly, the superuser's (i.e. root's) password. The script doesn't store or transmit this information, it simply uses the passwords to ascertain if you have access to the necessary privileges.
If you don't have access to root privileges (or don't trust the configure script) then simply enter nonsense when asked for the passwords. The superuser will subsequently have to execute an additional step in order to complete the installation process.
Inspect the file configure.log to verify the configuration
process. If an error occurred, then the reason for the error can often be
found in the file config.log (note the slightly different
name).
If you email the UPC because of a
problem with this step, be sure to enclose the files configure.log
and config.log.
Use a make(1) utility
appropriate for your system to build and install the package,
redirecting both standard output
and standard error to the file make.log.
The relevant command depends on your user shell. For example:
User Shell Command Standard UNIX� (e.g. sh, ksh, bash)make install >make.log 2>&1csh-like (e.g.csh, tcsh)make install >&! make.log
Inspect the file make.log to verify the build and installation
process. If something went wrong that you think might be fixed by setting the PATH environment variable or by invoking the configure script differently (such
as by using the cc compiler rather than the c89
compiler) then return to the clean-up step above.
If you email the
UPC
because of a problem with this step, be sure to
enclose the files configure.log,
config.log, and
make.log.
(Optional) If you decided that the just-built LDM system should work with the previous product-queue from a version 6.1 (or earlier) LDM, then verify that it does so by executing the command
If this indicates that the product-queue is invalid, then you must either reinstall this package -- starting with the clean-up step above -- and specify a different programming environment via the../bin/pqcheck
CC environment variable
(e.g. cc -m32 instead of
cc -m64)
before re-executing the configure script, or
you will have to remove the previous
product-queue and
create a new, empty one using the programs of this package before starting
the new LDM.
If the configure script was unable to access superuser privileges, then
the superuser must execute make root-actions to finish
the installation. For example:
Note that this example requires the superuser's password.su root -c 'make root-actions'
Among other things, this step is necessary for the
LDM server to listen on port 388 (which is
a restricted port)
and for the LDM's hupsyslog(1) utility
to notify the system logging daemon when a new log-file has been
created.
(Optional) Use the make(1) utility to clean-up after yourself.
make clean
Click here to see what gets installed where in a canonical installation process.