This man page describes the characteristics of data storage modules (public modules) for use by the Solaris Dynamic Host Configuration Protocol (DHCP) service.
Public modules are the part of the DHCP service architecture that encapsulate the details of storing DHCP service data in a data storage service. Examples of data storage services are NIS+, Oracle, and ufs file systems.
Public modules are dynamic objects which can be shipped separately from the Solaris DHCP service. Once installed, a public module is visible to the DHCP service, and can be selected for use by the service through the DHCP service management
interfaces (dhcpmgr(1M), dhcpconfig(1M), dhtadm(1M), and pntadm(1M)).
Public modules may be provided by Sun Microsystems, Inc or by third parties.
The Solaris DHCP service management architecture provides a mechanism for plugging in public module-specific administration functionality into the dhcpmgr(1m) and dhcpconfig(1m) utilities. This functionality is in the form of a Java Bean, which is provided by the public module vendor. This Java Bean collects public module-specific configuration from the user (you) and provides it to the Solaris DHCP service.
The Solaris DHCP service bundles three modules with the service, which are described below. There are three dhcpsvc.conf(4) DHCP service configuration parameters pertaining to public
modules: RESOURCE, PATH, and RESOURCE_CONFIG. See dhcpsvc.conf(4) for more information about these
This module stores it's data in ASCII files. Although the format is ASCII, hand-editing is discouraged. It is useful for DHCP service environments that support several hundred to a couple thousand of clients and lease times are a few hours
This module's data may be shared between DHCP servers through the use of NFS.
This module stores it's data in binary files. It is useful for DHCP service environments with many networks and many thousands of clients. This module provides an order of magnitude increase in performance and capacity over SUNWfiles.
This module's data cannot be shared between DHCP servers.
This module stores its data within a NIS+ domain. It is useful in environments where NIS+ is already deployed and facilitates sharing among multiple DHCP servers. This module suports several hundred to a few thousand clients with lease times
of several hours or more.
The NIS+ service should be hosted on a machine with ample CPU power, memory, and disk space, as the load on NIS+ is significant when it is used to store DHCP data. Periodic checkpointing of the NIS+ service
is necessary in order to roll the transaction logs and keep the NIS+ service operating at its highest efficiency. See nisping(1M) and crontab(1) for more information.