Duckwater: Simplified Name Services Management - Profiles

Contents

• 1   Introduction
• 2   Profile/configuration types
• 3   Profiles description and contents
  • 3.1   Implementation of name service profiles in SMF
  • 3.2   Name Service Switch Profile (NSSP)
    • 3.2.1   Automatic
    • 3.2.2   Links to NSBECs
  • 3.3   Name Service Back-End Configuration (NSBEC)
    • 3.3.1   DNS NSBEC
    • 3.3.2   LDAP NSBEC
    • 3.3.3   NIS NSBEC
    • 3.3.4   NIS+ NSBEC
• 4   Implementation in SMF

1   Introduction

This document describes what types of name service configurations there are, the contents of each of them, the implementation in SMF - both properties and their types.

2   Profile/configuration types

There are two name service profile/configuration types: Name Service Switch Profile (NSSP, a.k.a. profile) and Name Service Back-End Configuration (NSBEC - a.k.a. back-end configuration).

NSSP is a configuration for name service switch, currently being configured through nsswitch.conf(4). Additionally, there are pointers to NSBECs for each source type (DNS, NIS, NIS+, LDAP). NSSP + zero (for files only naming) or more NSBECs form a set of configuration form name service subsystem on (Open)Solaris OS.

NSBEC holds configuration information for particular back-end - e.g. DNS, NIS, NIS+, LDAP.

3   Profiles description and contents

This part describes the contents of NSSP and four different NSBECs as implemented in SMF. Also, semantics of a property values are described where needed.

3.1   Implementation of name service profiles in SMF

Due to unavailability of Enhanced SMF Profiles, Duckwater project implements its own profile management framework. We have decided to implement the profiles (NSSP) and back-end configurations (NSBEC) using property groups of particular name service related services/instances in SMF. We plan to convert the proprietary Duckwater profiles to Enhanced SMF Profiles once they are available in (Open)Solaris. We believe the transition will be quite straightforward as even Duckwater uses SMF to store the profile/configuration data.

The profile-implementing property group name format is profile_<name>. So, for example, test1 LDAP NSBEC FMRI is:

svc:/network/ldap/client:default/:properties/profile_test1

Every name services related instance in SMF also has one special property group dedicated to metadata called prof_META which, for now, has only one property active storing the name of currently active profile/configuration of particular type. E.g., the example below shows, that we have two profiles - test1 and test2 - and test1 is marked as being active:

prof_META/active    test1
profile_test1/prop1 ...
profile_test1/prop2 ...
...
profile_test2/prop1 ...
...

Using the simple scheme, we can easily store multiple profiles/configurations for name service switch and name service back-ends without any additional support from SMF. The drawback of this approach is that the switching between profiles - e.g. switching name service configuration from profile1 to profile2 has to be driven by nsadm(1M) - in other words, users won't be able to use stock SMF tools - svccfg(1M) or svcadm(1M) - to reconfigure name service subsystem, instead they would have to use nsadm(1M) to do it for them.

3.2   Name Service Switch Profile (NSSP)

As stated before, this profile configures name service switch - configuration which is traditionally found in /etc/nsswitch.conf. Additionally, it points to NSBECs for DNS, NIS, NIS+ and LDAP (zero or one for each back-end type). It is easily extensible to support new name service source type (or back-end) if needed - e.g. to support Microsoft Active Directory through nss_ads.

Please note, that we are not proposing to EOL /etc/nsswitch.conf completely. We are aware that it's well known interface used by administrator as well as 3rd party software. For more information about handling legacy configuration files in Duckwater, please see [legacyconffiles].

With respect to SMF services, this configuration will be stored as a property group in svc:/system/name-service-cache:default instance.

The full grammar for db_ property values is identical to the counterparts in nsswitch.conf(4).

3.2.1   Automatic

auto value for db_* properties means that the name service switch (nscd(1M)) should decide which source types to use based on the back-end availability information provided to it by back-ends and delivered using nsutil(1M) [nsutil]. This might also be implemented as a part of nscd's back-end monitoring facility.

auto value for bec_* properties means that special NSBEC instance for particular source type should be auto-configured (name service servers discovered using DHCP, DNS or mDNS where applicable).

3.2.2   Links to NSBECs

The idea is, that NSSP will include pointers to NSBECs (max one of each type), so there's a connection between configuration of switch and configurations of particular source types (name service back-ends). E.g. the NSSP validation procedure will have a chance to issue an error should for example particular source type being used in one or more databases, but no NSBEC of such type being "linked" to the particular NSSP.

3.3   Name Service Back-End Configuration (NSBEC)

Name Service Back-End Configuration (NSBEC) includes configuration for particular name service back-end. The reason these are not included in the NSSP is that they can exist separately, serving as independent configuration for particular name service back-end or name service tools specific for particular back-end type, like ldapaddent(1M) or ldaplist(1).

3.3.1   DNS NSBEC

As /etc/resolv.conf(4) is a Standard interface (Interface Stability: Standard BIND 8.3.3) we'll have to maintain backwards compatibility and generate the /etc/resolv.conf file from configuration repository at appropriate time and/or allow this file to be imported into the configuration repository.

Currently, the client DNS resolver is configured by SMF network-service net-svc script and it uses the information from DHCP (through dhcpinfo(1) utility). This is unfortunately not flexible enough. We need to generate the file when dns/client service is either being started or refreshed.

The DNS NSBEC properties are modeled based on /etc/resolv.conf and will be stored in property group of SMF service svc:/network/dns/client.

3.3.2   LDAP NSBEC

The configuration files for LDAP name service back-end is not public. It currently resides in /var/ldap directory.

• none
• simple
• sasl/CRAM-MD5
• sasl/DIGEST-MD5
• sasl/GSSAPI
• tls:simple
• tls:sasl/CRAM-MD5
• tls:sasl/DIGEST-MD5

• anonymous
• proxy
• self

Question: Should the property names be derived from what's in /var/ldap/ldap_client_file or should they be named after equivalent command-line options to ldapclient(1M)? I'd rather name them based on names of command-line options because users are more likely to be familiar with those.' ldapclient(1M)

LDAP type NSBEC(s) will be stored as a property group(s) in SMF service svc:/network/ldap/client.

3.3.3   NIS NSBEC

The configuration files for NIS name service back-end are not public. They currently reside in /var/yp directory.

servers set to auto means that ypbind(1M) will be run with -broadcast option.

If domain is empty, domain from NSSP to which that this particular NSBEC is associated to is used.

NSBEC(s) of this type will be stored as a property group(s) in SMF service svc:/network/nis/client.

3.3.4   NIS+ NSBEC

The configuration files for NIS+ name service back-end are not public. They currently reside in /var/nis directory.

server set to auto means that broadcasting will be used to locate NIS+ server.

If domain is empty, domain from NSSP to which that this particular NSBEC is associated to is used.

NSBEC(s) of this type will be stored as a property group(s) in SMF service svc:/network/rpc/nisplus.

4   Implementation in SMF

The ideal way of implementing the name service profiles is to leverage Enhanced SMF Profiles project. That way the SMF framework could be used for profile activation (and deactivation) - either by invoking svcadm(1M) (or possibly svccfg(1M)?) commands or by calling functions from libscf(3LIB) library. That way 3rd party software could manipulate name service profiles without having to rely on name service specific commands (like nsadm(1M)) or name service profile manipulation library (libnsconf).