Bug 428496

Summary: rpcbind-0.1.4-12.fc8.x86_64.rpm does not update properly
Product: [Fedora] Fedora Reporter: Eli Wapniarski <eli>
Component: rpcbindAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 8CC: edfriedmangvs, gwync, jonstanley, orion, patrick, phil
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: F8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-26 17:37:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to allow proper uid/permissions check on rpcbind.file none

Description Eli Wapniarski 2008-01-12 06:58:51 UTC
Description of problem:

I used smart to update rpcbind-0.1.4-12.fc8.x86_64.rpm with the latest batch 
of updates. When the updates got to rpcbind the process froze until I manually 
stopped the service. The update failed to complete properly with a postscript 
error. But the rest of the updates proceeded as expected.

I rpm -Uvh --force rpcbind-0.1.4-12.fc8.x86_64.rpm becuase of the resultant 
duplicate and rebooted the computer. Several services did not start.

I then rpm -Uvh --force rpcbind-0.1.4-11.fc8.x86_64.rpm. Rebooted. All was 
well.

Then stopped rpcbind again. Ran smart upgrade again. Rebooted and everything 
seems to be OK.

This was not a smooth update.

Comment 1 Eli Wapniarski 2008-01-12 07:00:09 UTC
Oh.. forgot to mention when I ran smart upgrade the second time 
rpcbind-0.1.4-12.fc8.x86_64.rpm was indeed upgraded properly.

Comment 2 Gwyn Ciesla 2008-01-14 22:49:29 UTC
Same update on a x86 seems to have partially broken my NIS install.  I followed
the steps above on my server, and even a local ypcat passwd comes out scrambled
halfway through, even after re-"make"ing my yp files and restarting rpcbind,
ypserv and ypbind.  Same remote behaviour, as well.

Evenutally traced to corrupted character in /etc/shadow.

Comment 3 Johan Kok 2008-01-19 08:14:07 UTC
*** Bug 429048 has been marked as a duplicate of this bug. ***

Comment 4 Johan Kok 2008-01-19 08:14:38 UTC
*** Bug 428872 has been marked as a duplicate of this bug. ***

Comment 5 Orion Poplawski 2008-01-28 15:31:15 UTC
look like -13 has the same problem.  Stopped the NFS server from working until
it was restarted.

Some more info:  (note that I'm running in permissive mode)

Jan 28 01:06:31 saga yum: Updated: rpcbind - 0.1.4-13.fc8.i386
Jan 28 01:06:43 saga rpcbind: rpcbind terminating on signal. Restart with
"rpcbind -w"
Jan 28 01:06:43 saga kernel: audit(1201507603.810:38): avc:  denied  { write }
for  pid=2005 comm="rpcbind" name="rpcbind.file" dev=dm-2 ino=31794
scontext=system_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:var_lib_t:s0
tclass=file
Jan 28 01:06:43 saga kernel: audit(1201507603.821:39): avc:  denied  { getattr }
for  pid=2005 comm="rpcbind" path="/var/lib/rpcbind/rpcbind.file" dev=dm-2
ino=31794 scontext=system_u:system_r:rpcbind_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=file
Jan 28 01:07:59 saga kernel: audit(1201507679.883:40): avc:  denied  { write }
for  pid=29116 comm="rpc.statd" path="pipe:[1323194]" dev=pipefs ino=1323194
scontext=system_u:system_r:rpcd_t:s0 tcontext=system_u:system_r:automount_t:s0
tclass=fifo_file
Jan 28 01:07:59 saga rpc.statd[29117]: Version 1.1.0 Starting
Jan 28 01:07:59 saga rpc.statd[29117]: Flags:

Then I saw no more messages from rpc.mountd until I restarted it.

Jan 28 08:10:05 saga mountd[2454]: Caught signal 15, un-registering and exiting.
Jan 28 08:10:36 saga mountd[16186]: authenticated mount request from
earth.cora.nwra.com:615 for /export/backup1 (/export/backup1)
Jan 28 08:10:36 saga kernel: audit(1201533036.526:41): avc:  denied  { write }
for  pid=16186 comm="rpc.mountd" name="control" dev=tmpfs ino=270
scontext=root:system_r:nfsd_t:s0 tcontext=system_u:object_r:lvm_control_t:s0
tclass=chr_file


Comment 6 Eli Wapniarski 2008-01-28 16:41:37 UTC
Problem persists with the new -13 build

Comment 7 Steve Dickson 2008-01-28 19:27:00 UTC
f I were to summarize this, its not the actual rpm 
upgrade that's failing (i.e the new bits are being
laid down correctly), it the services that are
using rpcbind (i.e. nfs, nis, etc) that fail with
the upgrade occurs. Right?

If this is the case, a fix for this would be for
upgrades to tell the current rpcbind to store all
the current registered service in a data file, and then 
have the new rpcbind do a warm start, using that data
file. 



Comment 8 Eli Wapniarski 2008-01-28 20:23:34 UTC
The actual rpm upgrade fails. It gets stuck until I kill the service. Then it 
tells me that there is some kind of error and the previous package remains. 
The solution as I mentioned in my original post is to 

/etc/rc.d/init.d/rpcbind stop
rpm -e --nodeps --allmatches rpcbind
rpm -Uvh rpcbindxxx.rpm

restart the computer.

The problem seems to only exist with x86_64 package. It does not seem to be a 
problem with i386 package.

Comment 9 Philippe Troin 2008-01-28 20:25:31 UTC
(In reply to comment #7)
> f I were to summarize this, its not the actual rpm 
> upgrade that's failing (i.e the new bits are being
> laid down correctly), it the services that are
> using rpcbind (i.e. nfs, nis, etc) that fail with
> the upgrade occurs. Right?

Exactly.

> If this is the case, a fix for this would be for
> upgrades to tell the current rpcbind to store all
> the current registered service in a data file, and then 
> have the new rpcbind do a warm start, using that data
> file. 

Yes.
The older portmap package contained pmap_dump and pmap_set for this purpose.

Phil.

Comment 10 Gwyn Ciesla 2008-01-28 20:43:11 UTC
I don't have the rpm failure, but I do get the service failures, and I'm on 32-bit.

Comment 11 Patrick Monnerat 2008-01-29 14:28:04 UTC
Created attachment 293284 [details]
Patch to allow proper uid/permissions check on rpcbind.file

Version 0.1.4-13 still causes the problem.
I've found a way that seems to overcome it:
Create file /etc/sysconfig/rpcbind with the single line
RPCBIND_ARGS=-w

This is not sufficient since rpcbind erroneously checks
/var/lib/rpcbind/rpcbind.file owner/permissions. Apply the patch and recompile.

That should do it.

I suggest to include /etc/sysconfig/rpcbind in RPM package as a %config file

Comment 12 Steve Dickson 2008-02-11 16:51:13 UTC
fixed in rpcbind-0.1.4-14.fc9

Comment 13 Bug Zapper 2008-11-26 09:24:21 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 to the applicable version.  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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 14 Jon Stanley 2008-11-26 17:37:08 UTC
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report.

If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against.

Thanks for the report!