Read this before deleting a Satellite manifest in the customer portal (for disconnected satellites)

Latest response

Good thing to remember... Save yourself some work - If you have disconnected 6.2 satellites (not sure if this affects 6.3), and create manifests in the customer portal... Keep (do not delete) the manifest in the customer portal. The not immediately clear warning that comes up really translates into English that if you delete it (in the Customer Portal) there's no chance you will ever be able to accept a new satellite manifest without first deleting (on your disconnected satellite) the manifest and go through the pain of reassigning entitlements to all hosts, activation keys and so forth.

I'm hoping that someone else is saved from this pain we discovered as a result of this. Yes it's documented, it sadly is not clear until after the fact and have to deal with the aftermath.

That being said in retrospect, it's not as terrible as I had thought before going through the resulting path needed to delete the manifest and then reassign entitlements.

Just for reference, Here's what Red Hat mentioned... added in retrospect, it turned out not as bad for my location. Now depending on the sheer number of systems you have, it may be a tad more difficult to determine. Our systems have a mostly straightforward naming convention that in most cases is easy to identify what is a server and what is a workstation. So I was able to en-masse assign entitlements using the Content Host view (where hosts are on the left), and then take a "Bulk Action" to assign subscriptions. Before that, I assigned the necessary subscriptions first to the satellite server, ensuring the "satellite" entitlement was assigned.

When uploading a manifest over the top of a different 
manifest, the error that you encountered is seen. When 
you upload a new version of the same manifest over the 
top of a current manifest, you do not get the error. This is 
because each manifest has a uuid that is listed on the 
portal. The satellite uses this uuid to communicate back to 
the portal to pull the updated list of entitlements that were 
added/removed in the event of a refresh.

If you wish to upload a new manifest, then you are required 
to delete the current manifest, since the uuid's are different.

In the host configuration guide, here is a note[1]:

'Manifests should not be deleted. If you delete the manifest 
from the Red Hat Customer Portal or in the Satellite Web 
UI it will unregister all of your content hosts.'

[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_subscriptions#Managing_Subscriptions-Updating_a_Manifest

When deleting the manifest from the customer portal, this 
warning is presented:

"Are you sure you want to delete this subscription 
management application?
This action will remove all subscriptions from this 
subscription management application and permanently 
delete the subscription management application. You 
cannot undo this action."

That said, you'll need to delete the manifest from the 
satellite webUI before being able to upload a new manifest.

I cannot promise that the re-registrations and re-entitlements 
will be automatic, but you are welcome to wait 24 hours 
and see if this happens.

Hoping this post helps someone else avoid the pain I apparently inflicted on myself - and now I know.

Original post turns out the aftermath is not as bad as I thought, see preceding notes

Bottom line, I'm experiencing issues uploading and getting our disconnected satellites to upload/accept our recently renewed manifests, our satellites had expired while had our support renewed (lag of a couple weeks). I do have a priority ticket with Red Hat #02049342 but I'm curious if anyone else has faced this issue and found some resolution - I'd appreciate any help.

I have several RH Satellites, 2 of which are "disconnected" satellites at version 6.2.11.

We just had the majority of our entitlements renewed for support, so I'm going through what I go through each year, re-uploading our RH Satellite manifests.

So yes, I made sure to select the proper version in the satellite manifest/certificate creation tool. I also deleted previous manifests/certificates from the web portal (not in our disconnected satellites, but in the Red Hat Customer Portal). I've done this before.

I also made sure the proper set of entitlements is assigned, the satellite itself, and the appropriate number of entitlements for RHEL server/workstation and oracle things to cover all the systems. so there is no disparity with the number of entitlements supported. There's room for growth.

I made sure to be in the proper context (organizational, location), we only have one organization. And we just use "default location".

I had at one point considered deleting the manifest on my disconnected satellite, but a warning in the web interface pops up with this set of not-good consequences:


| "Delete Manifest"
| Are you sure you want to delete the manifest?
|
| Note: Deleting a subscription manifest is STRONGLY discouraged. Deleting a manifest will:
|
| > Delete all subscriptions that are attached to running hosts.
| > Delete all subscriptions attached to activation keys.
| > Disable Red Hat Insights
| > Require you to upload the subscription-manifest and re-attach subscriptions to hosts and activation keys
|
| This action should only be taken in extreme circumstances or for debugging purposes.
|___________________________________
That warning seems "Pretty Strong(TM)"

If I really had to, like no other option, I could delete the manifest on my disconnected satellites, but I've never had to do that before (we go through this every year, and we've been using RH Satellite 6.2.x for a while now). Based on the pop-up warning I typed out above, it seems like a considerable amount of work to manually reassign all entitlements to systems, activation keys etc. I could do that, but I've never had to do that before, and it seems like a lot of work that if possible ought to be avoided if a better method could be used.

Appreciate any assistance

Responses

Oh, the solution at https://access.redhat.com/solutions/1257053 is outdated and by it's own qualifications, not applicable to our version of Red Hat satellite. That's for RH satellites before version 6.2.4 and not anything above 6.2.4. Our version for the affected RH satellites is 6.2.11

Also, the error I received upon attempting to upload the manifest is:

"error importing manifest. owner has already imported from another subscription management application"

I've tried the Satellite web UI to upload it, then I also per Red Hat's suggestion, tried the hammer command method:

# [root@oursatellite /var/tmp ] # hammer subscription upload --file /var/tmp/<manifest_file>.zip --organization="thosepeople"
Error: Owner has already imported from another subscription management application

I checked the active tasks, and found these errors relating to the failed upload of the manifests:

"Errors" tab within tasks shows some possible relevant errors such as
/opt/theforeman/tfm/root/user/share/gems/gems/concurrent-ruby-1.0.0/lib/concurrent/executor/ruby_thread_post_executor.rb:304:in 'block in create_worker'
and a few lines above, something similar but says 
/opt/theforeman/tfm/root/user/share/gems/gems/concurrent-ruby-1.0.0/lib/concurrent/executor/ruby_thread_post_executorrb:322:in 'block (3 levels) in create worker'

It was suggested to refresh the manifest on my disconnected satellite (sigh) and I did, however, since I can't upload the most current manifest, all that did was refresh the expired manifest, and did not resolve the issue.

Also, in the off-chance there was something Terribly Wrong(TM) with the manifest I initially created, I deleted it, recreated a new manifest and this produced the same issues...

So the moral of the story, know what manifest goes with whatever disconnected satellite you have. Don't delete the manifest in the Customer Portal because the warning is understated.

It helps if you have already established some naming convention that will allow you to to discern what systems are servers or workstations just by looking at the hostnames, and selecting a "bulk action" when in a specific WebUI content view (hosts at the left), and assigning subscriptions with that bulk action.

Your manifest is trackable via the UUID (seen via the rct cat-manifest command.

Also, the warning that the portal gives today is quite unclear.

In the new Subscription Allocations page, we give a much stronger warning.

Deleting a distributor/subscription management application/subscription allocation that is being used on a connected Satellite is EXTREMELY grave, as it places all of the entitlement certificates of the revocation list, effectively breaking the ability of the Satellite to sync from the portal.

For a disconnected Satellite, the above isn't that bad (since you don't sync from the CDN), but it does make the process of importing a new manifest painful.

Satellite knows which manifest it was originally set up with (see the UUID I spoke of above), and it will only let you upload updated versions of the same manifest.

The error message of "error importing manifest. owner has already imported from another subscription management application", should really be: hey dude, this manifest's UUID doesn't match the one you originally used.

Thanks Rich for the extra detail there.

Mercifully, I found today that the reattachment of the entitlements on my disconnected satellites, was not nearly as bad as it could have been. I like your paraphrase of the error message, seems proper from what I've experienced. I'll keep the new subscriptions allocation link for reference, thank you.

Rich, is this same scenario applicable for Satellite 6.3 as well?

Thanks,

RJ

I think I have the same issue. or very similar. It looks like someone has deleted the manifest definition for our satellite. Somewhere around the time of subscription renewal... I've re-created the manifest in the portal... I take it I actually have to delete the manifest from my sat6 (6.3) and import the new one now to get this (repo syn) working again (SInce they all stopped syncing 27 days ago, which co-incides quite well with the subscription renewal).

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.