Foreman + Katello Server on Azure
Deploy the open-source upstream of Red Hat Satellite on AlmaLinux 9.
Introduction
30 Second Summary
Every enterprise IT team needs a way to control which software packages land on their servers. Without a central content management system, updates become a guessing game where each machine might be running a different version of the same software.
In this project, you will build a Foreman + Katello content management server on an AlmaLinux 9 virtual machine in Azure. This is the exact open-source technology stack that powers Red Hat Satellite in enterprise environments.
What You'll Build
When you finish, you will open your browser and see two management dashboards: the Foreman web UI for managing RPM repositories and content lifecycles, and the Cockpit console for server administration.
By the end of this project, you'll have:
- SSH access to a cloud-hosted AlmaLinux 9 server in Azure, sized with 4 vCPUs and 32 GiB RAM for enterprise content management workloads.
- A working Foreman 3.18 + Katello 4.20 installation where you can log into the same web UI layout used in Red Hat Satellite to manage repositories, content views, and lifecycle environments.
- A Cockpit web console running alongside Foreman where you can monitor CPU, memory, and disk usage, run terminal commands, and manage services directly from your browser.
- Secret Mission: Configure Foreman's lifecycle environment structure to prepare for uploading RPMs and containers in a follow-on project.
Are there any prerequisites?
You just need a Windows computer with internet access. This project walks you through every setup step, from creating your Azure account to installing all server software.
Before We Start
Before diving in, take a moment to commit to what you're about to build and why it matters.
You are about to install Foreman with Katello from scratch on an AlmaLinux 9 server in Azure. This is the exact open-source technology that powers Red Hat Satellite in enterprise environments.
Create Your Azure Account and Deploy an AlmaLinux 9 VM
Foreman with Katello needs at least 4 CPU cores and 20 GB of RAM to run. That is far more than most laptops can spare for a background server.
Azure lets you spin up a VM with the right specs on demand. The Standard_E4s_v5 costs about $0.252/hour in US regions. If you complete this project in 2-3 hours and deallocate the VM immediately after, total cost stays under $1.
In this step, get ready to:
- Create an Azure free account.
- Deploy an AlmaLinux 9 VM with 4 vCPUs and 32 GiB RAM.
- Connect to the VM via SSH from Windows PowerShell.
Create an Azure free account
Azure is Microsoft's cloud platform where you will host the server. You need a free account to get started.
✔️ I already have an Azure account
You are all set. Skip ahead to the next substep where you create a Resource Group and deploy the VM.
ⓧ I need to create an account
- Open your browser and go to https://portal.azure.com.
- Click Start free (or Try Azure for free).
- Sign in with a Microsoft account. If you do not have one, create one when prompted.
- Complete the phone verification step with your phone number.
- Enter a credit card for identity verification. You will not be charged during the free trial.
- Accept the agreement and click Sign up.
After sign-up completes, you land on the Azure Portal home page.
What is Azure's free trial?
New Azure accounts receive $200 in free credit for 30 days. If you are past that trial period, you pay as you go. The Standard_E4s_v5 VM costs roughly $0.252/hour. Deallocate the VM from the Azure Portal whenever you are not actively using it to keep costs low.
Create a Resource Group and deploy an AlmaLinux 9 VM
Every Azure resource lives inside a Resource Group. Think of it as a folder that keeps all the pieces of a project together so you can manage or delete them as one unit.
- In the Azure Portal search bar at the top, type Resource groups and select Resource groups from the results.
- Click + Create.
- Select your Subscription (the free trial subscription).
- In Resource group, enter foreman-lab-rg.
- Choose a Region close to you (for example, East US).
- Click Review + create, then click Create.
You should see a notification confirming the Resource Group was created. Now deploy the VM inside it.
- In the Azure Portal search bar, type Virtual machines and select Virtual machines from the results.
- Click + Create, then select Azure virtual machine.
- Under Resource group, select foreman-lab-rg.
- Enter a name for your VM (for example, foreman-server).
- Choose the same Region you used for the Resource Group.
- For Image, click See all images. Search for AlmaLinux and select the AlmaLinux 9 image (publisher: almalinux).
- For Size, click See all sizes. Search for Standard_E4s_v5 and select it (4 vCPUs, 32 GiB memory).
Why Standard_E4s_v5?
Foreman's installer needs a minimum of 20 GB RAM. The Standard_E4s_v5 provides 32 GiB, giving comfortable headroom for the database, Pulp content storage, and Candlepin services that the installer sets up.
- For Authentication type, select SSH public key.
- Set Username to azureuser.
- For SSH public key source, select Generate new key pair.
- Under Inbound port rules, make sure SSH (22) is allowed.
- Click Next: Disks at the bottom of the page.
- On the Disks tab, set the OS disk type to Premium SSD.
- Change the OS disk size to 128 GiB.
- Click Next: Networking. On the Networking tab, leave the defaults. Azure automatically creates a virtual network, a public IP, and a Network Security Group (NSG) that allows inbound SSH on port 22.
- Click Review + create.
- Review the summary, then click Create.
A dialog titled Generate new key pair appears. Click Download private key and create resource. A .pem file downloads to your computer. Remember where it saves (usually your Downloads folder). This file is your private key for SSH access.
Keep your private key safe
The .pem file grants full SSH access to your server. Do not share it, email it, or commit it to version control.
Azure now deploys the VM. This takes 1-2 minutes. When deployment finishes, click Go to resource to view your new VM's overview page.
Don't see Standard_E4s_v5 in the size list?
Not every VM size is available in every region. Try selecting a different region (for example, East US 2 or West US 2). You need a size with at least 4 vCPUs and 32 GiB RAM.
If you see a quota error, your free trial subscription may have a vCPU limit for the region. Switch to a region with available quota or request a quota increase from the Azure Portal.
help me find an Azure VM size with at least 32 GiB RAM for Foreman
Connect to the VM via SSH
Your VM is running in the cloud. Now you need to connect to it from your Windows machine using SSH.
- On the VM's overview page in the Azure Portal, find and copy the Public IP address listed in the Essentials section.
- Press the Windows key on your keyboard to open the search bar.
- Type PowerShell and press Enter to open Windows PowerShell.
- Connect to the VM by running this command:
ssh -i [[KEY_PATH="path to your downloaded .pem file"]] azureuser@[[VM_PUBLIC_IP="your VM's public IP address"]]
What does this command do?
The ssh command opens a secure connection to your remote server. The -i flag tells SSH which private key file to use for authentication. azureuser is the username you set during VM creation, and the IP address is your VM's public address.
SSH may ask you to confirm the host fingerprint the first time you connect. Type yes and press Enter.
Seeing a permissions error about the key file?
Windows may download the .pem file with permissions that are too open. SSH refuses to use a key that other users on your machine can read. Fix this by restricting the file permissions.
- Close your SSH attempt and run these two commands in PowerShell, replacing the path with the actual location of your .pem file:
icacls [[KEY_PATH="path to your .pem file"]] /inheritance:r
icacls [[KEY_PATH="path to your .pem file"]] /grant:r "$env:USERNAME:(R)"
- Try the ssh command again after fixing the permissions.
help me fix SSH key permission errors on Windows
Before you run the next command, what do you think you will see when you switch to the root user?
- Switch to the root user by running:
sudo -i
Your terminal prompt changes to root@ followed by your hostname. You now have full administrative access to the server.
Your AlmaLinux 9 server is running and you are connected as root. Next up, you will prepare the server for the Foreman installation by setting the hostname, opening firewall ports, and adding the required package repositories.
Prepare the Server for Foreman Installation
Your AlmaLinux 9 server is running in Azure and you have a root shell ready to go. The next goal is to prepare this server for the Foreman installer.
The Foreman installer is strict about what it expects. It needs a valid fully-qualified domain name, specific firewall ports, and its own package repositories before it will run. Missing any of these causes the installer to fail with cryptic errors about DNS or missing packages.
In this step, get ready to:
- Set the server's hostname and configure DNS resolution.
- Open firewall ports for Foreman services.
- Install the Foreman, Katello, and OpenVox repository packages.
Set the hostname and configure DNS resolution
Foreman requires a fully-qualified domain name (FQDN) to generate its SSL certificates and identify the server. Without one, the installer refuses to run.
- Set the server's hostname to foreman.lab.local by running this command:
hostnamectl set-hostname foreman.lab.local
- Verify the hostname was set correctly by running:
hostname -f
You should see foreman.lab.local printed in the terminal.
Now test whether the hostname resolves to an IP address. This is the same check the Foreman installer performs internally.
- Test DNS resolution by running:
ping -c1 $(hostname -f)
The ping fails with a "Name or service not known" error. This is expected. No DNS server knows about foreman.lab.local because it is not a real domain registered in public DNS.
The fix is to add a local entry in /etc/hosts that maps the VM's private IP address to the hostname.
- Add the hostname entry to /etc/hosts by running this command:
echo "$(hostname -I | awk '{print $1}') foreman.lab.local" >> /etc/hosts
What does this command do?
This command finds the VM's private IP address using hostname -I, picks the first address with awk, and appends a line to /etc/hosts mapping that IP to foreman.lab.local.
Linux checks /etc/hosts before querying external DNS servers. Adding this entry lets the server resolve its own hostname locally without needing a public DNS record.
- Run the ping test again to confirm DNS resolution now works:
ping -c1 $(hostname -f)
This time the ping succeeds. You should see one packet transmitted and one received, with foreman.lab.local resolving to your VM's private IP address.
Ping still failing?
- Check that the /etc/hosts entry was written correctly by running cat /etc/hosts. Look for a line containing your VM's private IP followed by foreman.lab.local.
- If the entry is missing or malformed, delete the broken line and re-run the echo command above.
- Help me troubleshoot this
Open firewall ports for Foreman services
Your AlmaLinux server runs firewalld by default. Foreman needs several ports and services open on the Linux firewall so its components can communicate.
What is the difference between the Linux firewall and the Azure NSG?
There are two layers of firewall protecting your server. The Linux firewall (firewalld) runs on the server itself and controls which ports the operating system accepts traffic on.
The Azure Network Security Group (NSG) is a cloud-level firewall that controls which traffic reaches the VM from the internet. Traffic must pass through both layers to reach a service.
You are configuring the Linux firewall now. You will open the Azure NSG later when you need browser access to the Foreman dashboard.
- Open the required ports for Foreman by running this command:
firewall-cmd --add-port="8000/tcp" --add-port="9090/tcp"
- Add the required services by running this command:
firewall-cmd --add-service=dns --add-service=dhcp --add-service=tftp --add-service=http --add-service=https --add-service=puppetmaster
What do these ports and services do?
- Port 8000/tcp is used for provisioning template downloads.
- Port 9090/tcp is used by Foreman's Smart Proxy for HTTPS communication.
- The services (dns, dhcp, tftp, http, https, puppetmaster) open the standard ports for network booting, web access, and configuration management.
These rules are currently active but only stored in memory. If the server reboots, they disappear.
- Persist the firewall rules so they survive a reboot by running:
firewall-cmd --runtime-to-permanent
- Confirm the firewall configuration by running:
firewall-cmd --list-all
You should see 8000/tcp and 9090/tcp in the ports line. You should also see dns, dhcp, http, https, puppetmaster, and tftp in the services line.
Missing ports or services in the output?
- Make sure you ran both firewall-cmd commands. The first adds ports, and the second adds services.
- Re-run the missing command, then run firewall-cmd --runtime-to-permanent again to persist.
- Help me fix my firewall configuration
Install the Foreman repository packages
Foreman is not included in the default AlmaLinux repositories. You need to install three separate repository packages that tell dnf where to download Foreman, Katello, and OpenVox packages from.
- Install the Foreman 3.18 repository package by running:
dnf install https://yum.theforeman.org/releases/3.18/el9/x86_64/foreman-release.rpm
When prompted to confirm the installation, type y and press Enter. You should see "Complete!" at the end of the output.
- Install the Katello 4.20 repository package by running:
dnf install https://yum.theforeman.org/katello/4.20/katello/el9/x86_64/katello-repos-latest.rpm
Type y and press Enter when prompted.
- Install the OpenVox repository package by running:
dnf install https://yum.voxpupuli.org/openvox8-release-el-9.noarch.rpm
Type y and press Enter when prompted.
What are these three packages?
- foreman-release.rpm adds the Foreman 3.18 repository for Enterprise Linux 9.
- katello-repos-latest.rpm adds the Katello 4.20 repository, which provides content management features like repository syncing, content views, and lifecycle environments.
- openvox8-release-el-9.noarch.rpm adds the OpenVox repository, which provides the configuration management agent that Foreman uses.
- Clean the package cache so dnf picks up the new repositories by running:
dnf clean all
Before you run the next command, think about what you expect to see. You just installed three new repository packages on top of the default AlmaLinux repositories. How many repositories do you expect in the list?
- Check the list of enabled repositories by running:
dnf repolist enabled
You should see foreman, katello, and openvox repositories in the output, alongside the default AlmaLinux repositories (baseos, appstream).
Don't see the Foreman repositories?
- Check that all three dnf install commands completed successfully. Look for "Complete!" at the end of each command's output.
- If any install failed, re-run that specific command. A common cause is a typo in the URL.
- Run dnf clean all before retrying dnf repolist enabled.
- Help me troubleshoot my repository setup
Your server now has a valid hostname, open firewall ports, and the package repositories Foreman needs. Next up, you will run the Foreman installer itself and watch it transform this bare server into a full content management platform.
Install Foreman with Katello
Your server has a hostname, firewall rules, and the right package repositories. The foundation is ready for the main event.
In this step, you will run the Foreman installer. This single command transforms your bare AlmaLinux server into a full content management platform equivalent to Red Hat Satellite. The installer configures PostgreSQL for data storage, Pulp for content storage, Candlepin for subscription management, and the Foreman web application.
In this step, get ready to:
- Upgrade all system packages and install the Foreman installer.
- Run the Foreman installer to set up PostgreSQL, Pulp, Candlepin, and the web application.
- Verify all Foreman services are running and discover a gap in browser access.
Upgrade system packages and install the Foreman installer
Before running the Foreman installer, the system needs every package fully up to date. Outdated packages can cause dependency conflicts during the install.
- In your root SSH session on the VM, upgrade all system packages by running this command:
dnf upgrade -y
This takes a few minutes. You will see a long list of packages being downloaded and updated. The final line reads Complete! when it finishes.
Seeing a mirror or network error?
Make sure your VM has outbound internet access. Try ping -c1 google.com to confirm connectivity. If the command times out, check your Azure Network Security Group for outbound rules.
If a single mirror is down, re-run the same command. dnf will pick a different mirror automatically.
Why is my dnf upgrade failing with a network error?
- Install the Foreman installer package by running:
dnf install -y foreman-installer-katello
You will see the package and its dependencies being installed. The output ends with Complete! once everything is in place.
What is foreman-installer-katello?
This package contains the installer script and all the Puppet modules it needs to configure Foreman with the Katello content management plugin. It does not install Foreman itself yet. The actual installation happens in the next substep when you run the installer command.
Run the Foreman installer
The Foreman installer takes 10 to 20 minutes to complete. If your SSH session drops during that time, the install process dies with it. To protect against this, you will run the installer inside a tmux session that persists even if your connection breaks.
- Install tmux by running:
dnf install -y tmux
- Start a new tmux session by running:
tmux new -s foreman-install
Your terminal prompt now has a green status bar at the bottom. This means you are inside a tmux session.
If your SSH drops during the install
Reconnect via SSH, switch back to root with sudo -i, then reattach to the tmux session with tmux attach -t foreman-install. The installer will still be running.
- Run the Foreman installer with your organization and location names by running this command:
foreman-installer --scenario katello \
--foreman-initial-organization "My_Organization" \
--foreman-initial-location "My_Location" \
--foreman-initial-admin-username admin \
--foreman-initial-admin-password your-chosen-password
- Replace your-chosen-password with a strong password of your choice. You will use this to log into the Foreman web dashboard later.
What does this command do?
--scenario katello tells the installer to set up Foreman with the Katello content management plugin. This is the scenario that makes Foreman equivalent to Red Hat Satellite.
--foreman-initial-organization and --foreman-initial-location create the top-level containers that group your hosts and content. These mirror the organization and location structure in Red Hat Satellite.
Behind the scenes, the installer configures PostgreSQL as the database, Pulp for storing RPM packages and container images, Candlepin for subscription tracking, and the Foreman web application that ties everything together.
The installer takes 10 to 20 minutes. You will see progress messages scrolling as it configures each service. Wait for it to finish.
When the installer completes successfully, it prints a success message along with the Foreman URL and your admin credentials. Write down or remember the password you chose.
Where are the installer logs?
The installer writes a detailed log to /var/log/foreman-installer/katello.log. If anything goes wrong, check this file for the full error details.
🙋♀️ Installer failed or exited with errors?
Check the log file at /var/log/foreman-installer/katello.log for details. Scroll to the bottom of the file to find the most recent error.
If the error mentions DNS resolution, verify your hostname still resolves by running ping -c1 $(hostname -f). If ping fails, check that your /etc/hosts entry for foreman.lab.local is still in place.
If the error mentions memory, confirm your VM is the Standard_E4s_v5 size with 32 GiB RAM. Foreman requires at least 20 GB of RAM.
Help me debug my Foreman installer failure
Verify Foreman services and test browser access
The installer printed a success message, but let's confirm that every service it configured is actually running and healthy.
- Check all Foreman services by running:
hammer ping
You should see a list of services including database, candlepin, katello_events, pulp3, and foreman_tasks. Every service should show Status: ok.
Seeing a service with Status: FAIL?
Some services (especially pulp3) can take an extra minute to start after the installer finishes. Wait 60 seconds and run hammer ping again.
If a service still shows as failed, restart it with foreman-maintain service restart and check hammer ping once more.
Why is one of my Foreman services showing FAIL in hammer ping?
All services are running on the server. Before you move on, take a moment to think: do you think you can open the Foreman dashboard in your browser right now?
- Open your browser on your local Windows machine.
- Navigate to https:// followed by your VM's public IP address (the same one you used to SSH in).
The page times out. Nothing loads.
Why does the page time out?
Your Foreman web application is running on port 443 inside the VM. The Linux firewall you configured in the previous step already allows HTTPS traffic through. The problem is a layer higher.
Azure's Network Security Group (NSG) is a separate cloud-level firewall that controls which traffic reaches your VM from the internet. Right now, the NSG only allows inbound SSH on port 22. It blocks HTTPS on port 443, so your browser's request never reaches the server.
This is a common pattern in cloud deployments. You have two firewalls to manage: the Linux firewall on the server itself, and the cloud provider's network firewall. Both must allow the same traffic. You will fix the NSG in the next step.
Foreman with Katello is fully installed and every service is healthy. The only thing standing between you and the dashboard is Azure's Network Security Group. In the next step, you will open port 443 in the NSG and log into the Foreman web UI for the first time.
Access the Foreman Dashboard
Your Foreman server is fully installed and all services passed the hammer ping health check. But when you tried opening the web UI at the end of the last step, the connection timed out.
The Foreman web application is listening on port 443 inside the server. The problem sits one layer higher: Azure's Network Security Group. This cloud-level firewall only allows SSH traffic by default. In this step, you will add HTTPS and HTTP rules to the NSG, then log into the Foreman dashboard for the first time.
In this step, get ready to:
- Add HTTPS and HTTP inbound rules to the Azure Network Security Group.
- Log into the Foreman web UI and accept the self-signed certificate.
- Confirm the dashboard layout and organization context from your installation.
Add inbound NSG rules for HTTPS and HTTP
The Linux firewall you configured in Step 2 opens ports on the server itself. Azure's Network Security Group is a separate layer of network control that sits in front of your VM at the cloud level. Both layers must allow traffic for it to reach Foreman.
- Switch back to the Azure Portal in your browser.
- Navigate to your VM's overview page inside the foreman-lab-rg resource group.
- Click Networking in the left sidebar.
- Click Network Settings.
- Click the name of your Network Security Group to open its settings.
- Click Inbound security rules in the left menu.
- Click + Add to create a new rule.
What is a Network Security Group?
A Network Security Group (NSG) is a cloud-level firewall that Azure places in front of your VM. It filters traffic before it even reaches the VM's operating system.
This means your server actually has two firewalls: the Linux firewall (firewalld) running inside the OS, and the NSG running in Azure's network layer. Both must allow a port for traffic to get through.
- Enter 443 in the Destination port ranges field.
- Set Protocol to TCP.
- Enter 310 in the Priority field.
- Enter AllowHTTPS in the Name field.
- Click Add.
You should see the AllowHTTPS rule appear in the inbound rules list.
- Click + Add again to create a second rule.
- Enter 80 in the Destination port ranges field.
- Set Protocol to TCP.
- Enter 320 in the Priority field.
- Enter AllowHTTP in the Name field.
- Click Add.
Both rules now appear in the list. Your VM accepts HTTPS and HTTP traffic from the internet.
Rule not appearing in the list?
Make sure the priority numbers 310 and 320 do not conflict with existing rules. Each rule in an NSG must have a unique priority.
If the portal shows a generic error, try refreshing the page and adding the rule again. You can also verify existing rules by scrolling through the inbound rules list to check for duplicates.
help me add an inbound NSG rule in the Azure Portal for my Foreman server
Log into the Foreman web UI
Before you open the URL, think about what you expect to see this time. The NSG now allows HTTPS traffic. Will the page load, or will it time out again?
- Open a new tab in your browser.
- Navigate to your Foreman server's URL:
https://[[VM_PUBLIC_IP="your VM's public IP address"]]
Your browser displays a certificate warning. This is expected because Foreman uses a self-signed certificate that your browser does not trust by default.
- Click through the certificate warning to proceed. In most browsers, click Advanced and then select the option to continue to the site.
- Enter admin in the Username field.
- Enter the password you chose during the Foreman installation.
- Click Log In.
The Foreman dashboard loads, showing the host overview page. The page that timed out just minutes ago is now fully accessible.
Why a self-signed certificate?
Foreman generates its own TLS certificate during installation so that all traffic is encrypted by default. Your browser warns you because this certificate was not issued by a public certificate authority.
In a production environment, you would replace this with a certificate from your organization's internal CA or a public provider. For a lab, the self-signed certificate is fine.
🙋♀️ Page still timing out?
Double-check that both NSG rules show Allow in the Action column and Inbound in the Direction column. A rule set to Deny blocks traffic instead of allowing it.
Confirm you are using https:// (not http://) in your browser's address bar. Foreman listens on port 443.
my Foreman dashboard is still timing out after adding NSG rules
Confirm the dashboard matches Red Hat Satellite's layout
Foreman is the open-source upstream of Red Hat Satellite. The dashboard you see now is the same web UI layout that enterprise Satellite administrators use every day.
- Look at the top navigation bar. You should see Hosts, Content, Infrastructure, and Administer in the menu.
- Look at the top-left corner of the page. The context selector should show My_Organization and My_Location. These are the values you set during the Foreman installer.
- Click Content in the top navigation to confirm the menu loads. This is where you will manage RPM repositories, content views, and lifecycle environments in a follow-on project.
How does this relate to Red Hat Satellite?
Red Hat Satellite is built directly on top of Foreman and Katello. The navigation structure, organization and location selectors, and content management workflows are functionally identical.
Skills you build here transfer directly to a production Satellite environment. The only difference is licensing and Red Hat support.
Your Foreman dashboard is live and accessible from your browser. Next up, you will install Cockpit for browser-based server management alongside Foreman.
Set Up Cockpit for Server Management
Your Foreman dashboard is live and you have explored the content management interface. In production, administrators pair Red Hat Satellite with a second tool for day-to-day server management.
Cockpit is a browser-based console for monitoring services, checking storage, and running terminal commands on your Linux server. Instead of opening an SSH session every time you need to check something, you open a browser tab.
In this step, get ready to:
- Install and configure Cockpit on a custom port to avoid a conflict with Foreman's Smart Proxy.
- Open port 9091 in both the Linux firewall and the Azure Network Security Group.
- Log into the Cockpit dashboard and explore your server's system overview.
Install and configure Cockpit on port 9091
- In your SSH session, install Cockpit by running this command:
dnf install -y cockpit
What is Cockpit?
Cockpit is a web-based administration console for Linux servers. It provides a graphical interface for monitoring system resources, managing services, and running terminal commands directly from your browser.
In production environments, administrators use Cockpit alongside Red Hat Satellite for day-to-day server administration. You are setting up the same dual-dashboard pattern here.
The install finishes with Complete! in the terminal output.
Seeing an error during installation?
- Make sure your server has internet access. Run ping google.com to test connectivity.
- Verify that your repositories are enabled by running dnf repolist enabled.
- Help me troubleshoot a Cockpit installation error on AlmaLinux 9.
- Create the Cockpit configuration directory and set the listening port to 9091 by running this command:
mkdir -p /etc/cockpit && echo -e "[WebService]\nListenPort = 9091" > /etc/cockpit/cockpit.conf
- Enable and start the Cockpit socket service by running this command:
systemctl enable --now cockpit.socket
Why port 9091 instead of 9090?
Cockpit defaults to port 9090. Foreman's Smart Proxy is already listening on port 9090 on this server.
Running both services on the same port would cause a conflict, so you configure Cockpit to use port 9091 instead. This is a common adjustment when Cockpit runs alongside Satellite or Foreman.
- Check that the service is listening by running this command:
systemctl status cockpit.socket
You should see active (listening) in the output. This confirms Cockpit is running and waiting for connections on port 9091.
Not seeing active (listening)?
- Check the configuration file for typos by running cat /etc/cockpit/cockpit.conf. You should see [WebService] on the first line and ListenPort = 9091 on the second.
- Try restarting the socket with systemctl restart cockpit.socket and check the status again.
- Help me troubleshoot Cockpit socket not starting on AlmaLinux 9.
- Open port 9091 in the Linux firewall by running this command:
firewall-cmd --add-port=9091/tcp --permanent && firewall-cmd --reload
- Confirm the port is open by running this command:
firewall-cmd --list-ports
You should see 8000/tcp, 9090/tcp, and 9091/tcp in the output.
Open port 9091 in the Azure Network Security Group
The Linux firewall is open, but the Azure Network Security Group also needs to allow traffic on port 9091 before your browser can reach Cockpit.
- Return to the Azure Portal in your browser.
- Navigate to your VM's page.
- Click Networking, then Network Settings.
- Click on your Network Security Group.
Add a new inbound rule with these settings:
- Click Add inbound port rule.
- Set Protocol to TCP.
- Set Destination port ranges to 9091.
- Set Priority to 330.
- Set Name to AllowCockpit.
- Click Add.
Linux firewall vs. cloud security group
Your server has two separate firewalls. The Linux firewall (firewalld) controls traffic at the operating system level. The Azure Network Security Group controls traffic at the cloud network level.
Both must allow port 9091 for Cockpit to be accessible from your browser. This is the same pattern you used in the previous step when opening ports 443 and 80 for Foreman.
Log into the Cockpit dashboard
Cockpit authenticates with a Linux username and password. Azure VMs created with SSH key authentication do not have passwords set by default.
- Set a password for the azureuser account by running this command in your SSH session:
passwd azureuser
The terminal does not display characters as you type. This is normal for Linux password prompts.
- Type a new password when prompted and press Enter.
- Re-type the password to confirm and press Enter again.
Before you open the Cockpit URL, what do you think the page will look like? Will it resemble the Foreman dashboard, or something different?
- Open https://your VM's public IP address:9091 in your browser.
- Accept the self-signed certificate warning, the same way you did for Foreman.
- Log in with username azureuser and the password you just set.
The Cockpit system overview loads, showing your server's CPU usage, memory, disk, and network activity.
Can't reach the Cockpit login page?
- Confirm the Linux firewall port is open by running firewall-cmd --list-ports and looking for 9091/tcp.
- Double-check that the Azure NSG rule allows TCP port 9091 inbound.
- Make sure you are using https:// (not http://) and that :9091 is at the end of the URL.
- Verify the Cockpit socket is still running with systemctl status cockpit.socket.
- Help me troubleshoot Cockpit not loading in my browser.
- Click Storage in the left navigation to see your 128 GB disk listed.
- Click Terminal to open a command-line session directly from your browser.
- Click Services and look for foreman, foreman-proxy, and pulpcore in the running services list.
What should I see in the dashboard?
The system overview shows real-time CPU, memory, disk, and network graphs for your server. The Storage page lists your 128 GB Premium SSD and its current usage.
The Services page shows all systemd units on your server. Finding the Foreman-related services confirms that your content management platform is running alongside Cockpit on the same machine.
You now have two management dashboards. Foreman handles content management, and Cockpit handles server administration on port 9091.
Secret mission
Configure Foreman's Lifecycle Structure
Your Foreman server is running, but it still uses default placeholder names. In a production Red Hat Satellite environment, organizations, locations, and lifecycle environments are configured before syncing any content. Can you set up these structures to prepare your server for managing RPMs and containers?
Clean Up Your Resources
Clean Up Your Resources
Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The Standard_E4s_v5 VM costs approximately $0.252/hour while running, so stopping or deleting it when you are not using it prevents unnecessary charges on your Azure account.
Cost warning
Your VM consumes about $6/day while running. If you leave it running and forget about it, charges add up quickly.
If you are not planning to start the follow-on project right away, stop or delete the VM to avoid unnecessary charges. Deallocating stops compute billing immediately. Only disk storage (~$0.32/day) continues while the VM is stopped.
Resources you used:
- Azure Resource Group (foreman-lab-rg) containing your VM, OS disk, and Network Security Group.
- Standard_E4s_v5 VM running AlmaLinux 9 with Foreman 3.18 + Katello 4.20 installed (~$0.252/hour while running).
- 128 GB Premium SSD OS disk (~$9.60/month even when the VM is stopped).
- Network Security Group with custom inbound rules for SSH, HTTPS, HTTP, and Cockpit.
Keep everything running
No action needed. Choose this if you are planning to start the follow-on project (uploading RPMs and containers) soon. Be aware the VM continues to bill at ~$6/day while running.
- Your VM will continue running and consuming approximately $6/day in compute costs.
- Your Foreman dashboard remains accessible at https://<vm-public-ip> and Cockpit at https://<vm-public-ip>:9091.
- All lifecycle environments, organizations, and locations you configured are preserved.
Pause - I'll come back to this later
Stop the VM to free up compute costs while keeping your Foreman installation and all configuration preserved on disk.
- In the Azure Portal, search for and select Virtual machines.
- Select your VM from the list.
- On the VM Overview page, click Stop.
- Click Yes to confirm. Wait until the Status changes to Stopped (deallocated).
Why deallocate instead of shutting down from the terminal?
Shutting down the OS from inside the VM puts it in a Stopped state, but Azure still reserves the hardware and bills you for compute. Clicking Stop in the Azure Portal deallocates the hardware, so you only pay for disk storage (~$0.32/day).
When you are ready to continue, come back to the VM page and click Start. Your VM's public IP address may change after deallocation, so check the Overview page for the new IP before reconnecting.
Delete - I don't want to use this again
Remove all project resources and stop all charges immediately by deleting the entire Resource Group.
- In the Azure Portal, search for and select Resource groups.
- Select foreman-lab-rg from the list (or your chosen resource group name).
- Click Delete resource group at the top of the page.
- Type the resource group name to confirm, then click Delete.
This deletes the VM, OS disk, Network Security Group, and all other resources inside the group. All charges stop immediately.
This action is irreversible
Deleting the Resource Group permanently removes your Foreman installation, Cockpit configuration, lifecycle environments, and all server data. You would need to start from Step 1 to rebuild.
Nice Work!
Nice Work!
Nice work! You just built a production-grade Foreman + Katello content management server on AlmaLinux 9 in Azure. This is the exact open-source technology stack that powers Red Hat Satellite in enterprise environments.
You've learned how to:
- Deploy an AlmaLinux 9 VM in Azure and install Foreman 3.18 with Katello 4.20 from scratch, configuring hostnames, repositories, and firewall rules along the way.
- Navigate the difference between the Linux firewall and Azure's Network Security Group, configuring both layers to expose the Foreman dashboard and log into the same web UI layout used in Red Hat Satellite.
- Set up Cockpit on a custom port for browser-based server management alongside Foreman, giving you two management dashboards for your content management server.
- Secret Mission: Configured organizations, locations, and lifecycle environments to prepare the server for uploading RPMs and containers in the follow-on project.
Ready to quiz yourself?