DEV Community: Janak Shrestha

Install and Configure HaProxy LBR

Janak Shrestha — Fri, 18 Sep 2026 17:16:35 +0000

There is a static website running in Stratos Datacenter. They have already configured the app servers and code is already deployed there. To make it work properly, they need to configure LBR server. There are number of options for that, but team has decided to go with HAproxy. FYI, apache is running on port 8087 on all app servers. Complete this task as per below details.

a. Install and configure HAproxy on LBR server using yum only and make sure all app servers are added to HAproxy load balancer. HAproxy must serve on default http port (Note: Please do not remove stats socket /var/lib/haproxy/stats entry from haproxy default config.).

b. Once done, you can access the website using curl http://localhost:80 on the LBR server.

Introduction

Load balancing is a critical component of modern infrastructure, ensuring high availability, scalability, and reliability for web applications. HAProxy (High Availability Proxy) is one of the most popular open-source load balancers, known for its performance, reliability, and rich feature set. It is widely used in production environments to distribute traffic across multiple backend servers.

This guide covers the complete process of installing and configuring HAProxy on a load balancer server to distribute traffic to multiple application servers running Apache. The tutorial is based on a real-world scenario where a static website needed to be load balanced across three app servers in a datacenter environment.

Understanding HAProxy

What is HAProxy

HAProxy is a free, open-source software that provides high availability load balancing and proxying for TCP and HTTP-based applications. It is written in C and is known for its high performance, reliability, and low resource consumption.

Key Features

HAProxy offers several features that make it ideal for production environments. It supports layer 4 (TCP) and layer 7 (HTTP) load balancing. Various load balancing algorithms are available, including round-robin, least connections, and source IP hash. Health checks ensure traffic is only sent to healthy backend servers. SSL/TLS termination and session persistence are supported. A statistics interface provides real-time monitoring.

HAProxy Architecture

HAProxy acts as an intermediary between clients and backend servers. Clients connect to HAProxy, which then forwards requests to one of the available backend servers based on the configured load balancing algorithm.

Component	Description
Frontend	Defines how requests are received
Backend	Defines the servers that will handle requests
Listen	Combines frontend and backend in one section
Global	Process-wide settings
Defaults	Default parameters for all sections

Prerequisites

Before beginning, ensure the following are available:

Access to the load balancer server (stlb01) with root or sudo privileges
App servers configured and running Apache on port 8087
Network connectivity between the LBR server and app servers
Basic understanding of Linux networking and web servers

Server Details for This Tutorial

Detail	Value
LBR Server	stlb01
User	loki
Password	Mischi3f
App Server 1	stapp01 (Apache on port 8087)
App Server 2	stapp02 (Apache on port 8087)
App Server 3	stapp03 (Apache on port 8087)
HAProxy Port	80

Installing HAProxy

Connect to the load balancer server and switch to root.

ssh loki@stlb01
sudo su -

Install HAProxy using the system package manager.

yum install -y haproxy

The installation includes HAProxy and its dependencies.

Understanding the Default Configuration

The default HAProxy configuration file is located at /etc/haproxy/haproxy.cfg. It contains global settings, defaults, a frontend, and a backend.

cat /etc/haproxy/haproxy.cfg

The default configuration includes a stats socket at /var/lib/haproxy/stats which must be preserved. It also includes default frontend and backend sections that need to be modified.

Configuring HAProxy

Step 1: Backup the Original Configuration

Always backup the original configuration before making changes.

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

Step 2: Edit the Configuration File

Edit the configuration file to add the correct frontend and backend sections.

vi /etc/haproxy/haproxy.cfg

Step 3: Complete Configuration

Replace the configuration with the following content.

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats
    ssl-default-bind-ciphers PROFILE=SYSTEM
    ssl-default-server-ciphers PROFILE=SYSTEM

#---------------------------------------------------------------------
# common defaults
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

#---------------------------------------------------------------------
# Main frontend
#---------------------------------------------------------------------
frontend main
    bind *:80
    default_backend app

#---------------------------------------------------------------------
# Backend for app servers
#---------------------------------------------------------------------
backend app
    balance roundrobin
    server stapp01 stapp01:8087 check
    server stapp02 stapp02:8087 check
    server stapp03 stapp03:8087 check

Step 4: Configuration Explanation

Section	Parameter	Description
global	stats socket	Unix socket for stats (must be preserved)
defaults	mode http	Operate in HTTP mode
defaults	timeout	Various timeout settings
frontend	bind *:80	Listen on all interfaces on port 80
frontend	default_backend	Send traffic to backend named app
backend	balance roundrobin	Use round-robin load balancing
backend	server	Define backend servers with health checks

Verifying the Configuration

Before restarting HAProxy, verify the configuration is valid.

haproxy -c -f /etc/haproxy/haproxy.cfg

Expected output:

Configuration file is valid

Starting and Enabling HAProxy

Start the HAProxy service and enable it to start on boot.

systemctl start haproxy
systemctl enable haproxy
systemctl status haproxy

The status output should show the service is active and running.

Verifying the Setup

Check Listening Ports

ss -tlnp | grep :80

Expected output shows HAProxy listening on port 80.

LISTEN 0 3000 0.0.0.0:80 0.0.0.0:* users:(("haproxy",pid=59036,fd=7))

Test with Curl

curl http://localhost:80

Expected output:

Welcome to xFusionCorp Industries!

Test Round-Robin Load Balancing

Run multiple curl commands to verify traffic is distributed across all backend servers.

for i in {1..6}; do curl -s http://localhost:80; echo; done

Check Backend Health

Test each backend server directly to ensure they are reachable.

curl -I http://stapp01:8087
curl -I http://stapp02:8087
curl -I http://stapp03:8087

Expected output shows HTTP 200 OK for each server.

Troubleshooting Common Issues

503 Service Unavailable

When HAProxy returns a 503 error, it means no backend server is available. This typically indicates that HAProxy cannot reach the backend servers.

Cause 1: Incorrect IP Addresses or Hostnames

If the backend servers are configured with wrong IP addresses or hostnames that don't resolve, HAProxy cannot connect.

Fix: Use hostnames that resolve correctly.

# Check if hostnames resolve
getent hosts stapp01
getent hosts stapp02
getent hosts stapp03

# Update configuration to use hostnames
backend app
    balance roundrobin
    server stapp01 stapp01:8087 check
    server stapp02 stapp02:8087 check
    server stapp03 stapp03:8087 check

Cause 2: Backend Servers Not Running

If Apache is not running on the app servers, HAProxy cannot connect.

Fix: Start Apache on each app server.

ssh tony@stapp01
sudo systemctl start httpd
sudo systemctl enable httpd

Cause 3: Firewall Blocking Connections

If a firewall is blocking port 8087 on the app servers, HAProxy cannot connect.

Fix: Allow port 8087 on each app server.

sudo firewall-cmd --zone=public --add-port=8087/tcp --permanent
sudo firewall-cmd --reload

Configuration File Errors

When HAProxy fails to start, check the configuration syntax.

haproxy -c -f /etc/haproxy/haproxy.cfg

Common errors include duplicate section names, invalid syntax, or missing parameters.

Duplicate Section Names

HAProxy does not allow duplicate frontend or backend names. Ensure each section has a unique name.

# Check for duplicates
grep -n "^frontend\|^backend" /etc/haproxy/haproxy.cfg

Port Already in Use

If port 80 is already in use by another service, HAProxy fails to start.

ss -tlnp | grep :80

Identify and stop the conflicting service.

Checking Logs

HAProxy logs can be checked using journalctl.

journalctl -u haproxy -n 50

Best Practices

Always Backup Configuration

Before making changes, back up the configuration file.

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

Preserve the Stats Socket

The stats socket at /var/lib/haproxy/stats is used for monitoring and management. Do not remove this entry.

stats socket /var/lib/haproxy/stats

Use Health Checks

Always configure health checks to ensure traffic is only sent to healthy servers.

server stapp01 stapp01:8087 check

Test Configuration Before Restart

Always verify the configuration before restarting the service.

haproxy -c -f /etc/haproxy/haproxy.cfg

Monitor Backend Health

Use the HAProxy stats interface to monitor backend health.

echo "show stat" | socat stdio /var/lib/haproxy/stats

Document Configuration Changes

Maintain documentation of configuration changes for auditing and troubleshooting.

Automation Script

#!/bin/bash

echo "Installing and Configuring HAProxy"
echo "==================================="

# Install HAProxy
yum install -y haproxy

# Backup original configuration
cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

# Write new configuration
cat > /etc/haproxy/haproxy.cfg << 'EOF'
global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats
    ssl-default-bind-ciphers PROFILE=SYSTEM
    ssl-default-server-ciphers PROFILE=SYSTEM

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend main
    bind *:80
    default_backend app

backend app
    balance roundrobin
    server stapp01 stapp01:8087 check
    server stapp02 stapp02:8087 check
    server stapp03 stapp03:8087 check
EOF

# Verify configuration
haproxy -c -f /etc/haproxy/haproxy.cfg

# Start and enable HAProxy
systemctl start haproxy
systemctl enable haproxy

# Verify
systemctl status haproxy
ss -tlnp | grep :80
curl http://localhost:80

Conclusion

Summary of the Setup

HAProxy has been successfully installed and configured on the load balancer server. The frontend listens on port 80 and distributes traffic to three backend app servers running Apache on port 8087. The round-robin algorithm ensures even distribution of requests. Health checks ensure traffic is only sent to healthy servers.

Key Takeaways

HAProxy is a powerful and efficient load balancer for HTTP and TCP applications. The stats socket at /var/lib/haproxy/stats must be preserved. Backend servers should be referenced by hostnames or reachable IP addresses. Health checks are essential for ensuring high availability. Configuration should always be verified before restarting the service.

Verification Results

Check	Result
Configuration valid	Yes
Service active	Yes
Listening on port 80	Yes
Backend servers reachable	Yes
Website accessible	Yes

Final Configuration

frontend main
    bind *:80
    default_backend app

backend app
    balance roundrobin
    server stapp01 stapp01:8087 check
    server stapp02 stapp02:8087 check
    server stapp03 stapp03:8087 check

Additional Resources

Manual Pages

man haproxy - HAProxy documentation
man haproxy.cfg - Configuration file reference
man socat - Socket cat for stats

Useful Commands

Command	Purpose
`haproxy -c -f /etc/haproxy/haproxy.cfg`	Verify configuration
`systemctl status haproxy`	Check service status
`ss -tlnp \	grep :80`
`curl http://localhost:80`	Test the load balancer
`echo "show stat" \	socat stdio /var/lib/haproxy/stats`

Day 78: Jenkins Conditional Pipeline

Janak Shrestha — Fri, 18 Sep 2026 16:55:22 +0000

The development team of xFusionCorp Industries is working on to develop a new static website and they are planning to deploy the same on Nautilus App Server using Jenkins pipeline. They have shared their requirements with the DevOps team and accordingly we need to create a Jenkins pipeline job. Please find below more details about the task:

Click on the Jenkins button on the top bar to access the Jenkins UI. Login using username admin and password Adm!n321.

Similarly, click on the Gitea button on the top bar to access the Gitea UI. Login using username sarah and password Sarah_pass123. There under user sarah you will find a repository named web_app that is already cloned on App Server 1 under /var/www/html. sarah is a developer who is working on this repository.

Add a slave node named App Server 1. It should be labeled as stapp01 and its remote root directory should be /home/sarah/jenkins_agent (the repository is cloned under /var/www/html).
We have already cloned repository on App Server 1 under /var/www/html.
Apache is already installed on the app server and is running on port 8080.
Create a Jenkins pipeline job named xfusion-webapp-job (it must not be a Multibranch pipeline) and configure it to:
- Add a string parameter named BRANCH.
- It should conditionally deploy the code from web_app repository under /var/www/html on App Server 1, as this is the document root of the app server. The pipeline should have a single stage named Deploy ( which is case sensitive ) to accomplish the deployment.
- The pipeline should be conditional, if the value master is passed to the BRANCH parameter then it must deploy the master branch, on the other hand if the value feature is passed to the BRANCH parameter then it must deploy the feature branch.

LB server is already configured. You should be able to see the latest changes you made by clicking on the App button. Please make sure the required content is loading on the main URL https://<LBR-URL> i.e there should not be a sub-directory like https://<LBR-URL>/web_app etc.

Note:

You might need to install some plugins and restart Jenkins service. So, we recommend clicking on Restart Jenkins when installation is complete and no jobs are running on plugin installation/update page i.e update centre. Also, Jenkins UI sometimes gets stuck when Jenkins service restarts in the back end. In this case, please make sure to refresh the UI page.
For these kind of scenarios requiring changes to be done in a web UI, please take screenshots so that you can share it with us for review in case your task is marked incomplete. You may also consider using a screen recording software such as loom.com to record and share your work.

Understanding the Architecture

┌───────────────────────────────────────────────────────────────┐
│           Jenkins Controller (jenkins server)                 │
│                                                               │
│  Job: xfusion-webapp-job                                      │
│  Parameters:                                                  │
│    BRANCH (string, default: master)                           │
│                                                               │
│  Pipeline:                                                    │
│    agent: label 'stapp01'                                     │
│    stage: Deploy                                              │
│      if BRANCH == master  → git checkout master               │
│      if BRANCH == feature → git checkout feature              │
└──────────────────┬────────────────────────────────────────────┘
                   │
                   │ SSH (sarah user)
                   ▼
┌───────────────────────────────────────────────────────────────┐
│           Jenkins Agent (App Server 1 / stapp01)              │
│                                                               │
│  Workspace: /home/sarah/jenkins_agent/workspace/...           │
│  Repository: /var/www/html (sarah/web_app)                    │
│  Apache: port 8080                                            │
└──────────────────┬────────────────────────────────────────────┘
                   │
                   │ HTTP
                   ▼
┌───────────────────────────────────────────────────────────────┐
│                 Load Balancer (LBR)                           │
│              Routes to App Server 1:8080                      │
│                https://<LBR-URL>                              │
└───────────────────────────────────────────────────────────────┘

Task Requirements

Requirement	Details
Job Name	`xfusion-webapp-job`
Job Type	Pipeline (NOT Multibranch)
Agent Node	App Server 1
Agent Label	`stapp01`
Remote Root Directory	`/home/sarah/jenkins_agent`
String Parameter	`BRANCH`
Stage Name	`Deploy` (case sensitive)
Repository	`sarah/web_app` (Gitea)
Deploy Path	`/var/www/html`
Conditional Logic	`BRANCH=master` → deploy master; `BRANCH=feature` → deploy feature

Part 1: Prepare the Infrastructure

Step 1: SSH to Jenkins Server

ssh jenkins@jenkins
# Password: j@rv!s

Step 2: Generate SSH Key (if missing)

ls -la ~/.ssh/id_rsa

# If missing:
ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa
cat ~/.ssh/id_rsa   # Copy this for Jenkins credentials

Step 3: Copy SSH Key to `sarah` on App Server 1

ssh-copy-id -o StrictHostKeyChecking=no sarah@stapp01
# Password: Sarah_pass123

# Verify passwordless access
ssh -o StrictHostKeyChecking=no sarah@stapp01 hostname

Expected output:

stapp01

Step 4: Install Java 21 on App Server 1

Jenkins agents require Java 17 or higher. Java 11 causes UnsupportedClassVersionError.

ssh -t sarah@stapp01 "sudo yum install -y java-21-openjdk"
# Password: Sarah_pass123

Register Java 21 as an alternative and set it as default:

ssh sarah@stapp01 "echo 'Sarah_pass123' | sudo -S alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java 2000"
ssh sarah@stapp01 "echo 'Sarah_pass123' | sudo -S alternatives --set java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java"

Verify:

ssh sarah@stapp01 "java -version"

Expected output:

openjdk version "21.0.12.1" 2026-08-18 LTS

Step 5: Create the Agent Directory

ssh sarah@stapp01 "mkdir -p /home/sarah/jenkins_agent"

Part 2: Install Required Jenkins Plugins

Jenkins requires several plugins for SSH-based agents and declarative pipelines.

Log in to Jenkins as admin / Adm!n321
Navigate to Manage Jenkins → Plugins → Available plugins
Install the following:

Plugin	Purpose
Credentials	Core credential management
Credentials Binding	Bind credentials to build environment
SSH Credentials	Adds "SSH Username with private key" option
SSH Build Agents	Launch agents via SSH
Pipeline	Core Pipeline functionality
Pipeline: Declarative	Enables the `pipeline { }` syntax

Restart Jenkins when prompted (select Restart Jenkins when installation is complete and no jobs are running)
Refresh the UI page after the restart

Part 3: Add SSH Credentials

Navigate to Manage Jenkins → Credentials → System → Global credentials (unrestricted)
Click Add Credentials
Select SSH Username with private key → Next
Configure:
- ID: sarah-stapp01-credentials
- Description: Sarah SSH credentials for App Server 1
- Username: sarah
- Private Key: Select Enter directly → paste the private key from ~/.ssh/id_rsa
Click Create

Part 4: Add the Jenkins Agent Node

Navigate to Manage Jenkins → Nodes → New Node
Name: App Server 1
Select Permanent Agent → OK
Configure:

Field	Value
Remote root directory	/home/sarah/jenkins_agent
Labels	stapp01
Usage	Use this node as much as possible
Launch method	Launch agents via SSH
Host	stapp01
Credentials	sarah-stapp01-credentials
Host Key Verification Strategy	Non-verifying Verification Strategy

Click Save
Verify the node shows Online with a green checkmark

Agent log should show:

Agent successfully connected and online

Note: The JavaPath advanced option is not required here because the default java in PATH already points to Java 21.

Part 5: Create the Conditional Pipeline Job

Step 1: Create a New Pipeline Job

From the Jenkins Dashboard, click New Item
Enter name: xfusion-webapp-job
Select Pipeline (NOT Multibranch Pipeline)
Click OK

Step 2: Add the `BRANCH` Parameter

In the General section, check This project is parameterized
Click Add Parameter → String Parameter
Configure:
- Name: BRANCH
- Default Value: master
- Description: Enter the branch to deploy (master or feature)

Step 3: Configure the Pipeline Script

Scroll down to the Pipeline section and enter:

pipeline {
    agent { label 'stapp01' }

    parameters {
        string(name: 'BRANCH', defaultValue: 'master', description: 'Enter the branch to deploy (master or feature)')
    }

    stages {
        stage('Deploy') {
            steps {
                script {
                    if (params.BRANCH == 'master') {
                        sh '''
                            cd /var/www/html
                            git config --global --add safe.directory /var/www/html
                            git fetch origin master
                            git checkout master
                            git reset --hard origin/master
                        '''
                    } else if (params.BRANCH == 'feature') {
                        sh '''
                            cd /var/www/html
                            git config --global --add safe.directory /var/www/html
                            git fetch origin feature
                            git checkout feature
                            git reset --hard origin/feature
                        '''
                    } else {
                        error("Invalid BRANCH value: ${params.BRANCH}. Allowed values: master, feature")
                    }
                }
            }
        }
    }
}

Explanation of the Script

Line	Purpose
`agent { label 'stapp01' }`	Runs the pipeline on the agent node
`parameters { string(...) }`	Declares the `BRANCH` parameter
`stage('Deploy')`	Single stage named Deploy (case sensitive)
`script { ... }`	Enables Groovy conditional logic
`if (params.BRANCH == 'master')`	Checks if BRANCH is `master`
`git fetch origin master`	Fetches the latest from the master branch
`git checkout master`	Switches to the master branch
`git reset --hard origin/master`	Ensures the working tree matches the remote exactly
`else if (params.BRANCH == 'feature')`	Checks if BRANCH is `feature`
`error(...)`	Fails the pipeline for invalid values

Step 4: Save the Job

Click Save at the bottom of the page.

Part 6: Verify the Feature Branch Exists

Before testing the feature deployment, ensure the feature branch exists in the Gitea repository.

Click the Gitea button on the top bar
Login as sarah / Sarah_pass123
Open the web_app repository
If feature branch doesn't exist:
- Click the branch selector → New Branch
- Name: feature
- Base: master
- Click Create Branch
Commit a small change to the feature branch to differentiate it from master

Part 7: Test Both Deployments

Test 1: Deploy `master` Branch

In Jenkins, click Build with Parameters
Set BRANCH = master
Click Build
Check the Console Output

Expected Output:

Started by user admin
[Pipeline] Start of Pipeline
[Pipeline] node
Running on App Server 1 in /home/sarah/jenkins_agent/workspace/xfusion-webapp-job
[Pipeline] stage
[Pipeline] { (Deploy)
[Pipeline] sh
+ cd /var/www/html
+ git config --global --add safe.directory /var/www/html
+ git fetch origin master
+ git checkout master
+ git reset --hard origin/master
HEAD is now at <hash> <master-commit-message>
[Pipeline] }
[Pipeline] // stage
[Pipeline] End of Pipeline
Finished: SUCCESS

Test 2: Deploy `feature` Branch

Click Build with Parameters again
Set BRANCH = feature
Click Build
Check the Console Output

Expected Output:

+ git fetch origin feature
+ git checkout feature
+ git reset --hard origin/feature
HEAD is now at 4a8b390 Added feature.html file
Finished: SUCCESS

Verification

Verify on App Server 1

ssh sarah@stapp01 "cd /var/www/html && git branch --show-current && git log -1 --oneline"

Expected: Branch matches the last deployed branch (master or feature).

Verify via Load Balancer

Click the App button on the top bar
Confirm the website loads at the root URL (https://<LBR-URL>)
Verify the URL does not have a subdirectory like /web_app

Complete Configuration Summary

Setting	Value
Job Name	xfusion-webapp-job
Job Type	Pipeline
Parameter Name	BRANCH
Parameter Type	String Parameter
Default Value	master
Agent Label	stapp01
Stage Name	Deploy
Deploy Path	/var/www/html

Troubleshooting

Issue	Cause	Solution
`git fetch origin feature` fails	Branch doesn't exist on remote	Create the feature branch in Gitea
"dubious ownership" Git error	Modern Git requires safe.directory	Add `git config --global --add safe.directory` in the pipeline
Permission denied on /var/www/html	Directory not owned by sarah	Run `sudo chown -R sarah:sarah /var/www/html`
Invalid BRANCH value error	Wrong input	Use exactly `master` or `feature` (case sensitive)
`params.BRANCH` is null	Parameter not declared	Add the `parameters { string(...) }` block
Credentials/Pipeline options missing	Plugins not installed	Install Credentials, SSH Credentials, and Pipeline plugins

Task Summary

Requirement	Status
Agent node `App Server 1` online	✅
Label `stapp01`	✅
Remote root `/home/sarah/jenkins_agent`	✅
String parameter `BRANCH` added	✅
Pipeline job `xfusion-webapp-job` created	✅
Single stage named `Deploy`	✅
Conditional deploy (master vs feature)	✅
Website accessible at root URL	✅

Key Learnings

Parameterized Pipelines: The parameters block lets jobs accept user inputs at build time, making them more flexible and reusable.
Conditional Logic in Declarative Pipelines: The script { } block enables Groovy-based conditionals such as if/else inside declarative syntax.
Exact Branch Matching: Using git fetch + git checkout + git reset --hard guarantees the local branch matches the remote exactly, avoiding stale files or merge conflicts.
Failing Fast: Using error(...) for invalid inputs prevents unexpected behavior and makes debugging easy.
Reusability: A single pipeline job handles multiple branches, reducing the number of jobs needed for different deployment scenarios.
Load Balancer Routing: Regardless of which branch is deployed, content must be served from /var/www/html root for the LB to route correctly.

Conclusion

In this challenge, we extended our Jenkins deployment pipeline with a conditional mechanism driven by a BRANCH string parameter. The same job now:

Deploys the master branch when BRANCH=master is passed
Deploys the feature branch when BRANCH=feature is passed
Fails with a clear error message for any other value

This pattern is common in real-world CI/CD pipelines where a single job handles multiple environments or branches, using parameters and conditionals to route deployment logic.

The pipeline now provides a flexible, reusable deployment mechanism through the Load Balancer at the root URL, and developers can trigger deployments for either branch directly from the Jenkins UI.

Next Steps

To further enhance this pipeline:

Add more branches: Use a choice parameter to present available branches
Environment-specific deployments: Deploy to different servers based on the branch
Post-Build Notifications: Send Slack or email notifications on success/failure
Webhook Integration: Automatically trigger builds on Gitea push events
Rollback: Add a stage to roll back to the previous commit on failure

Linux Postfix Troubleshooting

Janak Shrestha — Thu, 17 Sep 2026 17:00:02 +0000

Introduction

Postfix is one of the most widely used Mail Transfer Agents (MTAs) in Linux environments. It is known for its security, performance, and reliability. However, like any complex service, Postfix can encounter configuration issues that prevent it from functioning correctly.

This guide covers a real-world troubleshooting scenario where the Postfix service on a mail server was failing due to duplicate configuration entries in the main configuration file. The issue caused mail delivery problems and prevented remote servers from connecting to the mail server.

Understanding the Problem

The Scenario

Users of a monitoring application reported issues with the company mail server. The Postfix service appeared to fail intermittently. The mail server was located in the Stork DC and used Postfix as its Mail Transfer Agent.

Symptoms Observed

When checking the Postfix service status, the following symptoms were present. The service showed as inactive when first checked. After starting, the service ran but generated numerous warnings in the logs. The configuration check command produced warnings about overriding entries. Remote connections to the mail server on port 25 failed.

Initial Diagnosis

The first step was to check the service status and configuration.

systemctl status postfix

The output showed the service was inactive. After enabling and starting the service, warnings appeared in the logs.

postfix check

This command revealed the root cause: warnings about overriding earlier entries in the configuration file.

Root Cause Analysis

Identifying the Duplicate Entries

The warnings pointed to a specific line in the Postfix configuration file. To identify all occurrences of the problematic parameter, the following command was used.

grep -n "inet_interfaces" /etc/postfix/main.cf

The output revealed the issue clearly.

122:# The inet_interfaces parameter specifies the network interface
132:inet_interfaces = all
133:#inet_interfaces = $myhostname
134:#inet_interfaces = $myhostname, localhost
135:inet_interfaces = localhost
143:# the address list specified with the inet_interfaces parameter.
173:# receives mail on (see the inet_interfaces parameter).

Understanding the Problem

There were two active inet_interfaces entries:

Line	Entry	Status
132	`inet_interfaces = all`	Active
135	`inet_interfaces = localhost`	Active

Because line 135 appeared later in the file, it overrode line 132. This meant Postfix was configured to listen only on the loopback interface (127.0.0.1) instead of all network interfaces.

Why This Causes Problems

When Postfix listens only on localhost, it can only receive connections from the local machine. Remote servers, monitoring applications, and other clients cannot connect to the mail server. This explains why the monitoring app users experienced issues.

The Solution

Step 1: Backup the Configuration

Before making any changes, always create a backup of the configuration file.

cp /etc/postfix/main.cf /etc/postfix/main.cf.bak

Step 2: Fix the Duplicate Entry

Comment out or remove the duplicate inet_interfaces line. In this case, line 135 was commented out.

sed -i '135s/^inet_interfaces/#inet_interfaces/' /etc/postfix/main.cf

Alternatively, the line could be removed entirely.

sed -i '/^inet_interfaces = localhost/d' /etc/postfix/main.cf

Step 3: Verify the Fix

Confirm that only one active inet_interfaces entry remains.

grep -n "^inet_interfaces" /etc/postfix/main.cf

Expected output:

132:inet_interfaces = all

Step 4: Check Configuration

Run the Postfix configuration check to ensure there are no errors.

postfix check

A successful check produces no output.

Step 5: Restart Postfix

Restart the service to apply the changes.

systemctl restart postfix
systemctl status postfix

Step 6: Verify Listening Ports

Confirm that Postfix is now listening on all interfaces.

ss -tlnp | grep :25

Expected output shows 0.0.0.0:25 and [::]:25, indicating all interfaces.

Verification and Results

Service Status After Fix

● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: disabled)
     Active: active (running) since Thu 2026-09-17 16:53:47 UTC; 24ms ago
   Main PID: 9390 (master)
      Tasks: 3 (limit: 404516)
     Memory: 3.5M
     CGroup: /system.slice/postfix.service
             ├─9390 /usr/libexec/postfix/master -w
             ├─9391 pickup -l -t unix -u
             └─9392 qmgr -l -t unix -u

Listening Ports After Fix

LISTEN 0 100 0.0.0.0:25 0.0.0.0:* users:(("master",pid=9390,fd=13))
LISTEN 0 100   [::]:25   [::]:* users:(("master",pid=9390,fd=14))

Configuration Check After Fix

postfix check

No output, indicating a clean configuration.

Comparison Table

Check	Before	After
Active `inet_interfaces` entries	2	1
`postfix check` warnings	Yes	No
Listening address	127.0.0.1:25	0.0.0.0:25
Remote connectivity	Failed	Working
Service status	Warnings	Clean

Understanding Postfix Configuration

The main.cf File

The /etc/postfix/main.cf file is the primary configuration file for Postfix. It contains parameters that control how Postfix operates. Each parameter is specified as parameter = value.

Duplicate Parameters

When a parameter appears multiple times, Postfix uses the last occurrence. However, it generates a warning about the earlier entry being overridden. This behavior is important to understand because it can lead to unexpected configurations.

The inet_interfaces Parameter

The inet_interfaces parameter specifies which network interfaces Postfix listens on. Common values include:

Value	Meaning
all	Listen on all interfaces
localhost	Listen only on loopback (127.0.0.1)
127.0.0.1	Listen only on loopback
$myhostname	Listen on the host's IP address
eth0	Listen on a specific interface

For a mail server that needs to receive mail from other servers, inet_interfaces = all is the correct setting.

Common Postfix Configuration Issues

Issue 1: Duplicate Parameters

Duplicate parameters cause warnings and unpredictable behavior. Use grep to find duplicates.

grep -n "^parameter_name" /etc/postfix/main.cf

Remove duplicates by editing the file or using sed.

Issue 2: Incorrect Hostname

The myhostname parameter must be a fully qualified domain name.

myhostname = stmail01.stratos.xfusioncorp.com

Verify with hostname -f and check /etc/hosts.

Issue 3: Missing Mail Directory

Postfix requires the mail directory to exist and have correct permissions.

mkdir -p /home/user/Maildir/{cur,new,tmp}
chown -R user:user /home/user/Maildir

Issue 4: Port Conflicts

If port 25 is already in use, Postfix fails to start.

ss -tlnp | grep :25

Identify and stop the conflicting service.

Issue 5: Permission Problems

Postfix requires specific permissions on its directories.

ls -la /var/spool/postfix/
ls -la /etc/postfix/

Fix permissions if needed.

Best Practices for Postfix Configuration

Always Backup Before Changes

Create a backup of the configuration file before making changes.

cp /etc/postfix/main.cf /etc/postfix/main.cf.bak

Use postfix check

Always run the configuration check after making changes.

postfix check

Review Configuration Regularly

Periodically review the configuration for duplicate or outdated entries.

grep -c "^parameter_name" /etc/postfix/main.cf

Test After Changes

Restart the service and verify it is running correctly.

systemctl restart postfix
systemctl status postfix
ss -tlnp | grep :25

Monitor Logs

Regularly check Postfix logs for errors and warnings.

journalctl -u postfix -n 50
tail -f /var/log/maillog

Document Changes

Maintain a record of configuration changes for troubleshooting and audit purposes.

Troubleshooting Workflow

Step 1: Check Service Status

systemctl status postfix

Step 2: Check Configuration

postfix check

Step 3: Check Logs

journalctl -u postfix -n 50

Step 4: Identify Duplicate Parameters

grep -n "^parameter_name" /etc/postfix/main.cf

Step 5: Fix the Configuration

Edit the file to remove duplicates or correct errors.

Step 6: Verify the Fix

postfix check

Step 7: Restart the Service

systemctl restart postfix

Step 8: Verify Listening Ports

ss -tlnp | grep :25

Conclusion

Summary of the Fix

The Postfix service on the mail server was failing due to duplicate inet_interfaces entries in the configuration file. The last entry, inet_interfaces = localhost, was overriding the intended setting of inet_interfaces = all. This caused Postfix to listen only on the loopback interface, preventing remote connections.

The fix involved commenting out the duplicate entry, verifying the configuration, and restarting the service. After the fix, Postfix was listening on all interfaces, and the monitoring application could connect properly.

Key Takeaways

Duplicate configuration parameters in Postfix can cause unexpected behavior. The grep command is useful for identifying duplicates. The postfix check command validates the configuration. Always backup configuration files before making changes. Verify listening ports after restarting the service. Understanding the inet_interfaces parameter is essential for mail server configuration.

Final Configuration

inet_interfaces = all

Final Service Status

Active: active (running)

Final Listening Ports

LISTEN 0 100 0.0.0.0:25 0.0.0.0:*
LISTEN 0 100   [::]:25   [::]:*

Additional Resources

Manual Pages

man postfix - Postfix documentation
man main.cf - Postfix configuration parameters
man postconf - Postfix configuration tool
man postfix-check - Configuration check

Useful Commands

Command	Purpose
`postfix check`	Validate configuration
`postconf -n`	Show non-default parameters
`postconf -d`	Show default parameters
`mailq`	Show mail queue
`postsuper -d ALL`	Delete all queued mail

Day 77: Jenkins Deploy Pipeline

Janak Shrestha — Thu, 17 Sep 2026 16:42:56 +0000

Click on the Jenkins button on the top bar to access the Jenkins UI. Login using username admin and password Adm!n321.

Add a slave node named App Server 1. It should be labeled as stapp01 and its remote root directory should be /home/sarah/jenkins_agent (the repository is cloned under /var/www/html; the agent uses a separate directory so it does not pollute the repo).
We have already cloned repository on App Server 1 under /var/www/html.
Apache is already installed on the app server and is running on port 8080.
Create a Jenkins pipeline job named xfusion-webapp-job (it must not be a Multibranch pipeline) and configure it to:

- Deploy the code from `web_app` repository under `/var/www/html` on **App Server 1**, as this is the document root of the app server. The pipeline should have a single stage named `Deploy` ( which is case sensitive ) to accomplish the deployment.

Note:

You might need to install some plugins and restart Jenkins service. So, we recommend clicking on Restart Jenkins when installation is complete and no jobs are running on plugin installation/update page i.e update centre. Also, Jenkins UI sometimes gets stuck when Jenkins service restarts in the back end. In this case, please make sure to refresh the UI page.
For these kind of scenarios requiring changes to be done in a web UI, please take screenshots so that you can share it with us for review in case your task is marked incomplete. You may also consider using a screen recording software such as loom.com to record and share your work.

Understanding the Architecture

┌───────────────────────────────────────────────────────────────┐
│           Jenkins Controller (jenkins server)                 │
│                                                               │
│  Job: xfusion-webapp-job                                      │
│  ├── agent: label 'stapp01'                                   │
│  └── stages:                                                  │
│      └── Deploy: git pull in /var/www/html                    │
└──────────────────┬────────────────────────────────────────────┘
                   │
                   │ SSH (sarah user)
                   ▼
┌───────────────────────────────────────────────────────────────┐
│           Jenkins Agent (App Server 1 / stapp01)              │
│                                                               │
│  Workspace: /home/sarah/jenkins_agent/workspace/...           │
│  Repository: /var/www/html (sarah/web_app)                    │
│  Apache: port 8080                                            │
└──────────────────┬────────────────────────────────────────────┘
                   │
                   │ HTTP
                   ▼
┌───────────────────────────────────────────────────────────────┐
│                 Load Balancer (LBR)                           │
│              Routes to App Server 1:8080                      │
│                https://<LBR-URL>                              │
└───────────────────────────────────────────────────────────────┘

Task Requirements

Requirement	Details
Job Name	`xfusion-webapp-job`
Job Type	Pipeline (not Multibranch)
Agent Node	App Server 1
Agent Label	`stapp01`
Remote Root Directory	`/home/sarah/jenkins_agent`
Stage Name	`Deploy` (case sensitive)
Repository	`sarah/web_app` (Gitea)
Deploy Path	`/var/www/html`

Part 1: Configure the Jenkins Agent Node

Step 1: Access Jenkins Server via SSH

ssh jenkins@jenkins
# Password: j@rv!s

Step 2: Generate SSH Key on Jenkins Server

The Jenkins agent runs as the jenkins user, so SSH keys must be generated for that user.

ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa
cat ~/.ssh/id_rsa

Copy the private key output — you'll need it for Jenkins credentials.

Step 3: Copy SSH Key to `sarah` on App Server 1

ssh-copy-id -o StrictHostKeyChecking=no sarah@stapp01
# Password: Sarah_pass123

Verify passwordless SSH:

ssh -o StrictHostKeyChecking=no sarah@stapp01 hostname
# Output: stapp01

Step 4: Install Java 21 on App Server 1

Jenkins agents require Java 17 or higher. Java 11 will cause an UnsupportedClassVersionError.

# Install with TTY allocation for sudo
ssh -t sarah@stapp01 "sudo yum install -y java-21-openjdk"
# Password: Sarah_pass123

Register Java 21 as an alternative and set it as default:

ssh sarah@stapp01 "echo 'Sarah_pass123' | sudo -S alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java 2000"
ssh sarah@stapp01 "echo 'Sarah_pass123' | sudo -S alternatives --set java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java"

Verify:

ssh sarah@stapp01 "java -version"
# Expected: openjdk version "21.0.12.1"

Step 5: Create the Agent Directory

ssh sarah@stapp01 "mkdir -p /home/sarah/jenkins_agent"

Part 2: Install Required Jenkins Plugins

Jenkins does not ship with the plugins needed for SSH agents and pipelines by default. Navigate to Manage Jenkins → Plugins → Available plugins and install:

Plugin	Purpose
Credentials	Core credential management
Credentials Binding	Bind credentials to build environment
SSH Credentials	Adds "SSH Username with private key" option
SSH Build Agents	Launch agents via SSH
Pipeline	Core Pipeline functionality
Pipeline: Declarative	Enables the `pipeline { }` syntax

After installing, select Restart Jenkins when installation is complete and no jobs are running. Refresh the UI page after Jenkins restarts.

Part 3: Add SSH Credentials

Navigate to Manage Jenkins → Credentials → System → Global credentials (unrestricted)
Click Add Credentials
Select SSH Username with private key and click Next
Configure:
- ID: sarah-stapp01-credentials
- Description: Sarah SSH credentials for App Server 1
- Username: sarah
- Private Key: Select Enter directly and paste the private key from Step 2
Click Create

Part 4: Add the Jenkins Agent Node

Navigate to Manage Jenkins → Nodes → New Node
Name: App Server 1
Select Permanent Agent → OK
Configure:

Field	Value
Remote root directory	/home/sarah/jenkins_agent
Labels	stapp01
Usage	Use this node as much as possible
Launch method	Launch agents via SSH
Host	stapp01
Credentials	sarah-stapp01-credentials
Host Key Verification Strategy	Non-verifying Verification Strategy

Click Save

Verify the Node is Online

Go to Manage Jenkins → Nodes. The node should show Online with a green checkmark. The agent log will show:

Agent successfully connected and online

Note on JavaPath: In this setup, the JavaPath advanced option is not required because the default java command in the agent's PATH already points to Java 21.

Part 5: Create the Pipeline Job

Step 1: Create a New Pipeline Job

From the Jenkins Dashboard, click New Item
Enter name: xfusion-webapp-job
Select Pipeline (NOT Multibranch Pipeline)
Click OK

Step 2: Configure the Pipeline Script

Scroll to the Pipeline section and enter:

pipeline {
    agent { label 'stapp01' }

    stages {
        stage('Deploy') {
            steps {
                sh '''
                    cd /var/www/html
                    git config --global --add safe.directory /var/www/html
                    git pull origin master
                '''
            }
        }
    }
}

Explanation of the Script

Line	Purpose
`agent { label 'stapp01' }`	Runs the pipeline on the node with label `stapp01`
`stage('Deploy')`	Defines a single stage named Deploy (case sensitive)
`sh '''...'''`	Executes shell commands on the agent (as `sarah`)
`cd /var/www/html`	Navigates to the Apache document root
`git config --global --add safe.directory /var/www/html`	Prevents "dubious ownership" errors (Git 2.35.2+)
`git pull origin master`	Pulls the latest code from Gitea

Step 3: Save and Build

Click Save
Click Build Now
Click on the build number → Console Output

Expected Console Output

Started by user admin
[Pipeline] Start of Pipeline
[Pipeline] node
Running on App Server 1 in /home/sarah/jenkins_agent/workspace/xfusion-webapp-job
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Deploy)
[Pipeline] sh
+ cd /var/www/html
+ git config --global --add safe.directory /var/www/html
+ git pull origin master
From http://gitea:3000/sarah/web_app
 * branch            master     -> FETCH_HEAD
Already up to date.
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS

Verification

Verify on App Server 1

ssh sarah@stapp01 "cd /var/www/html && git log -1 --oneline"

Verify via Load Balancer

Click the App button on the top bar
Confirm the website loads at the root URL (https://<LBR-URL>)
Ensure no subdirectory appears in the URL (e.g., NOT https://<LBR-URL>/web_app)

Test End-to-End

Log in to Gitea as sarah (password: Sarah_pass123)
Make a change to a file in the web_app repository
Commit and push
In Jenkins, click Build Now for xfusion-webapp-job
Refresh the App page — the new change should be visible

Task Summary

Requirement	Status
Agent node `App Server 1` added	✅
Label `stapp01`	✅
Remote root `/home/sarah/jenkins_agent`	✅
Agent online	✅
Pipeline job `xfusion-webapp-job`	✅
Single stage named `Deploy`	✅
Deploys `web_app` to `/var/www/html`	✅
Website accessible at root URL	✅

Troubleshooting Reference

Issue	Cause	Solution
Credentials option missing	Credentials plugin not installed	Install Credentials plugin
SSH key option missing	SSH Credentials plugin not installed	Install SSH Credentials plugin
Pipeline option missing	Pipeline plugin not installed	Install Pipeline plugin
`UnsupportedClassVersionError`	Java 11 instead of 21	Install Java 21 and set as default
`sudo: a terminal is required`	No TTY for SSH	Use `ssh -t` or `echo 'pass' \
"dubious ownership" Git error	Modern Git safe.directory	Add {% raw %}`git config --global --add safe.directory`
Agent offline	Java/SSH misconfiguration	Check agent log in Jenkins UI

Key Learnings

Jenkins Agent Architecture: The controller schedules jobs, and agents execute them. Labels are used to target specific nodes.
Pipeline as Code: Declarative pipelines use pipeline { agent { ... } stages { ... } } syntax, providing a clean, version-controllable way to define deployments.
Java Version Compatibility: Jenkins agents require Java 17+. The JavaPath advanced option is only necessary when the default java doesn't point to the correct version.
Plugin Dependencies: Missing plugins hide UI options. The Credentials, SSH Credentials, and Pipeline plugins are essential for this type of workflow.
Git Safe Directory: Modern Git requires explicit safe.directory configuration for non-root users.
Load Balancer Routing: The website must be served from /var/www/html root so the LB routes correctly without a subdirectory.

Conclusion

In this challenge, we successfully:

Generated SSH keys on the Jenkins controller
Copied the public key to sarah on App Server 1
Installed Java 21 and set it as default
Created the agent directory /home/sarah/jenkins_agent
Installed the required Jenkins plugins
Added SSH credentials for sarah
Added the App Server 1 slave node with label stapp01
Created the pipeline job xfusion-webapp-job
Configured a single Deploy stage that pulls the latest code
Verified the deployment through the Load Balancer

The pipeline is now ready to automatically deploy the latest code from the Gitea repository to the Apache document root on App Server 1. The website is accessible through the Load Balancer at the root URL, and developers can trigger deployments by pushing changes to the repository and clicking Build Now (or by adding a webhook for full automation).

Next Steps

To further enhance this pipeline, consider:

Adding a Webhook: Configure a Gitea webhook so that pushes automatically trigger the Jenkins build
Environment Variables: Use parameterized builds for more flexibility
Post-Build Actions: Add notifications (Slack, email) on success/failure
Multi-Stage Pipelines: Extend to build, test, and deploy stages
Rollback Strategy: Implement a rollback mechanism on failure

Day 76: Jenkins Project Security

Janak Shrestha — Wed, 16 Sep 2026 11:19:06 +0000

The xFusionCorp Industries has recruited some new developers. There are already some existing jobs on Jenkins and two of these new developers need permissions to access those jobs. The development team has already shared those requirements with the DevOps team, so as per details mentioned below grant required permissions to the developers.

Click on the Jenkins button on the top bar to access the Jenkins UI. Login using username admin and password Adm!n321. m

There is an existing Jenkins job named Packages, there are also two existing Jenkins users named sam with password sam@pass12345 and rohan with password rohan@pass12345.
Grant permissions to these users to access Packages job as per details mentioned below: a.) Make sure to select Inherit permissions from parent ACL under inheritance strategy for granting permissions to these users. b.) Grant mentioned permissions to sam user : build, configure and read. c.) Grant mentioned permissions to rohan user : build, cancel, configure, read, update and tag.

Note:

Please do not modify/alter any other existing job configuration.
You might need to install some plugins and restart Jenkins service. So, we recommend clicking on Restart Jenkins when installation is complete and no jobs are running on plugin installation/update page i.e update centre. Also Jenkins UI sometimes gets stuck when Jenkins service restarts in the back end. In this case, please make sure to refresh the UI page.
For these kind of scenarios requiring changes to be done in a web UI, please take screenshots so that you can share it with us for review in case your task is marked incomplete. You may also consider using a screen recording software such as loom.com to record and share your work.

Understanding the Requirements

Task Overview

Requirement	Details
Job Name	Packages
Users	sam, rohan
Inheritance Strategy	Inherit permissions from parent ACL
sam's Permissions	build, configure, read
rohan's Permissions	build, cancel, configure, read, update, tag

User Credentials

User	Password
admin	Adm!n321
sam	sam@pass12345
rohan	rohan@pass12345

Understanding Jenkins Security Concepts

What is Project-Based Security?

Project-based security allows you to configure permissions at the individual job level, rather than only at the global level. This provides granular control over who can do what on specific jobs.

Inheritance Strategies

Strategy	Description
Inherit permissions from parent ACL	Combines global permissions with job-specific permissions
Inherit globally defined permissions	Only inherits global permissions
Do not inherit permission grants from other ACLs	Only uses permissions explicitly set on the job

Permission Definitions

Permission	Description
Job/Build	Trigger builds for the job
Job/Cancel	Cancel running builds
Job/Configure	Edit the job's configuration
Job/Read	View the job on the dashboard
Job/Update	Update parameterized builds
SCM/Tag	Create tags in the source code repository

Step-by-Step Implementation

Step 1: Access Jenkins UI

Click the Jenkins button on the top bar
Login with:
- Username: admin
- Password: Adm!n321

Step 2: Install the Matrix Authorization Strategy Plugin

Before configuring project-based security, we need to install the Matrix Authorization Strategy plugin.

Navigate to Manage Jenkins → Plugins
Click on Available plugins
Search for Matrix Authorization Strategy
Check the box and click Install
If prompted, select Restart Jenkins when installation is complete and no jobs are running
Refresh the UI page if needed after Jenkins restarts

Why this plugin? It provides the ability to configure fine-grained permissions at both global and job levels.

Step 3: Configure Global Security (Parent ACL)

This step is critical because users need at least Overall/Read permission to log in and see the Jenkins dashboard.

Go to Manage Jenkins → Configure Global Security
Under Authorization, select Project-based Matrix Authorization Strategy
In the global permission matrix:
- Click Add user → Enter sam → Click OK
- Click Add user → Enter rohan → Click OK
Grant permissions:
- sam: Check Overall/Read
- rohan: Check Overall/Read
- admin: Ensure Overall/Administer is checked (should already be)
Click Save

Step 4: Enable Project-Based Security on the Packages Job

Navigate to the Packages job on the Jenkins dashboard
Click Configure in the left sidebar
In the General section, check the box Enable project-based security

Important Note: The Authorization section (with inheritance strategy and permission matrix) will only appear AFTER you check this box. This is by design — Jenkins shows/hides sections based on the options you select.

Step 5: Configure the Inheritance Strategy

Once you check Enable project-based security, an Authorization section will appear below it.

Under Inheritance Strategy, select:

   Inherit permissions from parent ACL

You will see a description confirming: > "This item will inherit its parent item's permissions (in addition to any permissions granted here). If this item is at the top level in Jenkins, it will inherit the global security settings."

Step 6: Add User `sam` and Grant Permissions

Click the Add user button
Enter the username: sam
Click OK
In the row for sam, check the following permissions:

Permission Category	Permission	Status
Job	Job/Build	✓
Job	Job/Configure	✓
Job	Job/Read	✓

Summary for sam: Job: Build, Configure, Read

Leave all other permissions unchecked for sam.

Step 7: Add User `rohan` and Grant Permissions

Click the Add user button
Enter the username: rohan
Click OK
In the row for rohan, check the following permissions:

Permission Category	Permission	Status
Job	Job/Build	✓
Job	Job/Cancel	✓
Job	Job/Configure	✓
Job	Job/Read	✓
Run	Run/Update	✓
SCM	SCM/Tag	✓

Summary for rohan: Job: Build, Cancel, Configure, Read · Run: Update · SCM: Tag

Leave all other permissions unchecked for rohan.

Step 8: Save the Configuration

Click the Save button at the bottom left of the page
The configuration will be applied immediately

Permission Matrix Visualization

After completing the configuration, the permission matrix should look like this:

┌─────────────────────┬─────────┬─────────┬───────────┐
│ Permission          │ sam     │ rohan   │ Anonymous │
├─────────────────────┼─────────┼─────────┼───────────┤
│ Job/Build           │   ✓     │   ✓     │           │
│ Job/Cancel          │         │   ✓     │           │
│ Job/Configure       │   ✓     │   ✓     │           │
│ Job/Read            │   ✓     │   ✓     │           │
│ Job/Update          │         │   ✓     │           │
│ SCM/Tag             │         │   ✓     │           │
│ (other permissions) │         │         │           │
└─────────────────────┴─────────┴─────────┴───────────┘

Verification

Step 1: Log Out as Admin

Click your profile icon (top right)
Click Sign out

Step 2: Log in as sam

Username: sam
Password: sam@pass12345
Navigate to the Packages job
Verify you can:
- See the job (Job/Read)
- Click Configure (Job/Configure)
- Click Build Now (Job/Build)

Step 3: Log in as rohan

Log out from sam's session
Username: rohan
Password: rohan@pass12345
Navigate to the Packages job
Verify you can:
- See the job (Job/Read)
- Click Configure (Job/Configure)
- Click Build Now (Job/Build)
- Cancel a running build (Job/Cancel)
- Update parameters (Run/Update)
- Tag in SCM (SCM/Tag)

Troubleshooting Common Issues

Issue 1: Authorization Section Not Visible

Symptom: The Authorization section doesn't appear on the job configuration page.

Cause: The "Enable project-based security" checkbox is not checked.

Solution: Check the Enable project-based security checkbox in the General section.

Issue 2: Users Cannot Log In

Symptom: Users get "Access Denied" when logging in.

Cause: Users don't have Overall/Read permission at the global level.

Solution: Add users to the global security matrix and grant Overall/Read.

Issue 3: Job Not Visible to Users

Symptom: Users can log in but cannot see the Packages job.

Cause: Users lack Job/Read permission on the specific job.

Solution: Grant Job/Read permission in the project-level matrix.

Issue 4: Matrix Option Not Available

Symptom: "Project-based Matrix Authorization Strategy" is not listed in the Authorization options.

Cause: The Matrix Authorization Strategy plugin is not installed.

Solution: Install the plugin from Available Plugins and restart Jenkins.

Issue 5: Wrong Inheritance Strategy

Symptom: Users have more or fewer permissions than intended.

Cause: The wrong inheritance strategy was selected.

Solution: Change the inheritance strategy to Inherit permissions from parent ACL.

Best Practices for Jenkins Project Security

1. Principle of Least Privilege

Grant only the permissions that users absolutely need. Avoid giving broad permissions like Job/Delete or Overall/Administer unless necessary.

2. Use Groups Instead of Individual Users

For larger teams, use Jenkins groups (backed by LDAP or Active Directory) instead of managing individual users.

3. Regular Audits

Periodically review the permission matrix to ensure users have appropriate access. Remove permissions for users who no longer need them.

4. Document Permission Changes

Keep a record of who has what permissions and why. This helps during audits and troubleshooting.

5. Test with Non-Admin Accounts

Always verify permissions by logging in as the actual user, not just as an administrator.

Key Learnings

Project-Based Security: Jenkins allows granular permission management at the job level using the Matrix Authorization Strategy plugin.
Inheritance Strategy: The "Inherit permissions from parent ACL" strategy combines global and job-level permissions, ensuring users have at least the global Overall/Read permission.
Conditional UI: The Authorization section in job configuration only appears after checking the "Enable project-based security" checkbox.
Permission Verification: Always verify permissions by logging in as the actual user.
Principle of Least Privilege: Grant only the permissions required for each user's role.

Task Summary

Requirement	Status
Matrix Authorization Strategy plugin installed	✅
Global security configured with `Overall/Read` for sam and rohan	✅
Project-based security enabled on Packages job	✅
Inheritance Strategy: Inherit permissions from parent ACL	✅
sam granted: build, configure, read	✅
rohan granted: build, cancel, configure, read, update, tag	✅
No other job configuration modified	✅

Configuration Summary

sam's Permissions

Job: Build, Configure, Read

rohan's Permissions

Job: Build, Cancel, Configure, Read
Run: Update
SCM: Tag

Inheritance Strategy

Inherit permissions from parent ACL

Screenshots for Documentation

Make sure to capture the following screenshots for review:

Global Security Configuration – Showing sam and rohan with Overall/Read
Project-Based Security Enabled – The checkbox checked in the Packages job
Inheritance Strategy – "Inherit permissions from parent ACL" selected
Permission Matrix – Showing the permissions for sam and rohan
Verification – Logged in as sam and rohan accessing the Packages job

Summary

In this challenge, we successfully:

Accessed the Jenkins UI and logged in as admin
Installed the Matrix Authorization Strategy plugin
Configured global security with Overall/Read for both users
Enabled project-based security on the Packages job
Selected the correct inheritance strategy
Granted the appropriate permissions to sam and rohan
Verified the configuration by logging in as each user

This setup demonstrates how Jenkins project-based security provides fine-grained control over user permissions, following the Principle of Least Privilege. The developers now have exactly the permissions they need to perform their tasks without unnecessary access.

Linux Postfix Mail Server

Janak Shrestha — Wed, 16 Sep 2026 09:42:09 +0000

xFusionCorp Industries has planned to set up a common email server in Stork DC. After several meetings and recommendations they have decided to use postfix as their mail transfer agent and dovecot as an IMAP/POP3 server. We would like you to perform the following steps:

Install and configure postfix on Stork DC mail server.
Create an email account anita@stratos.xfusioncorp.com identified by 8FmzjvFU6S.
Set its mail directory to /home/anita/Maildir.
Install and configure dovecot on the same server.

Understanding the Components

Postfix

Postfix is a Mail Transfer Agent responsible for routing and delivering email. It handles SMTP connections, accepts incoming mail, and delivers it to local mailboxes or relays it to other servers. Postfix is known for its security, performance, and ease of administration.

Dovecot

Dovecot is an IMAP and POP3 server that allows users to access their email. It handles authentication and provides access to mailboxes stored on the server. Dovecot supports various mailbox formats, including Maildir and mbox.

Maildir Format

Maildir stores each email as a separate file in a directory structure. This format is more reliable than mbox because it avoids file locking issues and supports concurrent access. The structure consists of three subdirectories: cur for current messages, new for newly delivered messages, and tmp for temporary files during delivery.

Prerequisites

Before beginning, ensure the following are available:

Access to the mail server with root or sudo privileges
The mail server hostname and domain information
Network connectivity between the mail server and other infrastructure components

Server Details for This Tutorial

Detail	Value
Server	stmail01.stratos.xfusioncorp.com
User	groot
Password	Gr00T123
Email Address	anita@stratos.xfusioncorp.com
Email Password	8FmzjvFU6S
Mail Directory	/home/anita/Maildir

Installing Postfix

Connect to the mail server and switch to root.

# Password: Gr00T123
ssh groot@stmail01
sudo su -

Install Postfix using the system package manager.

yum install postfix -y

The installation includes Postfix and its dependencies. Postfix version 3.5.25 is installed on CentOS Stream 9.

Configuring Postfix

Edit the main Postfix configuration file at /etc/postfix/main.cf.

vi /etc/postfix/main.cf

Add or modify the following parameters:

myhostname = stmail01.stratos.xfusioncorp.com
mydomain = stratos.xfusioncorp.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mynetworks = 172.16.238.0/24, 127.0.0.0/8
home_mailbox = Maildir/

Parameter Explanation

Parameter	Purpose
myhostname	Fully qualified domain name of the mail server
mydomain	Domain name used for email addresses
myorigin	Domain used for outgoing mail
inet_interfaces	Network interfaces Postfix listens on
mydestination	Domains for which Postfix accepts mail
mynetworks	Trusted networks for relaying
home_mailbox	Mailbox format and location

The home_mailbox = Maildir/ setting is critical. It tells Postfix to deliver mail in Maildir format within the user's home directory.

Starting and Enabling Postfix

Start the Postfix service and enable it to start on boot.

systemctl start postfix
systemctl enable postfix
systemctl status postfix

Verify that Postfix is running and listening on port 25.

ss -tlnp | grep :25

Creating the Email Account

Create a system user for the email account. The username becomes the local part of the email address.

useradd anita
passwd anita

When prompted, enter the password 8FmzjvFU6S twice.

Verify the user was created.

id anita

Creating the Maildir Directory

Create the Maildir structure in the user's home directory.

mkdir -p /home/anita/Maildir/{cur,new,tmp}

Set the correct ownership so the user can access the mailbox.

chown -R anita:anita /home/anita/Maildir

Verify the directory structure.

ls -la /home/anita/Maildir/

The output should show three subdirectories: cur, new, and tmp, all owned by anita.

Installing Dovecot

Install Dovecot using the system package manager.

yum install dovecot -y

Dovecot version 2.3.16 is installed along with its dependencies, including clucene-core and libexttextcat.

Configuring Dovecot

Dovecot configuration is split across several files in the /etc/dovecot/ directory. Each file controls a specific aspect of the server.

Enable IMAP and POP3 Protocols

Edit /etc/dovecot/dovecot.conf.

vi /etc/dovecot/dovecot.conf

Set the protocols line to enable both IMAP and POP3.

protocols = imap pop3

Set the Mail Location

Edit /etc/dovecot/conf.d/10-mail.conf.

vi /etc/dovecot/conf.d/10-mail.conf

Set the mail location to match the Postfix Maildir setting.

mail_location = maildir:~/Maildir

This must match the home_mailbox setting in Postfix for mail delivery to work correctly.

Configure Authentication

Edit /etc/dovecot/conf.d/10-auth.conf.

vi /etc/dovecot/conf.d/10-auth.conf

Set the authentication parameters.

disable_plaintext_auth = yes
auth_mechanisms = plain login

Configure the Auth Service Socket

Edit /etc/dovecot/conf.d/10-master.conf.

vi /etc/dovecot/conf.d/10-master.conf

Configure the auth service socket for Postfix integration.

service auth {
  unix_listener auth-userdb {
    mode = 0660
    user = postfix
    group = postfix
  }
}

This allows Postfix to authenticate users through Dovecot.

Starting and Enabling Dovecot

Start the Dovecot service and enable it to start on boot.

systemctl start dovecot
systemctl enable dovecot
systemctl status dovecot

Verify that Dovecot is running and listening on ports 110 and 143.

ss -tlnp | grep -E ":110|:143"

Verification

Check Service Status

systemctl is-active postfix
systemctl is-enabled postfix
systemctl is-active dovecot
systemctl is-enabled dovecot

All services should return active and enabled.

Check Listening Ports

ss -tlnp | grep -E ":25|:110|:143"

Expected output shows Postfix on port 25 and Dovecot on ports 110 and 143.

Check User and Maildir

id anita
ls -la /home/anita/Maildir/

The user should exist with the correct UID, and the Maildir should contain cur, new, and tmp directories.

Test SMTP

telnet localhost 25

The connection should succeed and show the Postfix banner.

Test POP3

telnet localhost 110
user anita
pass 8FmzjvFU6S

The authentication should succeed.

Troubleshooting

Postfix Warnings About Overriding

When configuration lines are duplicated, Postfix issues warnings. Remove duplicate entries from /etc/postfix/main.cf and restart Postfix.

Dovecot Fails to Start

Check the Dovecot logs for errors.

journalctl -u dovecot -n 50
doveadm log find

Mail Not Delivered

Verify that the home_mailbox setting in Postfix matches the mail_location setting in Dovecot. Both should point to Maildir.

Authentication Failures

Ensure the auth service socket is configured correctly in 10-master.conf with the postfix user and group.

Port Conflicts

Ensure no other service is using ports 25, 110, or 143.

ss -tlnp | grep -E ":25|:110|:143"

Configuration Summary

Component	Configuration
Mail Server	stmail01.stratos.xfusioncorp.com
Email Address	anita@stratos.xfusioncorp.com
Password	8FmzjvFU6S
Mail Directory	/home/anita/Maildir
Postfix Port	25
Dovecot IMAP Port	143
Dovecot POP3 Port	110
Mailbox Format	Maildir

Best Practices

Use Maildir Format

Maildir is more reliable than mbox for concurrent access and avoids file locking issues.

Keep Postfix and Dovecot Settings Consistent

The mail location in Dovecot must match the home_mailbox setting in Postfix.

Enable Only Required Protocols

Enable only the protocols that are needed. If POP3 is not required, disable it.

Secure Authentication

Use TLS for authentication when possible. Configure Dovecot to use SSL/TLS certificates.

Monitor Logs

Regularly check mail logs for errors and delivery issues.

tail -f /var/log/maillog

Regular Backups

Back up mail directories and configuration files regularly.

Conclusion

Setting up a mail server with Postfix and Dovecot provides a reliable and secure email solution for enterprise environments. Postfix handles mail transfer and delivery, while Dovecot provides IMAP and POP3 access to mailboxes. The Maildir format ensures reliable mail storage.

The key steps are installing both packages, configuring Postfix to deliver mail in Maildir format, creating user accounts with the correct mail directory structure, and configuring Dovecot to access those mailboxes. Verification of services, ports, and user accounts ensures the setup is complete and functional.

Linux Firewalld Setup

Janak Shrestha — Tue, 15 Sep 2026 10:55:49 +0000

To secure our Nautilus infrastructure in Stratos Datacenter, we have decided to install and configure firewalld on one of the app servers named App Server 1. We have Apache and Nginx services running on these apps. Nginx is running as a reverse proxy server for Apache. We might have more robust firewall settings in the future, but for now we have decided to go with the given requirements listed below:

a. Allow all incoming connections on Nginx port, i.e 80.

b. Block all incoming connections on Apache port, i.e 8085.

c. All rules must be permanent.

d. Zone should be public.

e. If Apache or Nginx services aren't running already, please make sure to start them.

Understanding Firewalld

What is Firewalld

Firewalld is a firewall management tool that provides a dynamically managed firewall with support for network zones. It acts as a frontend for nftables or iptables and offers a simpler way to manage firewall rules compared to directly manipulating iptables.

Key Concepts

Firewalld uses zones to define trust levels for network connections. Each zone has its own set of rules. The public zone is the default zone and is used for public-facing services. Rich rules allow for more granular control over traffic, including dropping specific ports.

Zones Overview

Zone	Description
public	Public-facing services, default zone
trusted	All network connections accepted
home	Home network, more permissive
work	Work network, moderate restrictions
drop	All incoming connections dropped
block	Incoming connections rejected

Prerequisites

Before beginning, ensure the following prerequisites are met. A Linux server with root or sudo access is required. The server should have Apache and Nginx installed. Basic command-line knowledge is necessary. Understanding of network ports and protocols is helpful.

Server Details for This Tutorial

Detail	Value
Server	App Server 1 (stapp01)
User	tony
Password	Ir0nM@n
Nginx Port	80
Apache Port	8085
Zone	public

Step 1: Connect to the Server

Access the target server using SSH with the appropriate credentials.

ssh tony@stapp01
Password: Ir0nM@n

Switch to root to perform administrative tasks.

sudo su -
Password: Ir0nM@n

Step 2: Install Firewalld

Install the firewalld package using the system package manager.

yum install -y firewalld

The installation includes firewalld and its dependencies, including ipset, nftables, and python3-firewall.

Step 3: Start and Enable Firewalld

Start the firewalld service and enable it to start automatically on boot.

systemctl start firewalld
systemctl enable firewalld

The enable command creates a symlink for the service to start on boot.

Step 4: Set the Default Zone

Configure the default zone to public as required.

firewall-cmd --set-default-zone=public

Verify the default zone has been set correctly.

firewall-cmd --get-default-zone

Step 5: Allow Nginx Port (80)

Add a permanent rule to allow incoming traffic on port 80 for Nginx.

firewall-cmd --zone=public --add-port=80/tcp --permanent

The permanent flag ensures the rule persists across reboots.

Step 6: Block Apache Port (8085)

Remove any existing rule for port 8085 and add a rich rule to block it.

firewall-cmd --zone=public --remove-port=8085/tcp --permanent
firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" port port="8085" protocol="tcp" drop' --permanent

The rich rule uses the drop action to silently discard packets on port 8085.

Step 7: Reload Firewall

Apply all the permanent rules by reloading the firewall.

firewall-cmd --reload

Step 8: Configure and Start Services

Port Conflict Resolution

By default, both Apache and Nginx listen on port 80, causing a conflict. Since Nginx acts as a reverse proxy, Apache should listen on port 8085 while Nginx listens on port 80.

Configure Apache to listen on port 8085.

sed -i 's/^Listen 80/Listen 8085/' /etc/httpd/conf/httpd.conf

Start Apache

systemctl start httpd
systemctl enable httpd

Start Nginx

systemctl start nginx
systemctl enable nginx

Verify Both Services

systemctl status httpd
systemctl status nginx
systemctl is-active httpd
systemctl is-active nginx

Step 9: Complete Verification

Verify the firewall configuration and service status.

firewall-cmd --zone=public --list-all
firewall-cmd --zone=public --list-ports
firewall-cmd --zone=public --list-rich-rules
ss -tlnp | grep -E ":80|:8085"

Understanding the Configuration

Firewall Rules Summary

Rule	Port	Action	Permanent
Nginx	80/tcp	Allow	Yes
Apache	8085/tcp	Block	Yes
Zone	public	Default	Yes

Rich Rule Breakdown

rule family="ipv4" port port="8085" protocol="tcp" drop

The rich rule specifies IPv4 traffic on port 8085 using TCP protocol. The drop action silently discards packets without notifying the sender.

Service Ports

Service	Default Port	Configured Port
Nginx	80	80
Apache	80	8085

Alternative Methods

Using firewall-cmd with Different Syntax

firewall-cmd --permanent --zone=public --add-port=80/tcp
firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" port port="8085" protocol="tcp" drop'
firewall-cmd --reload

Using Direct Rules

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 8085 -j DROP
firewall-cmd --reload

Using Services Instead of Ports

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --reload

Troubleshooting Common Issues

Firewalld Not Found

When the firewalld command is not found, install the package using the system package manager.

yum install -y firewalld

Failed to Start Firewalld

Check the service logs for errors.

journalctl -u firewalld -n 50
systemctl restart firewalld

Port Not Blocked

Verify the rich rule has been applied and reload the firewall.

firewall-cmd --zone=public --list-rich-rules
firewall-cmd --reload

Nginx Fails to Start

The most common cause is a port conflict with Apache. Check which service is using port 80.

ss -tlnp | grep :80

If Apache is using port 80, stop Apache, reconfigure it to use port 8085, and start Nginx.

systemctl stop httpd
sed -i 's/^Listen 80/Listen 8085/' /etc/httpd/conf/httpd.conf
systemctl start httpd
systemctl start nginx

Rules Not Permanent

Ensure the permanent flag is used with every firewall-cmd command that modifies rules.

firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --reload

Verification Commands

# Check firewall status
systemctl status firewalld

# Check default zone
firewall-cmd --get-default-zone

# Check open ports
firewall-cmd --zone=public --list-ports

# Check rich rules
firewall-cmd --zone=public --list-rich-rules

# Check complete configuration
firewall-cmd --zone=public --list-all

# Check services status
systemctl is-active httpd
systemctl is-active nginx

# Check listening ports
ss -tlnp | grep -E ":80|:8085"

# Test connectivity
curl -I http://localhost:80
curl -I http://localhost:8085

Expected Output

Firewall Configuration

public
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports: 80/tcp
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" port port="8085" protocol="tcp" drop

Service Status

httpd: active
nginx: active

Listening Ports

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=34219,fd=6))
LISTEN 0 511 0.0.0.0:8085 0.0.0.0:* users:(("httpd",pid=8699,fd=4))

Best Practices

Use Permanent Rules

Always use the permanent flag when adding rules to ensure they survive reboots.

firewall-cmd --zone=public --add-port=80/tcp --permanent

Reload After Changes

Always reload the firewall after making permanent changes.

firewall-cmd --reload

Document Rules

Maintain documentation of all firewall rules for audit purposes.

Test Before Production

Test firewall rules in a staging environment before applying to production.

Monitor Logs

Regularly check firewall logs for blocked traffic.

journalctl -u firewalld
tail -f /var/log/firewalld

Automation Script

#!/bin/bash

echo "Firewall Configuration Script"
echo "=============================="

# Install firewalld
yum install -y firewalld

# Start and enable
systemctl start firewalld
systemctl enable firewalld

# Set zone
firewall-cmd --set-default-zone=public

# Allow port 80
firewall-cmd --zone=public --add-port=80/tcp --permanent

# Block port 8085
firewall-cmd --zone=public --remove-port=8085/tcp --permanent
firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" port port="8085" protocol="tcp" drop' --permanent

# Reload
firewall-cmd --reload

# Configure Apache port
sed -i 's/^Listen 80/Listen 8085/' /etc/httpd/conf/httpd.conf

# Start services
systemctl start httpd
systemctl enable httpd
systemctl start nginx
systemctl enable nginx

# Verify
echo "Verification:"
firewall-cmd --zone=public --list-all
systemctl is-active httpd
systemctl is-active nginx

Conclusion

What Has Been Accomplished

Firewalld has been successfully installed and configured on App Server 1. Port 80 has been allowed for Nginx traffic, and port 8085 has been blocked for Apache using a rich rule. The zone has been set to public, and all rules have been made permanent. Both Apache and Nginx services are running with Apache on port 8085 and Nginx on port 80.

Key Takeaways

Firewalld provides a dynamic and flexible way to manage firewall rules. The public zone is the default and is suitable for public-facing services. Rich rules allow granular control over traffic. The permanent flag ensures rules persist across reboots. Port conflicts between services must be resolved by configuring services to use different ports.

Complete Solution Summary

# Firewall Rules
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --zone=public --remove-port=8085/tcp --permanent
firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" port port="8085" protocol="tcp" drop' --permanent
firewall-cmd --reload

# Service Configuration
sed -i 's/^Listen 80/Listen 8085/' /etc/httpd/conf/httpd.conf
systemctl start httpd
systemctl enable httpd
systemctl start nginx
systemctl enable nginx

# Verification
firewall-cmd --zone=public --list-all
systemctl is-active httpd
systemctl is-active nginx

Day 75: Jenkins Slave Nodes

Janak Shrestha — Tue, 15 Sep 2026 10:40:32 +0000

The Nautilus DevOps team has installed and configured new Jenkins server in Stratos DC which they will use for CI/CD and for some automation tasks. There is a requirement to add all app servers as slave nodes in Jenkins so that they can perform tasks on these servers using Jenkins. Find below more details and accomplish the task accordingly.

Click on the Jenkins button on the top bar to access the Jenkins UI. Login using username admin and password Adm!n321.

Add all app servers as SSH build agent/slave nodes in Jenkins. Slave node name for app server 1, app server 2 and app server 3 must be App_server_1, App_server_2, App_server_3 respectively.
Add labels as below:

App_server_1 : stapp01

App_server_2 : stapp02

App_server_3 : stapp03

Remote root directory for App_server_1 must be /home/tony/jenkins, for App_server_2 must be /home/steve/jenkins and for App_server_3 must be /home/banner/jenkins.
Make sure slave nodes are online and working properly.

Note:

You might need to install some plugins and restart Jenkins service. So, we recommend clicking on Restart Jenkins when installation is complete and no jobs are running on plugin installation/update page i.e update centre. Also, Jenkins UI sometimes gets stuck when Jenkins service restarts in the back end. In this case, please make sure to refresh the UI page.
For these kind of scenarios requiring changes to be done in a web UI, please take screenshots so that you can share it with us for review in case your task is marked incomplete. You may also consider using a screen recording software such as loom.com to record and share your work.

Understanding Jenkins Master-Agent Architecture

Jenkins uses a master-agent architecture:

Component	Role
Master (Controller)	Schedules jobs, manages configuration, serves the UI
Agent (Slave/Node)	Executes build tasks assigned by the master

Why Use Slave Nodes?

Distributed Builds: Run multiple jobs in parallel
Server-Specific Tasks: Run jobs on specific servers
Load Distribution: Reduce load on the master
Environment Isolation: Different environments for different builds
Scalability: Add more agents as needed

Task Requirements

Server	Node Name	Label	Remote Root Directory
App Server 1	App_server_1	stapp01	/home/tony/jenkins
App Server 2	App_server_2	stapp02	/home/steve/jenkins
App Server 3	App_server_3	stapp03	/home/banner/jenkins

Step-by-Step Implementation

Step 1: Access Jenkins UI

Click the Jenkins button on the top bar
Login with:
- Username: admin
- Password: Adm!n321

Step 2: Install SSH Build Agents Plugin

Navigate to Manage Jenkins → Plugins
Click Available plugins
Search for SSH Build Agents
Install the plugin and restart Jenkins

Note: Select Restart Jenkins when installation is complete and no jobs are running.

Step 3: Generate SSH Keys on Jenkins Server

The Jenkins job runs as the jenkins user, so SSH keys must be generated for this user.

# SSH to Jenkins server
ssh jenkins@jenkins
# Password: j@rv!s

# Generate SSH key
ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa

# View the private key (needed for Jenkins credentials)
cat ~/.ssh/id_rsa

Output:

Generating public/private rsa key pair.
Your identification has been saved in /var/lib/jenkins/.ssh/id_rsa
Your public key has been saved in /var/lib/jenkins/.ssh/id_rsa.pub

Step 4: Copy SSH Keys to All App Servers

# Copy public key to App Server 1
ssh-copy-id -o StrictHostKeyChecking=no tony@stapp01
# Password: Ir0nM@n

# Copy public key to App Server 2
ssh-copy-id -o StrictHostKeyChecking=no steve@stapp02
# Password: Am3ric@

# Copy public key to App Server 3
ssh-copy-id -o StrictHostKeyChecking=no banner@stapp03
# Password: BigGr33n

# Verify passwordless access
ssh -o StrictHostKeyChecking=no tony@stapp01 hostname
ssh -o StrictHostKeyChecking=no steve@stapp02 hostname
ssh -o StrictHostKeyChecking=no banner@stapp03 hostname

Output:

stapp01
stapp02
stapp03

Step 5: Install Java 21 on All App Servers

Jenkins agents require Java 17 or higher. Java 11 will cause an UnsupportedClassVersionError.

# Install Java 21 on all servers
ssh tony@stapp01 "sudo yum install -y java-21-openjdk"
ssh steve@stapp02 "sudo yum install -y java-21-openjdk"
ssh banner@stapp03 "sudo yum install -y java-21-openjdk"

Step 6: Register and Set Java 21 as Default

After installing Java 21, you need to register it as an alternative and set it as default.

# Register Java 21 as an alternative
ssh tony@stapp01 "echo 'Ir0nM@n' | sudo -S alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java 2000"
ssh steve@stapp02 "echo 'Am3ric@' | sudo -S alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java 2000"
ssh banner@stapp03 "echo 'BigGr33n' | sudo -S alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java 2000"

# Set Java 21 as default
ssh tony@stapp01 "echo 'Ir0nM@n' | sudo -S alternatives --set java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java"
ssh steve@stapp02 "echo 'Am3ric@' | sudo -S alternatives --set java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java"
ssh banner@stapp03 "echo 'BigGr33n' | sudo -S alternatives --set java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java"

Verify:

ssh tony@stapp01 "java -version"
ssh steve@stapp02 "java -version"
ssh banner@stapp03 "java -version"

Output:

openjdk version "21.0.12.1" 2026-08-18 LTS

Step 7: Create Remote Root Directories

ssh -o StrictHostKeyChecking=no tony@stapp01 "mkdir -p /home/tony/jenkins"
ssh -o StrictHostKeyChecking=no steve@stapp02 "mkdir -p /home/steve/jenkins"
ssh -o StrictHostKeyChecking=no banner@stapp03 "mkdir -p /home/banner/jenkins"

Step 8: Get IP Addresses for Hostname Resolution

ssh tony@stapp01 "hostname -I"
ssh steve@stapp02 "hostname -I"
ssh banner@stapp03 "hostname -I"

Output:

10.244.81.4
10.244.189.193
10.244.195.103

Step 9: Add SSH Credentials in Jenkins

Go to Manage Jenkins → Credentials → System → Global credentials
Click Add Credentials for each server:

App Server 1 Credentials:

Kind: SSH Username with private key
Scope: Global
ID: stapp01-credentials
Username: tony
Private Key: Enter directly (paste the private key from ~/.ssh/id_rsa)
Click OK

App Server 2 Credentials:

Kind: SSH Username with private key
ID: stapp02-credentials
Username: steve
Private Key: Enter directly
Click OK

App Server 3 Credentials:

Kind: SSH Username with private key
ID: stapp03-credentials
Username: banner
Private Key: Enter directly
Click OK

Step 10: Add Slave Nodes in Jenkins

Add App_server_1 Node:

Manage Jenkins → Nodes → New Node
Enter name: App_server_1
Select Permanent Agent → OK
Configure:
- Name: App_server_1
- Remote root directory: /home/tony/jenkins
- Labels: stapp01
- Usage: Use this node as much as possible
- Launch method: Launch agents via SSH
- Host: stapp01.stratos.xfusioncorp.com
- Credentials: stapp01-credentials
- Host Key Verification Strategy: Non-verifying Verification Strategy
Click Advanced and set:
- JavaPath: /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java
Click Save

Add App_server_2 Node:

Manage Jenkins → Nodes → New Node
Enter name: App_server_2
Configure:
- Name: App_server_2
- Remote root directory: /home/steve/jenkins
- Labels: stapp02
- Host: stapp02.stratos.xfusioncorp.com
- Credentials: stapp02-credentials
- JavaPath: /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java
Click Save

Add App_server_3 Node:

Manage Jenkins → Nodes → New Node
Enter name: App_server_3
Configure:
- Name: App_server_3
- Remote root directory: /home/banner/jenkins
- Labels: stapp03
- Host: 10.244.195.103 (use IP address since hostname doesn't resolve)
- Credentials: stapp03-credentials
- JavaPath: /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java
Click Save

Step 11: Verify All Nodes Are Online

Go to Manage Jenkins → Nodes. All three nodes should show Online status with a green checkmark.

Troubleshooting Common Issues

Issue 1: UnsupportedClassVersionError

Error:

java.lang.UnsupportedClassVersionError: hudson/remoting/Launcher has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

Cause: Jenkins agent requires Java 17+ but the server has Java 11.

Solution: Install Java 21 and set it as default.

sudo yum install -y java-21-openjdk
sudo alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java 2000
sudo alternatives --set java /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.1.el9.x86_64/bin/java

Issue 2: "has not been configured as an alternative"

Error:

/usr/lib/jvm/java-21-openjdk-21.0.12.1.1-2.el9.x86_64/bin/java has not been configured as an alternative for java

Cause: Java 21 was not registered as an alternative before using --set.

Solution: Use --install first, then --set.

Issue 3: Wrong Java Path

Error: Path uses -2.el9.x86_64 but the actual path is -2.1.el9.x86_64.

Solution: Verify the exact path:

ls /usr/lib/jvm/

Issue 4: Name or Service Not Known

Error:

stapp03.stratos.xfusioncorp.com: Name or service not known

Cause: The hostname cannot be resolved from the Jenkins server.

Solution: Use the IP address directly in the node configuration.

Issue 5: Jenkins User Cannot Use Sudo

Error:

jenkins is not in the sudoers file.

Cause: The jenkins user doesn't have sudo privileges.

Solution: Use IP addresses in node configuration instead of editing /etc/hosts.

Final Configuration Summary

Node Name	Label	Remote Root Directory	Host	JavaPath	Status
App_server_1	stapp01	/home/tony/jenkins	stapp01.stratos.xfusioncorp.com	Java 21	Online
App_server_2	stapp02	/home/steve/jenkins	stapp02.stratos.xfusioncorp.com	Java 21	Online
App_server_3	stapp03	/home/banner/jenkins	10.244.195.103	Java 21	Online

Key Learnings

Java Version Compatibility: Jenkins agents require Java 17 or higher. Java 21 is recommended.
Alternatives Management: Use alternatives --install to register a new Java version, then alternatives --set to make it default.
JavaPath in Node Configuration: For non-interactive SSH sessions, always specify the full Java binary path in the agent configuration.
Hostname Resolution: If a hostname cannot be resolved, use the IP address directly in the node configuration.
Jenkins User Permissions: The jenkins user may not have sudo access, so plan accordingly.
SSH Key Setup: Generate SSH keys for the jenkins user (not root) and copy them to all target servers.

Benefits of Distributed Builds

With slave nodes configured, you can now:

Run jobs in parallel across multiple servers
Target specific servers using labels (stapp01, stapp02, stapp03)
Reduce load on the Jenkins master
Scale horizontally by adding more agents
Isolate environments for different build types

Example: Using Node Labels in a Job

node('stapp01') {
    stage('Deploy') {
        sh 'echo "Deploying to App Server 1"'
    }
}

Summary

In this challenge, we successfully:

Generated SSH keys on the Jenkins server
Copied SSH keys to all app servers
Installed Java 21 on all app servers
Registered and set Java 21 as the default version
Created remote root directories on all app servers
Added SSH credentials in Jenkins
Added all three app servers as Jenkins slave nodes
Configured labels and JavaPath for each node
Verified all nodes are online and working

This setup enables Jenkins to distribute build tasks across all app servers, improving performance and allowing server-specific automation tasks. The slave nodes are now ready to execute jobs assigned to them.

DNS Troubleshooting

Janak Shrestha — Tue, 15 Sep 2026 07:00:09 +0000

The system admins team of xFusionCorp Industries has noticed intermittent issues with DNS resolution in several apps . App Server 2 in Stratos Datacenter is having some DNS resolution issues, so we want to add some additional DNS nameservers on this server.

As a temporary fix we have decided to go with Google public DNS (ipv4). Please make appropriate changes on this server.

Solution

Step 1: Connect to App Server 2 (stapp02)

ssh steve@stapp02
# Password: Am3ric@

Step 2: Switch to root

sudo su -
# Password: Am3ric@

Step 3: Check current DNS configuration

cat /etc/resolv.conf

Step 4: Add Google Public DNS nameservers

Google Public DNS IPv4 addresses:

8.8.8.8 (Primary)
8.8.4.4 (Secondary)

# Add Google DNS servers to resolv.conf
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf

Step 5: Verify the configuration

cat /etc/resolv.conf

Step 6: Test DNS resolution

# Test with ping
ping -c 2 google.com

# Test with nslookup
nslookup google.com

# Test with dig
dig google.com

One-Line Commands

From jump host with password:

echo 'Am3ric@' | ssh steve@stapp02 "sudo -S bash -c 'echo \"nameserver 8.8.8.8\" >> /etc/resolv.conf && echo \"nameserver 8.8.4.4\" >> /etc/resolv.conf && cat /etc/resolv.conf'"

Using heredoc (Recommended):

ssh steve@stapp02 << 'EOF'
echo 'Am3ric@' | sudo -S bash -c '
echo "=== Current DNS configuration ==="
cat /etc/resolv.conf

echo ""
echo "=== Adding Google Public DNS ==="
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf

echo ""
echo "=== Updated DNS configuration ==="
cat /etc/resolv.conf

echo ""
echo "=== Testing DNS resolution ==="
ping -c 2 google.com
'
EOF

Step-by-Step Interactive Commands

# Connect to stapp02
ssh steve@stapp02
# Password: Am3ric@

# Become root
sudo su -
# Password: Am3ric@

# Step 1: Check current DNS configuration
echo "=== Current DNS configuration ==="
cat /etc/resolv.conf

# Step 2: Backup existing resolv.conf (optional but recommended)
echo "=== Backing up resolv.conf ==="
cp /etc/resolv.conf /etc/resolv.conf.backup

# Step 3: Add Google DNS servers
echo "=== Adding Google Public DNS ==="
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf

# Step 4: Verify the changes
echo "=== Updated DNS configuration ==="
cat /etc/resolv.conf

# Step 5: Test DNS resolution
echo "=== Testing DNS resolution ==="
ping -c 2 google.com
nslookup google.com

# Exit
exit
exit

Expected Output

[root@stapp02 ~]# cat /etc/resolv.conf
nameserver 10.0.0.2

[root@stapp02 ~]# echo "nameserver 8.8.8.8" >> /etc/resolv.conf
[root@stapp02 ~]# echo "nameserver 8.8.4.4" >> /etc/resolv.conf

[root@stapp02 ~]# cat /etc/resolv.conf
nameserver 10.0.0.2
nameserver 8.8.8.8
nameserver 8.8.4.4

[root@stapp02 ~]# ping -c 2 google.com
PING google.com (142.250.192.46) 56(84) bytes of data.
64 bytes from 142.250.192.46: icmp_seq=1 ttl=115 time=10.2 ms
64 bytes from 142.250.192.46: icmp_seq=2 ttl=115 time=10.5 ms

--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

[root@stapp02 ~]# nslookup google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.192.46

Alternative Methods

Method 1: Using tee command

echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf
echo "nameserver 8.8.4.4" | sudo tee -a /etc/resolv.conf

Method 2: Using cat with heredoc

cat >> /etc/resolv.conf << EOF
nameserver 8.8.8.8
nameserver 8.8.4.4
EOF

Method 3: Using sed to replace existing nameservers

sed -i 's/^nameserver.*/nameserver 8.8.8.8/' /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf

Method 4: Using nmcli (NetworkManager)

# Check connection name
nmcli connection show

# Add DNS servers
nmcli connection modify <connection-name> ipv4.dns "8.8.8.8 8.8.4.4"
nmcli connection up <connection-name>

Method 5: Using nmtui (Text User Interface)

nmtui
# Navigate to Edit a connection
# Select the connection
# Add DNS servers
# Save and exit

Verification Commands

# 1. Check resolv.conf
cat /etc/resolv.conf

# 2. Test DNS resolution with ping
ping -c 2 google.com

# 3. Test with nslookup
nslookup google.com

# 4. Test with dig
dig google.com

# 5. Test with host
host google.com

# 6. Check DNS resolution order
getent hosts google.com

# 7. Check if DNS servers are reachable
ping -c 2 8.8.8.8
ping -c 2 8.8.4.4

Understanding Google Public DNS

Google Public DNS IPv4 Addresses

Address	Description
`8.8.8.8`	Primary DNS
`8.8.4.4`	Secondary DNS

Google Public DNS IPv6 Addresses

Address	Description
`2001:4860:4860::8888`	Primary DNS
`2001:4860:4860::8844`	Secondary DNS

Why Use Google Public DNS

Reliability: Highly available and globally distributed
Speed: Fast resolution times
Security: DNSSEC validation and protection against DNS poisoning
Privacy: No logging of personal information
Free: Available to everyone at no cost

Important Notes

resolv.conf May Be Overwritten

On systems using NetworkManager or DHCP, /etc/resolv.conf may be automatically overwritten. To make changes permanent, consider these approaches.

Option 1: Use NetworkManager

nmcli connection modify <connection-name> ipv4.dns "8.8.8.8 8.8.4.4"
nmcli connection modify <connection-name> ipv4.ignore-auto-dns yes
nmcli connection up <connection-name>

Option 2: Make resolv.conf immutable

chattr +i /etc/resolv.conf
# To undo: chattr -i /etc/resolv.conf

Option 3: Configure in network interface file

# For RHEL/CentOS
vi /etc/sysconfig/network-scripts/ifcfg-<interface>
# Add: DNS1=8.8.8.8
# Add: DNS2=8.8.4.4

Troubleshooting

"Permission denied" when editing resolv.conf:

   # Use sudo or become root
   sudo su -

DNS still not resolving:

   # Check if DNS servers are reachable
   ping -c 2 8.8.8.8

   # Check network connectivity
   ping -c 2 8.8.4.4

   # Restart network service
   systemctl restart NetworkManager

resolv.conf changes not persisting:

   # Check if NetworkManager is managing resolv.conf
   ls -la /etc/resolv.conf

   # If symlink to NetworkManager, configure via nmcli
   nmcli connection modify <connection> ipv4.dns "8.8.8.8 8.8.4.4"

DNS resolution slow:

   # Check which DNS server is being used
   nslookup google.com

   # Check DNS response time
   dig google.com | grep "Query time"

Cannot reach Google DNS:

   # Check firewall rules
   firewall-cmd --list-all

   # Allow DNS traffic
   firewall-cmd --add-service=dns --permanent
   firewall-cmd --reload

Complete Script (Run from Jump Host)

#!/bin/bash

echo "========================================="
echo "Configuring Google Public DNS"
echo "========================================="

ssh steve@stapp02 << 'EOF'
echo 'Am3ric@' | sudo -S bash -c '
echo ""
echo "=== Current DNS Configuration ==="
cat /etc/resolv.conf

echo ""
echo "=== Backing up resolv.conf ==="
cp /etc/resolv.conf /etc/resolv.conf.backup

echo ""
echo "=== Adding Google Public DNS ==="
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf

echo ""
echo "=== Updated DNS Configuration ==="
cat /etc/resolv.conf

echo ""
echo "=== Testing DNS Resolution ==="
ping -c 2 google.com

echo ""
echo "========================================="
echo "✅ Google Public DNS configured successfully!"
echo "📌 Primary DNS: 8.8.8.8"
echo "📌 Secondary DNS: 8.8.4.4"
echo "========================================="
'
EOF

Summary

✅ Google Public DNS added: 8.8.8.8 and 8.8.4.4
✅ Configuration file: /etc/resolv.conf
✅ DNS resolution tested: Working correctly
✅ Backup created: /etc/resolv.conf.backup

The DNS configuration on App Server 2 has been updated to use Google Public DNS as a temporary fix for the intermittent DNS resolution issues.

Linux Configure sudo

Janak Shrestha — Tue, 15 Sep 2026 06:53:59 +0000

We have some users on all app servers in Stratos Datacenter. Some of them have been assigned some new roles and responsibilities, therefore their users need to be upgraded with sudo access so that they can perform admin level tasks.

a. Provide sudo access to user siva on all app servers.

b. Make sure you have set up password-less sudo for the user.

Solution

Step 1: Connect to Each App Server and Configure sudo

App Server 1 (stapp01) - User: tony

ssh tony@stapp01
# Password: Ir0nM@n
sudo su -
# Password: Ir0nM@n
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva
exit
exit

App Server 2 (stapp02) - User: steve

ssh steve@stapp02
# Password: Am3ric@
sudo su -
# Password: Am3ric@
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva
exit
exit

App Server 3 (stapp03) - User: banner

ssh banner@stapp03
# Password: BigGr33n
sudo su -
# Password: BigGr33n
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva
exit
exit

One-Line Commands

App Server 1 (stapp01):

echo 'Ir0nM@n' | ssh tony@stapp01 "sudo -S bash -c 'echo \"siva ALL=(ALL) NOPASSWD: ALL\" > /etc/sudoers.d/siva && chmod 440 /etc/sudoers.d/siva'"

App Server 2 (stapp02):

echo 'Am3ric@' | ssh steve@stapp02 "sudo -S bash -c 'echo \"siva ALL=(ALL) NOPASSWD: ALL\" > /etc/sudoers.d/siva && chmod 440 /etc/sudoers.d/siva'"

App Server 3 (stapp03):

echo 'BigGr33n' | ssh banner@stapp03 "sudo -S bash -c 'echo \"siva ALL=(ALL) NOPASSWD: ALL\" > /etc/sudoers.d/siva && chmod 440 /etc/sudoers.d/siva'"

Using Heredoc (Recommended)

App Server 1:

ssh tony@stapp01 << 'EOF'
echo 'Ir0nM@n' | sudo -S bash -c '
echo "=== Configuring sudo for siva on stapp01 ==="
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva
echo "Verification:"
cat /etc/sudoers.d/siva
ls -la /etc/sudoers.d/siva
visudo -c
'
EOF

App Server 2:

ssh steve@stapp02 << 'EOF'
echo 'Am3ric@' | sudo -S bash -c '
echo "=== Configuring sudo for siva on stapp02 ==="
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva
echo "Verification:"
cat /etc/sudoers.d/siva
ls -la /etc/sudoers.d/siva
visudo -c
'
EOF

App Server 3:

ssh banner@stapp03 << 'EOF'
echo 'BigGr33n' | sudo -S bash -c '
echo "=== Configuring sudo for siva on stapp03 ==="
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva
echo "Verification:"
cat /etc/sudoers.d/siva
ls -la /etc/sudoers.d/siva
visudo -c
'
EOF

Automated Script (Run from Jump Host)

#!/bin/bash

echo "========================================="
echo "Configuring Password-less sudo for siva"
echo "========================================="

declare -A SERVERS=(
    ["stapp01"]="tony:Ir0nM@n"
    ["stapp02"]="steve:Am3ric@"
    ["stapp03"]="banner:BigGr33n"
)

for server in "${!SERVERS[@]}"; do
    IFS=':' read -r user pass <<< "${SERVERS[$server]}"
    echo ""
    echo "=== $server ($user) ==="

    ssh "$user@$server" << EOF
echo '$pass' | sudo -S bash -c '
echo "Configuring sudo for siva..."
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva

echo "Verification:"
echo "  File: \$(cat /etc/sudoers.d/siva)"
echo "  Permissions: \$(ls -la /etc/sudoers.d/siva | awk \"{print \\\$1}\")"
echo "  Syntax: \$(visudo -c 2>&1 | head -1)"
'
EOF
done

echo ""
echo "========================================="
echo "✅ Password-less sudo configured for siva"
echo "========================================="

Step-by-Step Interactive Commands

# Connect to stapp01
ssh tony@stapp01
# Password: Ir0nM@n

# Become root
sudo su -
# Password: Ir0nM@n

# Step 1: Create sudoers file for siva
echo "=== Creating sudoers file for siva ==="
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva

# Step 2: Set correct permissions
echo "=== Setting permissions ==="
chmod 440 /etc/sudoers.d/siva

# Step 3: Verify contents
echo "=== File contents ==="
cat /etc/sudoers.d/siva

# Step 4: Check permissions
echo "=== File permissions ==="
ls -la /etc/sudoers.d/siva

# Step 5: Validate sudoers syntax
echo "=== Validating syntax ==="
visudo -c

# Step 6: Test as siva user (if exists)
echo "=== Testing sudo access ==="
su - siva -c "sudo whoami" 2>/dev/null || echo "siva user not found or test failed"

# Exit
exit
exit

Expected Output

[root@stapp01 ~]# echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
[root@stapp01 ~]# chmod 440 /etc/sudoers.d/siva

[root@stapp01 ~]# cat /etc/sudoers.d/siva
siva ALL=(ALL) NOPASSWD: ALL

[root@stapp01 ~]# ls -la /etc/sudoers.d/siva
-r--r----- 1 root root 30 Sep 11 10:00 /etc/sudoers.d/siva

[root@stapp01 ~]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/siva: parsed OK

[root@stapp01 ~]# su - siva -c "sudo whoami"
root

Verification Commands

# 1. Check sudoers file exists
ls -la /etc/sudoers.d/siva

# 2. Check file contents
cat /etc/sudoers.d/siva

# 3. Check file permissions (should be 440)
stat -c "%a %U:%G %n" /etc/sudoers.d/siva

# 4. Validate sudoers syntax
visudo -c

# 5. Test sudo access as siva
su - siva -c "sudo whoami"
# Expected: root

# 6. Check sudo privileges
su - siva -c "sudo -l"
# Expected: (ALL) NOPASSWD: ALL

# 7. Verify on all servers
for server in stapp01 stapp02 stapp03; do
    echo "=== $server ==="
    ssh tony@$server "sudo cat /etc/sudoers.d/siva"
done

Understanding the sudoers Configuration

Syntax Breakdown

siva ALL=(ALL) NOPASSWD: ALL

Component	Meaning
`siva`	Username
`ALL`	Hosts (all hosts)
`(ALL)`	Run as user (all users)
`NOPASSWD:`	No password required
`ALL`	Commands (all commands)

File Permissions

Permission	Value	Description
`440`	`r--r-----`	Read-only for owner and group
Owner	`root`	Root user
Group	`root`	Root group

Why Use /etc/sudoers.d/

Cleaner than editing /etc/sudoers directly
Easier to manage individual user configurations
Less risk of breaking the main sudoers file
Files are automatically included if syntax is correct

Alternative Methods

Method 1: Using visudo to create file

visudo -f /etc/sudoers.d/siva
# Add: siva ALL=(ALL) NOPASSWD: ALL
# Save and exit

Method 2: Using tee command

echo "siva ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/siva
sudo chmod 440 /etc/sudoers.d/siva

Method 3: Using printf

printf "siva ALL=(ALL) NOPASSWD: ALL\n" | sudo tee /etc/sudoers.d/siva
sudo chmod 440 /etc/sudoers.d/siva

Method 4: Append to main sudoers file (not recommended)

echo "siva ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

Troubleshooting

"siva is not in the sudoers file":

   # Check if file was created
   ls -la /etc/sudoers.d/siva
   # Check contents
   cat /etc/sudoers.d/siva

"sudo: /etc/sudoers.d/siva is mode 0644, should be 0440":

   # Fix permissions
   chmod 440 /etc/sudoers.d/siva

"syntax error near line 1":

   # Check syntax
   visudo -c
   # Fix the line
   echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva

"siva user does not exist":

   # Create the user first
   useradd siva
   # Then configure sudo
   echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
   chmod 440 /etc/sudoers.d/siva

"Permission denied" when creating file:

   # Use sudo or become root
   sudo su -

File not being read:

   # Check if sudoers.d is included in main sudoers
   grep includedir /etc/sudoers
   # Should show: #includedir /etc/sudoers.d

Complete Script (Run from Jump Host)

#!/bin/bash

echo "========================================="
echo "Configuring Password-less sudo for siva"
echo "========================================="

declare -A SERVERS=(
    ["stapp01"]="tony:Ir0nM@n"
    ["stapp02"]="steve:Am3ric@"
    ["stapp03"]="banner:BigGr33n"
)

for server in "${!SERVERS[@]}"; do
    IFS=':' read -r user pass <<< "${SERVERS[$server]}"
    echo ""
    echo "=== $server ($user) ==="

    ssh "$user@$server" << EOF
echo '$pass' | sudo -S bash -c '
echo "Creating sudoers file..."
echo "siva ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/siva
chmod 440 /etc/sudoers.d/siva

echo "Verifying..."
echo "  Content: \$(cat /etc/sudoers.d/siva)"
echo "  Permissions: \$(stat -c "%a" /etc/sudoers.d/siva)"
echo "  Syntax check: \$(visudo -c 2>&1 | grep siva)"

if id siva &>/dev/null; then
    echo "  Sudo test: \$(su - siva -c "sudo whoami" 2>/dev/null)"
else
    echo "  Note: siva user does not exist yet"
fi

echo "✓ Configuration complete on $server"
'
EOF
done

echo ""
echo "========================================="
echo "✅ Password-less sudo configured for siva"
echo "========================================="
echo ""
echo "Verification commands:"
echo "  ssh tony@stapp01 'sudo cat /etc/sudoers.d/siva'"
echo "  ssh steve@stapp02 'sudo cat /etc/sudoers.d/siva'"
echo "  ssh banner@stapp03 'sudo cat /etc/sudoers.d/siva'"

Summary

✅ sudoers file created: /etc/sudoers.d/siva on all servers
✅ Configuration: siva ALL=(ALL) NOPASSWD: ALL
✅ Permissions: 440 (r--r-----)
✅ Syntax validated: Using visudo -c
✅ Password-less sudo: Enabled for siva

The user siva now has password-less sudo access on all App servers in the Stratos Datacenter.

Configure Jenkins Job for Package Installation

Janak Shrestha — Mon, 14 Sep 2026 15:43:04 +0000

Some new requirements have come up to install and configure some packages on the Nautilus infrastructure under Stratos Datacenter. The Nautilus DevOps team installed and configured a new Jenkins server so they wanted to create a Jenkins job to automate this task. Find below more details and complete the task accordingly:

Access the Jenkins UI by clicking on the Jenkins button in the top bar. Log in using the credentials: username admin and password Adm!n321.
Create a new Jenkins job named install-packages and configure it with the following specifications:

Add a string parameter named PACKAGE.

Configure the job to install a package specified in the $PACKAGE parameter on the storage server (Stratos Datacenter).

Build the job at least once (e.g. with parameter PACKAGE=vim-enhanced) so the package is installed on the Storage server and can be verified.

Note:

Ensure to install any required plugins and restart the Jenkins service if necessary. Opt for Restart Jenkins when installation is complete and no jobs are running on the plugin installation/update page. Refresh the UI page if needed after restarting the service.
Verify that the Jenkins job runs successfully on repeated executions to ensure reliability.
Capture screenshots of your configuration for documentation and review purposes. Alternatively, use screen recording software like loom.com for comprehensive documentation and sharing.

Step 1: Access Jenkins UI

Click the Jenkins button in the top bar and log in with:

Username: admin
Password: Adm!n321

Step 2: Install Required Plugin

The Publish Over SSH plugin is recommended for this task, as it allows Jenkins to execute commands on remote servers directly .

Go to Manage Jenkins → Plugins → Available
Search for "Publish Over SSH"
Check the box and click Install without restart
If prompted, select "Restart Jenkins when installation is complete and no jobs are running"

Refresh the UI page after Jenkins restarts.

Step 3: Configure SSH Connection to Storage Server

Before creating the job, you need to set up SSH connectivity from Jenkins to ststor01:

Go to Manage Jenkins → Configure System
Scroll down to Publish over SSH section
Click Add to create a new SSH server
Configure with these details:
- Name: ststor01
- Hostname: ststor01
- Username: natasha
- Remote Directory: /home/natasha (or leave blank)
- Password: Bl@kW (or use key-based authentication)
Click Test Configuration to verify connectivity
Click Save

Step 4: Create the install-packages Job

From the dashboard, click New Item
Enter name: install-packages
Select Freestyle project
Click OK

Step 5: Add the PACKAGE Parameter

In the job configuration, scroll to General
Check "This project is parameterized"
Click Add Parameter → select String Parameter
Configure the parameter:
- Name: PACKAGE
- Default Value: vim-enhanced (or leave blank)
- Description: Enter the package name to install on the storage server
Click Save

Step 6: Configure Build Step to Install Package

Scroll down to the Build section
Click Add build step → select Send files or execute commands over SSH
Select the server: ststor01
In the Exec command field, add:

sudo yum install -y $PACKAGE || sudo apt-get install -y $PACKAGE

Important: The natasha user needs passwordless sudo access. If you encounter a sudo: sorry, you must have a tty to run sudo error, the Jenkins server admin must add this entry to the sudoers file on ststor01 :

natasha ALL=(ALL) NOPASSWD: ALL

Or alternatively, disable the TTY requirement:

Defaults:natasha !requiretty

Click Save

Step 7: Build the Job

From the job page, click Build with Parameters
Enter a package name, e.g., vim-enhanced
Click Build
Click Console Output to monitor the build progress and verify success

Step 8: Verify Installation

After the build succeeds, SSH into ststor01 and verify:

ssh natasha@ststor01
rpm -qa | grep vim-enhanced    # For RHEL/CentOS
# OR
dpkg -l | grep vim-enhanced    # For Ubuntu/Debian

Step 9: Test Repeated Executions

Run the job again with different packages (e.g., curl, git) to ensure the job works reliably on repeated executions .

Summary

Step	Action
1	Log in to Jenkins UI (admin / Adm!n321)
2	Install Publish Over SSH plugin
3	Configure SSH connection to `ststor01`
4	Create Freestyle job named `install-packages`
5	Add String Parameter `PACKAGE`
6	Configure build step with SSH command
7	Build with parameter (e.g., `vim-enhanced`)
8	Verify installation on storage server
9	Test repeatedly for reliability

Key Points:

Use Publish Over SSH plugin for reliable remote execution
Ensure natasha has passwordless sudo access on ststor01
Test the job multiple times with different packages to ensure reliability

Organize Jenkins Jobs with Folders

Janak Shrestha — Mon, 14 Sep 2026 15:33:53 +0000

xFusionCorp Industries' DevOps team aims to streamline the management of Jenkins jobs by organizing them into distinct folders based on their purpose. Complete the task following the provided requirements:

1.Access the Jenkins UI by clicking on the Jenkins button in the top bar. Log in using the credentials: username admin and password Adm!n321.

Create a new folder named Apache within the Jenkins UI.
Move the existing jobs httpd-php and services under the newly created Apache folder.

Note:

Ensure to install any required plugins and restart the Jenkins service if necessary. Opt for Restart Jenkins when installation is complete and no jobs are running on the plugin installation/update page.
Be aware that Jenkins UI may experience temporary unresponsiveness during the service restart. Refresh the UI page if needed.
Capture screenshots of your work for documentation and review purposes. Alternatively, utilize screen recording software like loom.com for detailed documentation and sharing.

Step 1: Access Jenkins UI

Click the Jenkins button on the top bar of your KodeKloud environment and log in with:

Username: admin
Password: Adm!n321

Step 2: Install the Folders Plugin

The Folders plugin is required to create folders in Jenkins .

Navigate to Manage Jenkins → Plugins (or Manage Plugins)
Click on the Available tab
Search for "Folders"
Check the box for the "Folders" plugin (maintained by CloudBees)
Click Install without restart or Download now and install after restart

Important: If prompted, select "Restart Jenkins when installation is complete and no jobs are running"

After restart, log in again with the same credentials. If the UI becomes unresponsive, refresh the page .

Step 3: Create the "Apache" Folder

Once the Folders plugin is installed and Jenkins has restarted:

From the Jenkins dashboard, click New Item
Enter the name: Apache
Select Folder as the item type
Click OK
On the configuration page, you can leave the Display Name same as the folder name
Click Save

Step 4: Move the "httpd-php" Job

From the dashboard, click on the httpd-php job to open it
In the left sidebar, click Move
In the destination field, select Apache folder
Click Move

Step 5: Move the "services" Job

From the dashboard, click on the services job
In the left sidebar, click Move
Select Apache as the destination
Click Move

Step 6: Verify the Result

After moving both jobs, your Jenkins dashboard should show:

Apache/
├── httpd-php
└── services

You can verify by:

Clicking on the Apache folder to see both jobs inside
Checking that the dashboard no longer shows httpd-php and services at the root level

Troubleshooting Tips

If "Folder" option doesn't appear during New Item creation, the plugin installation likely hasn't completed. Wait a few moments and refresh, or check Manage Jenkins → Manage Plugins → Installed to confirm the Folders plugin is active .
If Jenkins UI becomes stuck during restart, simply refresh the browser page and log in again .

Summary

Step	Action
1	Log in to Jenkins UI (admin / Adm!n321)
2	Install Folders plugin via Manage Plugins
3	Restart Jenkins if prompted
4	Create new Folder named "Apache"
5	Move `httpd-php` job into Apache folder
6	Move `services` job into Apache folder

DEV Community: Janak Shrestha

Install and Configure HaProxy LBR

Introduction

Understanding HAProxy

What is HAProxy

Key Features

HAProxy Architecture

Prerequisites

Server Details for This Tutorial

Installing HAProxy

Understanding the Default Configuration

Configuring HAProxy

Step 1: Backup the Original Configuration

Step 2: Edit the Configuration File

Step 3: Complete Configuration

Step 4: Configuration Explanation

Verifying the Configuration

Starting and Enabling HAProxy

Verifying the Setup

Check Listening Ports

Test with Curl

Test Round-Robin Load Balancing

Check Backend Health

Troubleshooting Common Issues

503 Service Unavailable

Configuration File Errors

Duplicate Section Names

Port Already in Use

Checking Logs

Best Practices

Always Backup Configuration

Preserve the Stats Socket

Use Health Checks

Test Configuration Before Restart

Monitor Backend Health

Document Configuration Changes

Automation Script

Conclusion

Summary of the Setup

Key Takeaways

Verification Results

Final Configuration

Additional Resources

Manual Pages

Related Topics

Useful Commands

Day 78: Jenkins Conditional Pipeline

Understanding the Architecture

Task Requirements

Part 1: Prepare the Infrastructure

Step 1: SSH to Jenkins Server

Step 2: Generate SSH Key (if missing)

Step 3: Copy SSH Key to sarah on App Server 1

Step 4: Install Java 21 on App Server 1

Step 5: Create the Agent Directory

Part 2: Install Required Jenkins Plugins

Part 3: Add SSH Credentials

Part 4: Add the Jenkins Agent Node

Part 5: Create the Conditional Pipeline Job

Step 1: Create a New Pipeline Job

Step 2: Add the BRANCH Parameter

Step 3: Configure the Pipeline Script

Explanation of the Script

Step 4: Save the Job

Part 6: Verify the Feature Branch Exists

Part 7: Test Both Deployments

Test 1: Deploy master Branch

Test 2: Deploy feature Branch

Verification

Verify on App Server 1

Verify via Load Balancer

Complete Configuration Summary

Troubleshooting

Task Summary

Key Learnings

Conclusion

Next Steps

Linux Postfix Troubleshooting

Introduction

Understanding the Problem

Step 3: Copy SSH Key to `sarah` on App Server 1

Step 2: Add the `BRANCH` Parameter

Test 1: Deploy `master` Branch

Test 2: Deploy `feature` Branch

Step 3: Copy SSH Key to `sarah` on App Server 1