Chapter 1 Overview of Solaris DHCP Data Access Architecture

This chapter presents an overview of the architecture of the Solaris Dynamic Host Configuration Protocol (DHCP) service introduced in the Solaris 8 7/01 operating environment. This overview can help you see where your work will fit into the architecture.

For general information about the Solaris DHCP service, see “About Solaris DHCP (Overview)” in System Administration Guide: IP Services.

The following topics are included:

Modular Framework

The Solaris DHCP service includes the DHCP daemon, administrative tools, and separate data access modules (called public modules) for different data storage facilities. Solaris DHCP provides an API that enables you to write your own public modules, implemented as shared objects, to support any data storage facility you want. When you integrate your public module into the Solaris DHCP framework, the DHCP service stores its data in your database using your public module. Public modules can be delivered independently of the Solaris DHCP service, enabling anyone to develop and deliver modules to support any data storage facility.

The first release of Solaris DHCP using this architecture provides public modules for ASCII files, NIS+, and file-system-based binary data stores. This manual provides information that enables developers to create their own public modules for any database.

DHCP Server Multithreading

The DHCP server implements multithreading, enabling it to service many clients simultaneously. Public modules are required to be MT-SAFE to support multithreading by the DHCP server, and this in itself allows the DHCP service to handle a larger number of clients. However, the capacity of the DHCP server is largely dependent on the capabilities of the data storage facility and the efficiency of the public module used to access the data. You can potentially increase the performance and capacity of your Solaris DHCP service by creating a public module for using a fast, high-capacity data storage facility.

Data Access Layers

The Solaris DHCP modular framework implementation employs the following data access layers:

Application/Service Layer, consisting of all consumers of DHCP service data such as the DHCP daemon (in.dhcpd), command line management utilities (pntadm, dhtadm, dhcpconfig), dhcpmgr, and report generators. These data consumers interface with the DHCP service using calls to API functions implemented by the Framework Configuration Layer of the architecture.
Framework Configuration Layer, consisting of the shared library libdhcpsvc.so and the /etc/inet/dhcpsvc.conf configuration file. The Framework Configuration Layer connects the Application/Service Layer and the Service Provider Layer. See The Framework Configuration Layer for more information about the Framework Configuration Layer.
Service Provider Layer, consisting of public modules that implement the Service Provider API functions, which are used by the Application/Service Layer through the Framework Configuration Layer to manipulate the data store containers and the records within them. The data store containers are the dhcptab and DHCP network tables.

The following figure shows the interaction of the architecture layers.

Figure 1–1 Architecture of Data Store Access in DHCP Service

Diagram with Application/Service Layer on top, Framework Configuration Layer in middle. Service Provider Layer on bottom connects to data store.

The Framework Configuration Layer

Functions implemented in libdhcpsvc.so are used by the Application/Service Layer to:

locate, load, and unload public modules
manage data container version changes
access the data store containers
manipulate data store records in the containers

The /etc/inet/dhcpsvc.conf contains a number of configuration parameters for the DHCP service, including the following keywords relevant to the public module developer:

RESOURCE: Public module to load. The value of RESOURCE matches the public module name. For example, the RESOURCE=SUNWfiles refers to public module ds_SUNWfiles.so. Naming the Public Module and Data Store Containers explains the rules for naming public modules.
PATH: Location of DHCP containers within the data service that the public module exports. The value of PATH is specific to the data service. For example, a UNIX™ path name would be assigned to PATH for the SUNWfiles resource.
RESOURCE_CONFIG: Configuration information specific to the public module. This is an optional keyword that you can use if the data service requires configuration information, such as authentication from the user. If you use this keyword, you must provide a public module management bean to prompt the user for information to set the keyword value. See Data Service Configuration and DHCP Management Tools. The module must also export the configure() function to receive the value of this keyword during module load time. See configure() for more information.

The Framework Configuration Layer also provides to the Service Provider Layer an optional API synchronization service, described in Synchronizing Access to File-System-Based Containers.

The Service Provider Layer API

The Service Provider Layer API consists of functions, data structures, and manifest constants contained in the /usr/include/dhcp_svc_public.h file.

The functions are summarized in the following table, with links to sections with more detail about each function.

Table 1–1 Service Provider Layer API Functions


API Function	Use
General functions for all data store containers
`configure()`	Pass a configuration string to the data store. Optional function.
`mklocation()`	Create the location in which the data store will reside.
`status()`	Return general status information for the data store.
`version()`	Return the version of the Service Provider Layer API implemented by the data store container.
Functions for `dhcptab` containers
`list_dt()`	Return the `dhcptab` container name.
`open_dt()`	Open or create the `dhcptab` container.
`lookup_dt()`	Perform a query for records in the `dhcptab` container.
`add_dt()`	Add a record to the `dhcptab` container.
`modify_dt()`	Modify an existing record in the `dhcptab` container.
`delete_dt()`	Delete a record from the `dhcptab` container.
`close_dt()`	Close the `dhcptab` container.
`remove_dt()`	Remove the `dhcptab` container from the data store.
Functions for DHCP network containers
`list_dn()`	Return a list of DHCP network container names.
`open_dn()`	Open or create a DHCP network container.
`lookup_dn()`	Perform a query for records in a DHCP network container.
`add_dn()`	Add a record to a DHCP network container.
`modify_dn()`	Modify an existing record in a DHCP network container.
`delete_dn()`	Delete a record from a DHCP network container.
`close_dn()`	Close a DHCP network container.
`remove_dn()`	Remove a DHCP network container from the data store.

Data Store Containers

The dhcptab and DHCP network tables are referred to generically as data store containers. By default, Solaris DHCP provides support for the container formats shown in the following table.

Data Service Supported	Public Module
File-system-based, ASCII format	`ds_SUNWfiles.so`
NIS+ service	`ds_SUNWnisplus.so`
File-system-based, binary format	`ds_SUNWbinfiles.so`