From Daniel.Ellard at netapp.com Thu May 1 09:33:40 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Thu, 1 May 2008 12:33:40 -0400 Subject: [Federated-fs] Todays conference call RESCHEDULED Message-ID: Due to scheduling conflicts with a number of our usual attendees, I'd like to reschedule the conference call from today to either tomorrow or early next week. If you wish to participate, please let me know which of these times works for you: Friday 5/2 4pm EDT Monday 5/5 2pm EDT Tuesday 5/6 1pm EDT Or none of the above; propose another time and we'll see what we can do. Thanks, -Dan From LeMahieu_Paul at emc.com Thu May 1 16:06:18 2008 From: LeMahieu_Paul at emc.com (Paul Lemahieu) Date: Thu, 1 May 2008 16:06:18 -0700 Subject: [Federated-fs] Todays conference call RESCHEDULED In-Reply-To: References: Message-ID: <36A9555F-C121-4995-9822-42216E06E8D3@emc.com> Monday 5/5 2PM EDT is best for me. --Paul On 2008-May-01, at 9:33, Ellard, Daniel wrote: > > Due to scheduling conflicts with a number of our usual attendees, I'd > like to reschedule the conference call from today to either tomorrow > or > early next week. > > If you wish to participate, please let me know which of these times > works for you: > > Friday 5/2 4pm EDT > > Monday 5/5 2pm EDT > > Tuesday 5/6 1pm EDT > > Or none of the above; propose another time and we'll see what we can > do. > > Thanks, > -Dan > From daniel.ellard at netapp.com Thu May 1 17:14:05 2008 From: daniel.ellard at netapp.com (Daniel Ellard) Date: Thu, 01 May 2008 20:14:05 -0400 Subject: [Federated-fs] Todays conference call RESCHEDULED In-Reply-To: <36A9555F-C121-4995-9822-42216E06E8D3@emc.com> Message-ID: Monday 2pm EDT is the time that works for everyone who has voted so far (except for one person who can't make any of those days), and tomorrow doesn't work at all for many people. So the winner is Monday 2pm EDT. Conference call info: 1-888-765-3653 # 6206056. -Dan On 5/1/08 7:06 PM, "Paul Lemahieu" wrote: > Monday 5/5 2PM EDT is best for me. > > --Paul > > On 2008-May-01, at 9:33, Ellard, Daniel wrote: > >> >> Due to scheduling conflicts with a number of our usual attendees, I'd >> like to reschedule the conference call from today to either tomorrow >> or >> early next week. >> >> If you wish to participate, please let me know which of these times >> works for you: >> >> Friday 5/2 4pm EDT >> >> Monday 5/5 2pm EDT >> >> Tuesday 5/6 1pm EDT >> >> Or none of the above; propose another time and we'll see what we can >> do. >> >> Thanks, >> -Dan >> > From Daniel.Ellard at netapp.com Mon May 5 11:51:20 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Mon, 5 May 2008 14:51:20 -0400 Subject: [Federated-fs] Notes from conference call Message-ID: - Due to connectathon and other events, it looks like the schedule for most of the participants is difficult for the next two weeks. We may need to postpone some of the calls. PLEASE let me know if you can attend: Thursday 5/8 Thursday 5/15 - Paul Lemahieu is going to write up his notes on a discovery protocol that combines the "active" and "passive" discovery modes. (Active is when a client knows it wants a particular server to be the root and seeks for it, and passive is when a client isn't so fussy and instead will accept a local root.) It's clear how to do "active" lookup with SRV records. It seems possible to do the local as well, with a local DNS server modified to to answer queries for a generic name with local values. For example, the name "nsdb" would always be resolved to a local NSDB, and a local NSDB will always resolve junctionKey XXX (where XXX is an agreed-upon constant UUID) to a local root. There could even be a space of junctionKeys (i.e., any with a given prefix) that resolve to different local roots, with different attributes, to give the client a choice. - Dan is going to send around the schema that he has put together for the LDAP-based NSDB. He confesses nearly total ignorance of good LDAP schema design and would like some feedback on how to make things a little more constrained (right now, most of the fields are simply strings, so the NSDB has no way to confirm whether the values make any sense whatsoever). - Renu is working on slides (coordinating with Theresa Raj) to show at Connectathon. She will send them to the list later this week. Rob Thurlow is going to talk about replication-related issues at the kickoff 11:30 on Monday 5/12, and there is going to be a fed-fs presentation 2pm on Tuesday 5/13. - Dan is looking for more comments on the most recent reqts draft. Please post them to the mailing list. -Dan From Daniel.Ellard at netapp.com Wed May 7 08:45:03 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Wed, 7 May 2008 11:45:03 -0400 Subject: [Federated-fs] LDAP schema for the NSDB - request for comments Message-ID: 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 # )) From Craig.Everhart at netapp.com Thu May 8 11:16:31 2008 From: Craig.Everhart at netapp.com (Everhart, Craig) Date: Thu, 8 May 2008 14:16:31 -0400 Subject: [Federated-fs] FW: Notes from conference call Message-ID: Forgot to CC: the list. -----Original Message----- From: Everhart, Craig Sent: Wednesday, May 07, 2008 12:06 PM To: Ellard, Daniel Subject: RE: [Federated-fs] Notes from conference call Hi, Dan. Thanks for writing up this much from Paul, etc. To your specific question, I'm available 5/8 and 5/15. Will be in the office with for the 5/15 call. I want to be sure we're talking about the same discovery question: are we trying to find an NSDB server or a file system to mount somewhere? To me the base requirement is finding a file system to mount; any NSDB servers can be found by the file server telling you where the NSDB service is. Finding a "local" NSDB service to act as a (shared) cache is a nice touch but not semantically necessary. There can easily be multiple namespaces that work by first locating a file system: (a) the one I was describing where the user gives a domain name (b) some "local" one that the client, by convention, mounts on "/idem" ("from the same place"). (c) some "local" one that the clients as issued/administered by organization XYZ mount under "/xyz". We don't need a convention for (c); that's up to organization XYZ to carry out in toto, including some pre-published configuration mechanism for what to mount under "/xyz". What I don't understand is what the user would ever expect to see under the "/idem" notion here. Now, there are other regimes that I suspect you may be talking about, ones that look both for a local NSDB server and then its choice of FSNs that might be published under standardized names: (a) the "local" NSDB server (a1) FSN "local", mounted at, say, "/local", or (a2) FSN "xyz" for organization XYZ--mounted where on the client? "/xyz"? I understand a local NSDB server. I also understand how an organization might want to set up (a2), but I'd expect that it would be able to do that itself, when it issued or configured its clients. What doesn't work is standardizing (a2)--some rule like "any unrecognized name issued as a lookup under '/' is auto-mounted as an FSN under the machine root". That sounds like an un-robust convention to me. Which kind of question are we trying to answer with what you're calling a "passive" lookup? Craig > -----Original Message----- > From: Ellard, Daniel > Sent: Monday, May 05, 2008 2:51 PM > To: federated-fs at sdsc.edu > Subject: [Federated-fs] Notes from conference call > > > - Due to connectathon and other events, it looks like the schedule for > most of the participants is difficult for the next two weeks. We may > need to postpone some of the calls. > PLEASE let me know if you can > attend: > > Thursday 5/8 > Thursday 5/15 > > - Paul Lemahieu is going to write up his notes on a discovery protocol > that combines the "active" and "passive" discovery modes. (Active is > when a client knows it wants a particular server to be the root and > seeks for it, and passive is when a client isn't so fussy and instead > will accept a local root.) It's clear how to do "active" lookup with > SRV records. It seems possible to do the local as well, with a local > DNS server modified to to answer queries for a generic name with local > values. For example, the name "nsdb" would always be resolved to a > local NSDB, and a local NSDB will always resolve junctionKey XXX > (where XXX is an agreed-upon constant > UUID) to a local root. There could even be a space of junctionKeys > (i.e., any with a given prefix) that resolve to different local roots, > with different attributes, to give the client a choice. > > - Dan is going to send around the schema that he has put together for > the LDAP-based NSDB. He confesses nearly total ignorance of good LDAP > schema design and would like some feedback on how to make things a > little more constrained (right now, most of the fields are simply > strings, so the NSDB has no way to confirm whether the values make any > sense whatsoever). > > - Renu is working on slides (coordinating with Theresa Raj) to show at > Connectathon. She will send them to the list later this week. Rob > Thurlow is going to talk about replication-related issues at the > kickoff 11:30 on Monday 5/12, and there is going to be a fed-fs > presentation 2pm on Tuesday 5/13. > > - Dan is looking for more comments on the most recent reqts draft. > Please post them to the mailing list. > > -Dan > From tewarir at us.ibm.com Sun May 11 16:42:55 2008 From: tewarir at us.ibm.com (Renu Tewari) Date: Sun, 11 May 2008 19:42:55 -0400 Subject: [Federated-fs] Fedfs slides for connectathon Message-ID: Hi Theresa, Here are my slides as well. regards renu -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.sdsc.edu/pipermail/federated-fs/attachments/20080511/7420d335/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fed-fs-cthon.ppt Type: application/octet-stream Size: 115712 bytes Desc: not available Url : https://lists.sdsc.edu/pipermail/federated-fs/attachments/20080511/7420d335/fed-fs-cthon.ppt From Daniel.Ellard at netapp.com Thu May 15 09:52:37 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Thu, 15 May 2008 12:52:37 -0400 Subject: [Federated-fs] conference call today Message-ID: I know that a lot of people are still tied up with Connectathon, but we're going to try to have a brief call anyway (to discuss the outcome from Connectathon, if nothing else). The time will be 2pm EDT, 1-888-765-3653 # 6206056. Agenda: - Connectathon reflections - Schedule going forward for new drafts - Reqts - Admin - NSDB - Discovery - Dublin and the WG - Planning for future conf calls (next week has a funny schedule). -Dan From tewarir at us.ibm.com Thu May 15 11:18:47 2008 From: tewarir at us.ibm.com (Renu Tewari) Date: Thu, 15 May 2008 11:18:47 -0700 Subject: [Federated-fs] conference call today In-Reply-To: Message-ID: Sorry couldn't make it today. am in an all day workshop. renu "Ellard, Daniel" To Sent by: federated-fs-boun cc ces at sdsc.edu Subject [Federated-fs] conference call 05/15/2008 09:52 today AM I know that a lot of people are still tied up with Connectathon, but we're going to try to have a brief call anyway (to discuss the outcome from Connectathon, if nothing else). The time will be 2pm EDT, 1-888-765-3653 # 6206056. Agenda: - Connectathon reflections - Schedule going forward for new drafts - Reqts - Admin - NSDB - Discovery - Dublin and the WG - Planning for future conf calls (next week has a funny schedule). -Dan From Daniel.Ellard at netapp.com Fri May 16 16:45:46 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Fri, 16 May 2008 19:45:46 -0400 Subject: [Federated-fs] Conf call time for next week Message-ID: I won't be able to host the conference call on Thursday 5/22. Can we move the call to Wednesday 5/21 (still at 2pm EDT), or should I find someone to host the call on Thursday? Thanks, -Dan From LeMahieu_Paul at emc.com Fri May 16 18:21:59 2008 From: LeMahieu_Paul at emc.com (Paul Lemahieu) Date: Fri, 16 May 2008 18:21:59 -0700 Subject: [Federated-fs] discussion on bootstrapping clients Message-ID: I had a talk with a few engineers here today, to get their opinions on the sort of client behavior they'd like to see. Here are a few key points I heard: * Rely on DNS SRV records * This is really automount functionality * Lookup by domain, most likely set via DHCP. Mount each domain for which a SRV record exists. For example, you'd automount both /net/ pasadena.emc.com and /net/emc.com, if SRV records existed. * Have DNS return value include both hostname and path to mount (I was told it's possible, I'd have to look into that to understand more). It was felt that simply mounting / on the given host wouldn't be flexible enough. For example, if you ever need to move / from fileserver A to a subdirectory on fileserver B, but want to continue showing the same world, what do you do? * Any more "local and friendly" names, which were referred to as aliases, got a less than warm welcome. For example, say EMC IT wanted everyone to see /net/emc or even /emc. Should there be any way to do that? The biggest benefit was that simply automatically mounting anything is the real benefit. That gets the client to the point where it has something it can browse. --Paul From Daniel.Ellard at netapp.com Sat May 17 17:10:47 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Sat, 17 May 2008 20:10:47 -0400 Subject: [Federated-fs] discussion on bootstrapping clients In-Reply-To: References: Message-ID: Regarding the automounter, yes, this could be done by a module in something extensible like autofs. That would be a fine vehicle for getting the top-level working, but that doesn't addess all of the issues. The first issue is what the autofs module needs to do to get the info it requires (not a big deal, but it needs to be speced). The second, and in my opinion more important, issue is about configuration. Right now, when I set up autofs on a new unixy machine, I have to copy several scripts and config files and create some directories and symlinks (and these operations require root or sudo) -- and these are neither portable nor user-friendly. I'd like to improve on that. We'd really like users to be able to utter a reasonably mnemonic name for the the filesystem they want, and have it appear in their namespace (if accessible, etc) without any more fuss. I think this is consistent with your last paragraph, but it never hurts to be sure... -Dan -----Original Message----- From: Paul Lemahieu [mailto:LeMahieu_Paul at emc.com] Sent: Friday, May 16, 2008 9:22 PM To: federated-fs at sdsc.edu Subject: [Federated-fs] discussion on bootstrapping clients I had a talk with a few engineers here today, to get their opinions on the sort of client behavior they'd like to see. Here are a few key points I heard: * Rely on DNS SRV records * This is really automount functionality * Lookup by domain, most likely set via DHCP. Mount each domain for which a SRV record exists. For example, you'd automount both /net/ pasadena.emc.com and /net/emc.com, if SRV records existed. * Have DNS return value include both hostname and path to mount (I was told it's possible, I'd have to look into that to understand more). It was felt that simply mounting / on the given host wouldn't be flexible enough. For example, if you ever need to move / from fileserver A to a subdirectory on fileserver B, but want to continue showing the same world, what do you do? * Any more "local and friendly" names, which were referred to as aliases, got a less than warm welcome. For example, say EMC IT wanted everyone to see /net/emc or even /emc. Should there be any way to do that? The biggest benefit was that simply automatically mounting anything is the real benefit. That gets the client to the point where it has something it can browse. --Paul From Spencer.Shepler at Sun.COM Sun May 18 02:30:05 2008 From: Spencer.Shepler at Sun.COM (Spencer Shepler) Date: Sun, 18 May 2008 04:30:05 -0500 Subject: [Federated-fs] discussion on bootstrapping clients In-Reply-To: References: Message-ID: <1459A9C1-DFDA-4B24-8FB1-EBE9F256F200@sun.com> On May 17, 2008, at 7:10 PM, Ellard, Daniel wrote: > > Regarding the automounter, yes, this could be done by a module in > something extensible like autofs. That would be a fine vehicle for > getting the top-level working, but that doesn't addess all of the > issues. The first issue is what the autofs module needs to do to get > the info it requires (not a big deal, but it needs to be speced). The > second, and in my opinion more important, issue is about > configuration. > Right now, when I set up autofs on a new unixy machine, I have to copy > several scripts and config files and create some directories and > symlinks (and these operations require root or sudo) -- and these are > neither portable nor user-friendly. I'd like to improve on that. > We'd > really like users to be able to utter a reasonably mnemonic name > for the > the filesystem they want, and have it appear in their namespace (if > accessible, etc) without any more fuss. This is my opinion as well. In short, any configuration to enable this feature other than turning the switch to "on" is too burdensome. The feature set may be contained within the automounter as an implementation choice but there must be one switch and a reasonable standard of defacto to specified behavior that leads to usefulness. Spencer > > I think this is consistent with your last paragraph, but it never > hurts > to be sure... > > -Dan > > -----Original Message----- > From: Paul Lemahieu [mailto:LeMahieu_Paul at emc.com] > Sent: Friday, May 16, 2008 9:22 PM > To: federated-fs at sdsc.edu > Subject: [Federated-fs] discussion on bootstrapping clients > > I had a talk with a few engineers here today, to get their opinions on > the sort of client behavior they'd like to see. > > Here are a few key points I heard: > * Rely on DNS SRV records > * This is really automount functionality > * Lookup by domain, most likely set via DHCP. Mount each domain > for > which a SRV record exists. For example, you'd automount both /net/ > pasadena.emc.com and /net/emc.com, if SRV records existed. > * Have DNS return value include both hostname and path to mount (I > was told it's possible, I'd have to look into that to understand > more). > It was felt that simply mounting / on the given host wouldn't be > flexible enough. For example, if you ever need to move / from > fileserver > A to a subdirectory on fileserver B, but want to continue showing the > same world, what do you do? > * Any more "local and friendly" names, which were referred to as > aliases, got a less than warm welcome. For example, say EMC IT wanted > everyone to see /net/emc or even /emc. Should there be any way to do > that? > > The biggest benefit was that simply automatically mounting anything is > the real benefit. That gets the client to the point where it has > something it can browse. > > --Paul From daniel.ellard at netapp.com Wed May 21 09:32:01 2008 From: daniel.ellard at netapp.com (Daniel Ellard) Date: Wed, 21 May 2008 09:32:01 -0700 Subject: [Federated-fs] NO FED-FS CALL THIS WEEK Message-ID: Due to scheduling conflicts, I can't host the call today or tomorrow. Sorry for the short notice. Let's try again next week (Thursday). Thanks, -Dan -- Daniel Ellard, Ph.D. NetApp Advanced Technology Group From Daniel.Ellard at netapp.com Wed May 28 11:12:35 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Wed, 28 May 2008 14:12:35 -0400 Subject: [Federated-fs] FW: LDAP schema for the NSDB - request for comments Message-ID: 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 # )) From Daniel.Ellard at netapp.com Wed May 28 11:16:12 2008 From: Daniel.Ellard at netapp.com (Ellard, Daniel) Date: Wed, 28 May 2008 14:16:12 -0400 Subject: [Federated-fs] Reminder: conference call tomorrow Message-ID: 2pm EDT, 1-888-765-3653 # 6206056 Agenda -- 1. State of the LDAP schema 2. How to convert LDAP messages to satisfy the reqts? Should we specify a programatic interface, with a reference impl? 3. The discovery / browsing protocol (for the client) -Dan