libnss-ldap should not depend on libpam-ldap

Bug #334374 reported by Michael Kofler
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ldap-auth-client (Ubuntu)
New
Undecided
Unassigned
libnss-ldap (Kairos Linux)
Confirmed
Medium
Kairos Maintainers "techref" group
libnss-ldap (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: libnss-ldap

I use LDAP to manage users and groups and Kerberos for authentification

thus, I need libnss-ldap and libpam-krb5, but NOT libpam-ldap

also note https://bugs.launchpad.net/bugs/306054 (which has auth-client-config as starting poing)

Revision history for this message
Andreas Olsson (andol) wrote :

Strictly speaking libpam-ldap isn't a dependency to libnss-ldap. Instead it listed as a Recommended.

From Intrepid and forward Ubuntu automatically installs Recommended packages. Still, there is a difference compared to if it had been a pure dependency. This way you can still remove libpam-ldap (afterwards) without libnss-ldap being removed too.

Do you still consider this a bug?

Changed in libnss-ldap:
status: New → Incomplete
Revision history for this message
Michael Kofler (michael-kofler) wrote :

> This way you can still remove libpam-ldap (afterwards)
> without libnss-ldap being removed too.

no (try it)

the problem is ldap-auth-client

libnss-ldap depends on ldap-auth-config
ldap-auth-config depends on ldap-auth-client
ldap-auth-client depends on both libnss-ldap and libpam-ldap

> Do you still consider this a bug?

perhaps it's not strictly a bug, but with the pam auto configuration introduced in 8.10 it leads to unneccessary confusion; you have to call pam-auth-update to explicitly deactivate libpam-ldap

Revision history for this message
Andreas Olsson (andol) wrote :

You are right; libpam-ldap really ends up being hard dependency to libnss-ldap.

I see the problem and agree that this isn't necessary an optimal solution. I'll mark this bug as confirmed, and we'll see what happens.

Changed in libnss-ldap:
status: Incomplete → Confirmed
Changed in libnss-ldap:
assignee: nobody → kairos-techref
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Andreas Olsson (andol) wrote :

Ok, revisiting this bug I got an idea, which might just be a good idea...

ldap-auth-config not always being a must to use libnss-ldap, perhaps it should be a Recommends instead of a Depends? Given that Recommends is now being installed by the default it will still give the normal user the same automatic behavior, while at the same making it possible to explicitly avoid ldap-auth-config if that is what you want.

@Michael: What is your take on such a solution?

Revision history for this message
Michael Kofler (michael-kofler) wrote :

fine for me, definitely an improvement

Revision history for this message
Andreas Olsson (andol) wrote :

Well, still think this is a good idea. Attaching a debdiff which removes ldap-auth-config as a (hard) dependency.

Not re-adding as a Recommends, as that part is indirectly covered by the Recommends on libpam-ldap.

Revision history for this message
Daniel Richard G. (skunk) wrote :

This bug report needs a visual aid.

Revision history for this message
Thierry Carrez (ttx) wrote :

Andreas: I would still explicitely recommend ldap-auth-config from libnss-ldap. Even if it is redundant from an "resulting installed packages" perspective, it is still very much recommended to have it installed if you use libnss-ldap. Not only if you use libpam-ldap.

Revision history for this message
Andreas Olsson (andol) wrote :

@Thierry: Attaching new debdiff.

@Daniel: Awesome visual aid!

Revision history for this message
Thierry Carrez (ttx) wrote :

Still unsure it's the best way to fix it. I agree one of those Depends must be turned into a Recommends, I'm just unsure this one is the best :)

How about making the ldap-auth-config -> ldap-auth-client link a Recommend ?

@Daniel: thanks ! That makes explaining the issue so much easier.

Revision history for this message
Thierry Carrez (ttx) wrote :

This still needs to be discussed to find the optimal fix, and it probably won't make it into karmic at this point (as it changes the behavior at a late stage).
Unsubscribing sponsors for now.

Changed in libnss-ldap (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Revision history for this message
Daniel Richard G. (skunk) wrote :

I think Thierry's solution in comment #10 is the way to go. It's appropriate for ldap-auth-client to depend on libpam-ldap, because that's the intent of the metapackage. But ldap-auth-config provides /etc/ldap.conf, which you need whether or not you're using LDAP for authentication. (That package would be better named "ldap-config".)

I see that libnss-ldap now recommends ldap-auth-config instead of hard-depending on it. But this is not useful, because without /etc/ldap.conf, you have no working LDAP setup. (Robie Basak made this change recently; I've subscribed him to this bug.) I think that this particular hard dependency was correct, in fact---unless you manually create a new /etc/ldap.conf from scratch, I see no reason why you would want to install libnss-ldap without ldap-auth-config (dependencies of the latter aside).

[tl;dr] IMO, the solution is
* ldap-auth-config Recommends ldap-auth-client
* libnss-ldap Depends-on ldap-auth-config

Revision history for this message
Robie Basak (racb) wrote :

ldap-auth-config does not exist in Debian. It is expected that those who want ldap authentication can write /etc/ldap.conf themselves.

In Ubuntu, I think it makes sense to permit this, so it should be possible to install libnss-ldap and libpam-ldap without ldap-auth-config installed. An example use case is an environment where the sysadmins use puppet to centrally manage /etc/ldap.conf.

Therefore, I don't think that there should be any hard dependency to ldap-auth-config at all. If in Ubuntu you decide to ignore recommendations, I think it's reasonable to expect that you have to configure bits of your system manually, such as by writing /etc/ldap.conf yourself.

If you do want to introduce a hard dependency to ldap-auth-config, keep in mind the use case I fixed in bug 1016592 - please don't regress this.

In a test just now, I successfully installed libnss-ldap in Raring without being forced to install libpam-ldap (though it was recommended). Thus I think the bug originally as reported has been fixed, so I'm marking this bug as Fix Released.

I appreciate that the dependency tree is complicated and it may not be ideal or fit all use cases. I suggest that you use the ubuntu-devel or ubuntu-devel-discuss lists if you want to discuss it further. Perhaps you could start there by presenting the specific use case that is causing you trouble?

A final note: I'm not sure why Ubuntu has such a complex delta against Debian here. It seems to mainly be driven by the existence of ldap-auth-config. What are the implications of either getting this package upstreamed to Debian or dropping it in Ubuntu?

Changed in libnss-ldap (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Daniel Richard G. (skunk) wrote :

Robie, thanks for commenting.

Note that the ldap-auth-config package does not preclude alternate forms of managing /etc/ldap.conf. It won't touch an existing config file, nor complain if the one it creates is modified. Also, while this package does not exist in Debian, the file is still created when libnss-ldap or libpam-ldap is installed---there is no expectation that the user will create this file (let alone *know* to create this particular file) from scratch.

The reason why I think a hard dependency is warranted is that if you install libnss-ldap without libpam-ldap, not only are you left with no config file for the former (i.e. /etc/ldap.conf), you could easily be misled into thinking that /etc/ldap/ldap.conf (from the libldap package) is relevant---especially as "man ldap.conf" refers to the latter. This is the scenario I encountered, and IMO it made clear why weakening the dependency on ldap-auth-config was the wrong way to go.

(Bug 1016592, and this one, would still be addressed by weakening the ldap-auth-config -> ldap-auth-client dependency instead.)

As far as Debian is concerned, I would strongly advocate for having ldap-auth-config (and perhaps ldap-auth-client and friends) paralleled there. Right now, you have duplicate logic in the libnss-ldap and libpam-ldap package postinst scripts; Ubuntu's approach essentially factors that out into a separate package. The only change I would make is downgrade the ldap-auth-config -> ldap-auth-client dependency to a Suggests (or nothing), to eliminate the cycle in the dependency graph.

Revision history for this message
Robie Basak (racb) wrote :

@Daniel

Makes sense to me. Since NSS isn't strictly auth, would it also make sense to rename ldap-auth-config to ldap-config?

This area is complex, especially with the delta with Debian in mind. I'm not even considering touching this because I'm worried I'll break something, and it seems like it would take significant effort to verify that all use cases will be fulfilled with any change at all.

I think this needs a stakeholder to drive it, particularly with speaking to Debian, coordinating, etc. Since it may have wider implications, I think it makes sense to seek consensus on the Ubuntu mailing lists, too.

Volunteers welcome :)

Revision history for this message
Daniel Richard G. (skunk) wrote :

Hi everyone. I've been setting up LDAP in Ubuntu lately, and have run headlong into this issue again.

Arguably, the situation has gotten worse in the past three years, as the dependency rat's nest has become more convoluted.

I've put together a new visual aid to illustrate the current situation; it is attached. Here's how to interpret it:

* As before, solid-line arrows represent Depends: or Pre-Depends:
* Dashed-line arrows represent Recommends:
* I've represented alternatives ("either X or Y") with diamond-shaped nodes

(Note that the alternatives in this graph are due to Provides: fields in lib{nss,pam}-ldapd, not the usual "|" syntax in Depends:)

Here's what I would like to see changed:

1. Rename the "ldap-auth-config" package to "ldap-config" (just as you suggested in 2013, Robie; that's my exact reasoning as well)

2. Weaken the dependency on auth-client-config. This utility is (1) confusing and poorly documented; (2) not necessary when nslcd is installed, because that package has its own logic to modify /etc/nsswitch.conf, and (3) dependent on Python, which means that if you setup LDAP on a minimal install, you're pulling in all of Python just to run a script that you likely don't even need.

3. Remove (or at least weaken) the dependency on ldap-auth-client. This is a metapackage for LDAP authentication. Not only is it inappropriate for ldap[-auth]-config to depend on this, given that an LDAP config does not necessarily exist for authentication purposes, a task-specific metapackage like this should be at the top of the dependency graph because it is meant to be directly/explicitly installed by a user.

4. Add a dependency (probably Recommends:) from libpam-ldapd and libnss-ldapd to ldap[-auth]-config, just as libnss-ldap already has. These components require an LDAP config to function, so that is reasonable to express in this way.

5. Weaken the dependency from libpam-ldap to ldap[-auth]-config, to be consistent with the same dependency from libnss-ldap.

6. Kill the Recommends: from libnss-ldap to libpam-ldap. There's absolutely no reason for that to be there; using LDAP for NSS in no way implies using it for authentication.

7. Weaken the dependencies on nslcd, because that daemon is not strictly required for lib{nss,pam}-ldapd to function (although it certainly helps). Better yet, replace these with a Recommends: from ldap[-auth]-config, because nslcd can benefit anything that uses /etc/ldap.conf for NSS purposes (primarily all of lib{nss,pam}-ldap{,d}) and one dependency is better than multiple.

Comments, thoughts?

Revision history for this message
Daniel Richard G. (skunk) wrote :

Also, for those interested, here is the GraphViz source for the "visual aid." The graphic can be regenerated with the command

    $ dot -Tpng ldap-deps.dot >ldap-deps.png

(The dot(1) command is in the "graphviz" package.)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.