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

Daylight Administration - Class Notes

These notes 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. Licensing

  2. Getting the Software

  3. 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.

  4. Environment Variables
  5. Web Server Configuration

    Daylight web tools require:

  6. Automation

Lab Exercise - Installation


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 Windows or Macintosh client programs.

  5. SMILES and SMARTS Editor
  6. The DayUtilServer provides a means to graphically input SMILES and SMARTS. The client application is JavaGrins.

  7. Useful Environment Variables

Lab Exercise - Clients & Servers


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. Servers

    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 the thorinfo user 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, an 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. Databases

    General database access can be controlled by the DY_DATABASE_PASSWORDS_FILE and is often set to be the same as dy_passwords.dat. Specific database access is controlled by a system of access rights and passwords as described in the file my_database.THOR. This file specifies read, write, and executive privledges and passwords.

    Database security can be mandated in three ways.

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

Lab Exercise - Security


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. Description & Control

    A description of options and allowed values are documented at $DY_ROOT/etc in the common and unix subdirectories in files with a .dat extension. 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.

Lab Exercise - Customization


E. Databases

  1. Installation

  2. Anatomy

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

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

  3. Creation
  4. Special Considerations
  5. Performance

  6. Automation

  7. Survey of Commercial Databases

Lab Exercise - Databases


Daycart

Oracle / SQL Introduction - Dave Wilbur

Daycart - Jack Delany

Daycart Labs:


Daylight Chemical Information Systems Inc.
support@daylight.com