Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Inconsistency in repo metadata expiration times causes invalid false positives on Satellite when updating hosts.
Version-Release number of selected component (if applicable):
candlepin-4.1.15-1.el8sat.noarch
satellite-6.12.0-4.el8sat.noarch
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Satellite clients are likely to miss updates on patching because of recently updated content views and clients still holding old repodata they still consider to be valid.
Expected results:
Satellite client's metadata_expire value should default to "1" and should be a customizable time in seconds on the content page of the Satellite settings for any user that wishes to set the time to anything else.
Additional info:
from satellite 6.12 fresh install:
[root@bombsat612 ~]# sudo -u postgres psql -d candlepin -c "select count(metadataexpire) from cp2_content where metadataexpire != 1;"
could not change directory to "/root": Permission denied
count
-------
5331
(1 row)
[root@bombsat612 ~]# sudo -u postgres psql -d candlepin -c "select count(metadataexpire) from cp2_content where metadataexpire = 1;"
could not change directory to "/root": Permission denied
count
-------
3512
(1 row)
[root@bombsat612 ~]# sudo -u postgres psql -d candlepin -c "select distinct(metadataexpire) from cp2_content;"
could not change directory to "/root": Permission denied
metadataexpire
----------------
1
86400
(2 rows)
Here are 2 ruby functions where we set the time (i believe if the product is not set by default):
/usr/share/gems/gems/katello-4.5.0.20/app/lib/actions/candlepin/product/content_create.rb:24: metadataExpire: 1,
/usr/share/gems/gems/katello-4.5.0.20/app/lib/actions/candlepin/product/content_update.rb:28: metadataExpire: 1,
Looking at the manifest on the 6.12 satellite and comparing with another from 2022:
tasander at xbox in /t/e/products
↪ for i in $(ls -1);cat $i | jq | grep metadataExpiration ; end | sort | uniq -c
8018 "metadataExpiration": 86400,
8018 "metadataExpiration": 86400,
[root@bombsat610 products]# for i in $(ls -1); do cat $i | json_reformat | grep metadataExpiration ; done | sort | uniq -c
1310 "metadataExpiration": 86400,
4 "metadataExpiration": 86401,
4 "metadataExpiration": 86402,
After discussion with Candlepin team and rjerrido, setting component to Candlepin.
For standalone Candlepin, metadataExpire should be getting set to 1 during manifest import.
Comment 9Nikos Moumoulidis
2023-02-27 15:58:35 UTC
A note on this: Once you upgrade to a candlepin version with the fix for this, you will need to refresh your manifest for the metadataexpire value in the database to change
Patrick- I'm not sure. Nikos would know better.. @nmoumoul
Comment 12Nikos Moumoulidis
2023-06-15 07:34:15 UTC
(In reply to Patrick Creech from comment #10)
> Is there a version of candlepin 4.3.z that this fix is in?
This fix should be in all 4.3.z versions (starting with 4.3.0), since it was fixed before the bump to 4.3.
I would recommend using the latest as of now (4.3.6)
Verified.
Tested on Satellite 6.14.0 Snap 6.0
Version: candlepin-4.3.1-1.el8sat.noarch
Steps:
1. Imported manifest, enabled few repositories, created and publish CV, Create AK with this CV
2. Register a client with AK create above and check /etc/yum.repos.d/redhat.repo for metadata_expire
# cat /etc/yum.repos.d/redhat.repo | grep metadata_expire
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
metadata_expire = 1
3. Also tried checking the candlepin DB for cp2_content table and there's also metadata_expire set 1
# sudo -u postgres psql -d candlepin -c "select distinct(metadataexpire) from cp2_content;"
could not change directory to "/root": Permission denied
metadataexpire
----------------
1
(1 row)
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 (Important: Satellite 6.14 security and bug fix update), 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/RHSA-2023:6818
Description of problem: Inconsistency in repo metadata expiration times causes invalid false positives on Satellite when updating hosts. Version-Release number of selected component (if applicable): candlepin-4.1.15-1.el8sat.noarch satellite-6.12.0-4.el8sat.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Satellite clients are likely to miss updates on patching because of recently updated content views and clients still holding old repodata they still consider to be valid. Expected results: Satellite client's metadata_expire value should default to "1" and should be a customizable time in seconds on the content page of the Satellite settings for any user that wishes to set the time to anything else. Additional info: from satellite 6.12 fresh install: [root@bombsat612 ~]# sudo -u postgres psql -d candlepin -c "select count(metadataexpire) from cp2_content where metadataexpire != 1;" could not change directory to "/root": Permission denied count ------- 5331 (1 row) [root@bombsat612 ~]# sudo -u postgres psql -d candlepin -c "select count(metadataexpire) from cp2_content where metadataexpire = 1;" could not change directory to "/root": Permission denied count ------- 3512 (1 row) [root@bombsat612 ~]# sudo -u postgres psql -d candlepin -c "select distinct(metadataexpire) from cp2_content;" could not change directory to "/root": Permission denied metadataexpire ---------------- 1 86400 (2 rows) Here are 2 ruby functions where we set the time (i believe if the product is not set by default): /usr/share/gems/gems/katello-4.5.0.20/app/lib/actions/candlepin/product/content_create.rb:24: metadataExpire: 1, /usr/share/gems/gems/katello-4.5.0.20/app/lib/actions/candlepin/product/content_update.rb:28: metadataExpire: 1, Looking at the manifest on the 6.12 satellite and comparing with another from 2022: tasander at xbox in /t/e/products ↪ for i in $(ls -1);cat $i | jq | grep metadataExpiration ; end | sort | uniq -c 8018 "metadataExpiration": 86400, 8018 "metadataExpiration": 86400, [root@bombsat610 products]# for i in $(ls -1); do cat $i | json_reformat | grep metadataExpiration ; done | sort | uniq -c 1310 "metadataExpiration": 86400, 4 "metadataExpiration": 86401, 4 "metadataExpiration": 86402,