Bug 428496
Summary: | rpcbind-0.1.4-12.fc8.x86_64.rpm does not update properly | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Eli Wapniarski <eli> | ||||
Component: | rpcbind | Assignee: | Steve Dickson <steved> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 8 | CC: | 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
Eli Wapniarski
2008-01-12 06:58:51 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. 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. *** Bug 429048 has been marked as a duplicate of this bug. *** *** Bug 428872 has been marked as a duplicate of this bug. *** 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 Problem persists with the new -13 build 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. 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. (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. I don't have the rpm failure, but I do get the service failures, and I'm on 32-bit. 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
fixed in rpcbind-0.1.4-14.fc9 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 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! |