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.
- 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
organizationsas principal division units ← one subscription manifest per org.
locationcreates a matrix → 3 org and 4 location will create
locationis then tied to a capsule server (isolated).
- Info flow: external source → main server → capsule server → managed host.
Content Viewsare subsets of content from the
Library(master copy of all contents).
- Multiple content views can be applied to one capsule server.
Content Viewscan be combined to create
Composite 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
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
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
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
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,
69.pem: identifies this as a RHEL system, no registration.
key.pem: created when you registered the system.
<a long digit string>.pem: certificates for subscriptions that have been attached to this system.
From bottom up,
subscription forms the
core, each pair has a
entitlement has a
1-1 relationship. From these
one can derive how many copies (
entitlements) one can use, and
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
packageis a name, eg,
libgnomeuimm, where then there is a file named
RPMcan refer to both. So use this term with caution.
.rpmfile has format:
Satellite supports 5 types of repos:
- yum: RH native repos are in this bucket. So are things like
Fedora EPEL. The key is the
/repodatafolder 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
wgetit 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
rpmsfrozen 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.
how many we have
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.
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).
scpit 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,
service tomcat6 status, likely is in error.
service tomcat6 start, then check status again, should be fine.
hammerupload again. This takes a while for a file size of only 300+k. Don't panic.
- Now go to
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>"
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
content view. By default, 6.3 server has a default
Library, which includes every subscriptions this SA knows about, and a content view
Default content view, again a catch all version.
- Go to
http://<sa server IP or FQDN>/pub/, and copy address of
On client machine:
Make sure it has a host name (hint:
If DNS is not resolving SA server's name, you can add it manually to
/etc/hosts. For example, SA server is at
192.168.1.100, and the machine you are to register will be
192.168.1.200, simply add two lines in
```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 ```
curl -O <link copied above>(Note: it is a capital O as oliver).
rpm -Uvhi --force katello-ca...rpm.
subscription-manager register --org="<org name>" --activationkey="<key name>".
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
repo on different
- 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), and
Red 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.
- 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