Copyright @ Lenovo US
These notes are based on Satellite 6.3. There are minor difference between 6.2 and 6.3. Grasp the concept here, and hopefully you will have a good understanding of the Satellite models and procedures.
Architecture
- One satellite server (master server), and 1+ capsule servers.
- The Satellite Server is required to connect to Red Hat Customer Portal ← main source of RH packags, errata, Puppet modules.
- The Satellite Server organizes the life cycle management by
using
organizations
as principal division units ← one subscription manifest per org. org
→location
creates a matrix → 3 org and 4 location will create3x4=12
management contexts.location
is then tied to a capsule server (isolated).- Info flow: external source → main server → capsule server → managed host.
Content view
Content Views
are subsets of content from theLibrary
(master copy of all contents).- Multiple content views can be applied to one capsule server.
Content Views
can be combined to createComposite Content Views
.- Composite view is just a grouping. Individual content view, once updated, shall still be promoted, but the composite shell does not need to be changed. So from its consumer's POV, it sees the change transparently.
RH subscription model
The center piece of Satellite is RH subscription. This is how
user/client can run yum install <pkg name>
in RHEL. There can be
multiple sources for you. In this discussion, we only distinguish them
between on-premise Satellite
source vs. everything else.
what is my source?
In RHEL, it's easy to find out which source you are pulling these rpms
from. Look at /etc/yum.repo.d/redhat.repo
:
For example:
[rhel-7-server-openstack-11-devtools-debug-rpms]
metadata_expire = 86400
sslclientcert = /etc/pki/entitlement/2890837266996509363.pem
#####
baseurl = https://cdn.redhat.com/content/dist/rhel/server/7/7Server/$basearch/openstack-devtools/11/debug
#####
ui_repoid_vars = basearch
sslverify = 1
name = Red Hat OpenStack Platform 11 Developer Tools for RHEL 7 (Debug RPMs)
sslclientkey = /etc/pki/entitlement/2890837266996509363-key.pem
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
enabled = 0
sslcacert = /etc/rhsm/ca/redhat-uep.pem
gpgcheck = 1
You see the baseurl
points to cdn.redhat.com
. This is the
catch-all Redhat source, meaning you are pulling things directly from
Red Hat.
On a Satellite client, instead, you will something like this:
[Lenovo_IBB_Lenovo_Yum_Repo_Lenovo_yum_repo_SLES11SP4_Default]
metadata_expire = 1
sslclientcert = /etc/pki/entitlement/3451950880933034925.pem
#####
baseurl = https://brain4-satellite.labs.lenovo.com/pulp/repos/Lenovo_IBB/...........
#####
sslverify = 1
name = Lenovo yum repo SLES11SP4_Default
sslclientkey = /etc/pki/entitlement/3451950880933034925-key.pem
enabled = 1
sslcacert = /etc/rhsm/ca/katello-server-ca.pem
gpgcheck = 0
For this one, baseurl
is pointing to a Satellite server named
brain4-satellite.labs.lenovo.com
. Note that the .pem
(sslcacert
)
is tied to a particular server (as url is in https
!). Therefore, it
is possible to switch source from Satellite A to Satellite B (see
another section below), but cert
needs to be switched together with url.
Am I registered?
From talk, on a RHEL system, ls /etc/pki/product
:
69.pem
: identifies this as a RHEL system, no registration.cert.pem
andkey.pem
: created when you registered the system.<a long digit string>.pem
: certificates for subscriptions that have been attached to this system.
Subscription model
From bottom up,
package
→repo
→product
→subscription
forms the
core, each pair has a 1-N
relationship;
subscription
→entitlement
has a 1-1
relationship. From these
one can derive how many copies (entitlements
) one can use, and
last, contract
defines time ← expiration dates. In its
simpliest term, a VM consumes 1 entitlement of a subscription. So
if you assign 10 entitlements
to, say RH Enterprise Linux
subscription (which as basic RHEL OS rpms), it will support 10 RHEL
VM, and your 11th one will fail to do even yum update
.

-
A
package
is arpm
(ref). Essentiallypackage
is a name, eg,libgnomeuimm
, where then there is a file namedlibgnomeuimm....rpm
. ButRPM
can refer to both. So use this term with caution..rpm
file has format:<name>-<version>-<release>.<architecture>.rpm
-
Satellite supports 5 types of repos:
- yum: RH native repos are in this bucket. So are things like
Fedora EPEL. The key is the
/repodata
folder which represents meta data for this yum repo. - file: One can upload any file to Satellite server. Satellite
will create a URL and function as a regular HTTP server →
client can just
wget
it from that. - OSTree: These are OS images flattened on a file system.
- Docker: TBD
- Puppet: TBD
- yum: RH native repos are in this bucket. So are things like
Fedora EPEL. The key is the
-
Product: is a grouping of repos (so one can put it on a brochure).
-
Subscription: is an umbrella term that covers not only the products one bought, but also service, patch, bug fix, and so forth (ref). It's the unit of software purchased from Red Hat.
Subscription does come with a license, which, once installed, is with the system for life time. So even subscription expires, the system that uses these subscriptions are still functional. The difference being that once it's expired, you will stop receiving updates, service, and so on (so it's like
rpms
frozen in time).There are 2 types of subscriptions to consider: standard and instance-based.
- standard: qty
1-N
, and doesn't matter deployment is BM or VM, always consumed 1. - instance-based: qty
1-N
, BM and VM consumes different amount (see "Entitle accounting" below for more details.)
- standard: qty
-
Entitlement: essentially a total number that how many clients can one subscription allows. For this, we need to do some accounting.
Entitlement accounting
how many we have
From Red Hat Subscription and Entitlement Accounting (pdf):
In implementation, the subscription service (Customer Portal for hosted connectivity or Satellite 6 for on-premise connectivity) converts each subscription into a “pool” of individual entitlements that can be attached to an end-system. The attachment process “consumes” an entitlement from the pool thereby “entitling” the end-system to access content stores.
The pdf has a clear example to describe this. In a nutshell,
entitlements = subscription qty * entitlement qty/sub * instance multiplier

how many we are using
Now, how are entitlement consumed? From Red Hat Subscription and Entitlement Accounting (pdf):
Each subscription has a consumption rule that determines the number of entitlements (rate) that are consumed from a pool to cover the end-system. The consumption rule depends on several factors including: the subscriptions type, the “unit of capacity” the subscription covers (e.g. sockets, ram, cores), and the deployed system type (physical or virtual); thus the consumption rate is governed by the following statements:
- “Standard” subscriptions consumed entitlements at a rate of:
- One per each virtual system deployment
- One per unit of capacity on the physical system
- “Instance-based” subscriptions consumed entitlements at a rate of:
- One per each virtual system deployment
- The “instance multiplier” per unit of capacity on the physical system.
So to simply things, if we are looking at VM primarily, 1 entitlement per VM. Period.
Manifest
Satellite has no entitlement to use. The pool is under a user account
and can be managed in Customer Portal. With the knowledge of
subscription tyeps, we can create a Subscription Allocation
which
then can be exported into a manifest
file. Satellite can import this
file to establish its entitlement pool.
Once you have created a subscription allocation
, export manifest
file to your computer, and see ref:
- Download manifest from Customer Portal (screenshot).
scp
it to Satellite server.- On satellite server,
hammer -u <sa user> -p <sa pwd> subscription upload --file <manifest zip> --organization "<org name>"
If getting an error A backend service [ Candlepin ] is unreachable
,
see ref:
service tomcat6 status
, likely is in error.service tomcat6 start
, then check status again, should be fine.- Run
hammer
upload again. This takes a while for a file size of only 300+k. Don't panic. - Now go to
Content
/Red Hat Repositories
, it will list repos.
Refresh subscription if allocation changed
If we change subscriptions in the allocation using Portal (add/remove subscriptions), we need to SSH back to Satellite server machine, and refresh manifest:
$ hammer subscription refresh-manifest --organization "<org name>"
Enable/disable repo
See ref. On Satellite server:
subscription-manager repos --list
subscription-manager repos --enable=[repo name]
subscription-manager repos --disable=[repo name]
Register a client to SA server

Two ways to register: activation key, or to an environment.
register with activation keys
On Satellite UI:
- create activation key: It asks to select an
environment
and acontent view
. By default, 6.3 server has a defaultenvironment
calledLibrary
, which includes every subscriptions this SA knows about, and a content viewDefault content view
, again a catch all version. - Go to
http://<sa server IP or FQDN>/pub/
, and copy address ofkatello-ca-consumer-latest.noarch.rpm
.
On client machine:
-
Make sure it has a host name (hint:
/etc/hosts
, and/etc/sysconfig/network
).If DNS is not resolving SA server's name, you can add it manually to
/etc/hosts
. For example, SA server is atbrain4-satellite.labs.lenovo.com
with IP192.168.1.100
, and the machine you are to register will beclient1.labs.lenovo.com
with IP192.168.1.200
, simply add two lines in/etc/hosts
:```shell In /etc/hosts: 192.168.1.100 brain4-satellite.labs.lenovo.coom 192.168.1.200 client1.labs.lenovo.com ```
Then restart network services:
```shell systemctl start chronyd systemctl enable chronyd systemctl start rhsmcertd ```
-
Download
katello-ca...rpm
, eg.curl -O <link copied above>
(Note: it is a capital O as oliver). - Install,
rpm -Uvhi --force katello-ca...rpm
. - Register,
subscription-manager register --org="<org name>" --activationkey="<key name>"
. - Verify,
subscription-manager repos --list
. - Go to Satellite UI
hosts/content hosts
, you should see this machine's host name.
How contents are used
It is actually quite confusing how to use it. I think the biggest
pitfall is the mixed use of product
, sub
, repo
on different
page:
- For content view, you are to select by
repo
← same product can have two versions of the same "thing", eg. RedHat OpenStack product can have two repos:Red Hat OpenStack Platform 13 for RHEL 7 RPMs x86_64
(OSP 13), andRed Hat OpenStack Platform 10 for RHEL 7 RPMs x86_64 7Server
(OSP 10) at the same time! But from OSP's POV, these two version are not compatible! - For environment, you don't get to choose either content view or repo. You get whatever content views give you, and each environment can have N content views.
- For activation key, you are to add by
subsctiption
, and you can manually enable/disable by repo. So following the OSP example above, if you have added both OSP 10 and OSP 13 to the same content view, then this key, which is a (content view, env) combo, will inherit both repos. Well, you can then go in to disable one, but that is hard to manage, don't you think. It's better you separate them in content view first.

See also
hammer
cheatsheetsubscription-manager
cheatsheet- Satellite 6.2 installation PDF
- Satellite 6.3 installation PDF
- subscription manager, a nice description of Satellite workflow
- Openstack repo requirements
- IBM doc on Satellite
- Lenovo Yum repo
- Red Hat Subscription Model FAQ
— by Feng Xia