This article was originally published on the Red Hat Customer Portal. The information may no longer be current.
With the introduction of the newer Systems Management tools such as Satellite 6, we introduced a new concept, the Subscription Manifest (which are different from Satellite 5 Entitlement XML certificates), as the means to import Subscriptions into Satellite for the purposes of synchronizing content and attaching subscriptions to systems.
What is a subscription manifest?
A subscription manifest is a digitally signed zip file containing:
- A listing of subscriptions that can be used by an on-premise subscription management tool (such as Red Hat Satellite)
- Various entitlement certificates associated with those subscriptions usable to download content from the Red Hat Content Delivery Network (CDN).
- A listing of Content Sets (directories on the CDN which access is granted to)
- A x.509 certificate used to authenticate with the Red Hat Customer Portal
- This is used by the Red Hat Insights tool to authenticate when uploading telemetry data
- This is used by Red Hat Satellite to authenticate when downloading updated manifests (using the Refresh manifest button in the UI)
Manifests are to Satellite 6 what XML Entitlement certificates were to Satellite 5.
How do I get a subscription manifest?
Subscription manifests can be created/downloaded via the Customer Portal by visiting https://access.redhat.com -> Subscriptions ->
Subscription Management Applications & selecting either
- Register a Subscription Management Application (for Subscription Asset Manager)
- Register a Satellite (for Satellite 5 & Satellite 6) (Note: This page only appears if you have a valid Satellite subscription)
What is a 'Subscription Management Application'
A 'Subscription Management Application', (occasionally called a 'distributor') is effectively a 'bucket of subscriptions' which have being selected for usage with an on-premise subscription management tool, such as Satellite. Thus, any subscription you wish to use with Satellite needs to be added to a Subscription Management Application first. After creating a Subscription Management Application, one needs to create the Subscription Manifest, which is a signed (thus authoritative) copy of what is actually in the bucket. (at time of signature).
The relationship between the two is similar to 'cargo' (Subscription Management Application) versus 'bill of lading' (Subscription Manifest)
How many subscription manifests do I need?
There is a pretty big difference between Satellite 5 and Satellite 6 with regards to the number of certificates / manifests needed.
Satellite 5 requires:
- A single certificate for the Satellite, which provided entitlements for the entire Satellite, which could be divided into logical organizations for systems management.
The upside to this was that a single certificate supported the entire Satellite. The downside was that is was very difficult to support multiple Red Hat Network Accounts. If you have > 1 Red Hat Network Account you wanted to support with Satellite 5, you had two options:
- Purchase a Satellite for each account.
- Work with your Red Hat account team to transfer subscriptions into a singular account for management.
Neither of these were usually ideal.
Summary: Satellite 5 requires one certificate per installation of Satellite 5.
Satellite 6 requires:
- A single manifest for each organization configured on the Satellite.
The upsides to this model is that since each organization maintains completely separate subscriptions, you can:
- create multiple Subscription Management applications (remember: bucket of sub) supporting multiple organizations.
- support multiple Red Hat Network Accounts
Example follows:In the example above, there are two fictitious customers, ACME Corp and Example Corp, who each wish to leverage the same Satellite 6 installation. Their subscriptions are in two distinct Red Hat Network accounts. In this scenario, ACME Corp can allocate any subset of their 60 subscriptions (in this example, they've allocated 30) to a Subscription Management Application, which can be imported in Example Corp's Satellite as a distinct Organization. This allows ACME's system administrators the ability to manage their systems leveraging Satellite 6 completely independently of Example Corp's 3 organizations (R&D, Operations, and Engineering)
Summary : Satellite 6 requires one manifest per organization. Manifests can be issued from any Red Hat Network Account that has Smart Management subscriptions for the systems that will be managed via Satellite 6
Examining a subscription manifest
Now that we've created a subscription manifest and downloaded it, let's take a look at it. As mentioned above, the subscription manifest is a .zip file, which can be extracted to inspect the various metadata files within. However, included in Red Hat Enterprise Linux is the rct command, part of the subscription-manager package, which allows you to introspect manifests.
$ rct cat-manifest My_Manifest.zip +-------------------------------------------+ Manifest +-------------------------------------------+ General: Server: Server Version: 0.9.51.15-1 Date Created: 2016-05-05T18:35:13.818+0000 Creator: candlepin_admin Consumer: Name: My_Manifest UUID: 57641572-27c9-4e98-8713-e6fed967a042 Type: satellite Subscription: Name: Red Hat Enterprise Linux for Virtual Datacenters, Premium Quantity: 50 Created: 2015-08-06T16:51:40.000+0000 Start Date: 2015-08-05T04:00:00.000+0000 End Date: 2016-08-05T03:59:59.000+0000 Service Level: Premium Service Type: L1-L3 Architectures: SKU: RH00001 Contract: [REDACTED] Order: [REDACTED] Account: [REDACTED] Virt Limit: unlimited Requires Virt-who: True Entitlement File: export/entitlements/8a99f9864efa4a57014f03ece4cf40ee.json Certificate File: export/entitlement_certificates/8194328514515623350.pem Certificate Version: 3.2 Provided Products: Content Sets: /content/dist/rhel/server/7/$releasever/$basearch/ceph-tools/1.3/debug /content/dist/rhel/server/7/$releasever/$basearch/ceph-tools/1.3/os /content/dist/rhel/server/7/$releasever/$basearch/ceph-tools/1.3/source/SRPMS /content/dist/rhel/server/7/$releasever/$basearch/debug /content/dist/rhel/server/7/$releasever/$basearch/iso /content/dist/rhel/server/7/$releasever/$basearch/kickstart /content/dist/rhel/server/7/$releasever/$basearch/openstack-tools/7.0/debug /content/dist/rhel/server/7/$releasever/$basearch/openstack-tools/7.0/os /content/dist/rhel/server/7/$releasever/$basearch/openstack-tools/7.0/source/SRPMS /content/dist/rhel/server/7/$releasever/$basearch/optional/debug /content/dist/rhel/server/7/$releasever/$basearch/optional/os /content/dist/rhel/server/7/$releasever/$basearch/optional/source/SRPMS /content/dist/rhel/server/7/$releasever/$basearch/oracle-java/iso /content/dist/rhel/server/7/$releasever/$basearch/oracle-java/os /content/dist/rhel/server/7/$releasever/$basearch/oracle-java/source/SRPMS /content/dist/rhel/server/7/$releasever/$basearch/os /content/dist/rhel/server/7/$releasever/$basearch/rh-common/debug <--OUTPUT SNIPPED FOR BREVITY --> Subscription: Name: Red Hat Enterprise Linux Server, Premium (Physical or Virtual Nodes) Quantity: 100 Created: 2015-08-06T16:49:55.000+0000 Start Date: 2015-08-05T04:00:00.000+0000 End Date: 2016-08-05T03:59:59.000+0000 Service Level: Premium Service Type: L1-L3 Architectures: x86_64,ppc64le,ppc64,ia64,ppc,s390,x86,s390x SKU: RH00003 Contract: [REDACTED] Order: [REDACTED] Account: [REDACTED] Virt Limit: Requires Virt-who: False Entitlement File: export/entitlements/8a99f9894efa4f28014f03eb49ea5a86.json Certificate File: export/entitlement_certificates/2073596929533310794.pem Certificate Version: 3.2 Provided Products: 69: Red Hat Enterprise Linux Server 70: Red Hat Enterprise Linux Server - Extended Update Support 84: Red Hat Enterprise Linux High Availability (for RHEL Server) - Extended Update Support 86: Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support 91: Red Hat Enterprise Linux Resilient Storage (for RHEL Server) - Extended Update Support 93: Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support 127: Red Hat S-JIS Support (for RHEL Server) - Extended Update Support 133: Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support 176: Red Hat Developer Toolset (for RHEL Server) 180: Red Hat Beta 182: Red Hat EUCJP Support (for RHEL Server) - Extended Update Support 201: Red Hat Software Collections (for RHEL Server) 205: Red Hat Software Collections Beta (for RHEL Server) 240: Oracle Java (for RHEL Server) 246: Oracle Java (for RHEL Server) - Extended Update Support 271: Red Hat Enterprise Linux Atomic Host 272: Red Hat Enterprise Linux Atomic Host Beta 273: Red Hat Container Images 274: Red Hat Container Images Beta Content Sets: /content/eus/rhel/server/7/$releasever/$basearch/debug /content/eus/rhel/server/7/$releasever/$basearch/highavailability/debug /content/eus/rhel/server/7/$releasever/$basearch/highavailability/os /content/eus/rhel/server/7/$releasever/$basearch/highavailability/source/SRPMS /content/eus/rhel/server/7/$releasever/$basearch/iso /content/eus/rhel/server/7/$releasever/$basearch/optional/debug /content/eus/rhel/server/7/$releasever/$basearch/optional/os /content/eus/rhel/server/7/$releasever/$basearch/optional/source/SRPMS /content/eus/rhel/server/7/$releasever/$basearch/oracle-java/iso /content/eus/rhel/server/7/$releasever/$basearch/oracle-java/os /content/eus/rhel/server/7/$releasever/$basearch/oracle-java/source/SRPMS /content/eus/rhel/server/7/$releasever/$basearch/os /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/debug /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/os /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/source/SRPMS <--OUTPUT SNIPPED FOR BREVITY -->
Let's take a look at those fields:
|Server||Which server generated the manifest||usually access.redhat.com|
|Server version||Software version of the server which generated the manifest|
|Date Created||When the Manifest was generated|
|Name||Name of the Subscription management application where this manifest was generated from|
|UUID||UUID of the Subscription management application||pro-tip: visit(https://access.redhat.com/management/distributors/$UUID to go directly to the Subscription Management app)|
|Type||Type of Subscription Management application||usually 'Satellite' or 'Sam'|
|Name||Name of the subscription|
|Quantity||Quantity of this type of subscription attached to the manifest|
|Created||When the subscription was attached to this manifest|
|Start Date||When the subscription begins|
|End Date||When the subscription ends|
|Service Level||SLA for this subscription||Usually Standard, Premium, Self-Support, Layered, etc|
|Service Type||Service Type for the SKU/td>
|Usually either 'L1-L3' or 'L3-only'|
|Architectures||What architecture does the SKU provide content for|
|SKU||Stock Keeping Unit(SKU) number|
|Contract||Red Hat Contract number that this subscription was purchased under|
|Order||Order number that the subscription was purchased under|
|Account||Red Hat Network account that this subscription is from.|
|Virt Limit||How many virtual guests can be supported per hypervisor with this subscription||this field is new in subscription-manager-1.17.10-1|
|Requires virt-who||Does this subscription require [virt-who](https://access.redhat.com/blogs/1169563/posts/2190731) to be used properly||this field is new in subscription-manager-1.17.10-1|
|Entitlement File||Which file (if you extract the manifest contains this data )|
|Certificate File||Which certificate can be used by Satellite to retrieve content provided by this subscription from the CDN|
|Certificate Version||Version of the Entitlement certificate|
|Provided Products||Which Red Hat components are provided via this subscription|
|Content Sets||Which CDN repositories does this subscription have access to (so that content can be synced)|
When do I need a new subscription manifest?
A new subscription manifest is required whenever the contents of the Subscription Management Application changes OR when the content that the subscriptions provided changes. Examples:
- When Satellite 6.2 was released, updated manifests were required to reflect the new Satellite 6.2 repositories.
- When renewing subscriptions, your new subscriptions need to be added to the Subscription Management Application.
- When adding subscriptions to your Subscription Management Application.
When it is necessary to refresh a manifest, you can do this one of two ways:
- In the UI via the Content->Red Hat Subscriptions->Manage Manifests->Refresh Manifest button.
- By downloading it from the Customer Portal and uploading it in the Satellite user interface.
Connected customers whose Satellites can connect to the Red Hat Customer Portal can use either option. Disconnected customers, whose Satellites cannot connect to the Red Hat Customer Portal can only use the latter option.
Hopefully this document helps to explain what a manifest is, and how they interact with Red Hat Satellite.