[Federated-fs] FW: LDAP schema for the NSDB - request for comments

Ellard, Daniel Daniel.Ellard at netapp.com
Wed May 28 11:12:35 PDT 2008


I'd like to wrap up the schema, so please send me your comments ASAP.

(please try to ignore Outlook's compulsion to fill all the
paragraphs...)

Thanks,
	-Dan
 

-----Original Message-----
From: Ellard, Daniel 
Sent: Wednesday, May 07, 2008 11:45 AM
To: federated-fs at sdsc.edu
Subject: [Federated-fs] LDAP schema for the NSDB - request for comments


Enclosed is the current NSDB LDAP schema.

I'm learning LDAP as I go.  While I can vouch for the correctness to the
first order (it runs, and LDAP queries give back the correct results)
I'm sure that someone with more than a few days of LDAP experience will
be able to offer significant constructive criticism about how to improve
the schema.

The schema OIDs are borrowed from the Glamour schema and may now
conflict (although I tried to choose unique values).  Assume that they
will change.

Thanks,
    -Dan 
 
# $Id: nsdb.schema,v 1.3 2008/05/07 15:29:09 ellard Exp $ # # LDAP NSDB
schema mock-up.
#
# This is a very rough prototype, just to get some bits moving.  I'm #
an LDAP novice (at best) and so suggestions for better (or correct) #
ways to accomplish what I'm trying to do are MORE THAN WELCOME.  If #
the code makes no sense, hopefully the comments will.
#
# The major issue is that many fields are underspecified.  It's #
possible to insert values with bogus syntax right now (i.e., where # the
schema expects a hostname, it will also accept nonsense like # "1").
I've attempted to abstract the types in such a way that we # can fix the
specifications later (for example by fixing nsdbUuid and # nsdbHostName,
which are base types for several other attributes).
#
# It is my understanding that some LDAP servers, such as openldap, can #
be extended, via plug-ins, to do more powerful syntax and semantic #
checks than can be specified via raw LDAP (or ASN.1, which I am not #
using here at all, for portability reasons).  That might be a # better,
albeit less portable, way to constraining these types.

# An nsdbUuid should eventually be a standard UUID.  It may be useful #
to also permit it to allow additional strings for debugging # purposes.
#
# Right now, an nsdbUuid can be anything a NAME can be.

attributetype ( 1.3.6.1.4.1.4203.666.121.100 NAME 'nsdbUuid'
	DESC 'nsdbUuid: a UUID used by NSDB'
	SUP name
	SINGLE-VALUE
	)

# An nsdbHostName is the locative name of a host.  It should be able #
to express network locations as IPv4, IPv6, and DNS FQDN notations. 
# May include a port specifier.
#
# The syntax is HOST[:PORT] where HOST can be a IPv4, IPv6, or DNS #
FQDN specification, and PORT is a 16-bit unsigned integer.
#
# There may be a special syntax at some point for specifying a SVR #
record (for a DNS FQDN).  There is no provision for that now; how a #
name is interpeted depends on context.
#
# Right now, an nsdbUuid can be anything a NAME can be.

attributetype ( 1.3.6.1.4.1.4203.666.121.101 NAME 'nsdbHostName'
	DESC 'nsdbHostName: the network name of a host or service'
	SUP name
	SINGLE-VALUE
	)

# A junctionKey is an nsdbUuid.
#
# A junctionKey is one of the two universal components of an FSN.

attributetype ( 1.3.6.1.4.4203.666.121.102 NAME 'junctionKey'
	DESC 'junctionKey: the FSN UUID component of an FSN'
	SUP nsdbUuid
	SINGLE-VALUE
	)

# An nsdbName is an nsdbHostName.
#
# A nsdbName is one of the two universal components of an FSN.

attributetype ( 1.3.6.1.4.1.4203.666.121.103 NAME 'nsdbName'
	DESC 'nsdbName: the NSDB location component of an FSN'
	SUP nsdbHostName
	SINGLE-VALUE
	)

# A fslHost is an nsdbHostName.

attributetype ( 1.3.6.1.4.1.4203.666.121.104 NAME 'fslHost'
	DESC 'fslHost: service location for a fileset server'
	SUP nsdbHostName
	SINGLE-VALUE
	)

# A fslPath is a name.
#
# If there is a better way to denote a path, we should use it here. 
# This is almost completely unconstrained.

attributetype ( 1.3.6.1.4.1.4203.666.121.105 NAME 'fslPath'
	DESC 'fslPath: server-local path to a fileset'
	SUP name
	SINGLE-VALUE
	)

# Implicitly MULTI-VALUED

attributetype (
	1.3.6.1.4.1.4203.666.121.106 NAME 'annotation'
	DESC 'annotation of an NSDB object'
	SUP name
	)

attributetype (
	1.3.6.1.4.1.4203.666.121.107 NAME 'descr'
	DESC 'description of an NSDB object'
	SUP name
	SINGLE-VALUE
	)

# We've had some discussion about each FSL having a "type" (i.e., #
CIFS, NFSv3, NFSv4) but we're not doing anything with this field # yet.
#
# Implicitly MULTI-VALUED

attributetype ( 1.3.6.1.4.1.4203.666.121.108 NAME 'type'
	DESC 'type: CIFS, NFS, etc'
	SUP name
	)

# Each FSL must have a UUID associated with it, which serves as part #
of its DN.
#
# There's probably a better way to do this, but I need a way to #
uniquify the DN for each FSL so that I can have each FSL for an FSN # be
its own object in the LDAP namespace and yet connected to the # FSN.

attributetype (
	1.3.6.1.4.1.4203.666.121.109 NAME 'fslUuid'
	DESC 'UUID of an FSL'
	SUP nsdbUuid
	SINGLE-VALUE
	)

# The FSN object.
#
# The dn of an FSN is assumed to take the following form:
#
# dn:  junctionKey=JUNCTIONKEY,dc=fed-fs,dc=com
#
# Note that the nsdbName is implicit, not explicit.

objectclass (
	1.3.6.1.4.1.4203.666.121.5 NAME 'FsnObject'
	DESC 'Representing a Fed-fs Fileset'
	SUP top STRUCTURAL
	MUST (
		junctionKey
		$ nsdbName
	)
	MAY  (
		descr
		$ annotation
	))

# An FSL is a subtype of an FSN at this point.
#
# Note that each FSL must be assigned a UUID.
#
# The dn of an FSL is assumed to take the following form:
#
# dn:  fslUuid=UUID,junctionKey=JUNCTIONKEY,dc=fed-fs,dc=com
#
# Therefore, to query for all the FSLs that match a given FSN, query #
an NSDB for all the CHILDREN (in the LDAP namespace) of the object #
with DN "junctionKey=JUNCTIONKEY,dc=fed-fs,dc=com" with a filter for #
objecttype = fslObject.  (If you want to be doubly careful, you can #
also filter by nsdbName.) It is NOT necessary to know the fslUuid of #
an FSL in order to find it.

objectclass (
	1.3.6.1.4.1.4203.666.121.7 NAME 'FslObject'
	DESC 'Represents a physical instance of a fileset'
	SUP fsnObject STRUCTURAL
	MUST (
		junctionKey 
		$ nsdbName 
		$ fslUuid
		$ fslHost 
		$ fslPath 
	)
	MAY  (
		descr 
		$ annotation
	))

# I no longer remember the purpose of the FsnJunctionObject class, so #
I'm going to comment it out until its necessity is reevaluated. 
# -DJE
#
# objectclass (
# 	1.3.6.1.4.1.4203.666.121.9 NAME 'FSNJunctionObject'
# 	DESC 'Represents a mount point'
# 	SUP  top STRUCTURAL
# 	MUST (
# 		parentFsnUuid
# 		$ targetFsnUuid
# 		$ nsdbName
# 		$ mountPath
# 	)
# 	MAY  (
# 		descr
# 		$ annotation
# 	))


More information about the Federated-fs mailing list