The Daylight Installation and Administration Guide is the relevant manual for this unit.
|v471||- software version directory|
|thordb||- database directory|
The operating system needs to know about the port numbers for Daylight servers. The following should be in the /etc/services file:
You can run multiple servers, each require an entry in the /etc/services file:
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:
|consolesgi-esphttp||5554/tcp # ESP web console server port|
by removing it or placing a pound sign (#) in column one. Otherwise, one of the services will need to be reconfigured.
testlicense: Command not found.
Here's an example for setting DY_ROOT and PATH:
testlicense: can't open license file ("").
If the license is expired, tampered, or erroneous, Daylight programs will not execute, i.e.,
Invalid license: license expired on 2001 01 01 (today is 2001 05 31 2053.59 GMT)
Invalid license: "#license key:" is wrong -- doesn't match license's data
A valid license gives:
Your license is valid.
ld.so.1: thorserver: fatal: libdt_apputils.so: open failed: No such file or directory
Programs dynamically link common code at run-time. The common code, referred as libraries or shared objects, are located at $DY_ROOT/lib. Here's an example for setting LD_LIBRARY_PATH:
Note: Some SGI's with multiple 32-bit/64-bit binary formats may require LD_LIBRARYN32_PATH and/or LD_LIBRARY64_PATH enviroment vairables.
Note: Old 32-bit format libraries are at $DY_ROOT/libo32 and 64-bit libraries are at $DY_ROOT/lib64
Daylight web tools require:
Lab Exercise - Installation
Daylight software is based on a client/server model.
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.
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.
The Remote Toolkit is comprised of the DayToolServer and Windows or Macintosh client programs.
The DayUtilServer provides a means to graphically input SMILES and SMARTS. The client application is JavaGrins.
|DY_THOR_LOG_FILE||- log file for data retreival (written by ThorServer program)|
|DY_MERLIN_LOG_FILE||- log file for data search (written MerlinServer program)|
|DY_MERLIN_SERVER_LIST||- machine names that are a MerlinServer|
|DY_MERLIN_MEMORY_LIMIT||- maximum memory size of MerlinServer|
Lab Exercise - Clients & Servers
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.
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.
|Restricted Host Mode||- match both user and host|
|Equivalent Host Mode||- match either user or host|
|None||- empty password file, e.g., thorserver -DATABASE_PASSWORDS_FILE ""|
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.
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.
|readpw||- read only access|
|writepw||- add, modify and delete access|
|executivepw||- ultimate access|
Here's a sample excerpt from a my_database.THOR file:
Lab Exercise - Security
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.
Note: All Daylight program options have a corresponding environment variable named DY_<option name>.
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
There may be several ways to design the datatypes and databases. Criteria is often based on convenience, compactness, and searchability.
Datatypes are frequently common to all databases at a particular site (i.e. all regular databases refer to the same datatypes database); this makes the data from all databases intercompatible. Standardized and tempplate datatypes are provided at $DY_ROOT/data/datatypes.
Frequently occuring data may best be represented indirectly. By using an indirect auxilliary database, a common datum my be stored only once, and compact indirect references stored in its place.
A monomer database defines a table of monomers, or molecular building blocks, which may be referenced by monomer symbols in a Chortles. By using a monomer auxilliary database, combinatorial mixtures can be specified by a Chortles, which denote a mixture of 1000's of individual compounds. SMILES represents mixtures by replacing variable positions with the wildcard ("*").
Regular data is the essence of the database. This is where the primary information is stored.
For a schematic relationship of how Daylight databases work, see the MUG '00 talk, "A Bit Larger Database".
Databases are created using sthorman or thormake Creating a database means creating the small files which are in the format required by the Daylight database servers. These files must then be loaded with data to be useful. When creating a database, the following must be specified:
Several conversion programs are provided with the SMILES Toolkit for converting structure files in other formats to Daylight SMILES-rooted TDTs. These programs are provided as contributed source code, and found in $DY_ROOT/contrib/src/applics/convert.
We recommend that the administrator take responsibility for the molecules loaded into the Daylight system to make best use of its capabilities. Consistency of valence models and tautomer representations is a prerequisite to reliable and comprehensible queries. (E.g., nitro-group representation and search). For information on "garbage-in, garbage-out (GIGO)", see A Beginner's Guide to Responsible Parenting or Knowing Your Roots, John Bradshaw, EuroMUG '98, Cambridge, UK.
Many features are available only to SMILES-rooted databases, making it highly desireable to use SMILES as the root of all TDTs. However, this may be impossible for substances of unknown or non-determinate structure (e.g., beeswax, Fresca, eye of newt). Thor permits TDTs rooted in non-SMILES identifiers, but does not allow sub-trees with additional identifiers in these TDTs. Only data belonging to the ID is allowed.
Non-identifier crossreferences are denoted by a preceding slash "/". These datatypes may occur anywhere and are regarded syntactically as data. However, Thor will automatically create a cross-references corresponding to this type of datum, thereby providing access to the root TDT, independent of whether it's a SMILES.
The corresponding entry in the my_database.THOR is:
tdt locking: TRUE
read only: TRUE
Note: Databases are configured writable by default.
Sufficient physical memory (RAM) is essential to the operation of the MerlinServer program. The MerlinServer has been optimized to achieve high speed searching in RAM, and will run prohibitively slow if swapping occurs. The Daylight administrator should consider the following in determination of memory requirements:
While it is possible to estimate memory usage a priori, in practice, it is much simpler to obtain pool-size information from the MerlinServer log file DY_MERLIN_LOG_FILE. Pool size data for commercial databases is available from Daylight.
Modern operating system caching has reduced the significance of caching performed by Daylight software. Nonetheless, Daylight database caching options are available.
Most administrators find it convenient to start and stop the Daylight servers using scripts designed to do this safely and efficiently. The start script ($DY_ROOT/contrib/src/admin/START_DCIS_SERVERS) can specify the environment and databases for loading, log files, etc. The stop script ($DY_ROOT/contrib/src/admin/KILL_DCIS_SERVERS) can evict users and ensure databases are properly closed before stopping the server processes. These scripts can be invoked by the operating system automatically at boot and shutdown.
Many other database administration tasks are well suited to the use of scripts. Building databases, saving them to files, extracting subsets, performing periodic searches, obtaining database statistics and server access statistics. All these and more may be automated using scripts and the Daylight suite of ThorFilters programs.
Lab Exercise - Databases