When running backup recovery, there was one issue running the restore procedure though, my already-registered client was getting 403's in yum. I think it may be the same symptom as another CRL issue I had earlier, so I'm going to req info from Ivan to see if restoring a several-day old CRL might cause this. https://bugzilla.redhat.com/show_bug.cgi?id=787184 The solution is to create create new CLI command katello admin crl_regen and API method/proxy that calls this in Candlepin. This change will need release note for the BackupRecovery.html chapter: Once recovery is finished and all systems are running, run the following command to regenerate CRL lists. Otherwise, yum clients will be giving 403 errors when connecting to CloudForms.
This bug has no code modified for it, is there any reason it is ON_DEV?
6fa0971 Merge pull request #151 from lzap/crl_regen_821644
Verified using: * candlepin-0.7.8-1.el6cf.noarch * candlepin-selinux-0.7.8-1.el6cf.noarch * candlepin-tomcat6-0.7.8-1.el6cf.noarch * katello-1.1.12-12.el6cf.noarch * katello-all-1.1.12-12.el6cf.noarch * katello-candlepin-cert-key-pair-1.0-1.noarch * katello-certs-tools-1.1.8-1.el6cf.noarch * katello-cli-1.1.8-6.el6cf.noarch * katello-cli-common-1.1.8-6.el6cf.noarch * katello-common-1.1.12-12.el6cf.noarch * katello-configure-1.1.9-6.el6cf.noarch * katello-glue-candlepin-1.1.12-12.el6cf.noarch * katello-glue-pulp-1.1.12-12.el6cf.noarch * katello-qpid-broker-key-pair-1.0-1.noarch * katello-qpid-client-key-pair-1.0-1.noarch * katello-selinux-1.1.1-1.el6cf.noarch * pulp-1.1.12-1.el6cf.noarch * pulp-common-1.1.12-1.el6cf.noarch * pulp-selinux-server-1.1.12-1.el6cf.noarch
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. http://rhn.redhat.com/errata/RHSA-2012-1543.html