Bug 816032 - /var/log/cluster directory attr collision with corosync
/var/log/cluster directory attr collision with corosync
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: corosync (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Friesse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-25 02:08 EDT by Milan Broz
Modified: 2013-02-28 23:11 EST (History)
9 users (show)

See Also:
Fixed In Version: corosync-1.4.3-1.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-10 10:19:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Milan Broz 2012-04-25 02:08:14 EDT
Description of problem:

In Fedora16, both cman and corosync packages are installed for cluster, and both these packages own /var/log/cluster directory.

For corosync, directory attributes are set to %attr(700, root, root) while
cman uses default attr.

There is no problem for rpm seems, but for appliance-creator it caused conflict
(cbox cannot install F16 for example):
file /var/log/cluster conflicts between attempted installs of cman-3.1.7-1.fc16.x86_64 and corosync-1.4.2-1.fc16.x86_64 

A trivial fix seems to be add the same attr to cman, iow this patch helps:

cluster.spec

 %{_datadir}/cluster/relaxng/cluster.rng.in.head
 %{_datadir}/cluster/relaxng/cluster.rng.in.tail
 %{perl_vendorarch}/*
+%attr(700, root, root) /var/log/cluster
 %dir /var/log/cluster
 %dir /var/lib/cluster


Version-Release number of selected component (if applicable):
cman-3.1.8-1.fc16.x86_64.rpm
corosync-1.4.2-1.fc16
Comment 1 Fabio Massimo Di Nitto 2012-04-25 02:36:12 EDT
Reassigning to corosync since cluster has never changed from 755.

At some point in time corosync switched from 755 to 700. rpm doesn´t complain and the final directory is 755 (from cman), but clearly the discrepancy creates problems for other packages too.

corosync should revert the change to 755.
Comment 2 Jan Friesse 2012-04-25 02:46:52 EDT
(In reply to comment #1)
> Reassigning to corosync since cluster has never changed from 755.
> 
> At some point in time corosync switched from 755 to 700. rpm doesn´t complain
> and the final directory is 755 (from cman), but clearly the discrepancy creates
> problems for other packages too.
> 
> corosync should revert the change to 755.

Actually, corosync was always shipping with 700 (we never changed that). We have similar bug for RHEL and it's fixed in RHEL 6.3, sadly change never propagated to f17. I'm building fixed package right now together with new 1.4.3 release.
Comment 3 Fedora Update System 2012-04-25 02:57:52 EDT
corosync-1.4.3-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/corosync-1.4.3-1.fc16
Comment 4 Fedora Update System 2012-04-27 01:56:16 EDT
Package corosync-1.4.3-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing corosync-1.4.3-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-6735/corosync-1.4.3-1.fc16
then log in and leave karma (feedback).
Comment 5 Milan Broz 2012-04-27 06:48:02 EDT
btw the same problem is in F15.
Comment 6 Fedora Update System 2012-05-10 10:19:47 EDT
corosync-1.4.3-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

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