EuroMUG '96

Daylight Database Security, Caching, and Other Issues

An updated summary of relevant theory and administration.

Motivation

The following topics have been chosen because there is a great deal of flexibility in the configuration of Daylight servers and databases in these areas. Hence, there are also many choices to be made by database administrators to optimize performance, security, and convenience of their Daylight software installation. Here we try to provide some straightforward background and guidance to assist in these choices.

SECURITY

Security is control over access to data and other resources. The Daylight system is concerned with:
  1. Access to the Daylight servers (Thor, Merlin, Daytools).
  2. Access to data in databases.
The security of the system is dependent upon the underlying filesystem permissions. For this reason we recommend that all software and databases are owned by a single user "thor", and that the servers are run by thor. Other users should be able to run the client executables.

Server Security

Server access is controlled by a system of users and passwords. This user list is completely separate from the list of unix users. However, some Daylight client programs (e.g., xvmerlin) may use the unix username as a "guess" to attempt server access. The list of Daylight users and passwords is contained in the file dy_passwords.dat, located in $DY_ROOT/etc by default or specified by environment variable DY_DATABASE_PASSWORDS_FILE. Although this file may be easily edited by hand, it is designed to modified by inputs to the sthorman program.

Security levels:

Example dy_passwords.dat file: 

	host:*only*
	host:gator
	host:corona
	user:norah:1aA3h3azZaqw23DS
	user:jj:
	user:june:GjkO96REnK2G1Waw
	user:mug:AsDF12REIO9PlLYb
	user:thor:
	user:thorinfo:

Note: if desired, a separate passwords file may be used by the DayToolserver, specified by the environment variable DY_TOOLSERVER_PASSWORDS_FILE.

Database Security

Each database has three passwords:

In practice, read/write access is sufficient to severly or completely corrupt a database. Thus, the executive password may be most useful for preventing unauthorized, accidental, inconvenient or catastrophic "boo-boos", while write password is responsible for securing the data from corruption.

Other Security Tricks

  1. If a directory is not included in DY_DATABASE_PATH, it will not be listed by "thorls" or other clients. Thus, it is somewhat hidden. However, it may still be accessed by specifying the exact path.

CACHING

Caching is using RAM instead of disk to improve speed and efficiency. Daylight caching may be specified by the configuration of a database, or initiated by client request if allowed by configuration.

Caching configuration specifications are normally made by thormake, thorchange, or sthorman.

The option CACHE_LEVEL is ignored unless CACHE_WHEN is ALWAYS. 

 -CACHE_WHEN NEVER
      Disable caching; all data remain in the disk files.
      Ignore caching requests from Thor clients.

 -CACHE_WHEN OK
      Cache if, when, and as specified by a Thor client.
      (Synonymous with "ON_REQUEST".)

 -CACHE_WHEN ALWAYS

      -CACHE_LEVEL WRITETHRU
           Read hashtable from RAM, write to disk (and RAM).
      -CACHE_LEVEL READWRITE
           Read and write hashtable in RAM.  Disk synced when necessary.
      -CACHE_LEVEL WRITETHRU_ALL
           Read entire database from RAM, write to disk (and RAM)
      -CACHE_LEVEL READWRITE_ALL
           Read and write entire database in RAM.  Disk synced when necessary.

By default, both primary data and cross-references are cached. However, we can select one or the other only. Note that both primary and xref data have separate hash tables and datafiles. 

      -CACHE_WHAT XREFS
      -CACHE_WHAT DATA

Possible values in the .THOR header file: 

	cache level: 
	cache level: NEVER
	cache level: ON_REQUEST
	cache level: ALWAYS WRITETHRU
	cache level: ALWAYS WRITETHRU XREFS_ONLY
	cache level: ALWAYS WRITETHRU DATA_ONLY
	cache level: ALWAYS READWRITE
	cache level: ALWAYS READWRITE XREFS_ONLY
	cache level: ALWAYS READWRITE DATA_ONLY
	cache level: ALWAYS WRITETHRU_ALL
	cache level: ALWAYS WRITETHRU_ALL XREFS_ONLY
	cache level: ALWAYS WRITETHRU_ALL DATA_ONLY
	cache level: ALWAYS READWRITE_ALL
	cache level: ALWAYS READWRITE_ALL XREFS_ONLY
	cache level: ALWAYS READWRITE_ALL DATA_ONLY

Another choice to be made is whether to cache the "regular" database, or perhaps the indirect database. For databases where there are a large number of indirect references per TDT, caching the indirect database can provide the greatest performance gains.

OTHER DATABASE CONFIGURATION ISSUES

Database Holding

"Holding" a database keeps it open when no clients are using it. This improves performance of frequently-opened and cached databases. Holding is independent from caching level.

TDT Locking

With record-locking enabled, clients can lock individual records for exclusive access, "commit" and "rollback" changes, and unlock records.

Header (.THOR) file entry: 

	tdt locking: TRUE         (Either present or not.)

Readonly databases

Databases can be configured writable (by default) or readonly. Readonly databases do not create lockfiles, thus they are useable from CDROM. Also it is possible to open one database with two separate Thorservers. Header file entry: 
	read only: TRUE           (Either present or not.)
JJY / 10-Dec-1996