Schema Kits

Schema Kits

To briefly review, a schema kit consists of three main parts:

Schema Definition
This is the definition of the object types that can be stored in the database. Each object type is defined in terms of the fields it contains, restrictions on those fields (allowed/disallowed characters, etc), and the name of any custom plug-in class which will define behavior for actions on objects of that type. The Ganymede Admin Console provide a graphical schema editor for developing and modifying schema definitions.

Custom Plug-ins
One of the most powerful aspects of Ganymede is the ability to write custom java code that can act as a plug-in to define the behavior of the server when acting on newly defined objects. For example, there may be certain consistency checks that must be made when modifying a DNS Zone object, but which would make no sense in the context of editing a User object. Creating a new subclass of the DBEditObject class (the base class for defining object behavior) and specifying in the DNS schema that this custom class defines the logic for manipulating Zones allows the server to manage the previously unknown Zone object type appropriately.

Builder Tasks
Once the new object types are defined in the schema and custom plug-ins are written to manage their behavior, one additional step may be necessary. For things like NIS, DNS, LDAP, etc., updates made in Ganymede need to be propagated through the network. Ganymede handles this through the use of "Builder Tasks." These are subclasses of the GanymedeBuilderClass, customized to the task at hand. A builder task has two stages. The first stage creates a lock on the database while it dumps out the relevant information. The lock ensures that the database remains in a consistent state during the dump. Once stage one is finished, the lock is released and stage two begins. This second stage takes the information generated in the first stage and does whatever is needed to propagate the new information through the network. This may involve running external scripts, generating data files, etc.

Early on in the life of Ganymede, a schema kit was written for managing DNS here at Applied Research Laboratories. It was designed to support transitioning from GASH, the management software used prior to Ganymede. As a result, it works well for the specific arrangement at the lab, and is currently in use here, but would be practically unusable for any network setup not previously administered using GASH.

The GASH schema kit contains a custom builder task which takes the DNS-related objects in the Ganymede database and generates a source file that can then be processed by an external script into the appropriate DNS db files. Currently, the source file that the GASH schema kit produces is identical in format to the original "hosts_info" file generated by GASH. Creating the same output file as GASH allows the use of existing scripts and configuration files, but there are several drawbacks to remaining tied to the hosts_info structure.

The hosts_info file has a very rigid structure which is not very user friendly. Information for a single host is spread throughout the file, with data separated by an unintuitive mixture of spaces, commas, and colons. This means that writing a script to extract pertinent data is much more difficult than necessary, and any addition or modification of data fields can require substantial changes to the code that processes the file. It also limits the applicability of the information to a single, very specific, perl script. It would be more useful if the data existed in a standard format which was both easily understood by humans and easily accessed by other applications.

The actual content of the hosts_info file is also somewhat restrictive. There is no representation of forward or reverse zone information such as the REFRESH/RETRY/EXPIRE values of the DNS db file header, nor any support for multiple zones at all. Limitations like these require the current perl script to access external data files or use values hard-coded into the script, resulting in the unnecessary burden of maintaining multiple files of data which should really be held in Ganymede. In addition, hosts_info contains extra information like room number and user that, since not used in the generation of the DNS files, is extraneous. Given GASH's rigidity and singleness of purpose, the hosts_info file fulfills its role adequately, but it is just not flexible enough to extend to non-GASH DNS configurations.

The overall strategy, then, is to develop a schema kit that can support DNS in a manner that is not tied to any particular network configuration, but that is as flexible as DNS itself. This involves defining in the schema the DNS-related object types previously discussed, writing the custom code for managing those object types, and writing the builder tasks for generating the DNS db files used by BIND. To achieve any degree of flexibility in DNS configuration, the builder task must output data in a format other than the hosts_info file.


Brian O'Mara
Last modified: Thu Jul 20 17:07:07 CDT 2000