On 03.06.2012 15:15, Andreas B. Mundt wrote: [] >>> "automount: files ldap" >> >> 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... > > Apart from leaving cruft back, I guess it should not hurt. > >> I mean, is it a bug to leave "ldap" in there on autofs-ldap removal? > > Not sure if "leaving cruft behind" is a bug in this case.
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... :) [] > 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>) 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
