@@ -102,6 +102,19 @@ objectClasses: (
#
#---------------------------------------------------------------------
#
+# objectClasses: ( 1.3.6.1.4.1.31103.1.1005 NAME 'fedfsNsdbContainerEntry' DESC 'Denotes an Nsdb Container Entry' SUP top AUXILIARY MAY ( fedfsAnnotation $ fedfsDescr ) )
+#
+objectClasses: (
+ 1.3.6.1.4.1.31103.1.1005
+ NAME 'fedfsNsdbContainerEntry'
+ DESC 'Denotes an Nsdb Container Entry'
+ SUP top
+ AUXILIARY
+ MAY ( fedfsAnnotation $ fedfsDescr )
+ )
+#
+#---------------------------------------------------------------------
+#
# attributeTypes: ( 1.3.6.1.4.1.31103.1.1 NAME 'fedfsUuid' DESC 'A UUID used by NSDB' EQUALITY uuidMatch ORDERING uuidOrderingMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE )
#
attributeTypes: (
@@ -326,3 +326,14 @@ objectclass (
$ fedfsNfsValidFor
))
+
+objectclass (
+ 1.3.6.1.4.1.31103.1.1005 NAME 'fedfsNsdbContainerEntry'
+ DESC 'Denotes an Nsdb Container Entry'
+ SUP top AUXILIARY
+ MAY (
+ fedfsAnnotation
+ $ fedfsDescr
+ ))
+
+
When constructing an NSDB, part of the process currently involves adding a fedfsNceDN attribute to one or more root suffix entries in an LDAP server's root DSE. Simo Source (FreeIPA) points out it may be difficult or impossible for some LDAP server implementations to allow modification of their root DSE. Or it could be a problem for some deployments to allow root DSE modification. For this reason, LDAP applications typically use an approach that does not require root DSE modification. My own experience with OpenLDAP and 389-ds is that root DSE modification is quite awkward. Long-term, we'd like to replace fedfsNsdbContainerInfo and fedfsNceDN with a form of NCE discovery that is simpler to configure. Old-style NCE discovery works like this: For each of the server's naming contexts, an NSDB client performs this query: ldapsearch -b "naming_context" -s base (objectClass=*) fedfsNceDN The fedfsNceDN attribute contains the full distinguished name of the NCE residing under that naming context (root suffix). New-style NCE discovery works like this: An NCE contains an auxiliary object class called fedfsNsdbContainerEntry. For each of the server's naming contexts, an NSDB client performs this query: ldapsearch -b "naming_context" -s subtree \ (objectClass=fedfsNsdbContainerEntry) The response carries the distinguished name of the NCE residing under that naming context, or NO_SUCH_OBJECT. Define the new object class that denotes an NSDB Container Entry. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> --- doc/ldap/fedfs-schema.ldif | 13 +++++++++++++ doc/ldap/fedfs.schema | 11 +++++++++++ 2 files changed, 24 insertions(+)