Description of problem: When ldap authentication is configured in authconfig, rpcbind will not install nor update. This causes nfslock to not be able to load, and nfs on a client machine will not work. By disabling ldap authentication in authconfig, the rpm will install. The error message given is: error: %pre(rpcbind-0.1.4-16.fc9.x86_64) scriptlet failed, exit status 9 error: install: %pre scriptlet failed (2), skipping Version-Release number of selected component (if applicable): 0.1.4-16.fc9 How reproducible:Always Steps to Reproduce: 1. Enable LDAP authentication via authconfig 2. Attempt to install (or upgrade) rpcbind 3. Actual results: rpcbind installation fails Expected results: rpcbind installation succeeds Additional info: This bug was present at least going back to Fedora 8. http://www.gudlyf.com/2008/01/29/techie-time-fedora-8-problems-with-updating-rpcbind/
rpcbind-0.1.4-17.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/rpcbind-0.1.4-17.fc9
Fixed in rpcbind-0.1.4-17.fc9
rpcbind-0.1.4-17.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rpcbind'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8543
rpcbind-0.1.4-17.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
I don't see the problem being fixed: $ rpm -Uvh rpcbind-0.1.4-17.fc9.x86_64.rpm Preparing... ########################################### [100%] error: %pre(rpcbind-0.1.4-17.fc9.x86_64) scriptlet failed, exit status 9 error: install: %pre scriptlet failed (2), skipping rpcbind-0.1.4-17.fc9
I investigated the problem a long time ago and the failure occurs because the preinstall script wants to delete and then recreate the "ldap" user. My workaround is to remove the ldap entries from the /etc/nsswitch.conf file, do the update of rpcbind, and then restore the original version of /etc/nsswitch.conf # cp -p /etc/nsswitch.conf /etc/nsswitch.conf.ldap # sed -e 's/ ldap//g' /etc/nsswitch.conf.ldap > /etc/nsswitch.conf # yum update rpcbind # mv /etc/nsswitch.conf /etc/nsswitch.conf.files && cp -p /etc/nsswitch.conf.ldap /etc/nsswitch.conf I never bothered to report this problem because I could not believe that I was the only one using LDAP for authentication.
I don't have any ldap entry in nsswitch.conf and the update to 0.1.7-1 still fails. I had to force it with --noscripts.
Here is what is happening in the %pre script: # if the rpc uid and gid is left over from the portmapper # remove both of them. /usr/sbin/userdel rpc 2> /dev/null || : /usr/sbin/groupdel rpc 2> /dev/null || : # Now re-add the rpc uid/gid /usr/sbin/groupadd -o -g 32 rpc > /dev/null 2>&1 /usr/sbin/useradd -o -l -c "Rpcbind Daemon" -d /var/lib/rpcbind -g 32 \ -M -s /sbin/nologin -u 32 rpc > /dev/null 2>&1 I just don't see what could be failing and why the failure is not being ignored...
What happened is that the shadow file didn't have an rpc entry. This causes the userdel command to fail (which is ignored). But it also means the groupdel fails (there is still a user whose primary group is rpc). This in turn means the groupadd and useradd commands fail because there is still such a user. These errors are not ignored. Unfortunately there is no way to force userdel to continue and only remove the entry in /etc/passwd. That seems to be a logical extension of the program. Until that time more manual tests and operations would be needed. I think this can be closed. I'll file a bug for shadow-utils to extend userdel.