DLXS Daemon: Installing and Configuring

From DLXS Documentation

Main Page > Installing DLXS > DLXS Daemon: Installing and Configuring

DLXS provides network software which allows middleware on one server to transparently search and display content hosted on another. This tool, called a daemon, can be used for a variety of purposes:

• to distribute resources across servers to balance load
• to bridge together resources hosted by different departments on separate servers
• to locate data on a remote or more tightly-secured server while running middleware on a server where staff have login access
• (in theory) to provide inter-institutional repositories of content (some institutions are indeed currently experimenting with such a model)

If you don't plan on doing any of these things, you don't need to install this tool. If you think this sounds interesting and you might want to do it in the future, you can wait until then to install.

If you want to use the DLXS daemon, it makes sense to install it last because

• it has the same requirements as the DLXS middleware, and
• it's not useful until the middleware is up and running anyway.

Installing the DLXS daemon

The DLXS daemon uses configuration files to store site-specific information. The configuration files are in the etc directory of the dlxsd distribution.

1. Make the following modifications to access.conf to specify up to 60 access control parameters.
   1. Add lines to specify allowable domains. For example,

  allow .umich.edu

allows access from any machine in the umich.edu domain, while

  allow .umdl.umich.edu

is more restrictive, allowing access only from the umdl.umich.edu domain, and

  allow .umich.edu
  allow .cornell.edu

permits access from machines at both Cornell and Michigan.

1. 1. Add lines to refuse access from specific domains. For example,

  deny .hackers.org

1. Make the following modifications to verbs.conf to specify how middleware will invoke utilities through the daemon.
   1. Adapt the existing lines with the proper paths to DLXS required software for built-in page viewing functions. For example,

  TIF2GIF /usr/local/bin/tif2web -G -N $1 -g $2 $3 -o $4 $5
  TIF2PDF /usr/local/bin/c42pdf  -o $1 REST_OF_ARGS
  TIF2PNG /usr/local/bin/tif2web -P -N $1 -g $2 $3 -o $4 $5
  XPAT /usr/local/bin/xpat $1 -q -s $2
  DELIVERFILE /bin/cp $1 $2

1. 1. If needed, add lines with new verbs and customized command strings to support extensions you make to DLXS middleware. For example,

  HACKME /bin/mailx -s HereYouGo $1 < /etc/passwd

The positional parameter $1 (you can have up to $9) and the special parameter REST_OF_ARGS shown in the previous example above are used to pass arguments from the middleware to the daemon. They are named in the order supplied ($1, $2, etc.) and are substituted as placed in the command string.
Important note: Clearly, providing the ability for remote execution of commands without authentication makes for huge potential security holes. The "HACKME" example configuration, above, is a ridiculously reckless example of the danger this service can pose if configured improperly. (It emails an extremely sensitive UNIX file to a random recipient.) The daemon provides some protection against this by not allowing certain characters in the arguments (to prevent poisoning), but care should be taken that this tool is not used in such a way as to introduce security risks into your environment.

You can recompile the DLXS daemon if you do not wish to use the binary distribution for your platform, or if you are attempting to run DLXS on a platform other than Linux or Solaris. For further instructions on building the DLXS daemon, consult the file README in the src directory of the DLXS daemon source distribution.

Configuring the Internet services daemon (inetd) to use the DLXS daemon

1. Add the line below to the /etc/inetd.conf (Linux) or /etc/inet/inetd.conf (Solaris) file, as appropriate. For example:

      dlxsd     stream tcp nowait nobody /usr/local/dlxsd/bin/dlxsd    /usr/local/dlxsd/bin/dlxsd
   

   Notes:

   The user ("nobody" in the example above) should be consistent with the userid under which the web server runs.
   • The path to dlxsd should be consistent with where you have installed the binary.

2. Add the line below to the /etc/services (Linux) or /etc/inet/services (Solaris) file, as appropriate. For example:

      dlxsd      620/tcp  # dlxsd server daemon
   

   We recommend using port 620, but if you need to use a different port number, you will need to change the value

   in the port column in your colldb for each class. For information on the colldb, please see the online help in the

   Collection Manager utility.
3. Signal inetd to use the new configuration, typically by issuing the command kill -HUP pid where pid is the process ID of the inetd daemon.