Hide Forgot
Currently bootstrap.py only checks for a .pem file in rhel 5 systems. If the purpose of the script is meant to make migration from satellite 5 to satellite 6 easier, it would be better to allow for the possibility that other versions of rhel (albeit uncommon) may also not have a .pem file. This particular issue was noticed in rhel 6.6 and lower releases. We were unable to determine why a .pem file was not found in these particular systems - but it would be unreasonable to investigate this in every system if it were a problem in larger migrations from satellite 5 to satellite 6.
A system that is RHEL6 should always have a .pem file unless it was - built with 6.0 (which didn't include subscription-manager on the install media) - the end user deleted it. RHEL7 systems should /always/ have a .pem. Newer versions of subscription-manager respect the presence of /etc/pki/product-default, which provides the required product certificate as part of the redhat-release-* package. rpm -qf /etc/pki/product-default/69.pem redhat-release-server-7.2-9.el7.x86_64 I could imagine that we: - check the presence of a product certificate - if product certificate isn't found either - fail gracefully and tell the user to fix it OR - (attempt to update the redhat-release-* package). Would either of those solve your request? I am hesitant on updating the redhat-release-* packages without the user's consent.
(In reply to Paul Dudley from comment #0) > Currently bootstrap.py only checks for a .pem file in rhel 5 systems. If the > purpose of the script is meant to make migration from satellite 5 to > satellite 6 easier, it would be better to allow for the possibility that > other versions of rhel (albeit uncommon) may also not have a .pem file. > > This particular issue was noticed in rhel 6.6 and lower releases. We were > unable to determine why a .pem file was not found in these particular > systems - but it would be unreasonable to investigate this in every system > if it were a problem in larger migrations from satellite 5 to satellite 6. To clarify the behavior, bootstrap explicitly has to check for the presence of a product certificate in RHEL5 because the version of rhn-classic-migrate-to-rhsm doesn't support activation keys, so we have special code that approximates the functionality. For a RHEL6 or RHEL7 system, we assume that if a system has a systemid (/etc/sysconfig/rhn/systemid) AND rhn-channel -l can list channels that it is properly subscribed to RHN Classic or Satellite 5 & we call rhn-classic-migrate-to-rhsm, which should always place a product certificate on the system. If not, I'd like to investigate it and raise a BZ on rhn-migrate-to-rhsm if needed. I am curious as to the setup that led to this client not receiving a product certificate, as I'd rather not carry code in bootstrap.py that rhn-classic-migrate-to-rhsm should be doing. That being said, the use case we /dont/ handle is a client that /isnt/ registered to RHN or Satellite 5 that doesn't have a product cert at all. And we'll have to handle that for all releases/variants of RHEL (Server, ComputeNode, Workstation, etc), so we'll keep this BZ as we'll need to implement more robust support.
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Rich Jerrido or Bryan Kearney. Thank you.