Wiki code for [NEW!] Name Service Profiles

Hide Line numbers
1: = Duckwater: Simplified Name Services Management - Profiles
2: 
3: |=Author:|Tomas Heran <[[tomas.heran@sun.com>>mailto:tomas.heran@sun.com]]>
4: |=Version:|DRAFT 1.0
5: |=Date:|2008-02-13
6: 
7: Contents
8: 
9: * [[1   Introduction>>#introduction]]
10: * [[2   Profile/configuration types>>#profile-configuration-types]]
11: * [[3   Profiles description and contents>>#profiles-description-and-contents]]
12: ** [[3.1   Implementation of name service profiles in SMF>>#implementation-of-name-service-profiles-in-smf]]
13: ** [[3.2   Name Service Switch Profile (NSSP)>>#name-service-switch-profile-nssp]]
14: *** [[3.2.1   Automatic>>#automatic]]
15: *** [[3.2.2   Links to NSBECs>>#links-to-nsbecs]]
16: ** [[3.3   Name Service Back-End Configuration (NSBEC)>>#name-service-back-end-configuration-nsbec]]
17: *** [[3.3.1   DNS NSBEC>>#dns-nsbec]]
18: *** [[3.3.2   LDAP NSBEC>>#ldap-nsbec]]
19: *** [[3.3.3   NIS NSBEC>>#nis-nsbec]]
20: *** [[3.3.4   NIS+ NSBEC>>#id1]]
21: * [[4   Implementation in SMF>>#implementation-in-smf]]
22: 
23: = [[1   Introduction>>#id2]]
24: 
25: 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.
26: 
27: = [[2   Profile/configuration types>>#id3]]
28: 
29: 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).
30: 
31: **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.
32: 
33: **NSBEC** holds configuration information for particular back-end - e.g. DNS, NIS, NIS+, LDAP.
34: 
35: = [[3   Profiles description and contents>>#id4]]
36: 
37: 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.
38: 
39: == [[3.1   Implementation of name service profiles in SMF>>#id5]]
40: 
41: 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.
42: 
43: The profile-implementing property group name format is profile_<name>. So, for example, test1 LDAP NSBEC FMRI is:
44: 
45: {{{
46: 
47: svc:/network/ldap/client:default/:properties/profile_test1
48: 
49: }}}
50: 
51: 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:
52: 
53: {{{
54: 
55: prof_META/active    test1
56: profile_test1/prop1 ...
57: profile_test1/prop2 ...
58: ...
59: profile_test2/prop1 ...
60: ...
61: 
62: }}}
63: 
64: 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.
65: 
66: == [[3.2   Name Service Switch Profile (NSSP)>>#id6]]
67: 
68: 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.
69: 
70: 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].
71: 
72: With respect to SMF services, this configuration will be stored as a property group in svc:/system/name-service-cache:default instance.
73: 
74: |=Property-name|=Type|=Value
75: |**Misc**
76: |domain|astring| 
77: |**Name Service Switch**
78: |db_passwd|astring|[<source> [<criteria>]]*|auto
79: |db_group|astring|[<source> [<criteria>]]*|auto
80: |db_hosts|astring|[<source> [<criteria>]]*|auto
81: |db_ipnodes|astring|[<source> [<criteria>]]*|auto
82: |db_networks|astring|[<source> [<criteria>]]*|auto
83: |db_protocols|astring|[<source> [<criteria>]]*|auto
84: |db_rpc|astring|[<source> [<criteria>]]*|auto
85: |db_ethers|astring|[<source> [<criteria>]]*|auto
86: |db_netmasks|astring|[<source> [<criteria>]]*|auto
87: |db_bootparam|astring|[<source> [<criteria>]]*|auto
88: |db_publickey|astring|[<source> [<criteria>]]*|auto
89: |db_netgroup|astring|[<source> [<criteria>]]*|auto
90: |db_automount|astring|[<source> [<criteria>]]*|auto
91: |db_aliases|astring|[<source> [<criteria>]]*|auto
92: |db_services|astring|[<source> [<criteria>]]*|auto
93: |db_printers|astring|[<source> [<criteria>]]*|auto
94: |db_auth_attr|astring|[<source> [<criteria>]]*|auto
95: |db_prof_attr|astring|[<source> [<criteria>]]*|auto
96: |db_*|astring|[<source> [<criteria>]]*
97: |**Links to NSBECs**
98: |bec_dns|astring|[<DNS NSBEC name>]|auto
99: |bec_nis|astring|[<NIS NSBEC name>]|auto
100: |bec_nisplus|astring|[<NIS+ NSBEC name>]|auto
101: |bec_ldap|astring|[<LDAP NSBEC name>]|auto
102: |bec_<type>|astring|[<<type> NSBEC name>]|auto
103: 
104: The full grammar for db_ property values is identical to the counterparts in nsswitch.conf(4).
105: 
106: === [[3.2.1   Automatic>>#id7]]
107: 
108: 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.
109: 
110: 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).
111: 
112: === [[3.2.2   Links to NSBECs>>#id8]]
113: 
114: 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.
115: 
116: == [[3.3   Name Service Back-End Configuration (NSBEC)>>#id9]]
117: 
118: 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).
119: 
120: === [[3.3.1   DNS NSBEC>>#id10]]
121: 
122: 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.
123: 
124: 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.
125: 
126: 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.
127: 
128: |=Property-group|=Type|=Value
129: |=Property|= |= 
130: |**DNS**
131: |nameserver|net_address_v4/6_list|Specifies the IPv4 or IPv6 Internet address of a name server that the resolver is to query.
132: |domain|astring|Specifies the local domain name.
133: |search|astring_list|The search list for host name lookup.
134: |sortlist|net_address_v4/6_list|Allows addresses returned by the libresolv-internal gethostbyname() to be sorted
135: |options|astring_list|Allows certain internal resolver variables to be modified
136: 
137: === [[3.3.2   LDAP NSBEC>>#id11]]
138: 
139: The configuration files for LDAP name service back-end is not public. It currently resides in /var/ldap directory.
140: 
141: |=Property-group|=Type|=Values
142: |=Property|= |= 
143: |**LDAP**
144: |ldap/FILE_VERSION|astring|2.0
145: |proxyDN|astring| 
146: |proxyPassword|astring| 
147: |preferredServerList|astring| 
148: |defaultServerList|astring| 
149: |defaultSearchBase|astring| 
150: |defaultSearchScope|astring| 
151: |authenticationMethod|astring|
152: * none
153: * simple
154: * sasl/CRAM-MD5
155: * sasl/DIGEST-MD5
156: * sasl/GSSAPI
157: * tls:simple
158: * tls:sasl/CRAM-MD5
159: * tls:sasl/DIGEST-MD5
160: |credentialLevel|astring|
161: * anonymous
162: * proxy
163: * self
164: |serviceSearchDescriptor|astring| 
165: |searchTimeLimit|count| 
166: |bindTimeLimit|count| 
167: |followReferrals|boolean| 
168: |profileTTL|count| 
169: |attributeMap|astring_list| 
170: |objectclassMap|astring_list| 
171: |profileName|astring| 
172: |serviceAuthMethod|astring_list| 
173: |serviceCredentialLevel|astring_list| 
174: |certificatePath|astring| 
175: 
176: **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)**
177: 
178: LDAP type NSBEC(s) will be stored as a property group(s) in SMF service svc:/network/ldap/client.
179: 
180: === [[3.3.3   NIS NSBEC>>#id12]]
181: 
182: The configuration files for NIS name service back-end are not public. They currently reside in /var/yp directory.
183: 
184: |=Property-group|=Type|=Value
185: |=Property|= |= 
186: |**NIS**
187: |servers|astring|auto or list of NIS servers
188: |domain|astring|NIS domain
189: 
190: servers set to auto means that ypbind(1M) will be run with -broadcast option.
191: 
192: If domain is empty, domain from NSSP to which that this particular NSBEC is associated to is used.
193: 
194: NSBEC(s) of this type will be stored as a property group(s) in SMF service svc:/network/nis/client.
195: 
196: === [[3.3.4   NIS+ NSBEC>>#id13]]
197: 
198: The configuration files for NIS+ name service back-end are not public. They currently reside in /var/nis directory.
199: 
200: |=Property-group|=Type|=Value
201: |=Property|= |= 
202: |**NIS+**
203: |server|astring|auto or trusted NIS+ server
204: |preferredServerList|host_list| 
205: |domain|astring|NIS+ domain
206: |coldstart|astring|NIS_COLD_START file location
207: 
208: server set to auto means that broadcasting will be used to locate NIS+ server.
209: 
210: If domain is empty, domain from NSSP to which that this particular NSBEC is associated to is used.
211: 
212: NSBEC(s) of this type will be stored as a property group(s) in SMF service svc:/network/rpc/nisplus.
213: 
214: = [[4   Implementation in SMF>>#id14]]
215: 
216: 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).
217: 
218: |[nss_man]|//nsswitch.conf(4)//, nsswitch.conf - configuration file for the name service switch
219: |[dns_man]|resolv.conf(4), resolv.conf - resolver configuration file
220: |[nis_man]|nis+(1), nis+, NIS+, nis - a new version of the network information name service
221: |[ldap_man]|ldap(1), ldap - LDAP as a naming repository
222: |[nsutil]|nsutil(1M) - see [[http://www.opensolaris.org/os/project/duckwater>>Project duckwater.WebHome]]
223: |[enhsmfprof]|Enhanced SMF Profiles - [[http://opensolaris.org/os/project/smf-profiles/>>Project smf-profiles.WebHome]]
224: |[nwamproject]|Network Auto-Magic [[http://opensolaris.org/os/project/nwam/>>Project nwam.WebHome]]
225: |[legacyconffiles]|Legacy config - [[http://opensolaris.org/os/project/duckwater/Documentation/legacyconffiles/>>Project duckwater.legacyconffiles]]
OpenSolaris

Top Menu

Wiki code for [NEW!] Name Service Profiles

Search

Collectives

Community Group

Project

User Group

Subsites

Project duckwater Pages
