LDM Source-Code Installation


Short Installation Instructions:

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.


Long Installation Instructions:

  1. Become the LDM User in That User's Home Directory

    Follow this advice on becoming the LDM user.

    Workshop-specific instructions.

  2. Obtain the LDM Source-Distribution

    The LDM source-distribution can be obtained via the command

    wget ftp://ftp.unidata.ucar.edu/pub/ldm/ldm-6.13.13.tar.gz
    
    or by clicking on the appropriate link in the LDM download page. Download the file into the LDM user's home directory.

    The remaining instructions assume that the distribution was downloaded into the LDM user's home-directory.

  3. Unpack the Distribution

    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:

    cd # go to the LDM user's home-directory
    gunzip -c ldm-6.13.13.tar.gz | pax -r '-s:/:/src/:' # unpack the distribution
    
    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 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.

  4. Build and Install the Distribution

    1. Go to the top-level directory of the just-unpacked package. For example

      cd $HOME/ldm-6.13.13/src
      

    2. 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:

      make distclean
      
      Don't worry if this command fails or even fails to execute.
    3. (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:/bin
      csh-like (e.g. csh, tcsh) setenv PATH /usr/gnu/bin:/usr/bin:/bin
    4. 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 ulog logging module that was standard prior to LDM version 6.12.15. When appropriate, the ulog module 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), the ulog module 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:

      User Shell Example
      Standard UNIX (e.g. sh, ksh, bash) ./configure ... >configure.log 2>&1
      csh-like (e.g. csh, tcsh) ./configure  ... >&! configure.log
      Where "..." 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.

    5. 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>&1
      csh-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.

    6. (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

      ../bin/pqcheck
      
      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 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.
    7. If the configure script was unable to access superuser privileges, then the superuser must execute make root-actions to finish the installation. For example:

      su root -c 'make root-actions'
      
      Note that this example requires the superuser's password.

      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.

    8. (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.

    Workshop-specific instructions.