Comment 14 for bug 1350778

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....