Red Hat Satellite 6 will not auto-attach Red Hat Enterprise Linux subscriptions if the activation key contains only custom product subscription

Solution Verified - Updated -

Environment

  • Red Hat Satellite 6

Issue

  • Red Hat Satellite 6 will not auto-attach subscriptions if the activation key contains only custom product subscriptions.

  • If auto-attach is set to yes for an activation key, and there are no subscriptions assigned to the activation key, the Red Hat Satellite auto-attaches to the best fit RHEL subscription from the general pool of subscriptions available to that Organization, even if it's the temporary virtual subscription until virt-who is executed. However, If there are ONLY custom products assigned to the Activation Key for third party products when a Content Host is registered with that Activation Key, it will not attach a Red Hat Enterprise Linux subscription.

Resolution

  • This has been determined to be the correct behaviour. The presence of any subscription whatsoever in the activation key will prevent auto-attach from running at registration time only. It will not stop future manual clicks of the Run auto-attach button from attaching subs, nor will it stop the auto-healing done when subscription-manager checks in.

  • To elicit auto-attach behavior at registration time in the above situation, it is recommended to use two Activation Keys.

  • The first Activation Key would have zero subscriptions attached, but would have auto-attach set to True. The second Activation Key would contain the subscriptions for the custom third-party products.

  • Then registration would specify both keys:

    # subscription-manager register --activationkey key1,key2
    

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

5 Comments

Not finding how to do step 1 in the workaround.

1.) Manually clicking "Run Auto-attach" on the the page for that specific Content Host after the registration WILL successfully auto-attach a Red Hat Enterprise Linux subscription.

Maybe a screenshot or steps on where this is.

This is a lot of excessive hoop jumping to get around a piss poor design in virt-who! If virt-who would monitor the hypervisor (speaking of RHV) and immediately report changes, (i.e. new, moved, and/or removed vms) we wouldn't have stupid problems like this. OR better yet, have a process to query the vm guest as to which host it's running on. There HAS To BE are more timely and affective way. Our problem is NOT that we just have custom product, but that virt-who will NOT report a new guest fast enough.

virt-who doesn't need to report guests immediately. Virtual guests which are registered, which are not reported, WILL get a temporary guest subscription that's valid for up to 1 day (sat6.2 and below) or 7 days(sat6.3 and above) while the host/guest mapping is reconciled. Specifically, in high-volume environments, you do NOT want a real-time feed as virtual machines are moving all the time, and you would effectively DDoS either your virt-management platform or the Satellite with all the API traffic.

You'd want to use multiple keys as a matter of good practice because (in the good ole UNIX model) you'd want things that do 'one thing well' and combine them to achieve desired result.

This is explained in Subscription-manager for the former Red Hat Network User: Part 3 - Understanding virt-who and Subscription-manager for the former Red Hat Network User: Part 9 - A Case Study with activation keys.

NO THEY DON'T. If you'd like to come and watch this happen I'd be glad for you to. We've been fighting this problem for weeks now. When we provision a new node with Ansible on RHV (both on Power and on X86) and register it, it gets NOTHING. NO TEMP. This reliance on a "temp" license doesn't work, if it did we wouldn't have to jump through the hoops of this article would we? And, no, I don't want the "old UNIX model" if I did I wouldn't be screwing around with Satellite. I want things to work like they're advertised, and like the official docs say they're supposed to work, I shouldn't have to open a ticket and have to dig around on Google to find obscure docs in order to do what I was told one thing would do when I paid for it. I've managed AIX for along time now, and you know what? It reports from the OS what Hypervisor it's running on, even in very large, very high volume environments. This enables more dynamic adjustments, monitoring and management. And, you can't get much more "old school" than AIX at this point.
You know something else that could be done? You could monitor the VMs from the RHV-M instead of each Hypervisor, Like with AIX it's all managed from the HMC. From an HMC I can report on nearly every single detail of every LPAR. Cool huh? Also, if virt-who ONLY reported the changes (which it should) even in High volume situations, if Satellite can't hang, then it's not going to hang when all the nodes and the changes over the last hour get reported all at once. I would much rather have the deltas reported in an ongoing incremental basis, than to have a mass dump every hour along with a dependence on a process that apparently doesn't work if you add your own stuff into the mix.

A year on and I have pretty much the same issue. virt-who doesn't make satellite aware when it needs to. Ansible Tower and RHV here as well. In the kickstart post script it does a "subscription-manager register --name="new.server.com" --org='My Org' --activationkey='ak-rhel6-test,ak-autoattach'" but "subscription-manager status" returns insufficient. This means the proceeding yum installs fail. All of them. Useless, just useless. So I have to hack all kinds of work arounds just to make this crap work.

Key difference between Satellite 5 and Satellite 6? Satellite 5 worked. It was also predictable. And stable.