Bug 760793 - backport the OrderWithRequires feature to RPM
Summary: backport the OrderWithRequires feature to RPM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Karel Srot
Stephen Wadeley
URL:
Whiteboard:
: 784289 905104 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-07 00:45 UTC by Simo Sorce
Modified: 2015-07-22 07:01 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
rpm supports ordered installation based on package tags The OrderWithRequires feature has been added to the RPM Package Manager, which utilizes the new OrderWithRequires package tag. If a package specified in OrderWithRequires is present in a package transaction, it is installed before the package with the corresponding OrderWithRequires tag is installed. However, unlike the Requires package tag, OrderWithRequires does not generate additional dependencies, so if the package specified in the tag is not present in the transaction, it is not downloaded.
Clone Of:
Environment:
Last Closed: 2015-07-22 07:01:10 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1452 normal SHIPPED_LIVE rpm bug fix and enhancement update 2015-07-20 18:43:47 UTC

Description Simo Sorce 2011-12-07 00:45:49 UTC
My upgrade from RHEL 6.1 to 6.2 didn't work as expected.

The upgrade updated sssd from version 1.5.1-34.el6_1.3.i686 to 1.5.1-66.el6.i686
In the same yum transaction selinux policy was upgraded from version 3.7.19-93.el6_1.7.noarch to 3.7.19-126.el6_2.3.noarch

Unfortunately within the transaction apparently sssd was upgraded and restarted before the selinux policy. This left the sssd monitor process unable to properly start the data providers and the nss and pam backends. After a few tries the monitor gave up and was left idle unable to serve any requests.

After logging to a console as root the audit.log showed denials.
Simply restarting sssd through the init scripts resolved the issue, so it seem a clear indication that the sssd was restarted before the selinux policy it depdned on was in place.

This left the machine in an unusable state for sssd-bound users until root intervention.

Comment 2 Stephen Gallagher 2011-12-07 00:56:03 UTC
Some additional information about the problem:

sssd-1.5.1-66.el6 made some changes that required new SELinux policy (if
SELinux is installed). Because it is possible to install SSSD on a system
without the selinux-policy package installed, we were instructed to use:

Conflicts: selinux-policy < 3.7.19-118

This should ensure that the policy version must be 3.7.19-118 or later in order
to install this version of SSSD. Unlike using Requires:, this will not forcibly
install selinux-policy if it's not currently on the system.

The problem is that the yum depsolver does not treat optional-requires of this
construction the same way that it treats Requires:

There is no guarantee by the depsolver that the policy will be updated before
SSSD is. As a result, while the final state of the yum transaction included the
correct versions of both of these packages, because the updated selinux-policy
was not installed before SSSD, it fails to successfully restart SSSD on
upgrade.

Comment 3 Panu Matilainen 2011-12-08 09:21:57 UTC
Yup, conflicts aren't considered on ordering. This case does suggest they should be, but I'll need to mull over it a bit to consider whether doing so would have any negative side-effects.

Comment 4 Ales Kozumplik 2011-12-13 14:32:59 UTC
> The problem is that the yum depsolver does not treat optional-requires of this
> construction the same way that it treats Requires:
> 
> There is no guarantee by the depsolver that the policy will be updated before
> SSSD is. As a result, while the final state of the yum transaction included the
> correct versions of both of these packages, because the updated selinux-policy
> was not installed before SSSD, it fails to successfully restart SSSD on
> upgrade.

With the rawhide rpm you can enforce installing the new selinux-policy before the new sssd with 

OrderWithRequires: selinux-policy

This won't create a requirement on selinux-policy yet will ensure selinux-policy is installed before sssd if whenever they are in the same transaction.

Comment 5 Panu Matilainen 2011-12-14 13:41:54 UTC
What kind of selinux policy change are we talking about here exactly? If it involves new/changed labels, ordering is not enough to do anything about this as rpm uses the context label definitions that existed when the transaction started. So in addition to somehow ordering selinux first, rpm would potentially need to learn to reload the labels in middle of transaction which has its own set of issues.

Comment 6 Panu Matilainen 2011-12-14 13:57:25 UTC
Anyway, conditional nak - we should be able to do something about this specific case, "generic fix" for the rpm <-> selinux interactions is likely to be beyond the scope of rhel-6 however.

Comment 9 Panu Matilainen 2012-02-14 05:43:25 UTC
*** Bug 784289 has been marked as a duplicate of this bug. ***

Comment 10 Stephen Gallagher 2012-02-14 12:25:00 UTC
(In reply to comment #5)
> What kind of selinux policy change are we talking about here exactly? If it
> involves new/changed labels, ordering is not enough to do anything about this
> as rpm uses the context label definitions that existed when the transaction
> started. So in addition to somehow ordering selinux first, rpm would
> potentially need to learn to reload the labels in middle of transaction which
> has its own set of issues.

In our particular case, it is only the addition of new rules on existing labels. So the ordering would be sufficient.

It does sound like OrderWithRequires: is the right answer here, but as discussed above it isn't available yet on RHEL 6. So what is the right course of action here? Breaking upgrades on SSSD is a very serious issue.

Comment 11 Stephen Gallagher 2012-02-28 18:46:57 UTC
I'm still looking to hear how we can handle this in SSSD for 6.3.

Comment 12 RHEL Product and Program Management 2012-05-03 05:17:32 UTC
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 13 Stephen Gallagher 2012-05-11 12:08:22 UTC
*** Bug 820759 has been marked as a duplicate of this bug. ***

Comment 19 RHEL Product and Program Management 2012-12-14 08:12:58 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 20 Scott Poore 2013-01-28 15:50:05 UTC
*** Bug 905104 has been marked as a duplicate of this bug. ***

Comment 22 Florian Festi 2013-04-08 07:32:52 UTC
Devel-ack for backporting the OrderWithRequires feature. The differences in the code base are not so severe as it first looked like.

OTOH NACK for considering conflicts for ordering. This is a way to intrusive change with unforeseeable consequences.

Comment 23 RHEL Product and Program Management 2013-07-25 21:11:22 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 25 RHEL Product and Program Management 2013-10-14 05:09:31 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 27 Ľuboš Kardoš 2015-03-04 12:49:32 UTC
Devel-ack for backporting the OrderWithRequires feature.

Comment 30 Karel Srot 2015-03-16 11:00:09 UTC
Pasting here the feature description, just for the record.

OrderWithRequires

Packages can supply extra transaction ordering hints via new OrderWithRequires tag. This follows Requires tag syntax, but does not generate actual dependencies. Only if the involved packages are present in the same transaction, the ordering hints are treated as if they were Requires when calculating the transaction order.

Comment 34 Ľuboš Kardoš 2015-03-19 20:01:04 UTC
Fixed in rpm-4.8.0-46.el6.

Comment 37 errata-xmlrpc 2015-07-22 07:01:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1452.html


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