Red Hat Network Satellite Server, as well as its upstream project Katello, enables you to easily manage the registered client hosts using Puppet: for this to work, you must first install the Puppet agent on the client host and register it to the Puppet master instance that is running on the Satellite (or on the Capsule).
This post is a step by step guide that does not only show you how to install and configure the Puppet agent on the client host: it also thoroughly describe how to create the Puppet product on the Red Hat Network Satellite Server 6 (or Katello), add repositories for the relevant architecture families, assign them to the right Content View and publish them into the right Lifecycle Environment.
The Linux distribution used in the examples is CentOS 7, but you can of course easily adapt it to any other Red Hat and derived Linux distribution.
Prerequisites
The straightforward requisite is having the client host already registered on the Red Hat Network Satellite Server 6 or Katello. If you do not know how to do this, or simply want to learn more on this topic, please read Register Clients To Satellite Server 6 Or Katello before going on with this post.
Create the Puppet Product
The very first thing to do is create the Puppet product on the Satellite, so that the client hosts registered to Satellite can be attached to the subscription and so become entitled to install it.
Login to the Satellite using SSH and switch to the user you decided to use to issue hammer commands:
sudo su - katello
Create The Product
Let's create the "Puppet" product:
hammer product create \
--organization "Carcano CH" \
--name "Puppet" \
--description "Puppet infrastructure automation and delivery suite"
the output must be as follows:
Product created.
Attach Clients To the Puppet Subscription
Now that the product has been created, the registered client hosts must be able to see it into the list of available subscriptions: login to an already registered client host using SSH and issue the following command:
sudo subscription-manager list --available
the output is a list that among the various member must contain the subscription to the "Puppet" product:
+-------------------------------------------+
Available Subscriptions
+-------------------------------------------+
Subscription Name: Puppet
Provides:
SKU: 768103798701
Contract:
Pool ID: 8a8180827e828d29017e836cd1c4005f
Provides Management: No
Available: Unlimited
Suggested: 1
Service Type:
Roles:
Service Level:
Usage:
Add-ons:
Subscription Type: Standard
Starts: 01/22/2022
Ends: 12/01/2049
Entitlement Type: Physical
Mind that simply creating a product does only mean that the Product with its related subscription(s) is available on the Satellite - despite the client hosts see it among the available subscriptions (and they can even attach to it), they are not still able to install the product yet: the subscription does not provide any repository yet, neither any of them has been linked to a Content View and published to a lifecycle environment infact.
Create The Puppet5 YUM Repository
We can now create the "Puppet 5" repositories that a client host gets access to after attaching the "Puppet" subscription.
Be wary that since the RPM packages contained in the online upstream Puppet repositories are GPG signed, we must publish this GPG key on Satellite so as to have clients automatically download and install it to verify the integrity of the packages before installing them from the local repositories provided by the Satellite itself.
Publish the GPG Signing Key
Let's download the GPG key from the online official Puppet repository:
wget https://yum.puppet.com/RPM-GPG-KEY-puppet-20250406
then we can push to the Satellite the GPG Key file we have just download:
hammer gpg create \
--key RPM-GPG-KEY-puppet-20250406 \
--name "RPM-GPG-KEY-puppet-20250406" \
--organization "Carcano CH"
the output must be as follows:
GPG Key created.
Create The Puppet5 YUM Repository For CentOS 7
We are now ready to create the local yum repositories for the "Puppet 5" version of the "Puppet" product hosted on the Satellite: in this post I show you only how to create the repository for the "el7" Linux family (that means "Red Hat Enterprise Linux 7", "CentOS 7" and derivatives).
hammer repository create \
--organization "Carcano CH" \
--product "Puppet" \
--name "Puppet 5 for CentOS 7 RPMs x86_64" \
--content-type yum \
--url "http://yum.puppetlabs.com/puppet5/el/7/x86_64" \
--gpg-key "RPM-GPG-KEY-puppet-20250406"
the output must be as follows:
Repository created.
Please note how we supplied both
- the URL of the upstream online repository from where download the packages
- the name of the GPG key we just published on Satellite.
Publish The Puppet5 Repository
The requisite for publishing a repository into a Lifecycle Environment is adding it to the Content View of the operating system family the repository belongs to: since we are using the "el7" family, we add the repository to the "CentOS 7" Content View.
Add The Puppet5 Repository To The CentOS 7 Content View
We now add the "Puppet 5 for CentOS 7 x86_64" YUM repository to the "CentOS 7" Content View (we are of course assuming that the Content View does already exist):
hammer content-view add-repository \
--organization "Carcano CH" \
--name "CentOS 7" \
--product "Puppet" \
--repository "Puppet 5 for CentOS 7 RPMs x86_64"
the output is as follows:
The repository has been associated.

Publish A new Version Of The Content View
A Content View is published into an environment using versions: each time anything is modified - for example if new software has been downloaded from the upstream repository, or a new upstream repository has been added, we must publish a new version of the Content View.
So, since we added a new repository, we must publish a new version of the "CentOS 7" content view:
hammer content-view publish \
--organization "Carcano CH" \
--name "CentOS 7" \
--description "Added Puppet5 repository"
the output is as follows:
[...................] [100%]
Since Puppet support on Katello is now officially deprecated, how will you manage your software supply chain? Successfully orchestrating Katello product subscriptions and syncing traditional repository trees is an excellent administrative milestone.
However, as Red Hat actively deprecates legacy configuration agents in favor of agentless solutions, your core architecture must evolve. Managing a distribution server is only half the battle: you must master the upstream engineering required to build, test, and sign custom software payloads securely before they reach your infrastructure.
If you want to check whether your technical stack is ready for modern, agentless DevSecOps frameworks, jump directly to the Apress Blueprint Box below to discover how to boost and evolve your career using a self-paced learning path.
Publish The New Version Of The Content View To A Lifecycle Environment
Every new version of a Content View gets published into the "Library": since the client hosts are not linked to the "Library" (despite it being possible, if necessary), rather than to a particular Lifecycle Environment, we must promote the new version of the "CentOS 7" content view to the target environment.
In this example, the client hosts are bound to the "Lab" environment: we can publish this version of the Content View as follows:
hammer content-view version promote \
--organization "Carcano CH" \
--content-view "CentOS 7" \
--to-lifecycle-environment Lab
the output is as follows:
[...................] [100%]

Install Puppet5 On Clients
We are eventually ready to install the "Puppet 5" RPM packages on the client hosts.
Attach Clients To the Puppet Subscription
Login to an already registered client host using SSH and issue the following command to list the available subscriptions:
sudo subscription-manager list --consumed
the "Puppet" subscription must be shown among the other subscriptions:
+-------------------------------------------+
Available Subscriptions
+-------------------------------------------+
Subscription Name: Puppet
Provides:
SKU: 768103798701
Contract:
Pool ID: 8a8180827e828d29017e836cd1c4005f
Provides Management: No
Available: Unlimited
Suggested: 1
Service Type:
Roles:
Service Level:
Usage:
Add-ons:
Subscription Type: Standard
Starts: 01/22/2022
Ends: 12/01/2049
Entitlement Type: Physical
to go on we need to know the "pool ID" of the "Puppet" subscription, since we need to specify it in the command to attach the client host to that subscription.

Are you enjoying these high quality free contents on a blog without annoying banners? I like doing this for free, but I also have costs so, if you like these contents and you want to help keeping this website free as it is now, please put your tip in the cup below:
Even a small contribution is always welcome!
In this example, the command to attach the client host to the "Puppet" subscription is:
sudo subscription-manager attach --pool=8a8180827e828d29017e836cd1c4005f
the output is as follows:
Successfully attached a subscription for: Puppet
Install puppet-agent
Now that the client have successfully attached the client host to the Puppet subscription, we can install the puppet-agent RPM package (that is part of the Puppet product):
sudo yum install -y puppet-agent
Configure Puppet-Agent
Once installed, Puppet agent must be configured so to connect to the Satellite (or the Capsule) - this can be easily achieved by running the following commands:
PUPPET_ENVIRONMENT="production"
PUPPET_RUNINTERVAL_MINUTES="180"
SATELLITE_FQDN=$(awk -F "=" '/baseurl[ ]*/ {print $2}' /etc/rhsm/rhsm.conf | cut -d / -f 3)
cat << EOF > /etc/puppetlabs/puppet/puppet.conf
[agent]
server = ${SATELLITE_FQDN}
certname = ${HOSTNAME}
runinterval = ${PUPPET_RUNINTERVAL_MINUTES}
environment = ${PUPPET_ENVIRONMENT}
listen = false
pluginsync = true
report = true
EOF
please note note how:
- we automatically guess the FQDN of the Satellite from the registration settings configured in "/etc/rhsm/rhsm.conf" file
- we set the Puppet environment using the "PUPPET_ENVIRONMENT" variable
- we use the PUPPET_RUNINTERVAL_MINUTES to set the interval in minutes between puppet-agent runs
Our first run of puppet-agent is a foreground launch in test mode set to verbose:
/opt/puppetlabs/bin/puppet agent -tv
the output must be as by the following (cut) snippet:
Info: Creating a new SSL key for srv-ci-up3a002.mgmt.carcano.local
Info: Caching certificate for ca
Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for srv-ci-up3a002.mgmt.carcano.local
Info: Certificate Request fingerprint (SHA256): 8D:0E:85:5C:5E:1A:34:8F:F9:9D:BE:1E:B6:40:62:B2:EF:4F:73:28:AD:E3:E5:0A:B6:C5:47:79:77:87:D5:8B
Info: Caching certificate for ca
Exiting; no certificate found and waitforcert is disabled
as you see, puppet-agent immediately stops right after creating a Certificate Signing Request (CSR) and submits it to the Puppet Master.
Sign The Client Certificate Of Puppet Agent
We must now login to the Satellite using SSH so to have a look to the pending CSRs: we can use the puppetserver command line to get them as follows:
sudo /opt/puppetlabs/bin/puppetserver ca list
the output must pretty similar to the following (cut) snippet:
Requested Certificates:
srv-ci-up3a002.mgmt.carcano.local (SHA256) 8D:0E:85:5C:5E:1A:34:8F:F9:9D:BE:1E:B6:40:62:B2:EF:4F:73:28:AD:E3:E5:0A:B6:C5:47:79:77:87:D5:8B
as we see by the FQDN ("srv-ci-up3a002.mgmt.corner.local") and the fingerprint, the pending request is actually the one sent by our client host - let's sign as follows:
sudo /opt/puppetlabs/bin/puppetserver ca sign --certname srv-ci-up3a002.mgmt.carcano.local
the output is as by the following (cut) snippet:
Successfully signed certificate request for srv-ci-up3a002.mgmt.carcano.local

Start The Puppet-Agent Service
Now that the client certificate of the puppet node has been issued, we only have to:
- login again on the client using SSH
- start the puppet service
- enable the puppet service to run at boot
systemctl enable puppet
systemctl start puppet
the client host is now configured to be managed by Puppet.
Beyond Legacy Agents: Building the DevOps and DevSecOps Foundations
Successfully creating software products, attaching local entitlements, and signing agent node certificates via dedicated CLI tools are vital systems administration activities. Yet, setting up a lifecycle environment for an aging platform agent represents just one operational brick in the massive wall of modern DevOps and DevSecOps engineering on Linux. In complex enterprise networks, you cannot rely on obsolete standalone deployment templates: you must master the upstream methodology required to develop, test, and wrap your applications into robust, digitally signed deployment packages without vendor lock-in.
When you evaluate your daily deployment tasks, are you completely confident in your ability to migrate your configurations and build repeatable software supply chains from scratch? Or are you simply maintaining legacy lifecycle channels without a comprehensive architecture strategy?
My book, "DevSecOps and DevOps for Linux: The Foundations", published by Apress, was specifically designed to drive this professional reflection during major technological transitions. Through a comprehensive, lab-driven blueprint, the volume guides you step-by-step through the architecture of modern code development governed by strict automated pre-commit compliance linters, testing frameworks, and digital signing to generate enterprise-ready RPM packages. Built entirely on cloud-agnostic, open-source principles, this practical learning path ensures you systematically identify and fill your technical gaps, allowing you to transform legacy configurations into fully secure, modern, and automated pipelines.
Key insights covered in this volume:
- The Holistic Skills Set Brick: Bridge technical engineering with team management frameworks. Master
Scrum,Kanban, andLeanmethodologies to design system architectures aligned with real corporate workflows. - The Shell Scripting & Unix Tools Brick: Build rigorous operational foundations. Master advanced
Bashshell scripting architecture while learning how to combine core Unix tools into robust, repeatable, and enterprise-ready host automations. - The Version Control Engineering Brick: Move past basic commits. Dive deep into
Gitversion control, mastering feature-branch workflows, repository lifecycle management, and complex conflict resolution. - The Data & Core Automation Brick: Build bulletproof data processing setups. Learn advanced
RegEx, how to operate using evergreen tools such asGrep,Sed, andAWK, and how to master structured data parsing (XML,JSON,YAML) usingPythonand tools likexmlstarlet,jq, andyq. - The Modern Python & Automation Brick: Develop a modern Python project using
pyproject.tomlwithpytest-based unit tests, governing the project withGNU Makefor testing, building, and digitally signingRPMpackages. The project is presented in an evolving fashion, showing how features are added step by step, highlighting how a properly structured Python project can be improved and evolved with minimal or no rework at all. - The Linux OS Hardening & PKI Brick: Learn the real mechanics of security. Implement
X.509/PKIarchitectures,TLSconfigurations, andGPGencryption and signing, while mastering low-level kernel defenses likeSELinuxandLinux Capabilities. - The Compliance Check and Shift-Left Security Brick: Learn how to leverage the
pre-commitframework to automate compliance checks withPylintandFlake8, and perform security scans withBanditandSafety, extending the security audit to the full software supply chain. - The Application Integration Brick: Master the foundational protocols used to securely interconnect enterprise microservices, including
HTTP,REST,OpenAPI,SOAP, andLDAP/LDAPS. - The Infrastructure Delivery Brick: Put theory into practice with vertical, real-world labs. Move from basic scripts to engineering
Ansiblearchitectures, rootlessPodmansetups, image creation viaBuildah, and completePulp3deployments usingDocker Compose. - The Enterprise GitOps Pipeline Brick: Tie everything together by automating your software supply chain. Build complete continuous deployment workflows using
Gitea CIpipelines hosted natively onKubernetes(RKE2).
Footnotes
Here it ends this tutorial on how to setup Puppet agent on client hosts registered to Red Hat Network Satellite Server 6 or Katello - we do not only learned how to install and configure it: we also know how to create the Puppet product on the Red Hat Network Satellite Server 6 (or Katello), how to add repositories for the relevant architecture families, assign them to the right Content View and publish them into the right Lifecycle Environment. I hope that you enjoyed it, but being however aware that, as I warned you, Puppet will be deprecated as of Red Hat Network Satellite Server 7.

2 thoughts on “Puppet agent on Red Hat Network Satellite Clients”