Bug 428496 - rpcbind-0.1.4-12.fc8.x86_64.rpm does not update properly
rpcbind-0.1.4-12.fc8.x86_64.rpm does not update properly
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rpcbind (Show other bugs)
8
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
: 428872 429048 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-12 01:58 EST by Eli Wapniarski
Modified: 2008-11-26 12:37 EST (History)
6 users (show)

See Also:
Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-26 12:37:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to allow proper uid/permissions check on rpcbind.file (3.74 KB, patch)
2008-01-29 09:28 EST, Patrick Monnerat
no flags Details | Diff

  None (edit)
Description Eli Wapniarski 2008-01-12 01:58:51 EST
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 02:00:09 EST
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 17:49:29 EST
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 03:14:07 EST
*** Bug 429048 has been marked as a duplicate of this bug. ***
Comment 4 Johan Kok 2008-01-19 03:14:38 EST
*** Bug 428872 has been marked as a duplicate of this bug. ***
Comment 5 Orion Poplawski 2008-01-28 10:31:15 EST
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 11:41:37 EST
Problem persists with the new -13 build
Comment 7 Steve Dickson 2008-01-28 14:27:00 EST
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 15:23:34 EST
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 15:25:31 EST
(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 15:43:11 EST
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 09:28:04 EST
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 11:51:13 EST
fixed in rpcbind-0.1.4-14.fc9
Comment 13 Bug Zapper 2008-11-26 04:24:21 EST
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 12:37:08 EST
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!

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