Re: automount and nsswitch.conf

Re: automount and nsswitch.conf

[raven]

On Tue, 13 Jul 2004, Jeff Moyer wrote:

> ==> Regarding Re: automount and nsswitch.conf; raven@themaw.net adds:
> 
> raven> On Mon, 12 Jul 2004, Ian McLeod wrote:
> >> On Tue, 13 Jul 2004 raven@themaw.net wrote:
> >> 
> >> [snip] > > 3) for fstype=autofs, we need to explicitly set the map type.
> >> I'm unsure > > where this is done, or if it must be a source:map format
> >> in the map > > file?  At any rate, this certainly does not allow us to
> >> take advantage > > of nsswitch.conf, and may result in unexpected
> >> behaviour for the user.
> >> > 
> >> > fstype=autofs is basically a submount and is specified as a filesystem
> >> > rather than a map source. This shouldn't be to big a problem (or have
> >> I > missed your point).
> >> 
> >> This one is near and dear to my heart, so I'll clarify my understanding.
> >> 
> >> Here's an actual line from the NIS based maps at a client site:
> >> 
> >> clearcase -fstype=autofs auto.src.clearcase
> >> 
> >> This line works on Solaris.  Specifically, Solaris will look for
> >> "auto.src.clearcase" in the places and order specified in nsswitch.conf.
> >> 
> >> This line will fail under the current Linux code with an error "missing
> >> script type on".  The code expects the map source to be explicitly
> >> specified in <source>:<map> format.  Something like:
> >> 
> >> clearcase -fstype=autofs yp:auto.src.clearcase
> >> 
> >> What I would like to see (and what I have quasi-implemented with some
> >> kludgey patches) is Linux behavior that matches (or at least is capable
> >> of matching) the Solaris behavior.  This has obvious benefits in
> >> heterogeneous environments.
> 
> raven> This is the patch I have, yes?
> 
> raven> And you would be wanting me to merge it for 4.1.4 or produce a
> raven> supported patch for 4.1.3, yes?
> 
> raven> Have you done any additional work on it?
> 
> The patch Ian M. came up with hard codes the lookup order to "files nis".
> I've been trying to do additional work on it, but that requires getting a
> few things straight in my head, and then writing gobs of code, and then
> upgrading glibc, etc, etc.
> 
> I think we can go with what Ian proposed for now, as it definitely solved a
> problem for him.
> 
> >> 
> >> 
> >> > As well as the map order there is missing functionality in the current
> >> > approach in that if a map key appears more than once, say in a global
> >> map > and in a local file map, the two maps are not merged. They should
> >> be. This > needs to be catered for in handling nsswitch.conf map sources
> >> and even > multiple entries in the same map (master map that is).
> >> 
> >> This does not match the Solaris behavior (at least, not based on tests
> >> that I've done on the Solaris infra here).  The only circumstance where
> >> the Solaris automounter will combine maps is if a file map contains "+"
> >> notation.  In this case, it will merge the NIS map into the file map.
> >> In all other cases, Solaris seems to do the following:
> >> 
> >> -Search for the map (including auto.master) in the order specified in
> >> nsswitch.conf -Stop after the first match and process the map (do not
> >> continue, do not merge additional matches)
> >> 
> 
> raven> That's not what I have observed, of course I could be mistaken (and
> raven> often am), but is not an big issue atm.
> 
> This is one thing I really want to understand.  Let me phrase my question
> as precisely as I can:

Please disregard merging of maps comment I made. It's confusing what you 
are trying to clear up.

Having said that ....

> 
> The format of the nsswitch.conf is as follows:
> 
> database: lookuptype
> 
> (we will ignore the [NOTFOUND=return] stuff for now)
> 
> For each database, you specify one or more lookup types.  Then, for each
> query to the database, each lookup type is consulted for data, and we do
> not stop until we find it or we've exhausted lookup types.  I believe Ian
> K. calls this merging of maps.

Not quite what I originally meant but the way I believe that nsswitch.conf 
works.

> 
> Please let me know if this is how autofs is expected to interpret its line
> in the nsswitch.conf.  Mike Waychison believes this not to be true.  Here
> is his take on the differences:
> 
> ---Mike W.---
> - getXXXent semantics for SUCCESS|UNAVAIL|NOTFOUND|TRYAGAIN apply to the
>   entries in the tables (defined by service name) themselves.
> - automounter semantics for SUCCESS|UNAVAIL|NOTFOUND|TRYAGAIN apply to
>   the tables (or 'maps').  (where the service name is 'automount').

This assumes that the map entries themselves are delivered by the 
getXXXent routines. I think that's what your proposing, right?

Then we have the added complexity of different retrieval methods for 
different map types aka gobs of code but already present in autofs 
modules.

I think the bigger task here would be defining the API as the getXXXent 
above may not be sufficient for autofs as is. The current autofs 
uses the lookup module code in several ways. I'd have to ponder this for a 
while.

> 
> 
> With automounting, there are two level's of lookup.
> 
> 1) Give me the entity described by this map name.
> 2) Give me the entity described by this key, from this map entity.
> ---Mike W.---
> 
> This means that we consult nsswitch.conf only to find the first lookup type
> that _exists_, not whether its contents contain the key we are looking
> for.  I find this quite odd, and a departure from the semantics of every
> other entry in nsswitch.conf.  However, I think this is the way we operate
> today, right?

Yes. Agreed.

But this was implemented (by someone) in the init script, found in the v3 
RH package ages ago, to get some semblance of using nsswitch.conf. There 
has never been any real effort to implement real nsswitch.conf 
infrastructure.

Merging that into autofs v4 was my doing.

> 
> I might add that I find it quite frustrating that the Solaris man pages
> don't really touch on this issue.  It's impossible to read documentation and
> figure out the precise behaviour.  :(

Tell me about it!

> 
> >> If nothing else, it would be nice to have a "SOLARIS_COMPAT" flag that
> >> switches Linux autofs to the two behaviors described above.
> 
> raven> I would rather move autofs toward the Solaris behaviour.
> 
> Agreed.  If there was a compat flag, it would default to on in my packages.
> 
> raven> So, appart from merging your work, and working out a way to cleanly
> raven> get the map order, what else do we need to do.
> 
> raven> Can you propose a simple work plan we can focus on.
> 
> I exchanged emails with Ulrich Drepper on the feasibility of a
> getautomountent (or similar) call in libc.  He was not at all opposed to
> the idea.  My only concern is that if things work the way Mike W. says they
> do, then it may not make sense to add such an interface to libc/libnss.
> I'd have to think on this some more, though, as a standard interface would
> make things a lot easier for us (and it may be feasible to "stretch" the
> interface to look the way we want it to).

Seems to me the choice is whether to "go the whole hog with libc" or 
"keep the implemention in autofs and grab map types ourselves". There is 
one consideration though and that's that the lookup functions change fairly 
frequently and as I said above a fair amount of autofs function is 
included there. The current design calls lookup then calls parse from 
inside with context and then calls mount from within that with differnet 
context so going libc will require considerable internal autofs change.

> 
> Mike, would you mind re-iterating your position, and perhaps correcting any
> misinterpretations of your email I've made?
> 
> Thanks!
> 
> Jeff
> 
> p.s.  Do you think we should move this discussion to on-list?  It may be
> a good thing to archive.
>

Yep.

Ian

Re: automount and nsswitch.conf

[Jeff Moyer]

> ==> Regarding Re: automount and nsswitch.conf; Michael Waychison adds:
[snip]

>>>> What I would like to see (and what I have quasi-implemented with some
>>>> kludgey patches) is Linux behavior that matches (or at least is
>>>> capable of matching) the Solaris behavior.  This has obvious benefits
>>>> in heterogeneous environments.
>>
raven> This is the patch I have, yes?
>>
raven> And you would be wanting me to merge it for 4.1.4 or produce a
raven> supported patch for 4.1.3, yes?
>>
raven> Have you done any additional work on it?
>> The patch Ian M. came up with hard codes the lookup order to "files
>> nis".  I've been trying to do additional work on it, but that requires
>> getting a few things straight in my head, and then writing gobs of code,
>> and then upgrading glibc, etc, etc.
>> 
>> I think we can go with what Ian proposed for now, as it definitely
>> solved a problem for him.

Michael.Waychison> Ian M. is correct in that nsswitch.conf logic should be
Michael.Waychison> observed when looking up a map.  I don't think it's
Michael.Waychison> worth the hassle and kludgyness of trying to bring any
Michael.Waychison> sort of API into glibc.  For the majority of Solaris
Michael.Waychison> users, 'files nis' is 'good enough'.  This is slowly
Michael.Waychison> changing to 'files ldap', so we do eventually need to
Michael.Waychison> have this be a configurable option for things to work
Michael.Waychison> properly..

Ok, my only beef here is that we are not at all honoring the semantics of
nsswitch.conf.  I attest that this is a design flaw, but given the Sun
automounter legacy, I see now ay around it.  We'll adhere to what is done
by all other automounters, even though it's wrong and poorly documented.

So, can I make the assumption that Suns's automounter does not then honor
the "reaction on lookup result", ala [NOTFOUND=return]?  If so, then our job
is a bit easier, though we are _still_ duplicating a parser, which I
despise.  (I'll do it, I just won't like it ;)


>>
>>>>
>>>>> As well as the map order there is missing functionality in the
>>>>> current approach in that if a map key appears more than once, say in
>>>>> a global
>>>> map > and in a local file map, the two maps are not merged. They
>>>> should be. This > needs to be catered for in handling nsswitch.conf
>>>> map sources and even > multiple entries in the same map (master map
>>>> that is).
>>>> 
>>>> This does not match the Solaris behavior (at least, not based on tests
>>>> that I've done on the Solaris infra here).  The only circumstance
>>>> where the Solaris automounter will combine maps is if a file map
>>>> contains "+" notation.  In this case, it will merge the NIS map into
>>>> the file map.

Michael.Waychison> Side note: If the included 'mapname' starts with a '/',
Michael.Waychison> then only local databases in nsswitch.conf should be
Michael.Waychison> checked.  If it doesn't, then only remote databases
Michael.Waychison> should be checked.  This all happens in the order
Michael.Waychison> specified.

Michael.Waychison> This differs from lookup of maps in auto.master however.
Michael.Waychison> In the master map, lookup is done (regardless of the
Michael.Waychison> first character) in the order specified by
Michael.Waychison> nsswitch.conf, prepending '/etc/' for 'files' if
Michael.Waychison> required.

And we don't support the '+' notation, correct?  Should we?  Since we're in
the code, it may make sense.

>>>> In all other cases, Solaris seems to do the following:
>>>> 
>>>> -Search for the map (including auto.master) in the order specified in
>>>> nsswitch.conf -Stop after the first match and process the map (do not
>>>> continue, do not merge additional matches)
>>>> 
>>
raven> That's not what I have observed, of course I could be mistaken (and
raven> often am), but is not an big issue atm.
>>

Michael.Waychison> Ian M's description is the correct one.

Easy enough.

[snip]

>>>> If nothing else, it would be nice to have a "SOLARIS_COMPAT" flag that
>>>> switches Linux autofs to the two behaviors described above.
>>
raven> I would rather move autofs toward the Solaris behaviour.
>> Agreed.  If there was a compat flag, it would default to on in my
Michael.Waychison> packages.
>>

Michael.Waychison> I don't know where the Linuxisms came from originally,
Michael.Waychison> but they really do smell of lazyness to not implement
Michael.Waychison> nsswitch.conf logic.  All other Unix do the right thing
Michael.Waychison> in a not so incompatible way.

ziiing!  call us lazy, will ya.  ;)

raven> So, appart from merging your work, and working out a way to cleanly
raven> get the map order, what else do we need to do.
>>
raven> Can you propose a simple work plan we can focus on.
>> I exchanged emails with Ulrich Drepper on the feasibility of a
>> getautomountent (or similar) call in libc.  He was not at all opposed to
>> the idea.  My only concern is that if things work the way Mike W. says
Michael.Waychison> they
>> do, then it may not make sense to add such an interface to libc/libnss.
>> I'd have to think on this some more, though, as a standard interface
>> would make things a lot easier for us (and it may be feasible to
>> "stretch" the interface to look the way we want it to).
>> 

Michael.Waychison> I'm just really against putting this in libc ;).  With a
Michael.Waychison> single consumer and no defined interface to 'copy',
Michael.Waychison> what's the point?

What's the point?  The point is to leverage existing code.  As it stands,
my feeling on the matter is that an entry should never have been added to
nsswitch.conf.  It should have been in an automounter configuration file,
since the semantics are worse than completely different, they're slightly
different!

So, as such, it seems I agree with you in that we should not add an
interface to libc.  ;)


>> Mike, would you mind re-iterating your position, and perhaps
>> correcting any misinterpretations of your email I've made?
>> 

Michael.Waychison> Sure.

Michael.Waychison> - Current automount 4 (and 3) do not support any 
Michael.Waychison>   nsswitch.conf logic.
Michael.Waychison> - We need nsswitch.conf logic.
Michael.Waychison> - I don't think we should have to add any API to glibc.
Michael.Waychison>   - we don't want to be completely dependent on 'given 
Michael.Waychison>     versions of glibc'.
Michael.Waychison>   - it becomes a bit of a maintenance nightmare.
Michael.Waychison>   - so far, we'd be the _only_ consumer of such an API.
Michael.Waychison>   - lack of standard API means we are playing guessing 
Michael.Waychison>     games at coming up with API semantics.
Michael.Waychison>   - nss/* is a maze of macros and one liner files that 
Michael.Waychison>     bogs my mind.
Michael.Waychison> - My understanding is Ian M's patch adds 'files nis' 
Michael.Waychison>   logic.  Good.
Michael.Waychison> - Let's try to extend that somehow to actually parse out
Michael.Waychison>   and use nsswitch.conf
Michael.Waychison> - Maps are not automatically 'merged'.
Michael.Waychison> - Maps are instead explictly 'included' (only possible 
Michael.Waychison>   from local flat files).
Michael.Waychison> - There _is_ a lookup algorithm.. ..it's just not well 
Michael.Waychison>   documented.

I believe I've addressed these points.  Thanks for your time on this, Mike.

-Jeff

Re: automount and nsswitch.conf

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Moyer wrote:
>>==> Regarding Re: automount and nsswitch.conf; Michael Waychison adds:
>
> [snip]
>
>
>>>>>What I would like to see (and what I have quasi-implemented with some
>>>>>kludgey patches) is Linux behavior that matches (or at least is
>>>>>capable of matching) the Solaris behavior.  This has obvious benefits
>>>>>in heterogeneous environments.
>>>
> raven> This is the patch I have, yes?
>
> raven> And you would be wanting me to merge it for 4.1.4 or produce a
> raven> supported patch for 4.1.3, yes?
>
> raven> Have you done any additional work on it?
>
>>>The patch Ian M. came up with hard codes the lookup order to "files
>>>nis".  I've been trying to do additional work on it, but that requires
>>>getting a few things straight in my head, and then writing gobs of code,
>>>and then upgrading glibc, etc, etc.
>>>
>>>I think we can go with what Ian proposed for now, as it definitely
>>>solved a problem for him.
>
>
> Michael.Waychison> Ian M. is correct in that nsswitch.conf logic should be
> Michael.Waychison> observed when looking up a map.  I don't think it's
> Michael.Waychison> worth the hassle and kludgyness of trying to bring any
> Michael.Waychison> sort of API into glibc.  For the majority of Solaris
> Michael.Waychison> users, 'files nis' is 'good enough'.  This is slowly
> Michael.Waychison> changing to 'files ldap', so we do eventually need to
> Michael.Waychison> have this be a configurable option for things to work
> Michael.Waychison> properly..
>
> Ok, my only beef here is that we are not at all honoring the semantics of
> nsswitch.conf.  I attest that this is a design flaw, but given the Sun
> automounter legacy, I see now ay around it.  We'll adhere to what is done
> by all other automounters, even though it's wrong and poorly documented.
>
> So, can I make the assumption that Suns's automounter does not then honor
> the "reaction on lookup result", ala [NOTFOUND=return]?  If so, then
our job
> is a bit easier, though we are _still_ duplicating a parser, which I
> despise.  (I'll do it, I just won't like it ;)
>

I don't know if Sun's automounter does, I'd have to do a bit of testing,
although I don't see why it wouldn't support status -> action predicates.

>
>
>>>>>>As well as the map order there is missing functionality in the
>>>>>>current approach in that if a map key appears more than once, say in
>>>>>>a global
>>>>>
>>>>>map > and in a local file map, the two maps are not merged. They
>>>>>should be. This > needs to be catered for in handling nsswitch.conf
>>>>>map sources and even > multiple entries in the same map (master map
>>>>>that is).
>>>>>
>>>>>This does not match the Solaris behavior (at least, not based on tests
>>>>>that I've done on the Solaris infra here).  The only circumstance
>>>>>where the Solaris automounter will combine maps is if a file map
>>>>>contains "+" notation.  In this case, it will merge the NIS map into
>>>>>the file map.
>
>
> Michael.Waychison> Side note: If the included 'mapname' starts with a '/',
> Michael.Waychison> then only local databases in nsswitch.conf should be
> Michael.Waychison> checked.  If it doesn't, then only remote databases
> Michael.Waychison> should be checked.  This all happens in the order
> Michael.Waychison> specified.
>
> Michael.Waychison> This differs from lookup of maps in auto.master
however.
> Michael.Waychison> In the master map, lookup is done (regardless of the
> Michael.Waychison> first character) in the order specified by
> Michael.Waychison> nsswitch.conf, prepending '/etc/' for 'files' if
> Michael.Waychison> required.
>
> And we don't support the '+' notation, correct?  Should we?  Since
we're in
> the code, it may make sense.
>

Last I looked, '+' was only supported in the master map, handled by a
clause in the init script.  Ian K?

>>>>>If nothing else, it would be nice to have a "SOLARIS_COMPAT" flag that
>>>>>switches Linux autofs to the two behaviors described above.
>>>
> raven> I would rather move autofs toward the Solaris behaviour.
>
>>>Agreed.  If there was a compat flag, it would default to on in my
>
> Michael.Waychison> packages.
>
>
> Michael.Waychison> I don't know where the Linuxisms came from originally,
> Michael.Waychison> but they really do smell of lazyness to not implement
> Michael.Waychison> nsswitch.conf logic.  All other Unix do the right thing
> Michael.Waychison> in a not so incompatible way.
>
> ziiing!  call us lazy, will ya.  ;)

Nah. I just have a beef against the file: / program: / yp: / ldap:  /
nisplus: / hesiod: prefixes.  They make the map language context
dependent.  Consider these entries:

mikew	file:/some/path
jeffm   -fstype=autofs file:/some/path

My homedir would be an nfs mount coming from server 'file', but yours
would be an indirect mount defined by the map in flat file /some/path.
It just makes writing a *comprehensive* parser more difficult :\.  It's
also completely incompatible with everything else out there, which is
probably what prompted Ian M to write his patch in the first place.

>
> raven> So, appart from merging your work, and working out a way to cleanly
> raven> get the map order, what else do we need to do.
>
> raven> Can you propose a simple work plan we can focus on.
>
>>>I exchanged emails with Ulrich Drepper on the feasibility of a
>>>getautomountent (or similar) call in libc.  He was not at all opposed to
>>>the idea.  My only concern is that if things work the way Mike W. says
>
> Michael.Waychison> they
>
>>>do, then it may not make sense to add such an interface to libc/libnss.
>>>I'd have to think on this some more, though, as a standard interface
>>>would make things a lot easier for us (and it may be feasible to
>>>"stretch" the interface to look the way we want it to).
>>>
>
>
> Michael.Waychison> I'm just really against putting this in libc ;).
With a
> Michael.Waychison> single consumer and no defined interface to 'copy',
> Michael.Waychison> what's the point?
>
> What's the point?  The point is to leverage existing code.  As it stands,
> my feeling on the matter is that an entry should never have been added to
> nsswitch.conf.  It should have been in an automounter configuration file,
> since the semantics are worse than completely different, they're slightly
> different!

I pondered this over coffee this morning, and thought to myself:

"If we added this functionality to nss/, then we'd be abstracting out
the nsswitch.conf parser.  This is a benefit because we don't have to
worry about the status->action semantics and would allow us to change
the nsswitch.conf interface"

I then took another sip of coffee and realized that switching the switch
is a dumb idea ;)

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA8/qfdQs4kOxk3/MRAiOjAKCN3KCousS9RctMhXsGJq4Cxsx5zwCghMxT
ClxeViTcbakJZdsA9t4aJN4=
=+/XI
-----END PGP SIGNATURE-----

Re: automount and nsswitch.conf

[Jeff Moyer]

==> Regarding Re: automount and nsswitch.conf; Mike Waychison <Michael.Waychison@Sun.COM> adds:

[snip]

>> Ok, my only beef here is that we are not at all honoring the semantics
>> of nsswitch.conf.  I attest that this is a design flaw, but given the
>> Sun automounter legacy, I see now ay around it.  We'll adhere to what is
>> done by all other automounters, even though it's wrong and poorly
>> documented.
>> 
>> So, can I make the assumption that Suns's automounter does not then
>> honor the "reaction on lookup result", ala [NOTFOUND=return]?  If so,
>> then
Michael.Waychison> our job
>> is a bit easier, though we are _still_ duplicating a parser, which I
>> despise.  (I'll do it, I just won't like it ;)
>> 

Michael.Waychison> I don't know if Sun's automounter does, I'd have to do a
Michael.Waychison> bit of testing, although I don't see why it wouldn't
Michael.Waychison> support status -> action predicates.

ugh.

[snip]

>> And we don't support the '+' notation, correct?  Should we?  Since
Michael.Waychison> we're in
>> the code, it may make sense.
>> 

Michael.Waychison> Last I looked, '+' was only supported in the master map,
Michael.Waychison> handled by a clause in the init script.  Ian K?

from the init script:
        cat /etc/auto.master | grep -v '^\+' | sed -e '/^#/d' -e '/^$/d'

Yup, it's "handled" all right!

[snip]


Michael.Waychison> I don't know where the Linuxisms came from originally,
Michael.Waychison> but they really do smell of lazyness to not implement
Michael.Waychison> nsswitch.conf logic.  All other Unix do the right thing
Michael.Waychison> in a not so incompatible way.
>> ziiing!  call us lazy, will ya.  ;)

Michael.Waychison> Nah. I just have a beef against the file: / program: /
Michael.Waychison> yp: / ldap: /
nisplus> / hesiod: prefixes.  They make the map language context
Michael.Waychison> dependent.  Consider these entries:

Michael.Waychison> mikew file:/some/path jeffm -fstype=autofs
Michael.Waychison> file:/some/path

Michael.Waychison> My homedir would be an nfs mount coming from server
Michael.Waychison> 'file', but yours would be an indirect mount defined by
Michael.Waychison> the map in flat file /some/path.  It just makes writing
Michael.Waychison> a *comprehensive* parser more difficult :\.  It's also
Michael.Waychison> completely incompatible with everything else out there,
Michael.Waychison> which is probably what prompted Ian M to write his patch
Michael.Waychison> in the first place.

heh.  That's a good example.  Unfortunately, we may have legacy issues at
this point.

[snip]

Michael.Waychison> I'm just really against putting this in libc ;).  With a
Michael.Waychison> single consumer and no defined interface to 'copy',
Michael.Waychison> what's the point?
>> What's the point?  The point is to leverage existing code.  As it
>> stands, my feeling on the matter is that an entry should never have been
>> added to nsswitch.conf.  It should have been in an automounter
>> configuration file, since the semantics are worse than completely
>> different, they're slightly different!

Michael.Waychison> I pondered this over coffee this morning, and thought to
Michael.Waychison> myself:

Michael.Waychison> "If we added this functionality to nss/, then we'd be
Michael.Waychison> abstracting out the nsswitch.conf parser.  This is a
Michael.Waychison> benefit because we don't have to worry about the
Michael.Waychison> status->action semantics and would allow us to change
Michael.Waychison> the nsswitch.conf interface"

I don't entirely understand your pre-coffee nss pontification.  Might I
suggest a few more sips?  ;)

If we add support to nss, then we define the interface and the semantics of
that interface.  We could have one function return the result of a map
lookup, and another a key lookup.  They key lookup would take two
arguments, one being the source, the other being the key.  For ghosting,
you'd need an iterative function to enumerate the keys.  Hmm, what would
the functions be?

struct automapent *getautomapent(const char *mapname);
/* provide null key for iteration */
struct automntent *getautomntent(struct automapent *, const char *key);
void endautomntent(struct automapent *);

Now, before I go any further, Ian K's point stands.  Putting the parser
logic entirely in libc would require a significant structural change to the
code base.  I'm not an advocate of that, certainly not before we get things
a bit more stable.

SUMMARY

The current Linux automounter does not properly handle nsswitch.conf.  It
is desirable to leverage the nss library within libc to implement this
functionality, though it is infeasible to do so in the near future.  Thus,
we need to implement our own nsswitch.conf parser within the automount
code.  I believe future implementations should move toward the libc
approach.

In either approach, we need to move parsing logic out of the init script.
We can do this by making the new parsing code into a sort of library which
can be accessed by a helper program that the init script can run.  It is
insane to try to write this code in two languages, especially when one of
them is shell.

The current parsing of auto.master is flawed, but can be fixed with the
approach described in the immediately preceeding paragraph.  We definitely
do not want to source _all_ potential auto.master maps.

[NOTE] Ian Kent has, "making the automounter a threaded app," on his todo
list.  I believe this is partly motivated by the need to move logic out of
the init script and into the c code.  Thus, you would start one automounter
process, and it would spawn threads for each mount.  As such, the helper
program approach may only be an interim solution.

We need to think about the impact of removing the maptype:mapname grammar
from the map file formats, per example provided by Mike W.  A phasing out
of this seems like a reasonable approach, perhaps starting out with simple
warning messages early on and good documentation on how to get the proper
semantics with the tools available.  Of course, this requires that we
implement the nsswitch.conf parsing logic, first.

Handling of the '+' inclusion directive should also be implemented.


Ok, have I missed anything?  Does anyone want to contend any of these
points?

-Jeff

p.s. what a can of worms...  did anyone see the lid lying around?  ;)

Re: Re: automount and nsswitch.conf

[Joseph V Moss]

> ==> Regarding Re: automount and nsswitch.conf; Mike Waychison <Michael.Waychison@Sun.COM> adds:
> 
> [snip]
> 
> >> Ok, my only beef here is that we are not at all honoring the semantics
> >> of nsswitch.conf.  I attest that this is a design flaw, but given the
> >> Sun automounter legacy, I see now ay around it.  We'll adhere to what is
> >> done by all other automounters, even though it's wrong and poorly
> >> documented.
> >> 
> >> So, can I make the assumption that Suns's automounter does not then
> >> honor the "reaction on lookup result", ala [NOTFOUND=return]?  If so,
> >> then
> Michael.Waychison> our job
> >> is a bit easier, though we are _still_ duplicating a parser, which I
> >> despise.  (I'll do it, I just won't like it ;)
> >> 

H.P.A. was always quite opposed to using nsswitch.conf for autofs (see
http://www.mail-archive.com/autofs@linux.kernel.org/msg00733.html and other
messages in that thread, for example), but it does seem like it's a
defacto standard that linux should be compatible with.

Re: Re: automount and nsswitch.conf

[raven]

On Tue, 13 Jul 2004, Joseph V Moss wrote:

> > ==> Regarding Re: automount and nsswitch.conf; Mike Waychison <Michael.Waychison@Sun.COM> adds:
> > 
> > [snip]
> > 
> > >> Ok, my only beef here is that we are not at all honoring the semantics
> > >> of nsswitch.conf.  I attest that this is a design flaw, but given the
> > >> Sun automounter legacy, I see now ay around it.  We'll adhere to what is
> > >> done by all other automounters, even though it's wrong and poorly
> > >> documented.
> > >> 
> > >> So, can I make the assumption that Suns's automounter does not then
> > >> honor the "reaction on lookup result", ala [NOTFOUND=return]?  If so,
> > >> then
> > Michael.Waychison> our job
> > >> is a bit easier, though we are _still_ duplicating a parser, which I
> > >> despise.  (I'll do it, I just won't like it ;)
> > >> 
> 
> H.P.A. was always quite opposed to using nsswitch.conf for autofs (see
> http://www.mail-archive.com/autofs@linux.kernel.org/msg00733.html and other
> messages in that thread, for example), but it does seem like it's a
> defacto standard that linux should be compatible with.

Yes. I can understand his viewpoint. The original autofs has a character 
of its own and was never designed specifically to fit into Solaris type 
automounter environments. But this is something that many people need and 
as you say the Solaris behaviour is the defacto standard that several OSes 
implement so, for coexistence, we probably should as well.

Ian

Re: automount and nsswitch.conf

[raven]

On Tue, 13 Jul 2004, Jeff Moyer wrote:

> 
> [snip]
> 
> Michael.Waychison> I'm just really against putting this in libc ;).  With a
> Michael.Waychison> single consumer and no defined interface to 'copy',
> Michael.Waychison> what's the point?
> >> What's the point?  The point is to leverage existing code.  As it
> >> stands, my feeling on the matter is that an entry should never have been
> >> added to nsswitch.conf.  It should have been in an automounter
> >> configuration file, since the semantics are worse than completely
> >> different, they're slightly different!
> 
> Michael.Waychison> I pondered this over coffee this morning, and thought to
> Michael.Waychison> myself:
> 
> Michael.Waychison> "If we added this functionality to nss/, then we'd be
> Michael.Waychison> abstracting out the nsswitch.conf parser.  This is a
> Michael.Waychison> benefit because we don't have to worry about the
> Michael.Waychison> status->action semantics and would allow us to change
> Michael.Waychison> the nsswitch.conf interface"
> 
> I don't entirely understand your pre-coffee nss pontification.  Might I
> suggest a few more sips?  ;)
> 
> If we add support to nss, then we define the interface and the semantics of
> that interface.  We could have one function return the result of a map
> lookup, and another a key lookup.  They key lookup would take two
> arguments, one being the source, the other being the key.  For ghosting,
> you'd need an iterative function to enumerate the keys.  Hmm, what would
> the functions be?
> 
> struct automapent *getautomapent(const char *mapname);
> /* provide null key for iteration */
> struct automntent *getautomntent(struct automapent *, const char *key);
> void endautomntent(struct automapent *);
> 
> Now, before I go any further, Ian K's point stands.  Putting the parser
> logic entirely in libc would require a significant structural change to the
> code base.  I'm not an advocate of that, certainly not before we get things
> a bit more stable.

I think there is a long way to go to merge this function into libc/nss.

We need to merge this into autofs now.

> 
> SUMMARY
> 
> The current Linux automounter does not properly handle nsswitch.conf.  It
> is desirable to leverage the nss library within libc to implement this
> functionality, though it is infeasible to do so in the near future.  Thus,
> we need to implement our own nsswitch.conf parser within the automount
> code.  I believe future implementations should move toward the libc
> approach.

To early to really discuss whether it would actually be benifical to 
leverage the libc code. Developing with a eye to this end should show us 
what oppertunities or shortcommings exist with this approach.

> 
> In either approach, we need to move parsing logic out of the init script.
> We can do this by making the new parsing code into a sort of library which
> can be accessed by a helper program that the init script can run.  It is
> insane to try to write this code in two languages, especially when one of
> them is shell.

My thoughts were a seperate module but maybe not a seperate utility. I 
haven't done any experimentation with this specifically yet.

One thing to keep in mind is that we already have a fair bit of useful 
code in the lookup modules to talk to different map sources. Perhaps the 
lookup module interface should be extended to read master maps a well as 
entries. This is consistent with the current design. Comments?

> 
> The current parsing of auto.master is flawed, but can be fixed with the
> approach described in the immediately preceeding paragraph.  We definitely
> do not want to source _all_ potential auto.master maps.
> 
> [NOTE] Ian Kent has, "making the automounter a threaded app," on his todo
> list.  I believe this is partly motivated by the need to move logic out of
> the init script and into the c code.  Thus, you would start one automounter
> process, and it would spawn threads for each mount.  As such, the helper
> program approach may only be an interim solution.

If we are writting a parser then to turn it into a "supervisor" thread may 
not be that difficult. My experiments with future developments move the 
code to this type of module seperation because of the way I think things 
should go.

> 
> We need to think about the impact of removing the maptype:mapname grammar
> from the map file formats, per example provided by Mike W.  A phasing out
> of this seems like a reasonable approach, perhaps starting out with simple
> warning messages early on and good documentation on how to get the proper
> semantics with the tools available.  Of course, this requires that we
> implement the nsswitch.conf parsing logic, first.

It shouldn't be to hard to support the existing syntax as an override. 
While my goal has been to move autofs toward coexistence within Solaris 
style sites (I haven't been to successful but still want to) I think it 
would be a shame to discard the individuality and character of the 
original autofs, created by Peter Anvin for Linux, not for coexistence in 
Solaris environments. The original autofs had (has) a face of it's own and 
those creative ideas shouldn't be discarded out of hand.

> 
> Handling of the '+' inclusion directive should also be implemented.
>

Part and parcel of the master map parsing.

> 
> Ok, have I missed anything?  Does anyone want to contend any of these
> points?
> 
> -Jeff
> 
> p.s. what a can of worms...  did anyone see the lid lying around?  ;)

The can has been there for ages. The worms couldn't fit in the can any 
more so they just pushed it of and chucked it away.

Ian

Re: automount and nsswitch.conf

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

raven@themaw.net wrote:
> On Tue, 13 Jul 2004, Jeff Moyer wrote:
>
>
>>[snip]
>>
>>Michael.Waychison> I'm just really against putting this in libc ;).
With a
>>Michael.Waychison> single consumer and no defined interface to 'copy',
>>Michael.Waychison> what's the point?
>>
>>>>What's the point?  The point is to leverage existing code.  As it
>>>>stands, my feeling on the matter is that an entry should never have been
>>>>added to nsswitch.conf.  It should have been in an automounter
>>>>configuration file, since the semantics are worse than completely
>>>>different, they're slightly different!
>>
>>Michael.Waychison> I pondered this over coffee this morning, and
thought to
>>Michael.Waychison> myself:
>>
>>Michael.Waychison> "If we added this functionality to nss/, then we'd be
>>Michael.Waychison> abstracting out the nsswitch.conf parser.  This is a
>>Michael.Waychison> benefit because we don't have to worry about the
>>Michael.Waychison> status->action semantics and would allow us to change
>>Michael.Waychison> the nsswitch.conf interface"
>>
>>I don't entirely understand your pre-coffee nss pontification.  Might I
>>suggest a few more sips?  ;)
>>
>>If we add support to nss, then we define the interface and the
semantics of
>>that interface.  We could have one function return the result of a map
>>lookup, and another a key lookup.  They key lookup would take two
>>arguments, one being the source, the other being the key.  For ghosting,
>>you'd need an iterative function to enumerate the keys.  Hmm, what would
>>the functions be?
>>
>>struct automapent *getautomapent(const char *mapname);
>>/* provide null key for iteration */
>>struct automntent *getautomntent(struct automapent *, const char *key);
>>void endautomntent(struct automapent *);
>>
>>Now, before I go any further, Ian K's point stands.  Putting the parser
>>logic entirely in libc would require a significant structural change
to the
>>code base.  I'm not an advocate of that, certainly not before we get
things
>>a bit more stable.
>
>
> I think there is a long way to go to merge this function into libc/nss.
>
> We need to merge this into autofs now.
>

As per earlier discussions, I've confirmed that Solaris has no public
interface for grabbing map information from name services.  Infact, all
logic is done in the application layer.

>
>>SUMMARY
>>
>>The current Linux automounter does not properly handle nsswitch.conf.  It
>>is desirable to leverage the nss library within libc to implement this
>>functionality, though it is infeasible to do so in the near future.  Thus,
>>we need to implement our own nsswitch.conf parser within the automount
>>code.  I believe future implementations should move toward the libc
>>approach.
>
>
> To early to really discuss whether it would actually be benifical to
> leverage the libc code. Developing with a eye to this end should show us
> what oppertunities or shortcommings exist with this approach.
>
>
>>In either approach, we need to move parsing logic out of the init script.
>>We can do this by making the new parsing code into a sort of library which
>>can be accessed by a helper program that the init script can run.  It is
>>insane to try to write this code in two languages, especially when one of
>>them is shell.
>
>
> My thoughts were a seperate module but maybe not a seperate utility. I
> haven't done any experimentation with this specifically yet.
>
> One thing to keep in mind is that we already have a fair bit of useful
> code in the lookup modules to talk to different map sources. Perhaps the
> lookup module interface should be extended to read master maps a well as
> entries. This is consistent with the current design. Comments?
>
>
>>The current parsing of auto.master is flawed, but can be fixed with the
>>approach described in the immediately preceeding paragraph.  We definitely
>>do not want to source _all_ potential auto.master maps.
>>
>>[NOTE] Ian Kent has, "making the automounter a threaded app," on his todo
>>list.  I believe this is partly motivated by the need to move logic out of
>>the init script and into the c code.  Thus, you would start one
automounter
>>process, and it would spawn threads for each mount.  As such, the helper
>>program approach may only be an interim solution.
>
>
> If we are writting a parser then to turn it into a "supervisor" thread
may
> not be that difficult. My experiments with future developments move the
> code to this type of module seperation because of the way I think things
> should go.
>
>
>>We need to think about the impact of removing the maptype:mapname grammar
>>from the map file formats, per example provided by Mike W.  A phasing out
>>of this seems like a reasonable approach, perhaps starting out with simple
>>warning messages early on and good documentation on how to get the proper
>>semantics with the tools available.  Of course, this requires that we
>>implement the nsswitch.conf parsing logic, first.
>
>
> It shouldn't be to hard to support the existing syntax as an override.
> While my goal has been to move autofs toward coexistence within Solaris
> style sites (I haven't been to successful but still want to) I think it
> would be a shame to discard the individuality and character of the
> original autofs, created by Peter Anvin for Linux, not for coexistence in
> Solaris environments. The original autofs had (has) a face of it's own
and
> those creative ideas shouldn't be discarded out of hand.
>

I agree that supporting the nameservice prefixes as an override is
possible, but don't believe keeping it as a reminder of 'individuality'
has any merit.  When nss support comes in, I'd suggest we start
complaining loud and clear in the logs that nameservice prefixes are a)
deprecated, b) is completely incompatible with every other autofs system
out in the wild.

Prefixes are a hack.  Warts like this should only be supported for a
short term.  Let's cut our losses and move on.

>
>>Handling of the '+' inclusion directive should also be implemented.
>>
>
>
> Part and parcel of the master map parsing.

This is not master map specific.  It applies to all flat files.  But you
knew that right ;)

>
>
>>Ok, have I missed anything?  Does anyone want to contend any of these
>>points?
>>
>>-Jeff
>>
>>p.s. what a can of worms...  did anyone see the lid lying around?  ;)
>
>
> The can has been there for ages. The worms couldn't fit in the can any
> more so they just pushed it of and chucked it away.
>

Yup. Completely agree :)


- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9U2IdQs4kOxk3/MRAvgIAKCXj6ifmQnrSqSFWtZ/2xKm5QIb6gCfVUo9
fXMYpg+7LdFgKxY8Jd5Xjn4=
=Q3ya
-----END PGP SIGNATURE-----

Re: automount and nsswitch.conf

[raven]

On Wed, 14 Jul 2004, Mike Waychison wrote:

> 
> As per earlier discussions, I've confirmed that Solaris has no public
> interface for grabbing map information from name services.  Infact, all
> logic is done in the application layer.
> 
> >
> >>SUMMARY
> >>
> >>The current Linux automounter does not properly handle nsswitch.conf.  It
> >>is desirable to leverage the nss library within libc to implement this
> >>functionality, though it is infeasible to do so in the near future.  Thus,
> >>we need to implement our own nsswitch.conf parser within the automount
> >>code.  I believe future implementations should move toward the libc
> >>approach.
> >
> >
> > To early to really discuss whether it would actually be benifical to
> > leverage the libc code. Developing with a eye to this end should show us
> > what oppertunities or shortcommings exist with this approach.
> >
> >
> >>In either approach, we need to move parsing logic out of the init script.
> >>We can do this by making the new parsing code into a sort of library which
> >>can be accessed by a helper program that the init script can run.  It is
> >>insane to try to write this code in two languages, especially when one of
> >>them is shell.
> >
> >
> > My thoughts were a seperate module but maybe not a seperate utility. I
> > haven't done any experimentation with this specifically yet.
> >
> > One thing to keep in mind is that we already have a fair bit of useful
> > code in the lookup modules to talk to different map sources. Perhaps the
> > lookup module interface should be extended to read master maps a well as
> > entries. This is consistent with the current design. Comments?
> >
> >
> >>The current parsing of auto.master is flawed, but can be fixed with the
> >>approach described in the immediately preceeding paragraph.  We definitely
> >>do not want to source _all_ potential auto.master maps.
> >>
> >>[NOTE] Ian Kent has, "making the automounter a threaded app," on his todo
> >>list.  I believe this is partly motivated by the need to move logic out of
> >>the init script and into the c code.  Thus, you would start one
> automounter
> >>process, and it would spawn threads for each mount.  As such, the helper
> >>program approach may only be an interim solution.
> >
> >
> > If we are writting a parser then to turn it into a "supervisor" thread
> may
> > not be that difficult. My experiments with future developments move the
> > code to this type of module seperation because of the way I think things
> > should go.
> >
> >
> >>We need to think about the impact of removing the maptype:mapname grammar
> >>from the map file formats, per example provided by Mike W.  A phasing out
> >>of this seems like a reasonable approach, perhaps starting out with simple
> >>warning messages early on and good documentation on how to get the proper
> >>semantics with the tools available.  Of course, this requires that we
> >>implement the nsswitch.conf parsing logic, first.
> >
> >
> > It shouldn't be to hard to support the existing syntax as an override.
> > While my goal has been to move autofs toward coexistence within Solaris
> > style sites (I haven't been to successful but still want to) I think it
> > would be a shame to discard the individuality and character of the
> > original autofs, created by Peter Anvin for Linux, not for coexistence in
> > Solaris environments. The original autofs had (has) a face of it's own
> and
> > those creative ideas shouldn't be discarded out of hand.
> >
> 
> I agree that supporting the nameservice prefixes as an override is
> possible, but don't believe keeping it as a reminder of 'individuality'
> has any merit.  When nss support comes in, I'd suggest we start
> complaining loud and clear in the logs that nameservice prefixes are a)
> deprecated, b) is completely incompatible with every other autofs system
> out in the wild.
> 
> Prefixes are a hack.  Warts like this should only be supported for a
> short term.  Let's cut our losses and move on.

OK. But it was worth noting the heritage here.

> 
> >
> >>Handling of the '+' inclusion directive should also be implemented.
> >>
> >
> >
> > Part and parcel of the master map parsing.
>

And a hack in itself!
 
> This is not master map specific.  It applies to all flat files.  But you
> knew that right ;)
>

The recursive definition here makes this implementation 
annoyingly difficult.

Ian

Re: automount and nsswitch.conf

[Jeff Moyer]

==> Regarding Re: automount and nsswitch.conf; raven@themaw.net adds:

raven> On Tue, 13 Jul 2004, Jeff Moyer wrote:
>> [snip]
>> 
Michael.Waychison> I'm just really against putting this in libc ;).  With a
Michael.Waychison> single consumer and no defined interface to 'copy',
Michael.Waychison> what's the point?
>> >> What's the point?  The point is to leverage existing code.  As it >>
>> stands, my feeling on the matter is that an entry should never have been
>> >> added to nsswitch.conf.  It should have been in an automounter >>
>> configuration file, since the semantics are worse than completely >>
>> different, they're slightly different!
>> 
Michael.Waychison> I pondered this over coffee this morning, and thought to
Michael.Waychison> myself:
>>
Michael.Waychison> "If we added this functionality to nss/, then we'd be
Michael.Waychison> abstracting out the nsswitch.conf parser.  This is a
Michael.Waychison> benefit because we don't have to worry about the
Michael.Waychison> status->action semantics and would allow us to change
Michael.Waychison> the nsswitch.conf interface"
>> I don't entirely understand your pre-coffee nss pontification.  Might I
>> suggest a few more sips?  ;)
>> 
>> If we add support to nss, then we define the interface and the semantics
>> of that interface.  We could have one function return the result of a
>> map lookup, and another a key lookup.  They key lookup would take two
>> arguments, one being the source, the other being the key.  For ghosting,
>> you'd need an iterative function to enumerate the keys.  Hmm, what would
>> the functions be?
>> 
>> struct automapent *getautomapent(const char *mapname); /* provide null
>> key for iteration */ struct automntent *getautomntent(struct automapent
>> *, const char *key); void endautomntent(struct automapent *);
>> 
>> Now, before I go any further, Ian K's point stands.  Putting the parser
>> logic entirely in libc would require a significant structural change to
>> the code base.  I'm not an advocate of that, certainly not before we get
>> things a bit more stable.

raven> I think there is a long way to go to merge this function into
raven> libc/nss.

raven> We need to merge this into autofs now.

Sure.  I'm not keen on requiring a new libc to upgrade autofs, and I
believe this is the sentiment I conveyed.

>> SUMMARY
>> 
>> The current Linux automounter does not properly handle nsswitch.conf.
>> It is desirable to leverage the nss library within libc to implement
>> this functionality, though it is infeasible to do so in the near future.
>> Thus, we need to implement our own nsswitch.conf parser within the
>> automount code.  I believe future implementations should move toward the
>> libc approach.

raven> To early to really discuss whether it would actually be benifical to
raven> leverage the libc code. Developing with a eye to this end should
raven> show us what oppertunities or shortcommings exist with this
raven> approach.

I'm not so sure.  Writing parsers is prone to errors.  The parser within
glibc gets quite a bit of testing.  Now, re-writing all of the parse/lookup
modules using internal libc functions, that sounds like a pain.

>> In either approach, we need to move parsing logic out of the init
>> script.  We can do this by making the new parsing code into a sort of
>> library which can be accessed by a helper program that the init script
>> can run.  It is insane to try to write this code in two languages,
>> especially when one of them is shell.

raven> My thoughts were a seperate module but maybe not a seperate
raven> utility. I haven't done any experimentation with this specifically
raven> yet.

Not a separate utility.  My point was that the code should be modular
enough that it can be linked into a utility used by the init script.  That
doesn't mean it should be a shared object or anything, just a separate .o
that a simple main.c can link in.

raven> One thing to keep in mind is that we already have a fair bit of
raven> useful code in the lookup modules to talk to different map
raven> sources. Perhaps the lookup module interface should be extended to
raven> read master maps a well as entries. This is consistent with the
raven> current design. Comments?

Well, we sort of do this already for fstype=autofs, right?  I'd have to
think more about specifics for auto.master, but I imagine that wouldn't
come into play until we have a single automounter binary for all mount
points.[1]


-Jeff


[1]  BTW, for a separate discussion, I'm not convinced you need to go
to a threaded design.  There's no reason a single process can't manage
multiple mount points.

Re: automount and nsswitch.conf

[raven]

On Wed, 14 Jul 2004, Jeff Moyer wrote:

> ==> Regarding Re: automount and nsswitch.conf; raven@themaw.net adds:
> 
> raven> On Tue, 13 Jul 2004, Jeff Moyer wrote:
> >> [snip]
> >> 
> Michael.Waychison> I'm just really against putting this in libc ;).  With a
> Michael.Waychison> single consumer and no defined interface to 'copy',
> Michael.Waychison> what's the point?
> >> >> What's the point?  The point is to leverage existing code.  As it >>
> >> stands, my feeling on the matter is that an entry should never have been
> >> >> added to nsswitch.conf.  It should have been in an automounter >>
> >> configuration file, since the semantics are worse than completely >>
> >> different, they're slightly different!
> >> 
> Michael.Waychison> I pondered this over coffee this morning, and thought to
> Michael.Waychison> myself:
> >>
> Michael.Waychison> "If we added this functionality to nss/, then we'd be
> Michael.Waychison> abstracting out the nsswitch.conf parser.  This is a
> Michael.Waychison> benefit because we don't have to worry about the
> Michael.Waychison> status->action semantics and would allow us to change
> Michael.Waychison> the nsswitch.conf interface"
> >> I don't entirely understand your pre-coffee nss pontification.  Might I
> >> suggest a few more sips?  ;)
> >> 
> >> If we add support to nss, then we define the interface and the semantics
> >> of that interface.  We could have one function return the result of a
> >> map lookup, and another a key lookup.  They key lookup would take two
> >> arguments, one being the source, the other being the key.  For ghosting,
> >> you'd need an iterative function to enumerate the keys.  Hmm, what would
> >> the functions be?
> >> 
> >> struct automapent *getautomapent(const char *mapname); /* provide null
> >> key for iteration */ struct automntent *getautomntent(struct automapent
> >> *, const char *key); void endautomntent(struct automapent *);
> >> 
> >> Now, before I go any further, Ian K's point stands.  Putting the parser
> >> logic entirely in libc would require a significant structural change to
> >> the code base.  I'm not an advocate of that, certainly not before we get
> >> things a bit more stable.
> 
> raven> I think there is a long way to go to merge this function into
> raven> libc/nss.
> 
> raven> We need to merge this into autofs now.
> 
> Sure.  I'm not keen on requiring a new libc to upgrade autofs, and I
> believe this is the sentiment I conveyed.
> 
> >> SUMMARY
> >> 
> >> The current Linux automounter does not properly handle nsswitch.conf.
> >> It is desirable to leverage the nss library within libc to implement
> >> this functionality, though it is infeasible to do so in the near future.
> >> Thus, we need to implement our own nsswitch.conf parser within the
> >> automount code.  I believe future implementations should move toward the
> >> libc approach.
> 
> raven> To early to really discuss whether it would actually be benifical to
> raven> leverage the libc code. Developing with a eye to this end should
> raven> show us what oppertunities or shortcommings exist with this
> raven> approach.
> 
> I'm not so sure.  Writing parsers is prone to errors.  The parser within
> glibc gets quite a bit of testing.  Now, re-writing all of the parse/lookup
> modules using internal libc functions, that sounds like a pain.
> 
> >> In either approach, we need to move parsing logic out of the init
> >> script.  We can do this by making the new parsing code into a sort of
> >> library which can be accessed by a helper program that the init script
> >> can run.  It is insane to try to write this code in two languages,
> >> especially when one of them is shell.
> 
> raven> My thoughts were a seperate module but maybe not a seperate
> raven> utility. I haven't done any experimentation with this specifically
> raven> yet.
> 
> Not a separate utility.  My point was that the code should be modular
> enough that it can be linked into a utility used by the init script.  That
> doesn't mean it should be a shared object or anything, just a separate .o
> that a simple main.c can link in.

My bad description. Seems we are saying the same thing.

> 
> raven> One thing to keep in mind is that we already have a fair bit of
> raven> useful code in the lookup modules to talk to different map
> raven> sources. Perhaps the lookup module interface should be extended to
> raven> read master maps a well as entries. This is consistent with the
> raven> current design. Comments?
> 
> Well, we sort of do this already for fstype=autofs, right?  I'd have to
> think more about specifics for auto.master, but I imagine that wouldn't
> come into play until we have a single automounter binary for all mount
> points.[1]

Not sure I understand.

This is essentially just another fs type.

> 
> 
> -Jeff
> 
> 
> [1]  BTW, for a separate discussion, I'm not convinced you need to go
> to a threaded design.  There's no reason a single process can't manage
> multiple mount points.

Yes. I've thought about it some but have no definite preference either 
way. One process to manage all would achieve the same goal.

My plan for the direct mount rework will use one process for the entire 
map. I think the best way to do it is similar to the method Mike will be 
using but with the existing infrastructure. If all goes as expected it 
should be a natural progression to indirect mounts. If the master map 
processing can be included as well that would be great.

Ian