Daylight Summer School 2001, June 5-7 Santa Fe, NM

Daylight Administration - Class Notes

These are intended to be brief notes supplementing and outlining the course material presented in the course Introduction to Daylight. The Daylight manuals should be considered the text for the course and the authoritative documentation, and should be used in conjunction with these notes for best results!

The Daylight Installation and Administration Guide is the relevant manual for this unit.

A. Installation

  1. Getting the Software

  2. Distribution Contents
  3. Environment Variables
  4. Run-time Environment
  5. Licensing

  6. TCP/IP Services

    Note: Some SGI systems are configured to run a web service on the same port as the Daylight Remote toolkit. In cases where the SGI service is not used, disable the following /etc/services entry:

    by removing it or placing a pound sign (#) in column one. Otherwise, one of the services will need to be reconfigured.

  7. Web Server Configuration

    Daylight web tools require:

  8. Automation

B. Clients & Servers

    Daylight software is based on a client/server model.

  1. Storage and Retrieval

    The THOR System, implemented in the ThorServer program, provides data storage and retreival of SMILES, Reaction SMILES, and many other kinds of data. Utilities are provided to allow database customization to suit your needs. Client access is provided through the xvthor application.

  2. High-Speed Search

    The MERLIN System, implemented in the MerlinServer program, provides high-speed searching capabilities on databases. Client access is provided through mcl (Merlin Control Language). The xvmerlin application is a client to both ThorServer and MerlinServer.

  3. Remote Toolkit Programming
  4. The Remote Toolkit is comprised of the DayToolServer and one or more Macintosh or Windows client programs.

  5. SMILES and SMARTS Editor
  6. The DayUtilServer provides graphic description of SMILES and SMARTS. The client application is JavaGrins.

C. Security

    Since the security of the system is dependent upon the underlying filesystem permissions, we recommend that all software and databases are owned by a Daylight administor accouint, usually named "thor". The "thor" account is used to specify allowed users and their passwords, allowed hosts, and other configuration parameters. Servers should be run under the "thor" account. Other user accounts should have read access to binaries and libraries so they can run client programs.

    Access to data resources are controllable at two levels: by server and by database.

  1. Security by Server

    Server access is controlled by a system of users, hosts and passwords as described in the file dy_passwords.dat. This file is located at $DY_ROOT/etc or otherwise specified by the environment variable DY_DATABASE_PASSWORDS_FILE.

    Server security can be mandated in three ways.

    Here's a sample dy_passwords.dat file:

    Note: The software is pre-configured with users "thor" and "thorinfo". The thor user has built-in administrative privileges, and thorinfo has built-in read-only privileges. These users should always be present in the password file.

    Note: Both ThorServer and MerlinServer share the same passwords file ($DY_DATABASE_PASSWORDS_FILE), and database path ($DY_DATABASE_PATH).

    Note: The DayToolServer may be configured to use the same passwords file as defined by the $DY_TOOLSERVER_PASSWORDS_FILE environment variable. If program objects are needed, a allowed directory for program-object executables must be specified (option TOOLSERVER_PROGOB_DIR).

    Note: The password file is completely separate from UNIX password file. In the absence of user specification, some Daylight client programs (e.g., xvmerlin) will use the UNIX usernames to identify and verify server access.

    Note: Although this file is a simple text file and may be easily edited by hand, the sthorman program is designed to modified it.

  2. Security by Database

    Database access is controlled by a system of access rights and passwords as described in the file my_database.THOR. This file is located at $DY_THORDB or may be elsewhere in the environment variable DY_DATABASE_PATH. This file specifies read, write, an executive privledges and passwords.

    Database security can be mandated in three ways.

    Here's a sample excerpt from a my_database.THOR file:

D. Customization

  1. Options

    Daylight applications have a unified options manager whereby options and allowed values are defined, defaults specified, and non-default values can be specified in several ways according to defined precedence.

  2. Schema

    A description of options and allowed values are documented at $DY_ROOT/etc in the common and unix subdirectories in files named filename.dat. A master listing of options is referenced by the DY_OPTIONS environment variable and normally defined in the $DY_ROOT/etc/unix/dy_options.dat file.

    The dy_options.dat is quite powerful as it defines the location of the system (DY_SYSPROFILE) and user (DY_PROFILE) profiles.

    Note: The DY_ROOT, DY_LICENSEDATA and DY_THORDB environment variables are not options.

E. Databases

    For a schematic representation of how Daylight databases work, see the MUG '00 talk, "A Bit Larger Database".

  1. Installation, Configuration & Auxilliaries

  2. Anatomy

    There may be several ways to design the datatypes and databases. Criteria is often based on convenience, compactness, and searchability.

  3. Creation
  4. Considerations
  5. Performance

  6. Automation

  7. Survey of Commercial Databases

Daylight Chemical Information Systems Inc.
support@daylight.com