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, vet your build environment against the table of successful build environments and unsuccessful build environments. Choose a 64-bit environment if possible. Then, do the following:
$ su - ldm
$ wget ftp://ftp.unidata.ucar.edu/pub/ldm/ldm-6.10.1.tar.gz
$ gunzip -c ldm-6.10.1.tar.gz | pax -r '-s:/:/src/:'
$ rm ldm-6.10.1.tar.gz # optional
$ cd ldm-6.10.1/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 use this command, instead:
$ gunzip -c ldm-6.10.1.tar.gz | (mkdir -p ldm-6.10.1 &&
cd ldm-6.10.1 && tar -xf - && mv ldm-6.10.1 src)
The root of the installation tree will be $HOME/ldm-6.10.1
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.10.1.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.10.1/src
using the gunzip(1) and pax(1)
utilities.
For example:
NOTE: If you don't have the pax(1) utility, then use this command, instead:cd # go to the LDM user's home-directory mkdir ldm-6.10.1 # make a version-specific subdirectory cd ldm-6.10.1 # go to the version-specific subdirectory gunzip -c $HOME/ldm-6.10.1.tar.gz | pax -r # unpack the distribution mv ldm-6.10.1 src # rename the source directory
$ gunzip -c ldm-6.10.1.tar.gz | (mkdir -p ldm-6.10.1 &&
cd ldm-6.10.1 && tar -xf - && mv ldm-6.10.1 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.10.1/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. You should compare your build environment against the table of successful build environments and also against the table of unsuccessful build environments to determine if you need to perform this step. 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 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:
--enable-logging=localn- Configures the LDM to use the localn facility for logging messages. If you have a previous LDM installation, then you should use the same facility. The default is
local0.--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.
--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. You should compare your build environment against the table of successful build environments and also against the table of unsuccessful build environments to determine if you need particular arguments. 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 unnecessarilly 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:
User Shell Example Standard UNIX® (e.g. sh, ksh, bash)./configure ... >configure.log 2>&1
csh-like (e.g.csh, tcsh)./configure ... >&! configure.log
Because certain aspects of the LDM require root privileges (e.g., listening on port 388, using the system logging daemon), the configure script will acertain 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 acertain 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.