In the landscape of modern DevOps, automation is not a luxury—it is a necessity. Jenkins stands as the cornerstone of this ecosystem. As the world’s leading open-source automation server, Jenkins empowers development teams to orchestrate their entire software delivery lifecycle, from continuous integration (CI) to complex continuous delivery (CD) pipelines.

While newer CI tools have entered the market, Jenkins remains the industry standard due to its unmatched flexibility. Its vast plugin architecture allows it to integrate with virtually every tool in the software stack, including Docker, Kubernetes, and Git. By hosting Jenkins on a DigitalOcean Droplet, you gain a performant, cost-effective, and fully customizable environment—free from the "build minute" quotas and constraints of managed services.

Prerequisites

Before we begin, ensure you have the following:

• One Ubuntu 24.04 server: Set up with a non-root sudo user and a configured firewall.

• Hardware Note: While Jenkins can technically run on 1 GB of RAM, it is memory-intensive. For a stable production experience, we recommend a Droplet with at least 2 GB to 4 GB of RAM. For larger deployments, consult the official Jenkins Hardware Recommendations.

Each build node connection will take 2-3 threads, which equals about 2 MB or more of memory. You will also need to factor in CPU overhead for Jenkins if there are a lot of users who will be accessing the Jenkins user interface. [https://www.jenkins.io/doc/book/scaling/hardware-recommendations/]

⚠️ Critical Dependency Order On Debian and Ubuntu systems, the order of operations is vital. You must install the Java Runtime Environment (JRE) before installing the Jenkins package.

If you attempt to install Jenkins first, the service will attempt to start immediately, fail to locate a JVM, and crash with a failed to find a valid Java installation error. Installing Java first ensures the environment is primed for a successful first boot.

Step 1 - Installing Java Runtime

Jenkins is a Java application. As of 2025/2026, the Jenkins project has shifted its primary support and recommendations toward newer Long Term Support (LTS) releases of Java. While many legacy guides suggest Java 11, we will install OpenJDK 21 to future-proof your environment and improve garbage collection performance.

$ sudo apt update

$ sudo apt install fontconfig openjdk-21-jre

$ java -version

If the installation was successful, you should see an output similar to the following:

$ java -version
openjdk version "21.0.9" 2025-10-21
OpenJDK Runtime Environment (build 21.0.9+10-Ubuntu-124.04)
OpenJDK 64-Bit Server VM (build 21.0.9+10-Ubuntu-124.04, mixed mode, sharing)

Step 2 - Configuring the Jenkins Repository

By default, the Ubuntu repositories usually lag behind the official Jenkins release cycle. To ensure we get the latest stable features and security patches, we will use the official Debian-stable repository maintained by the Jenkins project.

2.1 Add the GPG Key

We must authenticate the packages to ensure they haven't been tampered with. Download the signed key to your system's keyring:

$ sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

--2026-01-02 01:07:17--  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
Resolving pkg.jenkins.io (pkg.jenkins.io)... 199.232.114.133, 2a04:4e42:5c::645
Connecting to pkg.jenkins.io (pkg.jenkins.io)|199.232.114.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3175 (3.1K) [application/octet-stream]
Saving to: ‘/usr/share/keyrings/jenkins-keyring.asc’

/usr/share/keyrings/jenkins-keyring.a 100%[=======================================================================>]   3.10K  --.-KB/s    in 0s      

2026-01-02 01:07:17 (37.8 MB/s) - ‘/usr/share/keyrings/jenkins-keyring.asc’ saved [3175/3175]

2.2 Add the Repository Source

Now, add the repository URL to your system's source list. We use the signed-by tag to strictly enforce security using the key we just downloaded:

$ echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc]" \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

Step 3: Installing and Starting Jenkins

$ sudo apt update

$ sudo apt install jenkins

Managing the Service

$ sudo systemctl start jenkins

$ sudo systemctl enable jenkins

You can verify the service is healthy and active by running:

$ sudo systemctl status jenkins

If successful, you will see an active (running) status in green.

$ sudo systemctl status jenkins
● jenkins.service - Jenkins Continuous Integration Server
     Loaded: loaded (/usr/lib/systemd/system/jenkins.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-01-02 01:10:56 UTC; 27s ag

Step 4: Securing Network Access (UFW)

DigitalOcean Droplets often come with ufw (Uncomplicated Firewall) configured. By default, Jenkins listens on port 8080, which is likely blocked.

We need to explicitly allow traffic on this port to access the dashboard.

$ sudo ufw allow 8080
Rules updated
Rules updated (v6)

Note: If the firewall is inactive, the following commands will allow OpenSSH and enable the firewall:

$ sudo ufw allow OpenSSH
Rules updated
Rules updated (v6)

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

To confirm the rule is active:

$  sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
8080                       ALLOW       Anywhere                  
OpenSSH                    ALLOW       Anywhere                  
8080 (v6)                  ALLOW       Anywhere (v6)             
OpenSSH (v6)               ALLOW       Anywhere (v6)

Step 5: The Post-Installation Setup

Now that the backend is running, we move to the browser to complete the setup.

1. Open your web browser and navigate to: http://<your_server_ip>:8080

   • You will be greeted by the Unlock Jenkins screen. This is a security measure to ensure you are the server administrator.

2. Return to your terminal to retrieve the automatically generated initial password:

$ sudo cat /var/lib/jenkins/secrets/initialAdminPassword
b80XXXXXXXXXXXXXXXXXXXX

3. Copy the alphanumeric string from the terminal, paste it into the browser field, and click Continue.

4. Select "Install suggested plugins". This installs the "Greatest Hits" of Jenkins (Git, Pipeline, basic UI features) and is the best starting point.

5. Create Admin User: Once the plugins finish downloading, create your primary admin account. Do not use the default "admin" user; create a specific user for yourself.

Enter the name, password and email for your user:

The final step is the Instance Configuration. You will be asked to define the root URL for your Jenkins installation. Ensure the field reflects the correct public IP address or domain name of your server.

After confirming the appropriate information, click Save and Finish. You’ll receive a confirmation page confirming that “Jenkins is Ready!”:

Click Start using Jenkins to visit the main Jenkins dashboard:

Conclusion

You have successfully deployed a modern Jenkins environment on DigitalOcean. You now have a powerful automation server ready to connect to your Git repositories and start building pipelines.

Although RHEL 8 and RHEL 9 are based on DNF*, they are compatible with **YUM** used in RHEL 7.*

Note: All technical procedures and CLI examples in this guide were validated on RHEL 9.7 (Plow). While most commands are backward compatible with RHEL 8, ensure you test in a staging environment before production execution.

1. Introduction: The Evolution of Package Management

In RHEL 8 and 9, the /usr/bin/yum command is a symbolic link to dnf. While legacy scripts still run, the backend is powered by the YUM v4 engine.

[root@mosalahlab ~]$ ll /usr/bin/yum
lrwxrwxrwx. 1 root root 5 Jul  1 07:15 /usr/bin/yum -> dnf-3
[root@mosalahlab ~]$

DNF uses an alternative dependency resolver (libsolv) which is significantly faster and more memory-efficient.

2. Anatomy of a Repo (.repo files)

Repository configurations reside in /etc/yum.repos.d/. Each .repo file can contain multiple repository stanzas.

Key Parameters Breakdown

• [repositoryid]: A unique name for the repo (no spaces).

• baseurl: The URL to the directory where the repodata resides.

• gpgcheck: (0 or 1) Enables/disables GPG signature checking to ensure package integrity.

• enabled: (0 or 1) Tells DNF whether to include this repo in operations.

• priority: Requires the dnf-plugins-core. Lower values mean higher priority (1 is highest).

Practical Example: Adding the HashiCorp Repository

Manually creating a repo file is a standard task for modern infrastructure tooling.

# Create the repo file manually
cat <<EOF | sudo tee /etc/yum.repos.d/hashicorp.repo
[hashicorp]
name=Hashicorp Stable - \$basearch
baseurl=https://rpm.releases.hashicorp.com/RHEL/\$releasever/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://rpm.releases.hashicorp.com/gpg
EOF

# Clean cache
dnf clean all

#  verify the repo is active
[root@mosalahlab yum.repos.d]$ dnf repolist 
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

repo id                                                        repo name
AppStream                                                      RHEL 9 AppStream Local Repository
BaseOS                                                         RHEL 9 BaseOS Local Repository
hashicorp                                                      Hashicorp Stable

3. Modern Management: AppStream & Modules

The most significant change in RHEL 8/9 is the AppStream repository. It allows the OS to decouple the lifecycle of the base operating system from the software running on it via Modules.

Understanding Modules

Modules represent a collection of packages that form a logical unit (e.g., a database). Each module can have multiple Streams, representing different versions (e.g., PostgreSQL 12 vs. 15).

To view available versions of a package like PostgreSQL:

[root@mosalahlab yum.repos.d]$ dnf module list postgresql
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:02:22 ago on Fri 19 Dec 2025 09:52:31 PM EET.
RHEL 9 AppStream Local Repository
Name                           Stream                     Profiles                              Summary                                               
postgresql                     15                         client, server [d]                    PostgreSQL server and client module                   
postgresql                     16                         client, server [d]                    PostgreSQL server and client module                   

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
[root@mosalahlab yum.repos.d]$

To enable a specific version (e.g., version 15):

[root@mosalahlab yum.repos.d]$ dnf module enable postgresql:15 -y 
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:03:21 ago on Fri 19 Dec 2025 09:52:31 PM EET.
Dependencies resolved.
======================================================================================================================================================
 Package                             Architecture                       Version                             Repository                           Size
======================================================================================================================================================
Enabling module streams:
 postgresql                                                             15                                                                           

Transaction Summary
======================================================================================================================================================

Complete!

To switch or reset a module stream:

[root@mosalahlab yum.repos.d]$ dnf module reset postgresql
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:04:00 ago on Fri 19 Dec 2025 09:52:31 PM EET.
Dependencies resolved.
======================================================================================================================================================
 Package                             Architecture                       Version                             Repository                           Size
======================================================================================================================================================
Resetting modules:
 postgresql                                                                                                                                          

Transaction Summary
======================================================================================================================================================

Is this ok [y/N]: y
Complete!
[root@mosalahlab yum.repos.d]$

[root@mosalahlab yum.repos.d]$ dnf module enable postgresql:16 -y 
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:04:52 ago on Fri 19 Dec 2025 09:52:31 PM EET.
Dependencies resolved.
======================================================================================================================================================
 Package                             Architecture                       Version                             Repository                           Size
======================================================================================================================================================
Enabling module streams:
 postgresql                                                             16                                                                           

Transaction Summary
======================================================================================================================================================

Complete!
[root@mosalahlab yum.repos.d]$

4. Survival Tools: History & Undo

One of DNF’s most powerful features is its "flight recorder." Every transaction is logged, allowing for surgical reverts.

Viewing the History

[root@mosalahlab yum.repos.d]$ dnf history
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

ID     | Command line                                                                                    | Date and time    | Action(s)      | Altered
------------------------------------------------------------------------------------------------------------------------------------------------------
     3 | install xorriso                                                                                 | 2025-12-09 21:04 | Install        |    4   
     2 | install pykickstart                                                                             | 2025-12-09 20:45 | Install        |    2   
     1 |                                                                                                 | 2025-12-09 20:01 | Install        |  694 EE
[root@mosalahlab yum.repos.d]$

This lists transaction IDs, the user who ran them, and the action taken. To see details of a specific transaction (e.g., ID 3):

[root@mosalahlab yum.repos.d]$ dnf history info 3
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Transaction ID : 3
Begin time     : Tue 09 Dec 2025 09:04:04 PM EET
Begin rpmdb    : 64be7ee728dfb9aafb51bc0706e2b79ec8c284bc9ed3bc8b24df455f1c310fda
End time       : Tue 09 Dec 2025 09:04:05 PM EET (1 seconds)
End rpmdb      : bec3710d8d5b695c528092b0ab93070f4a905320bb682da10984554a4a4793d7
User           : root <root>
Return-Code    : Success
Releasever     : 9
Command Line   : install xorriso
Persistence    : Persist
Comment        : 
Packages Altered:
    Install libburn-1.5.4-5.el9.x86_64      @AppStream
    Install libisoburn-1.5.4-5.el9_5.x86_64 @AppStream
    Install libisofs-1.5.4-4.el9.x86_64     @AppStream
    Install xorriso-1.5.4-5.el9_5.x86_64    @AppStream
[root@mosalahlab yum.repos.d]$

Scenario: Reverting a Broken Update

If a recent update caused a service failure, you can undo that specific transaction.

[!WARNING] While dnf history undo is generally safe, it may fail if dependencies have shifted significantly since the transaction or if packages have been removed from the upstream repository.

[root@mosalahlab yum.repos.d]$ dnf history undo 3  -y
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:01:36 ago on Fri 19 Dec 2025 09:59:11 PM EET.
Dependencies resolved.
======================================================================================================================================================
 Package                             Architecture                    Version                                Repository                           Size
======================================================================================================================================================
Removing:
 xorriso                             x86_64                          1.5.4-5.el9_5                          @AppStream                          334 k
Removing dependent packages:
 libburn                             x86_64                          1.5.4-5.el9                            @AppStream                          373 k
 libisoburn                          x86_64                          1.5.4-5.el9_5                          @AppStream                          1.1 M
 libisofs                            x86_64                          1.5.4-4.el9                            @AppStream                          483 k

Transaction Summary
======================================================================================================================================================
Remove  4 Packages

Freed space: 2.2 M
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                              1/1 
  Running scriptlet: xorriso-1.5.4-5.el9_5.x86_64                                                                                                 1/4 
  Erasing          : xorriso-1.5.4-5.el9_5.x86_64                                                                                                 1/4 
  Erasing          : libisoburn-1.5.4-5.el9_5.x86_64                                                                                              2/4 
  Erasing          : libburn-1.5.4-5.el9.x86_64                                                                                                   3/4 
  Erasing          : libisofs-1.5.4-4.el9.x86_64                                                                                                  4/4 
  Running scriptlet: libisofs-1.5.4-4.el9.x86_64                                                                                                  4/4 
  Verifying        : libburn-1.5.4-5.el9.x86_64                                                                                                   1/4 
  Verifying        : libisoburn-1.5.4-5.el9_5.x86_64                                                                                              2/4 
  Verifying        : libisofs-1.5.4-4.el9.x86_64                                                                                                  3/4 
  Verifying        : xorriso-1.5.4-5.el9_5.x86_64                                                                                                 4/4 
Installed products updated.

Removed:
  libburn-1.5.4-5.el9.x86_64         libisoburn-1.5.4-5.el9_5.x86_64         libisofs-1.5.4-4.el9.x86_64         xorriso-1.5.4-5.el9_5.x86_64        

Complete!

Undo VS. Rollback:

"undo" and "rollback" represent two fundamentally different approaches to reversing changes. Undo is transaction-based, targeting discrete operations within a session. Rollback is snapshot-based, reverting an entire system state to a previous point in time. Choosing the correct mechanism is critical for effective system management and recovery.

Locking Packages

Package locking is the practice of preventing specific packages from being updated, downgraded, or removed. This protects critical dependencies, ensures compliance, and maintains application compatibility. RHEL provides multiple mechanisms for package locking, each with distinct use cases.

[root@mosalahlab yum.repos.d]$ dnf install 'dnf-command(versionlock)'

Locking a Package

To lock the current version of the kernel:

[root@mosalahlab yum.repos.d]$ dnf versionlock add kernel
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:06:26 ago on Fri 19 Dec 2025 09:59:11 PM EET.
Adding versionlock on: kernel-0:5.14.0-611.5.1.el9_7.*
[root@mosalahlab yum.repos.d]$

To view all active locks:

[root@mosalahlab yum.repos.d]$ dnf versionlock list
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:09:35 ago on Fri 19 Dec 2025 09:59:11 PM EET.
kernel-0:5.14.0-611.5.1.el9_7.*

To remove a lock:

[root@mosalahlab yum.repos.d]$ dnf versionlock delete kernel
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Last metadata expiration check: 0:10:30 ago on Fri 19 Dec 2025 09:59:11 PM EET.
Deleting versionlock for: kernel-0:5.14.0-611.5.1.el9_7.*
[root@mosalahlab yum.repos.d]$

Summary Checklist for SysAdmins

1. Check Repolist: Always verify active repos with dnf repolist.

2. Modular Check: Before installing software, check if a module stream exists with dnf module list.

3. Audit Changes: Use dnf history as a standard part of your post-maintenance review.

4. Enforce Stability: Use versionlock for any package where a version jump would violate your SLA.

1. Introduction: The Automation Gap

In In a standard, vanilla Kubernetes cluster, if the API server or the networking plugin (CNI) fails, you are usually left digging through system logs or SSHing into master nodes. OpenShift eliminates this "hidden" complexity by making the infrastructure itself a set of managed Operators.

OpenShift changes the game by acknowledging a simple truth: Infrastructure is hard. Instead of leaving you to manage the "guts" of the cluster manually, OpenShift turns the infrastructure itself into a series of Operators. These are like tiny, specialized robots that live inside your cluster. Their only job is to watch their specific component, fix it if it breaks, and keep it updated.

These built-in operators represent Red Hat's revolutionary approach: a self-managing platform where the control plane continuously optimizes and heals itself, freeing platform engineers from routine maintenance and letting them focus on innovation.

The "Health Dashboard" via CLI

You don’t have to guess if the cluster is healthy. You can perform a "pulse check" with a single, simple command: $ oc get co (Short for clusteroperator)

$ oc get co 
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.18.0    True        False         False      119m    
baremetal                                  4.18.0    True        False         False      695d    
cloud-controller-manager                   4.18.0    True        False         False      695d    
cloud-credential                           4.18.0    True        False         False      695d    
cluster-autoscaler                         4.18.0    True        False         False      695d    
config-operator                            4.18.0    True        False         False      695d    
console                                    4.18.0    True        False         False      695d    
control-plane-machine-set                  4.18.0    True        False         False      695d    
csi-snapshot-controller                    4.18.0    True        False         False      695d    
dns                                        4.18.0    True        False         False      2m26s   
etcd                                       4.18.0    True        False         False      695d    
image-registry                             4.18.0    True        False         False      695d    
ingress                                    4.18.0    True        False         False      695d    
insights                                   4.18.0    True        False         False      695d    
kube-apiserver                             4.18.0    True        False         False      695d    
kube-controller-manager                    4.18.0    True        False         False      695d    
kube-scheduler                             4.18.0    True        False         False      695d    
kube-storage-version-migrator              4.18.0    True        False         False      695d    
machine-api                                4.18.0    True        False         False      695d    
machine-approver                           4.18.0    True        False         False      695d    
machine-config                             4.18.0    True        False         False      695d    
marketplace                                4.18.0    True        False         False      695d    
monitoring                                 4.18.0    True        False         False      11h     
network                                    4.18.0    True        False         False      695d    
node-tuning                                4.18.0    True        False         False      695d    
openshift-apiserver                        4.18.0    True        False         False      11h     
openshift-controller-manager               4.18.0    True        False         False      11h     
openshift-samples                          4.18.0    True        False         False      673d    
operator-lifecycle-manager                 4.18.0    True        False         False      695d    
operator-lifecycle-manager-catalog         4.18.0    True        False         False      695d    
operator-lifecycle-manager-packageserver   4.18.0    True        False         False      2m28s   
service-ca                                 4.18.0    True        False         False      695d    
storage                                    4.18.0    True        False         False      695d

Each operator reports four key conditions:

• AVAILABLE: This must be True. If it’s False, that specific part of the platform is broken (e.g., if ingress is False, your apps are unreachable).

• PROGRESSING: If this is True, the operator is currently applying an update or a configuration change. It’s "working," not "broken."

• DEGRADED: This is your warning light. If True, the service is running but is in an unhealthy state (perhaps a missing secret or a failing pod replica).

• SINCE: This tells you how long it has been in its current state—crucial for knowing if an issue is a temporary blip or a long-term failure.

And you get a detailed status of a specific operator as below:

$ oc describe co/kube-apiserver
Name:         kube-apiserver
Namespace:    
Labels:       <none>
Annotations:  exclude.release.openshift.io/internal-openshift-hosted: true
              include.release.openshift.io/self-managed-high-availability: true
              include.release.openshift.io/single-node-developer: true
API Version:  config.openshift.io/v1
Kind:         ClusterOperator
Metadata:
  Creation Timestamp:  2024-01-23T12:00:33Z
  Generation:          1
  Owner References:
    API Version:     config.openshift.io/v1
    Controller:      true
    Kind:            ClusterVersion
    Name:            version
    UID:             c1595d31-17e8-4a05-9002-d7399f1ed9c3
  Resource Version:  167395
  UID:               cb85b63c-7f1e-4249-a7dc-eddf9fdefafb
Spec:
Status:
  Conditions:
    Last Transition Time:  2024-01-23T12:13:20Z
    Message:               NodeControllerDegraded: All master nodes are ready
    Reason:                AsExpected
    Status:                False
    Type:                  Degraded
    Last Transition Time:  2025-12-18T12:39:13Z
    Message:               NodeInstallerProgressing: 1 nodes are at revision 14
    Reason:                AsExpected
    Status:                False
    Type:                  Progressing
    Last Transition Time:  2024-01-23T12:17:48Z
    Message:               StaticPodsAvailable: 1 nodes are active; 1 nodes are at revision 14
    Reason:                AsExpected
    Status:                True
    Type:                  Available
    Last Transition Time:  2024-01-23T12:08:51Z
    Message:               KubeletMinorVersionUpgradeable: Kubelet and API server minor versions are synced.
    Reason:                AsExpected
    Status:                True
    Type:                  Upgradeable
  Extension:               <nil>
......

The Operator of Operators

When you run oc get clusterversion, you're looking at the single most important operator in your OpenShift cluster. The Cluster Version Operator (CVO) isn't just another component—it's the conductor of your entire platform orchestra, coordinating the lifecycle of every built-in OpenShift operator.

$ oc get clusterversions.config.openshift.io 
\NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.18.0    True        False         696d    Cluster version is 4.18.0

If the other operators are the musicians, the CVO is the conductor on the podium. When you run oc get clusterversion, you’re looking at the single most important piece of the puzzle.

What is the Cluster Version Operator (CVO)?

The CVO is the declarative state manager for your entire OpenShift platform. It ensures that:

• Every single operator is present and accounted for.

• The cluster stays exactly on the version you requested.

• Upgrades happen safely. It talks to Red Hat, downloads the "blueprint" (payload) for the next version, and carefully walks the cluster through the update so you don't have to.

Day-2 Operations: What Cluster Operators Automate?

Most people love Kubernetes on Day 1 (Installation). Everyone hates it on Day 2 (Maintenance). This is where Operators become your "invisible hands."

Zero-Touch Upgrades

The Cluster Version Operator (CVO) orchestrates seamless platform upgrades:
It performs:

• Pre-flight health checks

• Component-by-component rolling updates

• Post-upgrade validation

Self-Healing Infrastructure

When a master node fails:

1. Machine API Operator detects the failure

2. etcd Operator reconfigures the etcd quorum

3. Kubernetes control plane operators redistribute workloads

Key Cluster Operators and Their Critical Roles

etcd Operator: The Brain's Memory Manager

Manages the etcd cluster—OpenShift's "source of truth." It:

• Automatically backs up and defragments etcd

• Handles member replacement during failures

• Optimizes performance based on cluster size

Machine API Operator: The Infrastructure Conductor

Revolutionizes node management by:

• Automatically provisioning worker nodes when needed

• Self-healing failed nodes without human intervention

• Enabling zero-downtime infrastructure updates

Ingress Operator: The Traffic Autopilot

Manages the entire ingress stack:

• Automatically deploys and scales router pods

• Configures load balancing based on traffic patterns

Monitoring Operator: The Platform's Health Monitor

Provides self-monitoring capabilities:

• Collects thousands of platform metrics

• Auto-scales monitoring stack based on cluster size

• Self-heals monitoring components

Ultimately, Operators are like having a specialized engineering team living right inside your cluster. They take the stress out of maintenance by handling the messy bits automatically, so you can focus on building great things instead of just keeping the engine from stalling.

This article examines Podman, a more secure container management solution that is a lightweight substitute for Containers.

By default, when you use docker, a daemon named root starts all of your containers. You can also run it without root privileges (https://docs.docker.com/engine/security/rootless/), but doing so would require having a different daemon for every user you wish to run containers as.
Podman is devoid of that. It may create containers as root or rootless, and it does it without the assistance of a controlling daemon.

Daemons are background programs that carry out the labor-intensive tasks of running containers without a user interface. Consider daemons as the go-betweens that facilitate communication between the user and the container.

Security Engineer's Nightmare 😖:-

Many daemons run with root privileges. The root account functions as a superuser in Linux systems, granting unrestricted access. Because of this, attackers looking to take over containers and gain access to the host system—possibly compromising the entire infrastructure—will find rogue daemons to be a prime target."

Rootless Podman

Podman removes the daemon "daemonless" and enables rootless containers, which let users run containers without having to deal with a root-owned daemon. Going rootless lowers security risks in your container system by enabling users to create, operate, and manage containers without requiring processes to have administrator capabilities. Podman launches each container with a security-enhanced Linux (SELinux) label.

But Containers can either be run by root or by a non-privileged user.

How Podman manages Containers?

Let's start by quoting the below from Podman Docs [https://docs.podman.io/en/latest/]

Containers under the control of Podman can either be run by root or by a non-privileged user. Podman manages the entire container ecosystem which includes pods, containers, container images, and container volumes using the libpod library. Podman specializes in all of the commands and functions that help you to maintain and modify OCI container images, such as pulling and tagging. It allows you to create, run, and maintain those containers and container images in a production environment.

Podman uses an OCI compliant Container Runtime (runc, etc) to communicate with the operating system and generate the running containers, just as other popular Container Engines (Docker, CRI-O, containerd). Because of this, the containers that are currently running that were made by Podman are almost identical to those made by any other popular container engine.

So Daemonless then what ?

Podman uses systemd, the Linux system and service manager, to communicate directly with the system. As a result, persistence and control are guaranteed even after a reboot, enabling Podman to administer containers as system services.

Podman is a reliable and safe way to manage your containerized apps since it does not require a privileged daemon and uses systemd for communication.

This is only the very beginning! We'll take a closer look at Podman's features and the realm of containers to learn more about them.

In traditional cloud computing models, developers have to manage virtual machines, storage, and networking resources. But in serverless computing, the cloud provider manages and allocates these resources on demand, based on the amount of usage required by the application.

Serverless computing allows developers to create and deploy applications faster because they can focus on the logic and features of their applications rather than the underlying infrastructure.

What is Fargate?

A computation engine called Fargate from Amazon Web Services (AWS) is used to execute containers in a serverless fashion. It is an approach to container deployment that eliminates the need to control the underlying infrastructure. AWS Fargate, to put it simply, is a serverless compute engine that hides the supporting infrastructure required to run containers.

You only need to package your application in containers, select the memory and CPU requirements, define IAM policies, and start your application when using the Fargate launch type.

Fargate Language.

• The main components of Fargate are as follows:

  1. Task definition:- An instruction for launching a Docker container is called a task definition. It includes details on the networking settings, CPU and memory requirements, and container image. Multiple containers can be launched using the same task definition that has been stored.

  2. Task:- A task is the instantiation of a "task definition" within a cluster. When a task is launched, Fargate provisions the required CPU and memory resources to run the container. A task can have one or more containers that run in a single instance of the task. All containers within the same task share the same network namespace, which means that they can communicate with each other using the localhost interface.

  3. An ECS service:- is a collection of tasks that are carried out by your task definition. It offers a mechanism to coordinate and scale several tasks, making it simpler to run and update your containers.

  4. Cluster:- A logical collection of tasks or services. you can have several clusters, and each cluster can have several tasks active in it.

Real-World Scenario

• Your application requires a custom container image, which you must create and put on a registry. Build your container image and store it in a registry.

• Fargate runs on top of ECS or EKS, so you need to create an ECS cluster first, and in the "Infrastructure" configuration, just choose "AWS Fargate".

• Create a Task Definition: A task definition describes how your container should be run, including the container image, CPU and memory requirements, networking, and other settings.

• Create an ECS Service: An ECS service allows you to run and maintain a specified number of tasks simultaneously. You can choose the specific Task Definition you created and how many tasks to run at once, and they will start and stop according to the amount you choose.

  Depending on the requirements and preferences of your application, the particular features and configurations may change.

Conclusion

Finally, Fargate completely transforms how we manage and deploy containers on the cloud. By offering a serverless container running experience, it frees developers from infrastructure management so they can concentrate on creating and expanding their applications. With Fargate, you can quickly deploy and run containers without the hassle of procuring and managing servers, resulting in a deployment process that is more productive and affordable.

Hola, Linux 👋 is a project that you can depend on it as a starter code for your brain 🧠 to rebuild Linux concepts.

Why this is possible?

• There's a user that you need to disable his/her account and restrict from using a command-line.

• Service Users.

First of all, lets grep information about all nologin users. if you didn't add users before to the nologin shell, the all users displayed are the service users.

mosalah@factory~$ grep nologin /etc/passwd

• Add new user and attach that user to the nologin shell.

Add new user "hashnoder" to nologin shell.

mosalah@factory~$ sudo useradd -s /sbin/nologin hashnoder

in the previous command i added new user, hashnoder and attached that user to nologin shell and now he can't start a command-line session.

If you want to switch an existing login user to restrict him/her from accessing the command-line utilities.

mosalah@factory~$ sudo usermod -s /sbin/nologin ex_hashnoder

in the previous command i modified an existing user, ex-hashnoder and attached that user to nologin shell, now he can't start a command-line session and he is restricted.

* You can display the hashnoder user and make sure he is attached to the nologin shell.

mosalah@factory~$ grep hashnoder /etc/passwd

you should see this entry.

Verfication Time.

Let's try to switch to the nologin user hashnoder through the CLI.

mosalah@factory~$ su - hashnoder

You should see a message

"This account is currently not available."

Customize nologin shell message.

• open the /etc/nologin.txt using your favorite editor.

mosalah@factory~$vi /etc/nologin.txt

-> Write your preferred message

Try again to switch to hashnoder user.

mosalah@factory~$ su - hashnoder

Your preferred message is shown instead of the default message.

To go back to your default (old) message, remove the /etc/nologin.txt file

 mosalah@factory~$ sudo rm /etc/nologin.txt

Conclusion.

• We created a new user and restrict that user from starting command-line sessions and he/she is no longer able to write command or login to the system.

• We modified an exiting user from login shell to nologin shell.

• We customized the default message that is displayed to the nologin user.

• Hola, Linux 👋 is a project that you can depend on it as a starter code for your brain 🧠 to rebuild Linux concepts.

One Shell, Many Sessions.

➡️ I want you to be quiet 😔 and divide the concept of shell logically to many shell(s) and give them the alias of "Shell Sessions"

➡️➡️ So it's one shell but many names "aliases" based on its function.

➡️ Linux has more than one shell session:-

1. Login Shell.
2. Non-Login Shell
3. Interactive Shell.
4. Non-Interactive Shell.

   ---

   Login Shell 👤:-

➡️ The shell is considered as Login Shell when you use the shell to :-

1. Login via a terminal (or Switching to another user).
2. Login via SSH.

After successful login (No authentication failure.), a shell starts and a new era of execution begins.

Login Shell Behind The Scene Sequence

When shell starts, a group of pre-configured scripts is executed to setup the environment and those scripts are executed under the umbrella of Global Environment, the execution of these scripts is in the -behind the scene- sequence:-

• Login Shell invokes /etc/profile that contains global configuration that applies to all users.

• accessing its /etc/profile.d/*.sh directory

• In the user's home directory, ~/.bash_profile file is executed and it's a personal initialization file for configuring the user environment to configure your shell before the initial command prompt besides ~/.bash_login and ~/.profile

• ~/.bash_profile is configured to invoke ~/.bashrc that defines settings for that logged-in user.

• ~/.bashrc calls /ect/.bashrc

Non-Login Shell 👤:-

➡️ The shell is considered as Non-Login Shell once the user has authenticated via terminal or via SSH and then opened a new terminal, that new terminal opened is considered as Non-Login Shell because user is no longer asked for login credentials. So, a non-login shell is started by a login shell.

Login Shell Behind The Scene Sequence

When that non-login shell starts, a group of pre-configured scripts is executed to setup the environment, the execution of these scripts is in the -behind the scene- sequence:-

• Non-login shell executes ~/.bashrc that defines the settings for the logged-in user (note: that ~/.bashrc is executed after a user has successfully logged in).

• ~/.bashrc executes /etc/bashrc

• /etc/bashrc invokes the scripts in /etc/profile.d

Interactive Shell 🥂 :-

➡️ The shell that expects you, User, to interact with it, for example the user is going to enter some inputs to the shell via keyboard. That one is considered as "Interactive Shell".

Non-Interactive Shell 🍸 :-

➡️ Non-interactive concept is for systems that are not used directly by people and they don't accept user input.

➡️ In our Linux, Shell is considered as Non-interactive one when there is no interaction on behalf of the user. User is not a part of that process and shell doesn't expect any interactivity from the user.

So, 🤔 Where interaction comes 🤔? that shell expects inputs to interact but in case of Non-Interactive shell, the input comes from automated script and the user doesn't interact with that shell with his hand and keyboard. A script does that interaction and the output is redirected to a file.

Conclusion

• So i tried to cover up one of the most concepts in shell, shell sessions, to change the way how you deal and interact with your next shell(s).
• We, together, started by Login and Non-Login Shell which the shell you daily use when accessing your remote server via SSH or via terminal.
• Then we moved to Interactive & Non-Interactive Shell, The Interactive Shell that you interact with it using your keyboard. And the one which is used by an automated script while user doesn't touch it and that is the Non-Interactive One*
• Hola, Linux 👋 will take the road of simplifying many Linux concepts.