All of lore.kernel.org
 help / color / mirror / Atom feed
* autofs & system libnss* libraries
@ 2008-09-24  9:57 Ondrej Valousek
  2008-09-24 12:16 ` Ian Kent
  0 siblings, 1 reply; 6+ messages in thread
From: Ondrej Valousek @ 2008-09-24  9:57 UTC (permalink / raw)
  To: autofs

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: autofs & system libnss* libraries
  2008-09-24  9:57 autofs & system libnss* libraries Ondrej Valousek
@ 2008-09-24 12:16 ` Ian Kent
  2008-09-24 12:47   ` Ondrej Valousek
  0 siblings, 1 reply; 6+ messages in thread
From: Ian Kent @ 2008-09-24 12:16 UTC (permalink / raw)
  To: Ondrej Valousek; +Cc: autofs

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: autofs & system libnss* libraries
  2008-09-24 12:16 ` Ian Kent
@ 2008-09-24 12:47   ` Ondrej Valousek
  2008-09-24 13:31     ` Jeff Moyer
  2008-09-24 13:33     ` Ian Kent
  0 siblings, 2 replies; 6+ messages in thread
From: Ondrej Valousek @ 2008-09-24 12:47 UTC (permalink / raw)
  Cc: autofs

>
> 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: autofs & system libnss* libraries
  2008-09-24 12:47   ` Ondrej Valousek
@ 2008-09-24 13:31     ` Jeff Moyer
  2008-09-24 14:00       ` Ondrej Valousek
  2008-09-24 13:33     ` Ian Kent
  1 sibling, 1 reply; 6+ messages in thread
From: Jeff Moyer @ 2008-09-24 13:31 UTC (permalink / raw)
  To: Ondrej Valousek; +Cc: autofs

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: autofs & system libnss* libraries
  2008-09-24 12:47   ` Ondrej Valousek
  2008-09-24 13:31     ` Jeff Moyer
@ 2008-09-24 13:33     ` Ian Kent
  1 sibling, 0 replies; 6+ messages in thread
From: Ian Kent @ 2008-09-24 13:33 UTC (permalink / raw)
  To: Ondrej Valousek; +Cc: autofs

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: autofs & system libnss* libraries
  2008-09-24 13:31     ` Jeff Moyer
@ 2008-09-24 14:00       ` Ondrej Valousek
  0 siblings, 0 replies; 6+ messages in thread
From: Ondrej Valousek @ 2008-09-24 14:00 UTC (permalink / raw)
  Cc: autofs


> 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
>   

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-09-24 14:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-24  9:57 autofs & system libnss* libraries Ondrej Valousek
2008-09-24 12:16 ` Ian Kent
2008-09-24 12:47   ` Ondrej Valousek
2008-09-24 13:31     ` Jeff Moyer
2008-09-24 14:00       ` Ondrej Valousek
2008-09-24 13:33     ` Ian Kent

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.