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 create 3x4=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 the Library (master copy of all contents).
Multiple content views can be applied to one capsule server.
Content Views can 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 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 and key.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 a rpm (ref). Essentially package is a name, eg, libgnomeuimm, where then there is a file named libgnomeuimm....rpm. But RPM 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:
1. 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.
2. 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.
3. OSTree: These are OS images flattened on a file system.
4. Docker: TBD
5. Puppet: TBD
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.
1. standard: qty 1-N, and doesn't matter deployment is BM or VM, always consumed 1.
2. instance-based: qty 1-N, BM and VM consumes different amount (see "Entitle accounting" below for more details.)
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

Download `katello ca` from Satellite 6.3 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 a content view. By default, 6.3 server has a default environment called 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 katello-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 at brain4-satellite.labs.lenovo.com with IP 192.168.1.100, and the machine you are to register will be client1.labs.lenovo.com with IP 192.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), 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