Description of problem: The current sudo package attempts to add a line to nsswitch.conf if it is missing but it fails it can fail if the update transaction also includes glibc on a multiarch system. What happens is that due to the multiarch nature two glibc packages will be installed and in some circumstances yum orders the updates in a way that first glibc is updated, then sudo (at which point the added line exists in /etc/nsswitch.conf) and then the other glibc arch is updated which overwrites /etc/nsswitch.conf with the copy included in glibc. Version-Release number of selected component (if applicable): sudo-1.7.2p1-14.el5_8.3.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install a fresh rhel 5.8/x86_64 with sudo and openssl and no updates 2. remove the 'sudoers:' line from /etc/nsswitch.conf 3. yum update sudo openssl glibc .... Running Transaction Updating : glibc-common 1/14 Updating : glibc 2/14 Updating : openssl 3/14 Updating : sudo 4/14 Updating : nscd 5/14 Updating : glibc 6/14 Updating : openssl 7/14 .... Actual results: # grep sudoers /etc/nsswitch.conf # Expected results: # grep sudoers /etc/nsswitch.conf sudoers: files ldap # Additional info: The example with 'sudo openssl glibc' is just one easy way to provoke this issue. Any combination of updates that can trigger sudo being updated in the middle of a glibc multiarch sandwich could cause this problem.
I think that this is correct behavior because if you manually remove the line from nsswitch.conf it should not be automatically recreated.
Lets see what happens if I revert my test VM and only update sudo: # rpm -q sudo sudo-1.7.2p1-13.el5.x86_64 # grep sudoers nsswitch.conf # # yum install sudo .... Running Transaction Updating : sudo 1/2 ... # rpm -q sudo sudo-1.7.2p1-14.el5_8.3.x86_64 # grep sudoers nsswitch.conf sudoers: files ldap # That does not match the behaviour you describe.