autofs & system libnss* libraries

autofs & system libnss* libraries

[Ondrej Valousek]

Hi List,

I have a question - is there any plan for autofs to use the system
libnss* libraries instead of implementing their own?
For example: If I wanted to use LDAP server to hold user accounts &
autofs maps, I would have 2 config files to configure:
- /etc/ldap.conf for libnss_ldap library
- /etc/autofs_ldap_auth.conf for automounter
It is quite confusing and it will be much more elegant to have just a
single configuration file for both services.
Is there any plan to do this in the future?

Many thanks,
Ondrej

Re: autofs & system libnss* libraries

[Ian Kent]

On Wed, 2008-09-24 at 11:57 +0200, Ondrej Valousek wrote:
> Hi List,
> 
> I have a question - is there any plan for autofs to use the system
> libnss* libraries instead of implementing their own?

No!

> For example: If I wanted to use LDAP server to hold user accounts &
> autofs maps, I would have 2 config files to configure:
> - /etc/ldap.conf for libnss_ldap library
> - /etc/autofs_ldap_auth.conf for automounter
> It is quite confusing and it will be much more elegant to have just a
> single configuration file for both services.
> Is there any plan to do this in the future?

No!

I considered that at the outset of version 5 development and decided
against it after working on integrating the outdated code that was
included in the nss_ldap distribution. Unless the situation changes
significantly then I'm not likely to change my mind on this.

I would have to write the nss code for "all" the possible sources
against a an API that is difficult to write for, partly because the
interface documentation is lousy. Not to mention that I'd then be at the
mercy of nss_ldap changes and bugs, and autofs would depend on a
configuration file that it doesn't control.
 
Ian

Re: autofs & system libnss* libraries

[Ondrej Valousek]

>
> No!
>
> I considered that at the outset of version 5 development and decided
> against it after working on integrating the outdated code that was
> included in the nss_ldap distribution. Unless the situation changes
> significantly then I'm not likely to change my mind on this.
>   
Does it mean that the nss_ldap is heavily outdated then?
> I would have to write the nss code for "all" the possible sources
> against a an API that is difficult to write for, partly because the
> interface documentation is lousy. Not to mention that I'd then be at the
> mercy of nss_ldap changes and bugs, and autofs would depend on a
> configuration file that it doesn't control.
>   
My primary concern was why should we (linux distro maintainers) support
2 things essentially doing the same?
I did not mean you specifically. Maintaining the libnss* libraries
should be (probably) job for someone else - you keep focused on the
autofs-specific tasks.
And if you think your nss_ldap is better, why should not it serve other
purposes (like gathering user info from LDAP repository), too?

I mean, from the longer perspective, I believe we should merge these
things. It is neither elegant nor transparent for normal sysadmins.
>  
> Ian
>
>
>   
Ondrej

Re: autofs & system libnss* libraries

[Jeff Moyer]

Ondrej Valousek <webserv@s3group.cz> writes:

>>
>> No!
>>
>> I considered that at the outset of version 5 development and decided
>> against it after working on integrating the outdated code that was
>> included in the nss_ldap distribution. Unless the situation changes
>> significantly then I'm not likely to change my mind on this.
>>   
> Does it mean that the nss_ldap is heavily outdated then?
>> I would have to write the nss code for "all" the possible sources
>> against a an API that is difficult to write for, partly because the
>> interface documentation is lousy. Not to mention that I'd then be at the
>> mercy of nss_ldap changes and bugs, and autofs would depend on a
>> configuration file that it doesn't control.
>>   
> My primary concern was why should we (linux distro maintainers) support
> 2 things essentially doing the same?
> I did not mean you specifically. Maintaining the libnss* libraries
> should be (probably) job for someone else - you keep focused on the
> autofs-specific tasks.
> And if you think your nss_ldap is better, why should not it serve other
> purposes (like gathering user info from LDAP repository), too?
>
> I mean, from the longer perspective, I believe we should merge these
> things. It is neither elegant nor transparent for normal sysadmins.

You have to understand that nss doesn't actually support the interfaces
autofs needs.  We would have to extend the API and get that approved by
the libc folks (which they have actually agreed to do, should we choose
that route).

Now, the reason autofs doesn't use the SASL and TLS configuration
options from the ldap.conf file is simply that autofs has no business
parsing that file.  Autofs *does* use the ldap library, so whatever
you've configured in /etc/openldap/ldap.conf should work for autofs.

I hope this helps.

Cheers,

Jeff

Re: autofs & system libnss* libraries

[Ondrej Valousek]

> You have to understand that nss doesn't actually support the interfaces
> autofs needs.  We would have to extend the API and get that approved by
> the libc folks (which they have actually agreed to do, should we choose
> that route).
>   
Yes, I have heard the libc API needs some extension....
> Now, the reason autofs doesn't use the SASL and TLS configuration
> options from the ldap.conf file is simply that autofs has no business
> parsing that file.  Autofs *does* use the ldap library, so whatever
> you've configured in /etc/openldap/ldap.conf should work for autofs.
>
>   
Ok, let me explain in detail what I was after, actually:

In my company, we use Centrify (www.centrify.com) DirectControl to
integrate Linux RHEL boxes into Win 2003 Active Directory.
Now, in Centrify they did quite an amount of work to make everything
working nicely:
1) they provide the system with their own set of libnss_centrifydc
libraries so you can use them in nsswitch.conf like this:

passwd   centrifydc files
group   centrifydc files

2) The libnss_centrifydc library does all the heck with communicating
with AD. AD is nothing strange, having it extended with RFC 2307
attributes, it behaves like a normal LDAP server. What the
libnss_centrifydc does for you is SASL encrypted channel with the
Windows domain controller - something PAINFUL (if possible) to do with a
plain libss_ldap.
3) The libnss_centrifydc will also provide you with a Kerberos principal
so that SASL is possible for other apps
...
4) That means that I can gather all necessary info securely from AD. But
the automounter. How perfect would it be if I could just add:

automount     centrifydc files

in my nsswitch.conf to add support for automounter, too! I know, both
libc and centrify folks would have to be informed and API changed to
support autofs in general, but the benefit would be massive for me - I
could solely rely on centrifydc_nss and encrypted SASL channel for
everything.

Now, I have to feed automounter via NIS which is something I would like
to get rid of, if possible.

I understand I do not care as much about Centrify, but hopefully it will
give you some explanation why I (and other system integrators too) would
welcome the libc & autofs merge.

Ondrej


> I hope this helps.
>
> Cheers,
>
> Jeff
>   

Re: autofs & system libnss* libraries

[Ian Kent]

On Wed, 2008-09-24 at 14:47 +0200, Ondrej Valousek wrote:
> >
> > No!
> >
> > I considered that at the outset of version 5 development and decided
> > against it after working on integrating the outdated code that was
> > included in the nss_ldap distribution. Unless the situation changes
> > significantly then I'm not likely to change my mind on this.
> >   
> Does it mean that the nss_ldap is heavily outdated then?

No, just the autofs stuff they had was quite a bit out of date and I had
to resolve this for "all" autofs map sources not just LDAP. So I took
the easy road.

> > I would have to write the nss code for "all" the possible sources
> > against a an API that is difficult to write for, partly because the
> > interface documentation is lousy. Not to mention that I'd then be at the
> > mercy of nss_ldap changes and bugs, and autofs would depend on a
> > configuration file that it doesn't control.
> >   
> My primary concern was why should we (linux distro maintainers) support
> 2 things essentially doing the same?

Not really such an issue for autofs.

We're only concerned with the "automount:" line in /etc/nsswitch.conf
and map source has always been a large part of autofs map management
anyway. The only bit that isn't something we have to do anyway is to
parse /etc/nsswitch.conf which is a relatively small amount of code.

> I did not mean you specifically. Maintaining the libnss* libraries
> should be (probably) job for someone else - you keep focused on the
> autofs-specific tasks.

Again, a bit of a concern relying on others for a fairly small bit of
functionality. Do you have someone in mind?

> And if you think your nss_ldap is better, why should not it serve other
> purposes (like gathering user info from LDAP repository), too?

That's not really applicable, as I say above, I don't do "nss_ldap" I
just parse /etc/nsswitch.conf, the bulk of the functionality has to be
in autofs anyway, which would essentially be the callback functions if
the glibc nss API was used.

> 
> I mean, from the longer perspective, I believe we should merge these
> things. It is neither elegant nor transparent for normal sysadmins.

Neither is a response like "I don't support that go ... for that" or the
converse "we don't support that go talk to the autofs folks for that".

I just can't see the benefit you see in this, sorry.

Perhaps if there was someone actually interested in working through this
there could be meaningful discussions. I suspect the glibc folks would
be happy to hand of (read "get rid of") the nss code to someone else.

Ian