Hi,

the libnss-ldapd package is a nice way to switch on LDAP as data
source for various services.  Unfortunatelly, it is not possible to
add automounter (autofs-ldap) and sudoers (sudo-ldap) to the list in
/etc/nsswitch.conf, like:

[...]
automount:    files ldap
sudoers:      files ldap
[...]

Thanks and best regards,

       Andi

The problem with those are that these services are not provided by the
NSS layer in the C library (even though some applications
abuse /etc/nsswitch.conf for this).

Both autofs-ldap and sudo-ldap are not very generic applications. It
seems that autofs uses a plugin-like setup so it should be possible to
either provide an autofs-ldapd or similar mechanism for it. I've had a
look at sudo-ldap once but it seems to be very hard to make something
independant (sudo-ldap is more a patched sudo).

Having said that, I don't think it is terribly difficult to implement
the needed features in nslcd. I would welcome patches for something like
this.

Thanks for your bugreport.

user debian-edu@lists.debian.org
tags 638007 + patch
usertag 638007 + debian-edu
thanks

Hi Arthur,

I prepared a simple patch now, to include automount and sudoers to the
list of services to be configured.  I'm not sure if we should make a
note in the template (debian/libnss-ldapd.templates) about the
'specialness' of these two services, something like:

"Note that automount and sudoers are not provided by the NSS layer in
the C library, but the corresponding applications parse
/etc/nsswitch.conf to determine their data source."

But that is probably just confusing to the user.  I also don't know if
the 'abuse' may cause problems.

Best regards,

     Andi

I have a bit of a problem with this patch because it doesn't actually do
anything related to libnss-ldapd. I would be better if the autofs-ldap
and sudo-ldap packages prompted for modification of /etc/nsswitch.conf.

I don't think it is a good idea to configure autofs-ldap and sudo-ldap
from the libnss-ldapd package as they are not related. There is no
dependency relationship between them and there are valid use cases to
use either one without the other (or use nss_ldap instead of
nss-pam-ldapd).

It would be nice if there would be some common infrastructure to
edit /etc/nsswitch.conf, similarly to what we have now for PAM. There
used to be a summer of code project for this but it didn't get very far
into actually being implemented:

http://www.milliways.fr/2009/01/28/debian-2008-where-now-2/
http://gnucrash.wordpress.com/category/google-summer-of-code/
http://bugs.debian.org/496915

So I'm considering tagging this wontfix I'm afraid. I'll try to give it
some more thought though.

clone 638007 -1 -2
reassign -1 autofs5-ldap
retitle -1 autofs5-ldap: please add "automount:  files  ldap" to /etc/nsswitch.conf
reassign -2 sudo-ldap
retitle -2 sudo-ldap: please add "sudoers:  files  ldap" to /etc/nsswitch.conf
merge -2 610600

thanks


Hi,

I agree with that. The best is probably to add the line(s) when
sudo-ldap and/or autofs5-ldap is installed.  Respectively:

sudoers:    files  ldap
automount:  files  ldap

The *-ldap packages make only sense with LDAP as datasource in
/etc/nsswitch.conf, so the line should be there in any case, and gone
if the corresponding package is removed.  Modifying nsswitch.conf
shouldn't be a problem, quoting from
<URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610600#34>:

"Usually, policy forbids that a package modifies the "configuration
file" of another package, but in this case /etc/nsswitch.conf is not a
conffile in dpkg sense but just a default. This is on purpose so that packages
that need to modify such file do so without having to ask me about that.

Therefore, I think we should just modify sudo-ldap so that the required
line is added to /etc/nsswitch.conf on postinst and removed on purge,
as only users of sudo-ldap need such line, i.e. please do not rely
on base-files and just do with nsswitch.conf whatever is required for
it to work with your package."

The same applies for autofs5-ldap.  I clone/merge the bugreport, feel
free to reasign it completely, but perhaps it's good to leave it here
for the record.

Thanks,

	Andi

tags 639529 + patch
thanks


Hi,

find attached simple patches for autofs5-ldap.postinst and
autofs5-ldap.postrm that add respectively remove the line "automount:
files ldap" from /etc/nsswitch.conf.

Best regards,

     Andi

Hi,

first, thank you all for the work on a refurbished autofs package!  I
would like to draw your attention to #639529, as it would be great to
fix this before the wheezy freeze and it's just a minor modification.

Let me sum up, as the lengthy history of the issue might be confusing:

The name service switch functionality allows to assign different
resources for various informations like passwords, groups etc.
The resource to use is defined in "/etc/nsswitch.conf".  Everybody
using the autfs-ldap package needs to add:

      "automount:      files ldap"

to "/etc/nsswitch.conf".  This activates the look up of mount points
in LDAP.  For example, this has to be done in debian-edu and
debian-lan.

The patches already attached above make sure the line needed is added
on installation and removed after purging the autofs-ldap package.
Modifying "/etc/nsswitch.conf" is fine, cf. [1].  A similar patch has
been applied to sudo-ldap, cf. #639530.

Thanks,

	Andi



[1] Modifying nsswitch.conf shouldn't be a problem, quoting from
    <URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610600#34>:

    "Usually, policy forbids that a package modifies the "configuration
    file" of another package, but in this case /etc/nsswitch.conf is not a
    conffile in dpkg sense but just a default. This is on purpose so that
    packages that need to modify such file do so without having to ask me
    about that.

    Therefore, I think we should just modify sudo-ldap so that the
    required line is added to /etc/nsswitch.conf on postinst and removed
    on purge, as only users of sudo-ldap need such line, i.e. please do
    not rely on base-files and just do with nsswitch.conf whatever is
    required for it to work with your package."

----------------------------------

A N D R E A S   B.   M U N D T

GPG key: 4096R/617B586D 2010-03-22 Andreas B. Mundt--<andreas.b.mundt@web.de>
                                   Andreas B. Mundt--<andi.mundt@web.de>

============================================================================

Will it be bad if this line will be left out after removing
autofs-ldap package, ie, when automount nsswitch entry is
listing non-existing lookup method?  I guess I should try...

I mean, is it a bug to leave "ldap" in there on autofs-ldap
removal?

Because I want to minimize messing up with this file as much
as possible.  For example, the user might reorder the entries
after installation, but on removal and reinstall we'll move
"ldap" entry there to the end, which might be considered a
bug too...

Thanks,

/mjt

Hi Michael,

Apart from leaving cruft back, I guess it should not hurt.

Not sure if "leaving cruft behind" is a bug in this case.
If it's missing, it'll be added at the end.

From what I learned in the discussions about "/etc/nsswitch.conf",
I suspect the order of entries does not matter.
(<URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639530#10>)

Best regards,

     Andi

On 03.06.2012 15:15, Andreas B. Mundt wrote:
[]

Not really - automount may start complaining or failing.  But
apparently it does not.  I mean the situation when we leave
`automount: files ldap' line in there on removal of autofs-ldap
package, when autofs package itself is still installed and
functioning.

And I really dislike this way of leaving ldap entry in place
in this case, even if automount itself appears to be working
fine - I'd say it works by incident not by design, as it should
complain about such an error.

So, on autofs-ldap removal, we should remove ldap entry from
automount nsswitch.conf line.  And here we've a few other issues
to sort out.  For example, say, we added `files ldap' into it
automaticlaly, and the user later changed that to `ldap': in
this case we can't remove just the ldap entry, since the line
will be wrong in this case.

And we definitely can not remove whole line too, like is done
in sudo-ldap case: we also have hesiod map which should be
handled the same way!

So... I'm not sure what to do really.  Too much smarts often
becomes dumber than doing nothing at all... :)

[]

Well, automount (or any other lookup "consumer" for that matter) should
choose one entry from several available.  For example, you can't
expect getpwnam("root") returning TWO entries, if passwd: entry in
nsswitch lists, eg, `files, ldap' and BOTH has definition for the
root user.  So order definitely does matter.

Thanks,

/mjt

I guess autofs doesn't use "nsswitch.conf" at all, does it?

Right.

No idea about hesiod.  Does it use "nsswitch.conf"?

Yes, again things are more complicated than expected on a first
sight...

Oh sorry, I got you wrong, I meant the ordering of the lines.  Of
course the order of entries in a single line matters, it tries the
first, then the second and so on.

Regards,

	Andi

Apparently it does -- this is the very end of default /etc/auto.master
file:

# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

When I put a map into "automount" line in nsswitch.conf
which does not exist, it logs the following line into
daemon.log:

 automount[1519]: ignored unsupported autofs nsswitch source "xyz"

the same happens with ldap if it is in that line and
there's no /usr/lib/autofs/lookup_ldap.so file found.

But wait.  What else uses nsswitch automount entry
if not automount itself?

All maps also can be used directly as well, by specifying
map-type properly in /etc/auto.master.
automount entry in nsswitch.conf except of autofs package
itself (where it has other mechanism too) ?

I'm about to mark this bug as a wishlist wontfix really... ;)

Thanks,

/mjt

Hi Michael,

OK.

[...]

I do not know of any.

Yes, I agree, maybe it's better to do nothing by default.  Instead of
supporting one setup but spoiling the others.
Thank you very much for taking the time on the issue.

Best regards,

     Andi