Upgrading nslcd on precise rewrites /etc/nslcd.conf, leaving users with unusable systems

I have just been affected by this exact same bug -- and it has caused us to be unable log in to our machines with any LDAP users.

This bug has very high impact but should be rather straightforward to fix -- shouldn't the config file not be touched if it has been modified from the original?

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

There are migrations that need to happen if you upgrade from 0.x to 0.y, but if you're upgrading within the same series, it shouldn't be touched. I'm working on a bugfix that implements that rule.

Patch attached for this issue.

The postint script contains a block that migrates configuration directives from previous versions. I surrounded it with a check to see if the installation was upgrading from a pervious series, or was a new installation. If the upgrade is still for the 0.8 series (I've assumed that precise will not be getting 0.9) then the config file migration doesn't happen, and the original configuration is preserved.

Could someone review please?

The attachment "nss-pam-ldapd-lp1350778.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

I don't think the configuration upgrade code is the issue here (that would probably only cause issues with some downgrades). Furthermore, from a quick glance it seems the patch disables debconf configuration altogether.

The Debian packages contains numerous fixes to the debconf handling and configuration parsing that most likely fix the above issues:

* don't clear the tls_reqcert option when using ssl without the start_tls option or an ldaps:// URL
  fixed in 0.8.8-3 (Debian bug https://bugs.debian.org/672301)
  patch: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1687&view=revision

* fix a problem in sed logic for commenting out disabled options
  fixed in 0.8.10-3 (Debian bug https://bugs.debian.org/689296)
  patch: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1777&view=revision

* make whitespace matching consistent in regular expressions
  fixed in 0.8.5
  patch: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1543&view=revision

* get the first configuration value instead of the last because that one is also written
  fixed in 0.8.5
  patch: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1567&view=revision

* properly parse and write configuration options with an optional map parameter during debconf configuration
  fixed in 0.8.10-2 (Launchpad bug https://bugs.launchpad.net/bugs/1029062)
  patch: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1740&view=revision

* 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
  fixed in 0.8.13-2 (Debian bug https://bugs.debian.org/717063)
  patch: http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=2016&view=revision

> I don't think the configuration upgrade code is the issue here (that would probably only cause issues with some downgrades).

Possibly not the code in that block itself, but it's certainly something in that block or code that it calls. This has been tested with a mirror of our production configuration, and you can use the sample configuration in the original bug report to confirm. Without this patch, we end up with systems that you cannot log in to after upgrading, because the configuration upgrade code (or code that it calls) mangles the config file.

> Furthermore, from a quick glance it seems the patch disables debconf configuration altogether.

No, it doesn't. It only disables the upgrades if you're upgrading within the same series (e.g. 0.8.x to 0.8.y).

    if dpkg --compare-versions "$2" lt-nl "0.8"

will perform the upgrade if you're installing fresh (that is, no previous version) or the previous version is lt 0.8. The format of a config file should not change during a series like that anyway, and going through the changelog I couldn't see any place that it did, so this patch seemed like the simplest thing that would work. Please let me know if I missed something.

However, if people are happier with the patches you list getting applied, and you're confident that the update code will no longer change our valid configuration, I can work on a new debdiff with the patches you list.

Granted, it is quite a long list of changes but 0.8.4 was never meant to be a stable release and the 0.8 series was in mind-development around 0.8.4 so that is to be expected.

On my system dpkg --compare-versions "" lt-nl "0.8" is false so it would seem the code is also not run on fresh installs (you should probably use lt instead of lt-nl if you want the described behaviour).

Furthermore, with the patch applied dpkg-reconfigure nslcd no longer has the expected behaviour.

> On my system dpkg --compare-versions "" lt-nl "0.8" is false so it would seem the code is also not run on fresh installs

It does run on fresh installs. You're getting confused between a 0 return code, which means the command succeeded and the condition passes, and false. In most other languages, 0 would be false, but not in a bash script, where a 0 return code means it succeeded :)

Good point about dpkg-reconfigure. I'll work on a debdiff with the patches you listed.

Out of interest, how much work do you think it would be to upgrade the package to the latest 0.8 release? We have another couple of years left with precise as a supported release, and I'd like to keep this package as close to upstream as possible. Should the 0.8 branch apply pretty cleanly?

dpkg --compare-versions "" lt-nl "0.8" returns 1 (false) here (Debian sid). Is this different on Ubuntu?

Debian wheezy has 0.8.10-4 which includes all the fixes mentioned above, except for #717063. This release also includes all the changes currently in the Ubuntu version (0.8.4ubuntu0.3).

There is also a 0.8.14-1 version available (http://snapshot.debian.org/package/nss-pam-ldapd/0.8.14-1/) which should be the most stable and well tested 0.8 version available.

Between 0.8.4 and 0.8.10-4 the biggest changes are:
* various logging improvements
* add ignorecase option
* I/O handling improvements (avoid broken pipes, use poll() instead of select(), etc.)
* pam_authz_search improvements
* various fixes to debconf configuration issues as described earlier
* various code improvements and small fixes

Between 0.8.10-4 and 0.8.14-1 the biggest changes are:
* add pam_password_prohibit_message option
* add sasl_canonicalize option
* a lot of small code fixes that were the result of testing tools

Diffstat between 0.8.4ubuntu0.3 and 0.8.10-4 (excluding documentation, test changes and other unrelated changes):
51 files changed, 743 insertions(+), 568 deletions(-)

Diffstat between 0.8.10-4 and 0.8.14-1 (same excludes):
57 files changed, 966 insertions(+), 818 deletions(-)

Ah, sorry, my mistake, typo with lt-nl. I had used the wrong operator. Thanks for catching that!

I'll see about getting a debdiff put together to bring this up to the latest in the 0.8 series, we don't want to be running an unstable release for the next two years :)

Thanks for your help on this, it's very much appreciated.

New debdiff that applies all the patches from https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/1350778/comments/6

All applied cleanly except the last one, where the lines were just far enough out of range for patch's default fuzziness not to apply it, but the actual change was easily applied manually.

I'll open another issue and post to the MOTU list about the updated deb, but if we can get the configuration patches applied that would be great because we know the 0.8.4 version of the lib itself is working well in production.

Same for me. It replaced the "uri" and the "base"in the nslcd.conf, and destroyed the central authentication for many workstations. Even if we will have a patch, I don't think it will revoke the changes...

Just to clarify the situation, the problem is that the current nslcd.postinst script (i.e. the one in 0.8.4ubuntu0.3) unconditionally rewrites various lines in the /etc/nslcd.conf file using the parameter values pulled from the debconf database... which can lead to a non-working configuration if the debconf values are obsolete or otherwise incorrect.

Mike's approach mentioned in https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/1350778/comments/4 would solve the immediate problem by causing the config-file rewriting to only happen for upgrades where there is actually a reason such rewrites might be needed -- so intra-Precise upgrades like this one wouldn't touch the file at all (though if the script did ever touch the file for some reason, it would still overwrite the current config with the debconf values).

In contrast, the fixes described in https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/1350778/comments/6 would make the config-file rewriting smarter in general, (hopefully) avoiding the problem of incorrectly changing the config file lines from their current values when the debconf value was different.

Another approach would be do do something like the grub-pc.postinst script, which creates a temporary-file version of /etc/default/grub and then uses a "ucf --three-way" call to allow the user to intervene if the generated file differs from the current "live" one.

Anyway, while waiting for one of those fixes to be implement in the package: some quick testing on one of my systems indicates that one can avoid having the nslcd package upgrade break LDAP connectivity by using "debconf-show nslcd", "dpkg-reconfigure nslcd", etc. to make sure that the debconf database values all match the current nslcd.conf values beforehand....

Over in LP #1229713 "nslcd auto-configuration disregards existing nslcd.conf" there's a proposed update package (currently available from a PPA for testing) which includes the patch Arthur mentioned (in comment #6) as a fix to Debian bug 717063.

The proposed nlscd package provided in LP: #1229713 successfully installed without generating a broken nslcd.conf file, at least for the case of my test server where the "uri" line was getting overwritten by a stale debconf value in previous upgrades.

It seems to me that bug 1229713 is a duplicate, or at least that the fix there will fix the original issue described in this bug. So I've uploaded the fix from there, as that bug already had a debdiff that looked good with all the correct SRU information filled out in that bug.

I'll mark this bug as a duplicate.

If I'm wrong, please correct me.