AFS + LDAP

AFS + LDAP

[Daniel Richard G.]

Does there exist a standard(ish) LDAP schema for AFS mounts?

I'm familiar with the Hesiod record format, along the lines of e.g.

	AFS /afs/athena.mit.edu/contrib/sipb n /mit/sipb 1
	AFS /afs/athena.mit.edu/user/y/o/yoav w /mit/yoav

(and supported by the Hesiod lookup module), but I'm interested in pulling 
this same sort of information via LDAP.


Any hints/pointers would be appreciated,


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@iskunk.org        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@alum.mit.edu      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)

Re: AFS + LDAP

[Ian Kent]

On Thu, 2006-07-06 at 01:50 -0400, Daniel Richard G. wrote:
> Does there exist a standard(ish) LDAP schema for AFS mounts?
> 
> I'm familiar with the Hesiod record format, along the lines of e.g.
> 
> 	AFS /afs/athena.mit.edu/contrib/sipb n /mit/sipb 1
> 	AFS /afs/athena.mit.edu/user/y/o/yoav w /mit/yoav
> 
> (and supported by the Hesiod lookup module), but I'm interested in pulling 
> this same sort of information via LDAP.

I'm not familiar with the hesoid system but I assume that in the record
above we have:

AFS -> filesystem type
/afs/athena.mit.edu/user/y/o/yoav -> filesystem
w -> read/write option rw

The last field is confusing but it may be the key used by hes_resolve?
If so for autofs it would not normally be a path but a component such as
yoav here.

So you could store this in LDAP by one of the schema such as the NIS
schema by setting attributes for a distinguished name like:

dn: cn=yoav,nisMapName=mymap,dc=dncom1,dc=dncomp2:

as

cn: yoav
nisMapEntry: AFS /afs/athena.mit.edu/user/y/o/yoav w

and using something like:

/mymount	ldap,hesoid://server/nasMapName=mymap,dc=my,dc=dnname

as a master map entry.

There's a fair bit of detail left out because I'm not sure about it so
there would have to be some trial and error. But the ",hesoid" will send
the entry to the hesoid parser instead of the sun parser in the same way
as the hesoid lookup module does.

Ian

Re: AFS + LDAP

[Daniel Richard G.]

On Thu, 2006 Jul 06 20:33:12 +0800, Ian Kent wrote:
> 
> I'm not familiar with the hesoid system but I assume that in the record
> above we have:
> 
> AFS -> filesystem type
> /afs/athena.mit.edu/user/y/o/yoav -> filesystem
> w -> read/write option rw

Aye, that's right.

> The last field is confusing but it may be the key used by hes_resolve?
> If so for autofs it would not normally be a path but a component such as
> yoav here.

It's the mount point, actually. The original way of working is that you 
would mount the volume by invoking "attach sipb" or "attach yoav", without 
reference to a base path. /mit is the usual location, but some special 
volumes (e.g. for system software) mount elsewhere in the filesystem.

> So you could store this in LDAP by one of the schema such as the NIS
> schema by setting attributes for a distinguished name like:
> 
[...]
> 
> cn: yoav
> nisMapEntry: AFS /afs/athena.mit.edu/user/y/o/yoav w
> 
[...]
> 
> There's a fair bit of detail left out because I'm not sure about it so
> there would have to be some trial and error. But the ",hesoid" will send
> the entry to the hesoid parser instead of the sun parser in the same way
> as the hesoid lookup module does.

Hmm. So it would basically be a Hesiod record stuffed into an LDAP 
attribute... and (if I understand correctly) autofs is currently limited to 
this sort of approach as _something_ ultimately has to be fed to the Hesiod 
parser.

I was hoping for something more along the lines of an extension to the 
standard NIS schema. (It's common for AFS sites to have each user's home 
directory be a separately mountable volume, so having some sort of 
user-volume equivalence in LDAP is reasonable.)

I take it something like this would require new code to support, then? And 
how would this work---pulling data from LDAP, but not doing any parsing per 
se (as the information is already broken out into attributes); there would 
be no lookup/parser disjunction. Should there be any issue with a backend 
module that effectively does both tasks?


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@iskunk.org        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@alum.mit.edu      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)

Re: AFS + LDAP

[Ian Kent]

On Thu, 2006-07-06 at 15:40 -0400, Daniel Richard G. wrote:
> On Thu, 2006 Jul 06 20:33:12 +0800, Ian Kent wrote:
> > 
> > I'm not familiar with the hesoid system but I assume that in the record
> > above we have:
> > 
> > AFS -> filesystem type
> > /afs/athena.mit.edu/user/y/o/yoav -> filesystem
> > w -> read/write option rw
> 
> Aye, that's right.
> 
> > The last field is confusing but it may be the key used by hes_resolve?
> > If so for autofs it would not normally be a path but a component such as
> > yoav here.
> 
> It's the mount point, actually. The original way of working is that you 
> would mount the volume by invoking "attach sipb" or "attach yoav", without 
> reference to a base path. /mit is the usual location, but some special 
> volumes (e.g. for system software) mount elsewhere in the filesystem.

OK. The existing code appears to call hes_resolve with just the
component of say yoav so that is the bit that would need to be stored as
the key in an alternate source.

> 
> > So you could store this in LDAP by one of the schema such as the NIS
> > schema by setting attributes for a distinguished name like:
> > 
> [...]
> > 
> > cn: yoav
> > nisMapEntry: AFS /afs/athena.mit.edu/user/y/o/yoav w
> > 
> [...]
> > 
> > There's a fair bit of detail left out because I'm not sure about it so
> > there would have to be some trial and error. But the ",hesoid" will send
> > the entry to the hesoid parser instead of the sun parser in the same way
> > as the hesoid lookup module does.
> 
> Hmm. So it would basically be a Hesiod record stuffed into an LDAP 
> attribute... and (if I understand correctly) autofs is currently limited to 
> this sort of approach as _something_ ultimately has to be fed to the Hesiod 
> parser.

Only to the extent that if you have existing records and you don't want
to convert them to the sun format. Ultimately something has to be feed
to a parser and hesoid and sun format parsers are all we have atm.

> 
> I was hoping for something more along the lines of an extension to the 
> standard NIS schema. (It's common for AFS sites to have each user's home 
> directory be a separately mountable volume, so having some sort of 
> user-volume equivalence in LDAP is reasonable.)

Don't quite follow.
There are three schema in use about the place, the automount NIS schema,
rfc2307 and rfc2307-bis automount schema.

They all have objectclasses to hold automount keys and corresponding
mount information.

> 
> I take it something like this would require new code to support, then? And 
> how would this work---pulling data from LDAP, but not doing any parsing per 
> se (as the information is already broken out into attributes); there would 
> be no lookup/parser disjunction. Should there be any issue with a backend 
> module that effectively does both tasks?

Not really, but maybe.
The entry point into this is the lookup module.

In version 4 and version 5 so far the lookup module for a map source is
called to find the mount data it then calls the parser module which in
turn calls the appropriate mount module.

You need to be careful not to implement something that is specific to
what you require rather than something that general and that others may
benefit from. Otherwise we would end up with a bunch of limited function
modules.

The feeling is that this design is inflexible and it will be redesigned
at some point.

Ian

Re: AFS + LDAP

[Daniel Richard G.]

On Fri, 2006 Jul 07 09:41:28 +0800, Ian Kent wrote:
> 
> OK. The existing code appears to call hes_resolve with just the
> component of say yoav so that is the bit that would need to be stored as
> the key in an alternate source.

Right. The semantics of the lookup are a bit different, but not enough to 
be of concern here.

> Only to the extent that if you have existing records and you don't want
> to convert them to the sun format. Ultimately something has to be feed
> to a parser and hesoid and sun format parsers are all we have atm.

This would be a legacy-free installation, so my focus is on doing things 
the Right Way(tm), whether new code is needed or not.

> > I was hoping for something more along the lines of an extension to the 
> > standard NIS schema. (It's common for AFS sites to have each user's home 
> 
> Don't quite follow.
> There are three schema in use about the place, the automount NIS schema,
> rfc2307 and rfc2307-bis automount schema.
> 
> They all have objectclasses to hold automount keys and corresponding
> mount information.

As I understand rfc2307, nisMap/nisObject/etc. is just a catch-all 
mechanism for adding attributes not already covered by the schema. The RFC 
advises against this approach in favor of defining new schemas as needed.

As for the automount schema (I assume this is samples/autofs.schema)... the 
suggestion is that the necessary information should go into the 
automountInformation attribute?

The reason I'm leery of the Hesiod-record-in-an-LDAP-attribute approach 
(and more generally, the everything-in-this-one-LDAP-attribute approach) is 
that the string itself really represents what should be three or four 
separate attributes. You can't [properly] administer or use that attribute 
without a parser, and especially on the admin side, this is awkward.

> > be no lookup/parser disjunction. Should there be any issue with a backend 
> > module that effectively does both tasks?
> 
> Not really, but maybe.
> The entry point into this is the lookup module.
> 
> In version 4 and version 5 so far the lookup module for a map source is
> called to find the mount data it then calls the parser module which in
> turn calls the appropriate mount module.

I see. So the separation is not enforced; the daemon only knows about 
lookup modules, and the modules can delegate however they wish.

> You need to be careful not to implement something that is specific to
> what you require rather than something that general and that others may
> benefit from. Otherwise we would end up with a bunch of limited function
> modules.

The point is not lost on me. I'd like to find a "tighter" solution that can 
nevertheless be generally applicable.


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@iskunk.org        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@alum.mit.edu      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)

Re: AFS + LDAP

[Jeff Moyer]

==> Regarding Re: [autofs] AFS + LDAP; "Daniel Richard G." <skunk@iskunk.org> adds:

skunk> On Fri, 2006 Jul 07 09:41:28 +0800, Ian Kent wrote:
>> > be no lookup/parser disjunction. Should there be any issue with a backend 
>> > module that effectively does both tasks?
>> 
>> Not really, but maybe.
>> The entry point into this is the lookup module.
>> 
>> In version 4 and version 5 so far the lookup module for a map source is
>> called to find the mount data it then calls the parser module which in
>> turn calls the appropriate mount module.

skunk> I see. So the separation is not enforced; the daemon only knows about 
skunk> lookup modules, and the modules can delegate however they wish.

And as things stand today, every lookup module falls into the model of
calling into the parse module to do parsing (and the parse module calls the
mount module).  If you're going to stray from this, you had better have a
really good reason to do so.

>> You need to be careful not to implement something that is specific to
>> what you require rather than something that general and that others may
>> benefit from. Otherwise we would end up with a bunch of limited function
>> modules.

skunk> The point is not lost on me. I'd like to find a "tighter" solution
skunk> that can nevertheless be generally applicable.

Good.

Jeff

Re: AFS + LDAP

[Ian Kent]

On Fri, 2006-07-07 at 13:09 -0400, Daniel Richard G. wrote:
> On Fri, 2006 Jul 07 09:41:28 +0800, Ian Kent wrote:
> > 
> > OK. The existing code appears to call hes_resolve with just the
> > component of say yoav so that is the bit that would need to be stored as
> > the key in an alternate source.
> 
> Right. The semantics of the lookup are a bit different, but not enough to 
> be of concern here.
> 
> > Only to the extent that if you have existing records and you don't want
> > to convert them to the sun format. Ultimately something has to be feed
> > to a parser and hesoid and sun format parsers are all we have atm.
> 
> This would be a legacy-free installation, so my focus is on doing things 
> the Right Way(tm), whether new code is needed or not.
> 
> > > I was hoping for something more along the lines of an extension to the 
> > > standard NIS schema. (It's common for AFS sites to have each user's home 
> > 
> > Don't quite follow.
> > There are three schema in use about the place, the automount NIS schema,
> > rfc2307 and rfc2307-bis automount schema.
> > 
> > They all have objectclasses to hold automount keys and corresponding
> > mount information.
> 
> As I understand rfc2307, nisMap/nisObject/etc. is just a catch-all 
> mechanism for adding attributes not already covered by the schema. The RFC 
> advises against this approach in favor of defining new schemas as needed.
> 
> As for the automount schema (I assume this is samples/autofs.schema)... the 
> suggestion is that the necessary information should go into the 
> automountInformation attribute?

I always get confused with these names.
Never the less it appears that other implementations are moving toward
rfc2307-bis for LDAP based automount maps. I would make this the default
schema for version 5 except that we need to retain backward
compatibility with those that use what was the default in version 4.
It's easy enough to change in the config anyway.

Have a look at the version 5 config file for examples of the three
schema in common use.

> 
> The reason I'm leery of the Hesiod-record-in-an-LDAP-attribute approach 
> (and more generally, the everything-in-this-one-LDAP-attribute approach) is 
> that the string itself really represents what should be three or four 
> separate attributes. You can't [properly] administer or use that attribute 
> without a parser, and especially on the admin side, this is awkward.
> 
> > > be no lookup/parser disjunction. Should there be any issue with a backend 
> > > module that effectively does both tasks?
> > 
> > Not really, but maybe.
> > The entry point into this is the lookup module.
> > 
> > In version 4 and version 5 so far the lookup module for a map source is
> > called to find the mount data it then calls the parser module which in
> > turn calls the appropriate mount module.
> 
> I see. So the separation is not enforced; the daemon only knows about 
> lookup modules, and the modules can delegate however they wish.

Yes but this is driven by the map entry itself. For example a Sun format
entry like

etc	-fstype=nfs,rw    server:/dir

will lead to a call to the mount_nfs.c mount module.

Sun format mount (and to a lesser extent Hesiod format) tables are
widely used and we are striving for interoperability so a storage
mechanism with multiple attributes would not fit in very well from a
standardization point of view.

Ian

Re: AFS + LDAP

[Daniel Richard G.]

On Sat, 2006 Jul 08 13:23:29 +0800, Ian Kent wrote:
> 
> I always get confused with these names.
> Never the less it appears that other implementations are moving toward
> rfc2307-bis for LDAP based automount maps. I would make this the default
> schema for version 5 except that we need to retain backward
> compatibility with those that use what was the default in version 4.
> It's easy enough to change in the config anyway.
>
> Have a look at the version 5 config file for examples of the three
> schema in common use.

I have to agree that rfc2307-bis looks like the most straightforward of the 
lot. (Shouldn't the tarball bundle a copy of the automount portion of that 
schema?)

> > I see. So the separation is not enforced; the daemon only knows about 
> > lookup modules, and the modules can delegate however they wish.
> 
> Yes but this is driven by the map entry itself. For example a Sun format
> entry like
> 
> etc	-fstype=nfs,rw    server:/dir
> 
> will lead to a call to the mount_nfs.c mount module.

"However they wish" was a bit cavalier; of course the modules obey the map
:)

> Sun format mount (and to a lesser extent Hesiod format) tables are
> widely used and we are striving for interoperability so a storage
> mechanism with multiple attributes would not fit in very well from a
> standardization point of view.

And this is the crux of the matter. The present approach seems to be to 
continue using these old Sun/Hesiod tables, only accessed in a different 
form. Hasn't anyone [with some clout] proposed something along more 
"modern" lines?

It's easy to conceive of a multi-attribute schema that could subsume NFS 
and AFS mappings, and others as well. For example...

	automountKey: foo
	automountType: nfs
	automountHost: budgie
	automountPath: /usr/local/foo
	automountWritable: true

	automountKey: bar
	automountType: afs
	automountHost: parakeets.com	(AFS cell name)
	automountPath: /afs/parakeets.com/users/bar
	automountWritable: no

	automountKey: qux
	automountType: device
	automountFormat: xfs
	automountPath: /dev/sda5
	automountWritable: yes

	etc.

(This was more or less what I had in mind for a schema that obviated the 
need for parsing---none of those attributes have to be chopped up.)

Interoperability is a concern, true. But a precise schema would be a win in 
an all/mostly-Linux network, the BSDs would probably follow suit if it were 
good enough, and for everyone else there's always program maps....

(Would appreciate comments on this, as I'm only speculating)


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@iskunk.org        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@alum.mit.edu      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)

Re: AFS + LDAP

[Ian Kent]

On Sat, 2006-07-08 at 03:53 -0400, Daniel Richard G. wrote:

> And this is the crux of the matter. The present approach seems to be to 
> continue using these old Sun/Hesiod tables, only accessed in a different 
> form. Hasn't anyone [with some clout] proposed something along more 
> "modern" lines?
> 
> It's easy to conceive of a multi-attribute schema that could subsume NFS 
> and AFS mappings, and others as well. For example...
> 
> 	automountKey: foo
> 	automountType: nfs
> 	automountHost: budgie
> 	automountPath: /usr/local/foo
> 	automountWritable: true
> 
> 	automountKey: bar
> 	automountType: afs
> 	automountHost: parakeets.com	(AFS cell name)
> 	automountPath: /afs/parakeets.com/users/bar
> 	automountWritable: no
> 
> 	automountKey: qux
> 	automountType: device
> 	automountFormat: xfs
> 	automountPath: /dev/sda5
> 	automountWritable: yes
> 

We would probably need a couple of other attributes, say for mount
options other than read/write.

> 	etc.
> 
> (This was more or less what I had in mind for a schema that obviated the 
> need for parsing---none of those attributes have to be chopped up.)
> 
> Interoperability is a concern, true. But a precise schema would be a win in 
> an all/mostly-Linux network, the BSDs would probably follow suit if it were 
> good enough, and for everyone else there's always program maps....
> 
> (Would appreciate comments on this, as I'm only speculating)

Interesting proposal.

Right row (and for quite a long time) I've been most concerned with
bringing the current autofs feature set up to par with functionality of
other industry standard products. This is where the interoperability
bent comes from and so haven't really thought about doing it better. The
other reason that interoperability is so important to me is that Linux
autofs must be able to fit into mixed vendor sites with minimal hassle
for the admin as the heaviest autofs users tend to have such
environments. In fact this one of the reasons I took up maintenance of
the package.

But it's getting there now so in the not so distant future a project
like this would be a great idea. I think it's likely to be a little
bigger task than you my be thinking. Perhaps your thinking a proof of
concept module(s) might be a good idea at this stage. And then
discussion about how the schema might need to change.

Just thinking about this is quite strange.
Linux autofs has been behind the pack for so long that to suddenly be
considering how the service could do things better and possibly
establish the standard in time to come is really weird.

Never the less I can't see us getting much support for such a proposal
unless Linux autofs is at least providing all the existing expected
functionality in a sound, stable and reliable way so I've still got my
hands full for at least a while.

Ian

Re: AFS + LDAP

[Daniel Richard G.]

On Sat, 2006 Jul 08 23:48:13 +0800, Ian Kent wrote:
> > 
> > 	automountKey: qux
> > 	automountType: device
> > 	automountFormat: xfs
> > 	automountPath: /dev/sda5
> > 	automountWritable: yes
> 
> We would probably need a couple of other attributes, say for mount
> options other than read/write.

This is why you want your standards written by some greybeard at Sun 
instead of a rabble-rouser like me :-)  Certainly here, there'd be a lot of 
ground to cover, corner cases and the like.

> Right row (and for quite a long time) I've been most concerned with
> bringing the current autofs feature set up to par with functionality of
> other industry standard products. This is where the interoperability
> bent comes from and so haven't really thought about doing it better. The
> other reason that interoperability is so important to me is that Linux
> autofs must be able to fit into mixed vendor sites with minimal hassle
> for the admin as the heaviest autofs users tend to have such
> environments. In fact this one of the reasons I took up maintenance of
> the package.

Absolutely no disagreement here.

> But it's getting there now so in the not so distant future a project
> like this would be a great idea. I think it's likely to be a little
> bigger task than you my be thinking. Perhaps your thinking a proof of
> concept module(s) might be a good idea at this stage. And then
> discussion about how the schema might need to change.

It's an intriguing idea, to allow a good "universal" schema to evolve.

I'm coming from the perspective of needing to support an organization, 
however, so this would go a bit beyond my mandate. I'd have to think about 
this, and gauge how well the idea of using a "prototype" schema would suit 
my colleagues.

> Just thinking about this is quite strange.
> Linux autofs has been behind the pack for so long that to suddenly be
> considering how the service could do things better and possibly
> establish the standard in time to come is really weird.

And that view in itself is a bit novel to me, seeing as how Linux in 
general seems to be getting the lion's share of new *nix features these 
days :)  (It doesn't hurt that autofs's userspace side seems eminently
hackable, too.)

> Never the less I can't see us getting much support for such a proposal
> unless Linux autofs is at least providing all the existing expected
> functionality in a sound, stable and reliable way so I've still got my
> hands full for at least a while.

It's a fair point, and your earlier comments make perfect sense in light of 
it. Though I'm still a bit surprised that my proposal wasn't something that 
you'd come across before, in one form or another.

Ian, kind thanks for expounding on the situation for me. You've given me a 
bit to think about. It does seem like a "six of one, half-dozen of the 
other" judgment call at this point in time.


Sincerely yours,


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@iskunk.org        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@alum.mit.edu      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)

Re: AFS + LDAP

[Timo Felbinger]

On Sun, Jul 09, 2006 at 01:35:04AM -0400, Daniel Richard G. wrote:
> 
> On Sat, 2006 Jul 08 23:48:13 +0800, Ian Kent wrote:
> > > 
> > > 	automountKey: qux
> > > 	automountType: device
> > > 	automountFormat: xfs
> > > 	automountPath: /dev/sda5
> > > 	automountWritable: yes
> > 
> > We would probably need a couple of other attributes, say for mount
> > options other than read/write.
> 
> This is why you want your standards written by some greybeard at Sun 
> instead of a rabble-rouser like me :-)  Certainly here, there'd be a lot of 
> ground to cover, corner cases and the like.

Sorry for bursting into your conversation and bringing up an old
issue again, but it seems to be quite related to this discussion:

A while ago I did suggest a generalized syntax for LDAP map names,
by implementing an already existing standard: LDAP URLs as in rfc2255.
This would be more a "meta"-standard, as it does not enforce any
specific schema, but allow one to use arbitrary schemas, encoded
into the map name. So far, I used to think in terms of schemas with
just two relevant attributes (automount key and information), but I
actually start to like the idea of splitting automountInformation
into several attributes.

The current map name format would be subset of the URL syntax, so
compatibility could be preserved.

I submitted a patch for autofs4 (http://timof.qipc.org/autofs), which
however didn't make it into autofs5. I understand that this would be
an ambitious change, and bringing other parts of autofs up to standard
was probably more urgent; however, it could give plenty of room for
future improvements (like the evolution of a new standard schema), while
staying compatible with traditional schemas (at least, I don't see any
fundamental issues here), so I would still like to hear your opinions
about implementing this in a future version?

...btw:

On Thu, Jul 06 2006 at 15:40:24 -0400, Daniel Richard G. wrote:
>
> I was hoping for something more along the lines of an extension to the¯«
> standard NIS schema. (It's common for AFS sites to have each user's home¯«
> directory be a separately mountable volume, so having some sort of¯«
> user-volume equivalence in LDAP is reasonable.)«

If I understand this correctly (I'm not familiar with AFS), this is pretty
much the reason why I started to patch lookup_ldap.c in the first place:
to pull automount information from user account entries (rather than from
an independent hierarchy), with the "uid" attribute used as the autmountKey,
when mounting user directories. Seems the natural way of doing it to me.


Best Regards,

Timo Felbinger


-- 
Timo Felbinger                  http://www.felbinger.net
Quantum Physics Group           Phone:  +49 331 977 1793   Fax: -1767
Institut fuer Physik            Mobile: +49 177 735 1936
Universitaet Potsdam, Germany   PGP key-id: E92567B2

Re: AFS + LDAP

[elw]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=unknown-8bit; format=flowed, Size: 1010 bytes --]



>> I was hoping for something more along the lines of an extension to 
>> the¯« standard NIS schema. (It's common for AFS sites to have each 
>> user's home¯« directory be a separately mountable volume, so having 
>> some sort of¯« user-volume equivalence in LDAP is reasonable.)«
>
> If I understand this correctly (I'm not familiar with AFS), this is 
> pretty much the reason why I started to patch lookup_ldap.c in the first 
> place: to pull automount information from user account entries (rather 
> than from an independent hierarchy), with the "uid" attribute used as 
> the autmountKey, when mounting user directories. Seems the natural way 
> of doing it to me.


The same problem is going to emerge with sites where home directories are 
on Solaris ZFS volumes.

I'm probably going to handle it with a programmatic map, here, both on our 
Solaris and Linux machines.  Hacking the program map we use now is easier 
than reinventing the whole wheel, axle, and car....

--elijah

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: AFS + LDAP

[Daniel Richard G.]

On Sun, 2006 Jul 09 14:59:24 +0200, Timo Felbinger wrote:
> 
> Sorry for bursting into your conversation and bringing up an old
> issue again, but it seems to be quite related to this discussion:
> 
> A while ago I did suggest a generalized syntax for LDAP map names,
> by implementing an already existing standard: LDAP URLs as in rfc2255.
> This would be more a "meta"-standard, as it does not enforce any
> specific schema, but allow one to use arbitrary schemas, encoded
> into the map name. So far, I used to think in terms of schemas with
> just two relevant attributes (automount key and information), but I
> actually start to like the idea of splitting automountInformation
> into several attributes.

Hmm... so this lets you encode information that would otherwise go into 
autofs.conf (DEFAULT_{MAP,ENTRY,VALUE}_ATTRIBUTE et al.) and ldap.conf in 
the ldap:// URL itself, eh? I take it the real power comes when you pull 
the map entry itself via LDAP, so that you can effectively reconfigure a 
large number of machines with a single database commit.

> The current map name format would be subset of the URL syntax, so
> compatibility could be preserved.
> 
> I submitted a patch for autofs4 (http://timof.qipc.org/autofs), which
> however didn't make it into autofs5. I understand that this would be
> an ambitious change, and bringing other parts of autofs up to standard
> was probably more urgent; however, it could give plenty of room for
> future improvements (like the evolution of a new standard schema), while
> staying compatible with traditional schemas (at least, I don't see any
> fundamental issues here), so I would still like to hear your opinions
> about implementing this in a future version?

Provided that automountInformation can be broken up, it's an interesting 
approach to hashing out a standard schema. I'm not sure, however, that it's 
a sufficiently flexible one.

The three existing LDAP schemas are easily parameterized---and they are so 
in the default autofs.conf file---but that works because they all have an 
automountInformation catch-all (or its equivalent). When you break that up, 
you get into the question of how the multiple attributes corresponding to 
it should be structured, which is rather open-ended. Certainly I'd prefer 
to tackle such a problem in code, just to avoid any possible constraint 
that a previously-devised parameterization scheme might impose.

> ...btw:
> 
> On Thu, Jul 06 2006 at 15:40:24 -0400, Daniel Richard G. wrote:
> >
> > I was hoping for something more along the lines of an extension to the??
> > standard NIS schema. (It's common for AFS sites to have each user's home??
> > directory be a separately mountable volume, so having some sort of??
> > user-volume equivalence in LDAP is reasonable.)?
> 
> If I understand this correctly (I'm not familiar with AFS), this is pretty
> much the reason why I started to patch lookup_ldap.c in the first place:
> to pull automount information from user account entries (rather than from
> an independent hierarchy), with the "uid" attribute used as the autmountKey,
> when mounting user directories. Seems the natural way of doing it to me.

Oh, absolutely. In fact, I'd been thinking of having non-user volumes live 
in the database as user-like entities, to avoid the separate table, and 
acknowledge the parallels between the two. (Non-user volume records would, 
for the most part, just have a subset of a user's attributes.)

Isn't it possible to do what you describe, however, just by remapping the 
appropriate LDAP attributes in /etc/libnss-ldap.conf? I've haven't tried 
this yet, but I believe you could specify something like

	nss_map_attribute automountKey uid

and with an appropriate automountInformation attribute in each user record, 
autofs would never know the difference.


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@iskunk.org        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@alum.mit.edu      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)

Re: AFS + LDAP

[Timo Felbinger]

On Sun, Jul 09, 2006 at 10:27:31PM -0400, Daniel Richard G. wrote:
> 
> Hmm... so this lets you encode information that would otherwise go into 
> autofs.conf (DEFAULT_{MAP,ENTRY,VALUE}_ATTRIBUTE et al.) and ldap.conf in 
> the ldap:// URL itself, eh? I take it the real power comes when you pull 
> the map entry itself via LDAP, so that you can effectively reconfigure a 
> large number of machines with a single database commit.

Yes, that's what I have ultimately in mind (not using it yet, though,
but hopefully soon)
:-)

> > If I understand this correctly (I'm not familiar with AFS), this is pretty
> > much the reason why I started to patch lookup_ldap.c in the first place:
> > to pull automount information from user account entries (rather than from
> > an independent hierarchy), with the "uid" attribute used as the autmountKey,
> > when mounting user directories. Seems the natural way of doing it to me.
> 
> Oh, absolutely. In fact, I'd been thinking of having non-user volumes live 
> in the database as user-like entities, to avoid the separate table, and 
> acknowledge the parallels between the two. (Non-user volume records would, 
> for the most part, just have a subset of a user's attributes.)
> 
> Isn't it possible to do what you describe, however, just by remapping the 
> appropriate LDAP attributes in /etc/libnss-ldap.conf? I've haven't tried 
> this yet, but I believe you could specify something like
> 
> 	nss_map_attribute automountKey uid

Yes and no: the problem with system-wide configuration files is that
they are, well, per system. I want finer granularity, with the ability
to specify filters and attribute names on a per-map basis:
On a typical workstation, I want (at least) these two maps:
- one that handles user home directories and looks below
    ou=people,ou=physik,...
  and filters for accounts valid on this host, and
- another one that looks below
    ou=hosts,ou=physik,...
  and filters for the hostname and handles local stuff like /media/usb, ...
Forcing both to use identical schemas (or identical filters) would
require some counter-intuitive tour-de-force, and I don't want to do that;
the great thing about LDAP is that it allows me to store information in
a natural structure.

Greetings,

Timo


-- 
Timo Felbinger                  http://www.felbinger.net
Quantum Physics Group           Phone:  +49 331 977 1793   Fax: -1767
Institut fuer Physik            Mobile: +49 177 735 1936
Universitaet Potsdam, Germany   PGP key-id: E92567B2