What did /etc/nslcd.conf look like before the update was applied?

---- BEFORE:
uri ldap://ldap1.dlib.indiana.edu
#ldap://ldap2.dlib.indiana.edu
base dc=dlib,dc=indiana,dc=edu
scope one

base passwd    ou=people,dc=dlib,dc=indiana,dc=edu
base shadow    ou=people,dc=dlib,dc=indiana,dc=edu
base group     ou=groups,dc=dlib,dc=indiana,dc=edu
base hosts     ou=hosts,dc=dlib,dc=indiana,dc=edu

timelimit 120
idle_timelimit 3600

ssl no
tls_cacertdir /etc/openldap/cacert
-------

---- After:
# uri ldap://ldap1.dlib.indiana.edu
#ldap://ldap2.dlib.indiana.edu
# base dc=dlib,dc=indiana,dc=edu
scope one

# base passwd    ou=people,dc=dlib,dc=indiana,dc=edu
# base shadow    ou=people,dc=dlib,dc=indiana,dc=edu
# base group     ou=groups,dc=dlib,dc=indiana,dc=edu
# base hosts     ou=hosts,dc=dlib,dc=indiana,dc=edu

timelimit 120
idle_timelimit 3600

ssl no
tls_cacertdir /etc/openldap/cacert

# This comment prevents repeated auto-migration of settings.
uri ldap://127.0.0.1/ 
base dc=example,dc=com
-------------

Ah, then the settings were migrated in from /etc/ldap.conf (or /etc/nss-ldapd.conf, or /etc/nss_ldap.conf, or /etc/pam_ldap.conf, most of which system-config-authentication knows to keep up to date) because the comment which is added when that happens wasn't already in /etc/nslcd.conf.  Which of the other files was present?  Did they contain the right settings?

* nslcd.conf had the correct settings in it
* ldap.conf had similar settings (The syntax was different, but the settings were effectively the same)
* nss-ldap.conf and nss_ldap.conf don't exist
* pam_ldap.conf has the localhost/example.com setup

So nslcd.conf and ldap.conf were correct and pam_ldap.conf wasn't (since I use nss for lookups in pam)

I'm glad it just commented the lines out (vs erasing them), but it seems that its a bit dangerous to rely on that comment to be in there.  I've copied that comment into the setup scripts I use...so that will avoid this issue in the future?

(In reply to comment #5)
> I'm glad it just commented the lines out (vs erasing them), but it seems that
> its a bit dangerous to rely on that comment to be in there.  I've copied that
> comment into the setup scripts I use...so that will avoid this issue in the
> future?

The %post script for the package shouldn't be touching the configuration file if the comment is there, so you should be fine after that.  Though it should probably also only happen when the package is first installed.

Nalin, your fix works on i386, but it does not work on 64bit archs (x86_64, s390x and ppc64):

1. yum -y remove nss-pam-ldapd* pam_ldap*
2. rm -f /etc/nslcd.conf* /etc/pam_ldap.conf*
3. getent -s 'passwd:ldap' passwd omoris (return 2, expected)
4. yum -y install pam_ldap pam_ldap.i686
5. cat >/etc/pam_ldap.conf<<EOF
   uid nslcd                                         
   gid ldap                                          
   uri ldap://ldap.corp.redhat.com/
   base dc=redhat,dc=com
   EOF
6. rpm -ihv --force /mnt/qa/scratch/hp-dl180g6-01/2011:11700/tps/new-files*list'
7. service nslcd restart && sleep 5
8. getent -s 'passwd:ldap' passwd omoris' (Expected 0, got 2)

Configuration from pam_ldap.conf is not copied into nslcd.conf:

/etc/nslcd.conf:
# This is the configuration file for the LDAP nameservice
# switch library's nslcd daemon. It configures the mapping
# between NSS names (see /etc/nsswitch.conf) and LDAP
# information in the directory.
# See the manual page nslcd.conf(5) for more information.

# The uri pointing to the LDAP server to use for name lookups.
# Multiple entries may be specified. The address that is used
# here should be resolvable without using LDAP (obviously).
#uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator
uri ldap://127.0.0.1/

# The LDAP version to use (defaults to 3
# if supported by client library)
#ldap_version 3

# The distinguished name of the search base.
base dc=example,dc=com

# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
#binddn cn=proxyuser,dc=example,dc=com

# The credentials to bind with.
# Optional: default is no credentials.
# Note that if you set a bindpw you should check the permissions of this file.
#bindpw secret

# The distinguished name to perform password modifications by root by.
#rootpwmoddn cn=admin,dc=example,dc=com

# The default search scope.
#scope sub
#scope one
#scope base

# Customize certain database lookups.
#base   group  ou=Groups,dc=example,dc=com
#base   passwd ou=People,dc=example,dc=com
#base   shadow ou=People,dc=example,dc=com
#scope  group  onelevel
#scope  hosts  sub

# Bind/connect timelimit.
#bind_timelimit 30

# Search timelimit.
#timelimit 30

# Idle timelimit. nslcd will close connections if the
# server has not been contacted for the number of seconds.
#idle_timelimit 3600

# Use StartTLS without verifying the server certificate.
#ssl start_tls
#tls_reqcert never

# CA certificates for server certificate verification
#tls_cacertdir /etc/ssl/certs
#tls_cacertfile /etc/ssl/ca.cert

# Seed the PRNG if /dev/urandom is not provided
#tls_randfile /var/run/egd-pool

# SSL cipher suite
# See man ciphers for syntax
#tls_ciphers TLSv1

# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key

# NDS mappings
#map group uniqueMember member

# Mappings for Services for UNIX 3.5
#filter passwd (objectClass=User)
#map    passwd uid              msSFU30Name
#map    passwd userPassword     msSFU30Password
#map    passwd homeDirectory    msSFU30HomeDirectory
#map    passwd homeDirectory    msSFUHomeDirectory
#filter shadow (objectClass=User)
#map    shadow uid              msSFU30Name
#map    shadow userPassword     msSFU30Password
#filter group  (objectClass=Group)
#map    group  uniqueMember     msSFU30PosixMember

# Mappings for Services for UNIX 2.0
#filter passwd (objectClass=User)
#map    passwd uid              msSFUName
#map    passwd userPassword     msSFUPassword
#map    passwd homeDirectory    msSFUHomeDirectory
#map    passwd gecos            msSFUName
#filter shadow (objectClass=User)
#map    shadow uid              msSFUName
#map    shadow userPassword     msSFUPassword
#map    shadow shadowLastChange pwdLastSet
#filter group  (objectClass=Group)
#map    group  uniqueMember     posixMember

# Mappings for Active Directory
#pagesize 1000
#referrals off
#filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
#map    passwd uid              sAMAccountName
#map    passwd homeDirectory    unixHomeDirectory
#map    passwd gecos            displayName
#filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
#map    shadow uid              sAMAccountName
#map    shadow shadowLastChange pwdLastSet
#filter group  (objectClass=group)
#map    group  uniqueMember     member

# Mappings for AIX SecureWay
#filter passwd (objectClass=aixAccount)
#map    passwd uid              userName
#map    passwd userPassword     passwordChar
#map    passwd uidNumber        uid
#map    passwd gidNumber        gid
#filter group  (objectClass=aixAccessGroup)
#map    group  cn               groupName
#map    group  uniqueMember     member
#map    group  gidNumber        gid
uid nslcd
gid ldap

/etc/pam_ldap.conf:
uid nslcd
gid ldap
uri ldap://ldap.corp.redhat.com/
base dc=redhat,dc=com

As I have mentioned, on i686 it works fine. The only difference is that on each 64b box one has to install both 64b and 32b version of nss-pam-ldapd and pam_ldap and hence it seems that installation of second nss-pam-ldapd somehow overwrite nslcd.conf back to defaults (it is my guess only).

The nslcd.conf file is marked %config(noreplace), so it shouldn't be overwritten.  The %post only migrates the settings if $1 is "1" (indicating that after the transaction is over, only one copy of the package will be installed), which as you've discovered won't trigger if we're installing both versions on a multilib system.  Normally I'd suggest moving the multilib piece (the nsswitch module) into a subpackage and making the main package no longer multilib, but I think that would get confusing during upgrades.

(In reply to comment #10)
> The nslcd.conf file is marked %config(noreplace), so it shouldn't be
> overwritten.  The %post only migrates the settings if $1 is "1" (indicating
> that after the transaction is over, only one copy of the package will be
> installed), which as you've discovered won't trigger if we're installing both
> versions on a multilib system.

I've put some debug statements into the scriptlets and this is what seems to be happening:

1) nss-pam-ldapd.32bit gets installed. In %post, the $1 is "1" and the config gets migrated
2) nss-pam-ldapd.64bit gets installed and overwrites the config file. In post, the $1 var is "2" (=upgrade), so nothing is migrated

I'm not sure why RPM overwrites the config during install of the second package..

Nalin, why not do the migration even on upgrades *if the comment is not found* ?

If that doesn't work, can we migrate the config file in %posttrans, maybe based on some flag we set during %post when $1 == 1

(In reply to comment #11)
> (In reply to comment #10)
> > The nslcd.conf file is marked %config(noreplace), so it shouldn't be
> > overwritten.  The %post only migrates the settings if $1 is "1" (indicating
> > that after the transaction is over, only one copy of the package will be
> > installed), which as you've discovered won't trigger if we're installing both
> > versions on a multilib system.
> 
> I've put some debug statements into the scriptlets and this is what seems to be
> happening:
> 
> 1) nss-pam-ldapd.32bit gets installed. In %post, the $1 is "1" and the config
> gets migrated
> 2) nss-pam-ldapd.64bit gets installed and overwrites the config file. In post,
> the $1 var is "2" (=upgrade), so nothing is migrated
> I'm not sure why RPM overwrites the config during install of the second
> package..

The file should not be overwritten, as it's marked %config(noreplace).  Are you installing both as part of the same transaction, or in two transactions?  The right thing appears to happen with the first installation when I install them separately.

> Nalin, why not do the migration even on upgrades *if the comment is not found*
> ?

If the user's doing things manually, nslcd.conf can be correct when pam_ldap.conf isn't, and we'd replace a known-good configuration with defaults which aren't.  This is us attempting to avoid that.

> If that doesn't work, can we migrate the config file in %posttrans, maybe based
> on some flag we set during %post when $1 == 1

Sounds reasonable.  We don't appear to have the ability to carry environment settings over from one scriptlet to another, though, so I'm not sure on where you're suggesting that the flags be kept.

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > The nslcd.conf file is marked %config(noreplace), so it shouldn't be
> > > overwritten.  The %post only migrates the settings if $1 is "1" (indicating
> > > that after the transaction is over, only one copy of the package will be
> > > installed), which as you've discovered won't trigger if we're installing both
> > > versions on a multilib system.
> > 
> > I've put some debug statements into the scriptlets and this is what seems to be
> > happening:
> > 
> > 1) nss-pam-ldapd.32bit gets installed. In %post, the $1 is "1" and the config
> > gets migrated
> > 2) nss-pam-ldapd.64bit gets installed and overwrites the config file. In post,
> > the $1 var is "2" (=upgrade), so nothing is migrated
> > I'm not sure why RPM overwrites the config during install of the second
> > package..
> 
> The file should not be overwritten, as it's marked %config(noreplace).  Are you
> installing both as part of the same transaction, or in two transactions?  The
> right thing appears to happen with the first installation when I install them
> separately.
> 

yum localinstall nss-pam-ldapd.i386 nss-pam-ldapd.x86_64

> > If that doesn't work, can we migrate the config file in %posttrans, maybe based
> > on some flag we set during %post when $1 == 1
> 
> Sounds reasonable.  We don't appear to have the ability to carry environment
> settings over from one scriptlet to another, though, so I'm not sure on where
> you're suggesting that the flags be kept.

Then it would have to be in some file, which is ugly and may break things if we failed to clean up this file after a migration, for instance.

Ping... so what? :)

(In reply to comment #14)
> Ping... so what? :)

Unless Nalin has objections, I'd like to ask the RPM maintainer for suggestions tomorrow. Maybe there's a better solution we're just overlooking.

OK so the RPM maintainer educated me that in RHEL6(*) we have basically two options:

1) the %posttrans hack. Use a file in /var/run as a flag as whether the %posttrans scriptlet already ran or not. Apparently this is used at least by texlive.

2) move the config file (and wheatever else must be on system only once) into a noarch subpackage.

In my opinion, 1) is a hack, but probably less work and less probability of things breaking down on upgrade. 2) is technically a better solution, but we would have to handle Provides/Obsoletes correctly which might be fragile. It might also be too late for introducing a new subpackage at this point of 6.2.

Thoughts (also from QE as per what's better testable for you) are welcome.

* RHEL7 RPM will apparently have the concept of "collections" that solves this use-case better

Jakub, I am definitely for the first proposed solution. Although the second one seems to be clearer, I cannot imagine that we can introduce a new sub-package in the current development/testing phase of RHEL6.2.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1705.html