nslcd auto-configuration disregards existing nslcd.conf

Bug #1229713 reported by Simon Fraser on 2013-09-24
This bug affects 8 people
Affects Status Importance Assigned to Milestone
nss-pam-ldapd (Ubuntu)
Rafael David Tinoco

Bug Description


 * When nslcd is upgraded, the config and postinst scripts run and
   wrongly update /etc/nslcd.conf with values previously saved in the
   debconf database. This can result in broken nslcd.conf configurations
   after the upgrade (thus causing LDAP authentication, etc. to stop

[Test Case]

 * Install older nslcd, configuring it with a bad uri at the debconf
 * edit the /etc/nslcd.conf directly to produce a working configuration.
 * Try to upgrade to a newer version of the package (but earlier than
   this fix) and then notice that the uri line /etc/nslcd.conf is
   changed back to the saved debconf value, thus leaving a non-working

[Regression Potential]

 * this is a cherry-pick from an upstream bzr fix (rev: #19).
 * it gives preference to values currently found in /etc/nslcd.conf
   over those saved in debconf in the event of an upgrade.
 * tested by 2 different users and they said it works.

[Other Info]

* Original BUG description

We have nslcd already installed, with /etc/nslcd.conf listing our LDAP servers. We also have an Active Directory server installed, which servers the DNS SRV entries to exist in order to function properly. Our Ubuntu servers do not use AD, however, and so when nslcd is upgraded, the config script runs:

server=`host -N 2 -t SRV _ldap._tcp.$domain 2> /dev/null | grep -v NXDOMAIN | awk '{print $NF}' | head -1 | sed 's/\.$//'` || true

... finds Active Directory, and replaces the LDAP servers we have in /etc/nslcd.conf with the name of the first AD server it finds. (I should note there are four listed, and it only adds the first one - this is probably a separate bug)

This is unwelcome behaviour, forcing us to use --force-confold as a workaround.

The guess_ldap_uri() function should only be called if /etc/nslcd.conf is not usable, to prevent it overwriting valid configuration with incorrectly guessed ones.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: nslcd 0.8.4ubuntu0.2
ProcVersionSignature: Ubuntu 3.2.0-53.81-generic-pae 3.2.50
Uname: Linux 3.2.0-53-generic-pae i686
ApportVersion: 2.0.1-0ubuntu17.4
Architecture: i386
Date: Tue Sep 24 14:07:45 2013
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MarkForUpload: True
SourcePackage: nss-pam-ldapd
UpgradeStatus: Upgraded to precise on 2012-04-30 (512 days ago)

Simon Fraser (simonfr) wrote :
Arthur de Jong (adejong) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nss-pam-ldapd (Ubuntu):
status: New → Confirmed
Changed in nss-pam-ldapd (Ubuntu):
assignee: nobody → Rafael David Tinoco (inaddy)

I'm not sure can be considered a "duplicate", but there's a similar package-upgrade bug (or set of bugs) discussed in LP#1350778 .

This behavior was fixed on bzr branch in the following revision:

revno: 19 [merge]
tags: 0.8.8-1
fixes bugs: http://bugs.debian.org/670419 http://bugs.debian.org/669680 http://bugs.debian.org/670133
author: Arthur de Jong <email address hidden>
committer: Package Import Robot <email address hidden>
branch nick: sid
timestamp: Fri 2012-04-27 13:20:00 +0200
  * new upstream release:
    - fix a problem in the handling of PAM requests in nslcd (closes: #670419)
    - install the ldapns.schema in nslcd docs (closes: #669680)
  * use the configuration file contents to determine the authentication
    type, not the debconf database (closes: #670133)
  * switch PAM account type to primary because it now does all the
    authorisation checks that pam_unix also does
  * drop functionality to check whether shadow information is exposed
    in /etc/nsswitch.conf, it was no longer needed sine 0.8.4
  * ensure that /var/run/nslcd is not removed during upgrades

So this fix is already present in Trusty & Utopic.

Since this fix is straight-forward I have cherry-picked:

  * [bzr lp:ubuntu/nss-pam-ldapd revno:19 tag:0.8.8-1]:
    - debian/nslcd.config: properly handle preseeding and reading values
    from the configuration file by forcefully overwriting debconf values
    from nslcd.conf and not overwriting debconf values when reading other
    configuration files. (LP: #1229713)

Changing the following files:

- debian/nslcd.config
- debian/changelog (of course)


I have also created one PPA so this fix can be tested by users:

# add-apt-repository ppa:inaddy/lp1229713
# apt-get update
# apt-get install nss-pam-ldapd

This will install version 0.8.4ubuntu0.4~lp1229713~2 which will be superseded by 0.8.4ubuntu0.4 when and if a SRU is available.

Appreciate if whoever suffers from this issue, and is willing to test, could give me feedback on this. The change only ignores already set debconf values unless "force" parameter (for parsecfg function) is given.

Thank you.

I tried upgrading to nlslcd 0.8.4ubuntu0.3 on a system where the "ldap-uris" debconf entry was out of sync from the "uri" line in nslcd.conf, and confirmed that the .conf file line was overwritten with the debconf value, thus resulting in a non-working configuration. (The "debconf-show nslcd" did not change during that upgrade process.)

I restored the working nslcd.conf and then upgraded to nslcd 0.8.4ubuntu0.4~lp1229713~2 from the PPA, and confirmed that the nslcd.conf file wasn't changed (though the file timestamp shows it was edited, nothing was actually changed)... and also see that the ldap-uris debconf entry was updated to contain the value pulled from the nslcd.conf file.

After the upgrade, LDAP functionality for both NSS and PAM seems to be working fine, so I think the PPA package does fix the upgrade problem, at least for the uri-value-has-changed case. (Note that we don't have AD-server DNS entries at this site, so my test doesn't specifically cover that particular problem.)

On Tue, Sep 24, 2013 at 13:13:32 -0000, Simon Fraser wrote:
> The guess_ldap_uri() function should only be called if /etc/nslcd.conf
> is not usable, to prevent it overwriting valid configuration with
> incorrectly guessed ones.

Looking more closely at the nslcd.config script, I'm pretty sure
that in fact guess_ldap_uri() is only called when the package is
first installed -- specifically, when the debconf "ldap-uris" value
is empty.

However, what happens during that initial run is that the value
returned by guess_ldap_uri() is then stored into debconf... and
from then on the bug discussed in Debian 717063 means that that
debconf value overwrites the nslcd.conf "uri" setting in later
package upgrades.

(Simon, you could confirm that this is your issue by running
"debconf-show nslcd" and seeing if indeed the AD servers were still
listed there in the "ldap-uris" value.)

Anyway, if that is the situation then I think Rafael's new package
will fix your problem, too (since it will make the current
nslcd.conf value overwrite the debconf value rather than the other
way around).


Simon Fraser (simonfr) wrote :

Luckily, while the original machine I used for testing has gone, another one exhibited these symptoms just recently. I can confirm that 'debconf-show nslcd' shows the AD server found in DNS. I agree that Rafael's new package seems like it will fix the issue. Thanks!

Thank you very much for the fast feedback on this. I'm attaching the debdiff to this bug and subscribing SRU team. Let me know if you encounter any problem/regression until it gets into -stable.


description: updated
description: updated

Subscribing sponsors team for this fix to get uploaded. Thank you.

Robie Basak (racb) wrote :

Looks fine on review. Uploaded, thanks. It looks to me that bug 1350778 is a duplicate. I'll comment in that bug.

Changed in nss-pam-ldapd (Ubuntu Precise):
status: New → In Progress
Changed in nss-pam-ldapd (Ubuntu):
status: Confirmed → Fix Released

Hello Simon, or anyone else affected,

Accepted nss-pam-ldapd into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/nss-pam-ldapd/0.8.4ubuntu0.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nss-pam-ldapd (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed

Nathan, Simon,

Could you guys check during the next days if -proposed package fixes the issue for you ?
This way we can change verification tag and make sure it gets released into -updates.

Thank you very much for your support on this.


The fix for this bug has been awaiting testing feedback in the -proposed repository for precise for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

tags: added: removal-candidate
Ryan Tandy (rtandy) wrote :


Just tested:

1. installed nslcd 0.8.4 from precise
2. edited uri in nslcd.conf
3. upgraded to 0.8.4ubuntu0.3 from precise-updates.

uri was replaced with the value from debconf.

1. installed nslcd 0.8.4 from precise
2. edited uri in nslcd.conf
3. upgraded to 0.8.4ubuntu0.4 from precise-proposed.

uri was not changed on upgrade.

Marking verified.

tags: added: verification-done
removed: verification-needed

I was in the middle of testing this, too, when Randy posted his message.

I got the same results he did for the 0.8.4 -> 0.8.4ubuntu0.3 and 0.8.4 -> 0.8.4ubuntu0.4 upgrades, using the "uri" value to test the upgrade behavior.

Also, to follow up on the original report in Bug #1350778, I did an additional test regarding the tls_reqcert value. I changed that setting using "dpkg-reconfigure nslcd" (thus producing a non-working nslcd configuration), changed the line back using "vi nslcd.conf" to get a working config, and then ran "dpkg-reconfigure -u nslcd" to see which of the two settings took precedence.
When I did this test with 0.8.4ubuntu0.4, the nslcd.conf file was not changed, but instead the debconf database value was overwritten with the value taken from the nslcd.conf file, as desired. So it looks like this patch does resolve the specific failure scenarios mentioned in both of these bugs.

Mathew Hodson (mhodson) on 2015-01-15
tags: removed: removal-candidate

The verification of the Stable Release Update for nss-pam-ldapd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nss-pam-ldapd - 0.8.4ubuntu0.4

nss-pam-ldapd (0.8.4ubuntu0.4) precise; urgency=low

  * [bzr lp:ubuntu/nss-pam-ldapd revno:19 tag:0.8.8-1]:
    - debian/nslcd.config: properly handle preseeding and reading values
    from the configuration file by forcefully overwriting debconf values
    from nslcd.conf and not overwriting debconf values when reading other
    configuration files. (LP: #1229713)
 -- Rafael David Tinoco <email address hidden> Thu, 14 Aug 2014 07:27:54 -0300

Changed in nss-pam-ldapd (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
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.