Bug 362711 - rpcbind fails to update ... rpcbind-0.1.4-6.fc7 > rpcbind-0.1.4-8.fc7
rpcbind fails to update ... rpcbind-0.1.4-6.fc7 > rpcbind-0.1.4-8.fc7
Product: Fedora
Classification: Fedora
Component: rpcbind (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-01 17:59 EDT by shane
Modified: 2008-06-16 22:47 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-16 22:47:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description shane 2007-11-01 17:59:19 EDT
Description of problem:  Trying to run yum update or gui software updater, it
finds the rpcbind-0.1.4-8-fc7.x86_64 update available, i currently have,
rpcbind-0.1.4-6.fc7.x86_64 installed.  but i get this error when it tries:

Running Transaction
error: %pre(rpcbind-0.1.4-8.fc7.x86_64) scriptlet failed, exit status 9
error:   install: %pre scriptlet failed (2), skipping rpcbind-0.1.4-8.fc7

Then it fails to install and redetects that i need to update it.

Version-Release number of selected component (if applicable): 
rpcbind-0.1.4-6.fc7.x86_64  >  rpcbind-0.1.4-8.fc7.x86_64

How reproducible:  not sure

Steps to Reproduce: 
1.  updated to rpcbind-0.1.4-6.fc7.x86_64
2.  now trying to update to rpcbind-0.1.4-8.fc7.x86_64
Actual results:  fails to update

Expected results:  should update

Additional info:  i am getting a selinux denial.  whenever i try to update to
the new version of rpcbind.

2 of these

Source Context:  user_u:system_r:nscd_tTarget Context: 
user_u:system_r:rpm_tTarget Objects:  pipe:[34263] [ fifo_file ]Affected RPM
Packages:  nscd-2.6-4 [application]Policy RPM: 
selinux-policy-2.6.4-48.fc7Selinux Enabled:  TruePolicy Type:  targetedMLS
Enabled:  TrueEnforcing Mode:  EnforcingPlugin Name:  plugins.catchallHost Name:
 s1ogs.3scs.netPlatform:  Linux s1ogs.3scs.net #1 SMP Fri Oct 19
14:35:28 EDT 2007 x86_64 x86_64Alert Count:  2First Seen:  Thu 01 Nov 2007
04:55:36 PM CDTLast Seen:  Thu 01 Nov 2007 04:55:36 PM CDTLocal ID: 
8676a9f6-f937-4afe-af86-6b7e17f8fbf2Line Numbers:  Raw Audit Messages :

and then 1 of these:

Source Context:  user_u:system_r:semanage_tTarget
Context:  user_u:system_r:rpm_tTarget Objects:  pipe:[34263] [ fifo_file
]Affected RPM Packages:  Policy RPM:  selinux-policy-2.6.4-48.fc7Selinux
Enabled:  TruePolicy Type:  targetedMLS Enabled:  TrueEnforcing
Mode:  EnforcingPlugin Name:  plugins.catchallHost
Name:  s1ogs.3scs.netPlatform:  Linux s1ogs.3scs.net #1 SMP Fri
Oct 19 14:35:28 EDT 2007 x86_64 x86_64Alert Count:  1First Seen:  Thu 01 Nov
2007 04:55:36 PM CDTLast Seen:  Thu 01 Nov 2007 04:55:36 PM CDTLocal
ID:  fe1d352b-bf5d-4e20-bc2e-3fb80821eb09Line Numbers:  Raw Audit Messages :
Comment 1 shane 2007-11-01 18:05:11 EDT
disabled selinux and rebooted tried to update the package again and got the
samething minus the selinux denials.
Comment 2 Steve Dickson 2007-11-08 06:22:18 EST
Try adding 

ALL: localhost

to /etc/hosts.allow fixes the problem.

Comment 3 shane 2007-11-09 22:49:07 EST
was already allowed.
Comment 4 Steve Dickson 2007-11-26 08:17:02 EST
So did changing 'SELINUX=enforcing' to 'SELINUX=permissive' in
/etc/selinux/config and rebooting help?
Comment 5 shane 2007-11-28 17:49:26 EST
no still got the same problem.  Tried with 0.1.4-7 and 0.1.4-8

i got it updated to rpcbind-0.1.4-8.fc7 by rpm -e rpcbind ... downloading the
rpm and rpm -Uvh --noscripts rpcbind-

it kept failing on the scriptlets error status 9.  not sure how to run the
scriptlets by themselves though or even look at them but anyways.  With selinux
in permissive or disabled it would just error out on the scriptlets with status 9.  

    SELinux is preventing semanage (semanage_t) "write" to pipe:[31603] (rpm_t).


avc: denied { write } for comm="semanage" dev=pipefs egid=0 euid=0
exe="/usr/bin/python" exit=0 fsgid=0 fsuid=0 gid=0 items=0 path="pipe:[31603]"
pid=3637 scontext=root:system_r:semanage_t:s0-s0:c0.c1023 sgid=0
subj=root:system_r:semanage_t:s0-s0:c0.c1023 suid=0 tclass=fifo_file
tcontext=root:system_r:rpm_t:s0-s0:c0.c1023 tty=tty1 uid=0
Comment 6 shane 2007-11-28 17:57:05 EST
oh yea, it upgraded just fine on my x86 arch machine.  from 0.1.4-6 > -7 > -8
Comment 7 Steve Dickson 2007-12-17 10:56:01 EST
So can this bug be closed?
Comment 8 shane 2008-03-06 04:55:34 EST
no x86 != x86_64

i found another guy that was having this problem, and he found a fix.  i am
trying to find the link to his page again.


rpm -qp --scripts ./rpcbind-0.1.4-13.fc8.x86_64.rpm > rpc-script

then edit the rpc-script on the groupadd and useradd lines you need to add a
switch -o.

Comment 9 shane 2008-03-06 05:00:53 EST
here is his link.  better info there.  his post is kind of wrong though because
if you do the rpm -qp --scripts <package> it outputs all the scripts the install
ones and uninstall ones.  So if you run it you end up uninstalling the user and
group stuff and executing all the files that would be in the rpm...

Comment 10 Steve Dickson 2008-03-06 08:33:51 EST
hmm to quote Gudlyf's World, 

"The ‘-o’ is necessary because, for some godforsaken reason, the reason this RPM 
 kept failing was because “32″ was not a unique userid. Thing is, it’s not in 
 /etc/passwd (note that it removes it first!), so why it’s complaining I can 
 only guess has to do with LDAP, though I haven’t had time to test yet."

What worries me about just adding a '-o' flage is what uid/gid 
would I be overriding? Plus another baffling this is why is
this an x86_64 only thing? 

To answer the first question, I wonder if the portmapper package
still exists which could be causing the confliction. 

Comment 11 shane 2008-03-10 15:18:13 EDT
No portmapper rpm is installed on my machine.

$: rpm -qa port*

Not sure... about the USERID its overriding.  this is from my current
/etc/passwd with rpcbind updated.  Maybe the userdel/groupdel isn't being run
with rights?  Or maybe that is what is causing the selinux denial.
grep :32: /etc/passwd
rpc:!!:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin

I have reinstalled several times, working on something else,  this always
happens, doesn't in x86 though.  I use local account sufficient option too so I
am not sure why it would be going to ldap.  I can't update ldap from the
machines I am trying to upgrade rpcbind on either.
Comment 12 shane 2008-03-10 15:35:50 EDT
oh wow i was on the wrong box when i posted before...  that info was from x86.

on my x86_64:
$: rpm -qa port*

still no portmapper though.  There are 2 rpc users on my x86 rpcuser and rpc, on
my x86_64 box there is only 1 rpcuser.  It looks like the useradd -o didn't add
the userid and now its coming from ldap.  There are a couple files on my x86_64
box that are owned by UID 32.

Comment 13 Steve Dickson 2008-03-10 17:13:36 EDT
I'm not understanding what you mean when you say:

"It looks like the useradd -o didn't add the userid and now its  
coming from ldap."

Could you expand please?

Comment 14 shane 2008-03-15 08:53:12 EDT
when it deletes the user it succeeds, but then when it tries to add the user,
rpc, back into the local password file it finds the the user rpc as uid 32 in
ldap.  The user rpc is being served out via ldap as well as it was in the local
passwd file.

So even when doing the `useradd -o rpc...` it isn't getting added back into the
local passwd file, this is causing the error when trying to update the rpm too.
 The user rpc can only get authenticated through ldap now.

I think deleting the user rpc in the rpm scripts is the wrong thing to do.  Why
not just check if it is there?  And if something in it is incorrect change it?


export IFS=$'\n'
NEWUSER=(rpc x 32 32 "Rpcbind Daemon" /var/lib/rpcbind /sbin/nologin)
EXISTINGUSER=(`sed -n '/^rpc:/s/:/\n/pg' /etc/passwd`)
for i in `seq 0 ${#NEWUSER[@]}`; do
        if [[ ${NEWUSER[i]} != ${EXISTINGUSER[i]} ]]; then
                echo "${NEWUSER[i]} >< ${EXISTINGUSER[i]}"
                echo "shit, user differs in passwd file."
if [ $DIFF == 1 ]; then
        echo -e '\n\nsomething is jacked with the passwd file on this machine
but here is a "no brain" attempt to fix it.\nSince this obviously hasnt been
tested it will probably be in the next rpcbind rpm only for x86_64 of course
because if both packages were the same, except of course for libraries and other
dependencies that would obviously be in different places it would stand to
reason they would be easier to maintain.\nBut I digress.  Dont worry Im just
busting your balls.  I still like fedora and Im not going to go back to Windows
anytime soon.  Slackware 12.0 just came out though.\n\n'
        sed -i '/^rpc:/s/.*/rpc:x:32:32:Rpcbind
Daemon:/var/lib/rpcbind:/sbin/nolgin/' /etc/passwd
Of course this might cause inconsistencies with shadow, group and gshadow.  But
you could just not delete the account when the script starts.  Or make adding
the user into the password file since it exists in ldap not a critical error,
but i think i would rather it be in the passwd file though, I guess it would be
faster.  No i dont want rpms updating my ldap accounts.
Comment 15 Bug Zapper 2008-05-14 10:57:07 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2008-06-16 22:47:01 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.