Bug 1408508 - If Advisory exists in multiple repos yum only uses one of the package lists
Summary: If Advisory exists in multiple repos yum only uses one of the package lists
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Pulp
Version: 6.2.6
Hardware: Unspecified
OS: Unspecified
high
high vote
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: jcallaha
URL:
Whiteboard:
: 1445091 (view as bug list)
Depends On:
Blocks: 1353215
TreeView+ depends on / blocked
 
Reported: 2016-12-23 23:07 UTC by nrhuff
Modified: 2019-06-13 21:25 UTC (History)
27 users (show)

Fixed In Version: pulp-rpm-2.8.7.14-2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1459336 (view as bug list)
Environment:
Last Closed: 2017-06-20 17:53:27 UTC
Target Upstream Version:


Attachments (Terms of Use)
errata repos (54.49 KB, image/png)
2017-06-09 23:05 UTC, jcallaha
no flags Details


Links
System ID Priority Status Summary Last Updated
Pulp Redmine 2227 Normal CLOSED - CURRENTRELEASE Only first pkglist is synced for erratum even if multiple are present 2017-06-06 21:37:41 UTC
Pulp Redmine 2559 High CLOSED - CURRENTRELEASE Empty pkglist for the erratum may be generated which may cause yum not to find applicable packages 2017-04-12 14:34:09 UTC
Pulp Redmine 2560 Normal CLOSED - CURRENTRELEASE Non-unique collection names in erratum pkglists causes yum not to show all packages 2017-06-06 11:37:06 UTC
Pulp Redmine 2623 High CLOSED - CURRENTRELEASE Errata publish performace degradation 2017-06-06 11:36:36 UTC
Red Hat Bugzilla 1445091 'high' 'CLOSED' 'yum list-sec and yum update-minimal do not show or install all available security updates when RHEL 6 Optional repo is ... 2019-11-12 16:12:42 UTC
Red Hat Knowledge Base (Solution) 3087631 None None None 2017-06-20 15:15:57 UTC

Internal Links: 1445091

Description nrhuff 2016-12-23 23:07:48 UTC
Description of problem:
If you have 2 repositories that have the same advisory, but different package lists yum updateinfo will only use one of the package lists.  This results in yum not thinking an errata is relevant when it is.

Version-Release number of selected component (if applicable):
RHEL 7.3

How reproducible:
Always

Steps to Reproduce:
1. Add rhel-7-server-rpms repo
2. Add rhel-7-server-optional-rpms repo
3. Have a package that has parts in both.  In my case sudo.
4. Run yum updateinfo list sudo

Actual results:

No errata listed

Expected results:

Expect errata list to include RHSA-2016:2872

Additional info:

yum updateinfo list sudo-devel returns

  RHBA-2015:0515 bugfix        sudo-devel-1.8.6p7-13.el7.i686
  RHBA-2015:2424 bugfix        sudo-devel-1.8.6p7-16.el7.i686
  RHBA-2016:0548 bugfix        sudo-devel-1.8.6p7-17.el7_2.i686
  RHSA-2016:2593 Low/Sec.      sudo-devel-1.8.6p7-20.el7.i686
  RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.i686

sudo-devel package comes from the hel-7-server-optional-rpms
sudo comes from rhel-7-server-rpms

The updateinfo.xml for the repos both contain RHSA-2016:2872, but the package list only includes the package for that repo.  Yum only appears to be using the entry from the rhel-7-server-optional-rpms repository.

Comment 2 Karel Srot 2017-01-03 13:54:27 UTC
Hello,
we have addressed few related issues in RHEL-7.3. Are you running the latest yum package (yum-3.4.3-150.el7.noarch)?

Comment 3 nrhuff 2017-01-03 16:22:54 UTC
Yes yum version is

yum-3.4.3-150.el7.noarch

Comment 4 Eva Mrakova 2017-01-04 08:39:15 UTC
(In reply to nrhuff from comment #0)

Hi nrhuff,

do you expect that
# yum updateinfo list sudo
will return
RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.i686
?

It is not expected to do so, no matter that sudo-devel is a sub-package of sudo.
You should run 
# yum updateinfo list sudo*
instead.

Comment 5 Karel Srot 2017-01-04 09:44:40 UTC
These are the results on my RHEL-7.3 system:

# rpm -qa sudo\*
sudo-1.8.6p7-20.el7.x86_64
sudo-devel-1.8.6p7-20.el7.x86_64

# yum updateinfo list
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64
RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.x86_64
updateinfo list done

# yum updateinfo list sudo
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64
updateinfo list done

# yum updateinfo list sudo-devel
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.x86_64
updateinfo list done

# yum updateinfo list sudo\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64
RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.x86_64
updateinfo list done

The above seem correct to me.

Comment 6 nrhuff 2017-01-04 18:00:19 UTC
I don't have sudo-devel installed

# rpm -qa sudo\*
sudo-1.8.6p7-20.el7.x86_64

I would expect that 'yum update info list sudo' should return RHSA-2016:2872 since the package list contains sudo-1.8.6p7-21.el7_3.x86_64.rpm.

When I run yum updateinfo sudo I get

# yum updateinfo sudo
Loaded plugins: package_upload, priorities, product-id, search-disabled-repos,
              : subscription-manager
AHC_AHC_RHEL_7_AHC_x86_64                                | 2.1 kB     00:00
AHC_EPEL_RHEL_7_EPEL_x86_64                              | 2.1 kB     00:00
AHC_Zabbix_RHEL_7_Zabbix_2_4_x86_64                      | 2.1 kB     00:00
rhel-7-server-optional-rpms/x86_64                       | 2.0 kB     00:00
rhel-7-server-rpms/x86_64                                | 2.0 kB     00:00
rhel-7-server-satellite-tools-6.2-rpms/x86_64            | 2.1 kB     00:00
updateinfo info done

# yum updateinfo sudo\*
Loaded plugins: package_upload, priorities, product-id, search-disabled-repos,
              : subscription-manager
AHC_AHC_RHEL_7_AHC_x86_64                                | 2.1 kB     00:00
AHC_EPEL_RHEL_7_EPEL_x86_64                              | 2.1 kB     00:00
AHC_Zabbix_RHEL_7_Zabbix_2_4_x86_64                      | 2.1 kB     00:00
rhel-7-server-optional-rpms/x86_64                       | 2.0 kB     00:00
rhel-7-server-rpms/x86_64                                | 2.0 kB     00:00
rhel-7-server-satellite-tools-6.2-rpms/x86_64            | 2.1 kB     00:00
updateinfo info done

If I run 'yum update --security' I get
 --> sudo-1.8.6p7-21.el7_3.x86_64 from rhel-7-server-rpms removed (updateinfo)

Comment 7 Michal Domonkos 2017-01-10 19:53:16 UTC
Even without sudo-devel, this is not an issue for me either.

# rpm -qa sudo\*
sudo-1.8.6p7-20.el7.x86_64

# yum updateinfo list sudo\*
Loaded plugins: product-id, search-disabled-repos, subscription-manager
RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64
updateinfo list done

(In reply to nrhuff from comment #6)
> If I run 'yum update --security' I get
>  --> sudo-1.8.6p7-21.el7_3.x86_64 from rhel-7-server-rpms removed
> (updateinfo)

This is weird and shouldn't really happen.  Sadly, there's no relevant debugging output to be enabled for remove_txmbrs() that's responsible for this, so could you please:

1) attach the respective updateinfo files from /var/cache/yum for both rhel-7-server-rpms and rhel-7-server-optional-rpms and

2) try running
  # yum --noplugins --disablerepo=* --enablerepo=rhel-7\* updateinfo sudo

Thanks!

Comment 8 Michal Domonkos 2017-01-11 12:35:59 UTC
(In reply to Michal Domonkos from comment #7)
> 1) attach the respective updateinfo files from /var/cache/yum for both
> rhel-7-server-rpms and rhel-7-server-optional-rpms and

Please disregard the above part and don't attach the updateinfo files directly to this BZ.  I didn't realize they contain RHEL errata information that shouldn't be redistributed:
https://access.redhat.com/help/terms/

If you still experience the issue even after trying step 2), please consider escalating this bug through your support representative.  They will also help you share these files securely with us.

Comment 9 nrhuff 2017-01-11 17:53:36 UTC
# yum --noplugins --disablerepo=* --enablerepo=rhel-7\* updateinfo sudo
rhel-7-server-optional-rpms/x86_64                                      | 2.0 kB  00:00:00     
rhel-7-server-rpms/x86_64                                               | 2.0 kB  00:00:00     
rhel-7-server-satellite-tools-6.2-rpms/x86_64                           | 2.1 kB  00:00:00     
updateinfo info done


If I disable the optional repo I get what I would expect.

# yum --noplugins --disablerepo=rhel-7-server-optional-rpms updateinfo sudo
AHC_AHC_RHEL_7_AHC_x86_64                                               | 2.1 kB  00:00:00     
AHC_EPEL_RHEL_7_EPEL_x86_64                                             | 2.1 kB  00:00:00     
AHC_Zabbix_RHEL_7_Zabbix_2_4_x86_64                                     | 2.1 kB  00:00:00     
mysql_ent                                                               | 2.1 kB  00:00:00     
rhel-7-server-rpms/x86_64                                               | 2.0 kB  00:00:00     
rhel-7-server-satellite-tools-6.2-rpms/x86_64                           | 2.1 kB  00:00:00     

===============================================================================
  Moderate: sudo security update
===============================================================================
  Update ID : RHSA-2016:2872
    Release : 0
       Type : security
     Status : final
     Issued : 2016-12-06 09:43:08 UTC
    Updated : 2016-12-06 09:43:09 UTC       Bugs : 1372830 - CVE-2016-7032 sudo: noexec bypass via system() and popen()
            : 1384982 - CVE-2016-7076 sudo: noexec bypass via wordexp()
       CVEs : CVE-2016-7032
            : CVE-2016-7076
Description : The sudo packages contain the sudo utility which allows system
            : administrators to provide certain users with the
            : permission to execute privileged commands, which
            : are used for system management purposes, without
            : having to log in as root.
            : 
            : Security Fix(es):
            : 
            : * It was discovered that the sudo noexec
            :   restriction could have been bypassed if
            :   application run via sudo executed system(),
            :   popen(), or wordexp() C library functions with a
            :   user supplied argument. A local user permitted
            :   to run such application via sudo with noexec
            :   restriction could use these flaws to execute
            :   arbitrary commands with elevated privileges.
            :   (CVE-2016-7032, CVE-2016-7076)
            : 
            : These issues were discovered by Florian Weimer
            : (Red Hat).
   Severity : Moderate
updateinfo info done

We are on a self-support license so I don't think I can go through a support rep.

Comment 10 nrhuff 2017-01-11 21:12:11 UTC
It appears this is an issue with the way that Satellite, at least as of version 6.2.6, is generating the updateinfo.xml file.  The updateinfo coming from the main RedHat subscription manager works as I would expect.  The updateinfo files coming from satellite are slightly different and cause the issue I am seeing.

Comment 11 Michal Domonkos 2017-01-18 15:53:58 UTC
I've managed to reproduce this by setting up a custom Satellite 6.2 instance.  The issue really is in the way updateinfo.xml files are generated by Satellite.  The same files taken directly from CDN are fine.

The way yum handles advisories spanning across multiple repos is by merging their <pkglist> elements by <collection><name>  It assumes these names don't overlap between the repos, though, so if it encounters such an overlap, the first version found is used and the second is discarded.

Now, Satellite 6.2 serves exactly such updateinfo files.  For example, for RHSA-2016:2872, the rhel-7-server-optional-rpms repo contains (probably by an accident) an extra <pkglist> with a <collection><name> being the same as in its rhel-7-server-rpms counterpart, but doesn't actually contain any packages.  So if yum reads the -optional repo first, it ignores the same definition in the non-optional repo later on, meaning the internal structure for this advisory won't contain the sudo package at all and yum will fail to match anything against "yum updateinfo sudo" (unless you disable the -optional repo just like the reporter showed in Comment 9).

While we could simply fix the merging logic in yum to ignore an empty <collection/> to make this work, this looks more like a bug in Satellite so I'm reassigning it.

Comment 13 nrhuff 2017-01-18 16:23:59 UTC
I did end up opening a support case against Satellite for this.  The Case ID is 01771450.

Comment 14 Michael Hrivnak 2017-01-18 16:53:51 UTC
Tanya, I think this is probably already fixed by the work you did. Is that right?

https://pulp.plan.io/issues/2227
https://github.com/pulp/pulp_rpm/pull/976

Comment 15 Tanya Tereshchenko 2017-01-18 18:21:37 UTC
Michael, 
I think this issue is different.

Michal,
I agree that the generation for the updateinfo.xml may be more sane in terms of not creating empty pkglists. But maybe a merging logic on the yum side is worth improving as well, consider the following scenario:

Users can not only mirror repositories but modify them as well.

1. Say, there is a repo A. It consists of 2 packages (P1 and P2) and the advisory ADV which pkglist has 2 packages (P1, P2) in it.

2. User creates two stripped copies of the repo A, so he/she will be able to publish packages P1 and P2 separately in different repositories:
 - repo A1 contain only package P1 + advisory ADV which pkglist will have only P1 now (because all the packages listed in the advisory should be available in the repository),
 - repo A2 contain only package P2 + advisory ADV which pkglist will have only P2 now.

3. If for some reason one will configure both repositories A1 and A2 then one of the packages P1 or P2  won't be found by yum according to the logic you described.

I am not sure if it is possible to guarantee unique collection names across the repositories. Keep in mind that user ca upload advisory of his own with the conflicting names.

What do you think about merging collections with the same name instead of choosing only one? This will solve both empty collection case and the scenario I described above. Any issues or downsides for such approach?

Comment 16 Michael Hrivnak 2017-01-20 18:43:26 UTC
Merging sounds like it would be reasonable.

But what if we assume that given repo A with advisory ADV, that all packages in the package list must stay with the advisory in order for it to be considered correct?

Ultimately, the advisory exists so a user can have confidence that "I installed ADV, and therefore my system is no longer affected by the problem it solves." If someone only installed a subset of the packages that were originally published with it, they would incorrectly believe they had resolved a problem. We want users to keep all of the listed packages with an advisory.

I'm not sure what katello enforces, but I think the above is true in terms of what behavior is correct.

Comment 17 Michal Domonkos 2017-01-24 15:07:23 UTC
Hey Tanya,

Thanks for the feeback!  Comments inline:

(In reply to Tanya Tereshchenko from comment #15)
> 2. User creates two stripped copies of the repo A, so he/she will be able to
> publish packages P1 and P2 separately in different repositories:
>  - repo A1 contain only package P1 + advisory ADV which pkglist will have
> only P1 now (because all the packages listed in the advisory should be
> available in the repository),
>  - repo A2 contain only package P2 + advisory ADV which pkglist will have
> only P2 now.

Would Satellite rename the <collection>s of ADV in repo A1 and A2 in the updateinfo files automatically (e.g. to the repo A1 and A2 names, respectively, just like we do that on CDN) or would it just leave them intact (e.g. "rhel-7-server-rpms__7Server__x86_64" and "rhel-7-server-optional-rpms__7Server__x86_64")?

> 3. If for some reason one will configure both repositories A1 and A2 then
> one of the packages P1 or P2  won't be found by yum according to the logic
> you described.

This depends on the question above.  In the former case, yum would combine the two update notices from repo A1 and A2 correctly, seeing both P1 and P2.  In the latter case, yum wouldn't find one of them, like you said.

> I am not sure if it is possible to guarantee unique collection names across
> the repositories. Keep in mind that user ca upload advisory of his own with
> the conflicting names.

According to this comment:
  https://bugzilla.redhat.com/show_bug.cgi?id=1302663#c35
it seems that the collections are always named after the repo they're defined in, which is exactly what yum assumes as well.

> What do you think about merging collections with the same name instead of
> choosing only one? This will solve both empty collection case and the
> scenario I described above. Any issues or downsides for such approach?

Doing the collection merging in yum would be pretty easy, no downsides come to mind.  If it turns out the scenario you described is really a valid one (see my questions inline), we'll happily implement it in yum.

Thanks!

Comment 18 Tanya Tereshchenko 2017-02-02 20:45:33 UTC
Thanks Michal! 

Sorry for the late response (DevConf + DevConf flu afterwards).

Pulp (the component we discuss in this BZ) does not modify collection names anyhow right now. Thanks for pointing out to the relevant BZ, though it was a patch and discussion of the RCM's Pulp which is different from the upstream.

To solve the current issue it would be enough not to generate empty pkglists which does not make any sense to do anyway. I will add upstream issue to this BZ.

As for the collection names. It sounds reasonable to have them constructed in the described way especially if yum relies on that. At the same time I think it should not be solved in the scope of this BZ.
I will file an issue upstream and we'll discuss it there. We will reach you in case of any questions

Thanks!

Comment 19 pulp-infra@redhat.com 2017-02-02 22:01:24 UTC
The Pulp upstream bug status is at NEW. Updating the external tracker on this bug.

Comment 20 pulp-infra@redhat.com 2017-02-02 22:01:28 UTC
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.

Comment 21 pulp-infra@redhat.com 2017-02-03 16:31:22 UTC
The Pulp upstream bug priority is at High. Updating the external tracker on this bug.

Comment 22 pulp-infra@redhat.com 2017-02-07 15:31:39 UTC
The Pulp upstream bug status is at ASSIGNED. Updating the external tracker on this bug.

Comment 23 pulp-infra@redhat.com 2017-02-17 01:02:06 UTC
The Pulp upstream bug status is at POST. Updating the external tracker on this bug.

Comment 24 pulp-infra@redhat.com 2017-02-23 23:31:42 UTC
The Pulp upstream bug status is at MODIFIED. Updating the external tracker on this bug.

Comment 25 pulp-infra@redhat.com 2017-02-24 00:01:40 UTC
All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST.

Comment 26 Dennis Kliban 2017-03-14 02:25:39 UTC
The Pulp upstream bug status is at ON_QA. Updating the external tracker on this bug.

Comment 28 Pavel Moravec 2017-04-11 10:29:37 UTC
Just a question when the upstream patch helps or not.

Am I right the fix removes the pkglists that are empty (instead of populating them)? If so, is that a proper solution?

Assume the pkglist for some errata is empty in repo A because the pkglist is populated in repo B. This is done on a pulp-server (Satellite or Capsule) during createrepo call. After the fix, pkglist in repo A will be removed.

What happens if I then register a client machine and enable just repo A but _not_ repo B? Wont it get incomplete metadata (not having pkglist for some errata that is populated in not-enabled repo B)?

Comment 29 Tanya Tereshchenko 2017-04-11 12:15:18 UTC
Pkglists are not empty and won't be removed or anyhow stripped in DB, no changes there. 
What changed is the way updateinfo.xml is generated, so after applying a fix no empty pkglists will be generated in updateinfo.xml.

I am not sure I get your question 100% but there is no impact on pkglist generation between different repositories. If an erratum belongs to both repo A and repo B, then pkglists for both repos will be generated separately and they may differ (packages for RHEL6 and for RHEL7, for example).

Hope that helps.

Comment 30 pulp-infra@redhat.com 2017-04-12 14:34:10 UTC
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.

Comment 32 pulp-infra@redhat.com 2017-06-06 11:36:37 UTC
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.

Comment 33 pulp-infra@redhat.com 2017-06-06 11:36:45 UTC
The Pulp upstream bug priority is at High. Updating the external tracker on this bug.

Comment 34 pulp-infra@redhat.com 2017-06-06 11:37:07 UTC
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.

Comment 35 pulp-infra@redhat.com 2017-06-06 11:37:13 UTC
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.

Comment 36 pulp-infra@redhat.com 2017-06-06 20:36:49 UTC
All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST.

Comment 37 pulp-infra@redhat.com 2017-06-06 21:37:42 UTC
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.

Comment 38 pulp-infra@redhat.com 2017-06-06 21:37:49 UTC
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.

Comment 44 jcallaha 2017-06-09 23:03:58 UTC
Verified in Satellite 6.2.10 Snap 4

I followed the instructions detailed in the setup. See attached screenshot for the repositories which all four of these errata were found in. 

-bash-4.2# yum updateinfo list
Loaded plugins: package_upload, product-id, search-disabled-repos, subscription-manager
Default_Organization_z-stream_7capsule                                                                                                                                 | 2.1 kB  00:00:00     
rhel-7-server-optional-rpms/7Server/x86_64                                                                                                                             | 2.0 kB  00:00:00     
RHSA-2014:1912 Moderate/Sec. rubygem-rake-0.9.6-22.el7_0.noarch
RHBA-2015:0594 bugfix        rubygem-rake-0.9.6-24.el7.noarch
RHBA-2015:1158 bugfix        rubygem-rake-0.9.6-25.el7_1.noarch
RHEA-2016:2422 enhancement   rubygem-rake-0.9.6-29.el7.noarch
updateinfo list done


for reference, here are the repos enabled on this system.

-bash-4.2# subscription-manager repos --list-enabled
+----------------------------------------------------------+
    Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID:   Default_Organization_z-stream_7capsule
Repo Name: 7capsule
Repo URL:  https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/custom/z-stream/7capsule
Enabled:   1

Repo ID:   rhel-7-server-rh-common-rpms
Repo Name: Red Hat Enterprise Linux 7 Server - RH Common (RPMs)
Repo URL:  https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/rh-common/os
Enabled:   1

Repo ID:   rhel-7-server-optional-rpms
Repo Name: Red Hat Enterprise Linux 7 Server - Optional (RPMs)
Repo URL:  https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/optional/os
Enabled:   1

Repo ID:   rhel-server-rhscl-7-rpms
Repo Name: Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server
Repo URL:  https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/rhscl/1/os
Enabled:   1

Repo ID:   rhel-7-server-rpms
Repo Name: Red Hat Enterprise Linux 7 Server (RPMs)
Repo URL:  https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/os
Enabled:   1

Repo ID:   rhel-7-server-satellite-capsule-6.2-rpms
Repo Name: Red Hat Satellite Capsule 6.2 (for RHEL 7 Server) (RPMs)
Repo URL:  https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/7Server/$basearch/sat-capsule/6.2/os
Enabled:   1

Comment 45 jcallaha 2017-06-09 23:05:01 UTC
Created attachment 1286558 [details]
errata repos

Comment 52 Bryan Kearney 2017-06-20 17:53:27 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://access.redhat.com/errata/RHBA-2017:1553

Comment 53 Chris Williams 2017-08-16 15:46:47 UTC
*** Bug 1445091 has been marked as a duplicate of this bug. ***


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