Install Satellite on RHEL8

From Bitbull Wiki
Jump to navigation Jump to search

1 VM SETUP

  • Red Hat Enterprise Linux 8
  • CPU: min 6 (4 Testing)
  • MEM: min 32G (24 Testing)
  • DISK:
  • / 10 GB -> 50 GB
  • /var/log 10 MB -> 10 GB
  • /var/lib/pgsql 100 MB -> 20 GB
  • /var/lib/pulp 1 MB -> 300 GB
  • /var/lib/qpidd ~2MB per managed host



2 LINKS

3 OUTSIDE CONNECTIVITY NEEDS

3.1 default

3.2 If using Insights



4 Install

subscription-manager register

dnf -y install firewalld sos

systemctl enable firewalld --now

firewall-cmd \
--add-port="80/tcp" --add-port="443/tcp" \
--add-port="5647/tcp" \
--add-port="8000/tcp" --add-port="9090/tcp" \
--add-port="8140/tcp" \
#--add-port="53/udp" --add-port="53/tcp" \
#--add-port="67/udp" \
#--add-port="69/udp"


firewall-cmd --runtime-to-permanent

firewall-cmd --list-all
  #ports: 80/tcp 443/tcp 5647/tcp 8000/tcp 9090/tcp 8140/tcp

ping -c1 localhost
ping -c1 `hostname -f`

hostnamectl set-hostname `hostname -f`
hostnamectl

subscription-manager list --all --available --matches 'Red Hat Satellite Infrastructure Subscription'

subscription-manager attach --pool=xxx-listed-above-xxx
subscription-manager list --consumed

subscription-manager repos --disable "*"

subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=satellite-6.13-for-rhel-8-x86_64-rpms --enable=satellite-maintenance-6.13-for-rhel-8-x86_64-rpms


dnf module enable satellite:el8

dnf clean all
dnf makecache
dnf -y upgrade

yum -y install chrony
systemctl start chronyd
systemctl enable chronyd

chronyc sources

reboot

dnf install satellite

4.1 Bugs

# during setup
Installing       : katello-client-bootstrap-1.7.9-1.el8sat.noarch                                                                                                                                                                                                                                                   313/489 
warning: user apache does not exist - using root
warning: group apache does not exist - using root
warning: user apache does not exist - using root
warning: group apache does not exist - using root

Running scriptlet: cyrus-sasl-2.1.27-6.el8_5.x86_64                                                                                                                                                                                                                                                                 390/489 
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.22], expected [0.23] for domain implicit_files!
Higher version of database is expected!
In order to upgrade the database, you must run SSSD.
Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials.
Could not open available domains
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.22], expected [0.23] for domain implicit_files!
Higher version of database is expected!
In order to upgrade the database, you must run SSSD.
Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials.
Could not open available domains
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.22], expected [0.23] for domain implicit_files!
Higher version of database is expected!
In order to upgrade the database, you must run SSSD.
Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials.
Could not open available domains
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.22], expected [0.23] for domain implicit_files!
Higher version of database is expected!
In order to upgrade the database, you must run SSSD.
Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials.
Could not open available domains



5 Setup Foreman

satellite-installer --scenario satellite --foreman-initial-organization "BITBULL" --foreman-initial-location "Verwaltung" --foreman-initial-admin-username admin --foreman-initial-admin-password admin --enable-foreman-cli-ansible --enable-foreman-cli --enable-foreman-cli-katello
# --skip-checks-i-know-better --tuning development



6 Foreman Content Management - Menu Overview

Foreman Menu


7 Manage Repos with Foreman

8 Create Content

  • Content > Subscriptions
Import Manifest, then allocate LICs if needed
  • Content > Red Hat Repositories
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
  • Content > Sync Plans
Create Sync Plan > Daily
  • Content > Products > [X] Red Hat Enterprise Linux for x86_64
Manage Sync Plan > Daily
Sync Selected
  • Content > Lifecycle Environment > Create
TestLcEnv > ProdLcEnv
  • Content > Content views > Create
  • Name: cv_rhel8
  • Solve dependencies: TRUE
  • Add needed Repos
  • Content > Content views > cv_rhel8 > Publish new version
  • Promote: TRUE
  • Version: 1.0
  • Env: TestLcEnv + ProdLcEnv
  • Content > Activation Keys > Create
  • Name: ak_rhel8_test
  • Environment: TestLcEnv
  • Content View: cv_rhel8
  • Repository Sets: Disable all but needed
  • Content > Activation Keys > Create
  • Name: ak_rhel8_prod
  • Environment: ProdLcEnv
  • Content View: cv_rhel8
  • Repository Sets: Disable all but needed
  • Here you can "Disable Overriden" Repos, which do show up but are disabled

8.1 OnBoard existing OS

8.1.1 deregister host

subscription-manager clean
subscription-manager remove --all
subscription-manager unregister
subscription-manager clean

8.1.2 register to satellite

dnf install http://satellite-fqdn.acme.com/pub/katello-ca-consumer-latest.noarch.rpm

subscription-manager register --org="BITBULL" --activationkey="ak_rhel8_prod"
# subscription-manager register --org="Your_Organization" --activationkey="Your_Activation_Key"

subscription-manager refresh
dnf repolist
cat /etc/yum.repos.d/redhat.repo
subscription-manager status

yes no | dnf upgrade



9 Patch Cycle Ideas Brainstorming

9.1 Prerequisites

  • Daily Sync of all Foreman Libraries (Product upstream Repos)
  • Working Repos as mentioned above
  • Systems are grouped and registered in Lifecycle Environments
  • TEST
  • TEST-LATE
  • PROD
  • PROD-LATE

The meaning of "LATE" is to patch this systems later to avoid production issues (eg: half of the systems of a Cluster (DNS, Web, ...)

9.2 Patch Cycle

  • All systems get patched at least every 4 weeks
  • A Rundeck Job does update the Content Views on a regular base.
EXAMPLE:
----------------------------------
KW01 -> "Library" (daily sync) into "TEST" Content View as Version "KW01"
KW02 -> Version "KW01" into "TEST-LATE" Content View
KW03 -> Version "KW01" into "PROD" Content View
KW04 -> Version "KW01" into "PROD-LATE" Content View
KW05 -> "Library" (daily sync) into "TEST" Content View as Version "KW05"
KW06 -> Version "KW05" into "TEST-LATE" Content View
KW07 -> Version "KW05" into "PROD" Content View
KW08 -> Version "KW05" into "PROD-LATE" Content View
...

9.3 Emergency Patching

Due security needs, it may be necessary to apply patches immediatly. For that, you have several options

9.3.1 Add Packages to Conent View

  • Create a custom Repository eg. "Rocky9 Custom"
  • Add RPMS, which are newer and needed for emergency patching to this repo
  • They get applied with Ansible on a daily base during patch cycle
  • Once they get obsolete (regular Repo gets updated) you can purge them out of the repo

9.3.2 Update Conent View

Easiest way to update repos but may apply more updates than needed for security reason

  • Needs to pause the automated "Content View" update in Rundeck

9.3.3 Manual Update

Manually Update custom packages with yum/dnf on affected systems

  • least prefered, due missing overview

10 Overview

10.1 Products

10.1.1 Short Description

A Product in The Foreman is essentially a container for repositories. It helps in organizing multiple repositories under a single umbrella for easier management.

10.1.2 Main Targets

  • Organizational Structure: Group related repositories together.
  • Simplified Management: Easier to manage permissions, subscriptions, and content synchronization.

10.1.2.1 Example

Create a Product named RHEL7 and add repositories like RHEL7-Base, RHEL7-Updates, and RHEL7-Extras under it.

10.2 Repositories

10.2.1 Short Description

Repositories hold the actual content like RPM packages, Puppet modules, or container images. They are the most granular level of content management.

10.2.2 Main Targets

  • Content Storage: Store packages, modules, or images.
  • Version Management: Keep track of different versions of content.

10.2.2.1 Example

Under the RHEL7 Product, you might have repositories like:

  • RHEL7-Base for basic packages
  • RHEL7-Updates for updated packages

10.3 Lifecycle Environments

10.3.1 Short Description

Lifecycle Environments represent stages in your deployment pipeline, such as Development, Testing, and Production.

10.3.2 Main Targets

  • Workflow Management: Control the flow of content through various stages.
  • Quality Assurance: Test content in isolated environments before production deployment.

10.3.2.1 Example

A typical flow might be: LcDev > LcTest > LcQA > LcProd.

  • Content first gets uploaded to LcDev for initial testing.
  • If it passes, it moves to LcTest for more rigorous checks.
  • After that, it goes to LcQA for quality assurance.
  • Finally, it gets promoted to LcProd for production use.

10.4 Content Views

10.4.1 Short Description

A Content View is a snapshot of multiple repositories and/or Puppet modules. It allows you to filter and combine content from various repositories.

10.4.2 Main Targets

  • Content Isolation: Create customized views of content for different hosts or host groups.
  • Versioning: Snapshot content for reliable deployments.

10.4.2.1 Example

Create a Content View named WebServers that includes packages from RHEL7-Base and RHEL7-Updates but excludes certain debugging packages.

10.5 Activation Keys

10.5.1 Short Description

Activation Keys are tokens used during the host registration process. They define which Content View and Lifecycle Environment a host should be associated with, and can also control repository subscriptions.

10.5.2 Main Targets

  • Automated Registration: Simplify the process of registering new hosts.
  • Configuration Management: Automatically apply the correct repositories and lifecycle environments to hosts.
  • Repository Override: Control which repositories are visible but not enabled, allowing clients to optionally subscribe to them.

10.5.2.1 Example

Create an Activation Key named ProdServers that is tied to the WebServers Content View and the LcProd Lifecycle Environment. Use this key when registering production servers.

10.5.2.1.1 Repository Override

Within the Activation Key settings, you can specify that certain repositories, like Epel, are visible but not automatically enabled. This means that while the repository will be available to the client, it won't be enabled by default. The client can then choose to manually subscribe to this repository if needed.

For example, you could have an Activation Key for development servers where the Epel repository is visible but not enabled. Developers can then decide whether or not to enable this repository on their individual servers.

Retrieved from "http://www.bitbull.ch/wiki/index.php?title=Install_Satellite_on_RHEL8&oldid=5742"