Forem: Wycliffe A. Onyango

You Bought a Domain. Now Why Does It Feel Like You Need Three?

Wycliffe A. Onyango — Sun, 18 Jan 2026 09:17:35 +0000

You’ve done the hard part. You built a frontend that looks incredible. You finished a backend that actually works. You even pulled the trigger and bought that professional .com or .co.ke you’ve been eyeing.

But now, you’re stuck.

You’re staring at the dashboard of your domain registrar, and the realization is hitting you: "I have one domain name, but I have three different things to show the world."

You need a Portfolio to land the job.
You need an App to show the product.
You need an API to power the whole thing.

You might be wondering: Did I make a mistake? Do I need to buy three different domains? How am I supposed to jam a React frontend, a Node.js backend, and a static portfolio into one single address?

Stop. You don’t need more domains. You just need to realize that you didn't buy a single room—you bought the whole plot of land.

The "Subdomain" Superpower

Right now, you’re likely looking at your domain as a static file. But your domain is actually a namespace. Think of it as a house. Your main domain is the front door (the Lobby), but you can add as many side doors as you want.

The Lobby (yourdomain.com): This is for your Portfolio. It’s your handshake with the world.
The Workshop (app.yourdomain.com): This is where your application lives. It’s a separate space for users to interact with your code.
The Engine Room (api.yourdomain.com): This is where your backend sits. It’s tucked away, doing the heavy lifting without cluttering your frontend.

The "DNS Map" in Your Hands

If you’re looking at settings like A Records, CNAMEs, and Nameservers and feeling like you’re about to break the internet—take a breath.

DNS is just a map. Your job is simply to draw the lines:

Point the "root" (@) to wherever you decide to host your portfolio.
Create a CNAME record named `app` and point it to your frontend host.
Create a CNAME record named `api` and point it to your backend host.

The moment you do this, you stop being someone who just "writes code" and you become a System Architect. You are now managing a professional-grade ecosystem where every part of your stack has its own home.

The Final "Handshake" (CORS)

Once you get those subdomains live, you’ll likely hit one last wall. Your frontend will try to talk to your backend, and the browser will stop it. It will say: "I don't trust this connection."

Don't panic. This is the CORS (Cross-Origin Resource Sharing) talk.

Even though your App and your API share a "last name," they are separate origins. You must go into your backend code and explicitly say: "I trust my workshop. Let app.yourdomain.com in." It’s the final handshake that connects your engine to your interface.

The Takeaway

If you’re frustrated today because your domain feels "too small" for your project, remember this: Your domain is as big as you make it. You have the power to host a portfolio, a production app, and a robust API all under one roof. You aren't just pointing URLs; you're building a professional infrastructure.

Stop staring at the "Site Not Found" error. Go to your DNS manager, add those records, and turn your one domain into a powerhouse.

100 Days of DevOps: Day 79

Wycliffe A. Onyango — Mon, 24 Nov 2025 07:49:34 +0000

Automated CI/CD for Nautilus Application

Overview

This article confirms the successful implementation of a robust Continuous Deployment (CD) pipeline using Jenkins. The solution ensures that any code push to the Git repository's master branch instantly triggers a build, deploying the complete application contents to the Storage Server (ststor01) under the required ownership of user sarah.

I. Infrastructure Setup Commands (Prerequisites)

These commands ensure the necessary passwordless access and user accounts are in place before deployment. They must be executed on the respective servers using administrative privileges (e.g., as jenkins or natasha via sudo).

A. Jenkins Server Setup (to enable passwordless SSH)

The jenkins user's public key must be generated and transferred to the remote natasha account.

Command (Run on Jenkins Server as `jenkins`)	Purpose
`ssh-keygen`	Generates the private (`id_ed25519`) and public (`id_ed25519.pub`) key pair.
`ssh-copy-id -i /var/lib/jenkins/.ssh/id_ed25519.pub natasha@ststor01.stratos.xfusioncorp.com`	Transfers the public key to the Storage Server for passwordless login as `natasha`.

B. Storage Server Setup (ststor01)

These steps are crucial for automation (Natasha's sudo rights) and the final file ownership/verification (Sarah's account).

Command (Run on Storage Server as `natasha` via `sudo`)	Purpose
`sudo visudo` (and add line below)	Configures passwordless `sudo` for `natasha` to allow the script to run `chown` and `tar` without prompts.
`natasha ALL=(ALL) NOPASSWD: ALL`	The line added to `/etc/sudoers` file.
`sudo useradd sarah`	Creates the user `sarah` (required for file ownership and Task 3).
`sudo passwd sarah`	Sets the login password for `sarah` (required for Task 3 SSH).

II. Jenkins Job Configuration & Execution

A. Build Trigger Setup (Webhook)

The job nautilus-app-deployment was configured to use the Generic Webhook Trigger.

Action	Value/URL Used
Jenkins URL Endpoint	`http://172.16.238.19:8080/generic-webhook-trigger/invoke?token=<SECRET_TOKEN>`
Gitea Webhook Target	The Jenkins URL above was pasted into the Git repository's webhook settings.
Gitea Trigger	Set to trigger on Push Events to the `master` branch.

B. Execution Shell Script (`deployment_script.sh`)

The following script was placed in the Jenkins job's Execute shell step. It uses tar piped over ssh to efficiently transfer the files, as rsync was not available on the Jenkins host.

#!/bin/bash

# ==============================================================================
# Jenkins Deployment Script for Storage Server (ststor01)
# ==============================================================================

# Target Server details
STORAGE_SERVER_USER="natasha" # Assuming we use the listed user to SSH into the server
STORAGE_SERVER_HOST="ststor01.stratos.xfusioncorp.com"
DEPLOY_PATH="/var/www/html"

# SSH Options for non-interactive execution:
# 1. StrictHostKeyChecking=no: Avoids the "Host key verification failed" error on first connect.
# 2. UserKnownHostsFile=/dev/null: Ensures the keys are not written to the known_hosts file.
SSH_OPTS="-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"

echo "Starting deployment process to $STORAGE_SERVER_HOST:$DEPLOY_PATH"

# 1. SSH into the Storage Server and set ownership to 'sarah'.
# This ensures that the subsequent file operations performed by 'natasha' on the directory
# will not affect the final deployed files' required ownership.
echo "1. Changing ownership of $DEPLOY_PATH to user 'sarah' on the Storage Server..."
ssh ${SSH_OPTS} ${STORAGE_SERVER_USER}@${STORAGE_SERVER_HOST} "sudo chown -R sarah:sarah ${DEPLOY_PATH}"

if [ $? -eq 0 ]; then
    echo "Ownership change successful."
else
    echo "ERROR: Failed to change ownership on the remote server. Check SSH keys, sudo rights."
    exit 1
fi

# 2. Deploy the new code using 'tar' piped over SSH.
echo "2. Deploying content from Jenkins workspace (${WORKSPACE}) to $DEPLOY_PATH using tar over SSH..."

# A. Execute 'tar' locally to create a compressed archive of the workspace, excluding .git.
# B. Pipe the output (-) directly to the remote 'ssh' connection.
# C. On the remote server:
#    i. Use 'sudo' to remove all existing files in the deployment path for a clean slate.
#    ii. Pipe the incoming compressed data to 'sudo tar -xzf -' to extract it into the path.
tar -czf - --exclude '.git' -C "${WORKSPACE}" . | \
    ssh ${SSH_OPTS} ${STORAGE_SERVER_USER}@${STORAGE_SERVER_HOST} "
        # Use sudo for file deletion and extraction
        sudo rm -rf ${DEPLOY_PATH}/* && sudo tar -xzf - -C ${DEPLOY_PATH}
    "

if [ $? -eq 0 ]; then
    echo "Deployment successful on $STORAGE_SERVER_HOST."
else
    echo "ERROR: Deployment failed during file transfer (tar/ssh pipe). Check permissions/connectivity."
    exit 1
fi

echo "Deployment finished successfully."

III. Final Verification

These commands are used to push the code and trigger the fully automated pipeline.

Command (Run on Storage Server as `sarah`)	Purpose
`ssh sarah@ststor01.stratos.xfusioncorp.com`	Log in to the Storage Server as the user `sarah`.
`cd web`	Navigate to the cloned repository.
`echo "Welcome to the xFusionCorp Industries" > index.html`	Modify the content of the index file as required.
`git add index.html`	Stage the modified file.
`git commit -m "Updated homepage content for deployment"`	Commit the change locally.
`git push origin master`	Triggers the webhook and starts the Jenkins job, completing the CD cycle.

100 Days of DevOps: Day 78

Wycliffe A. Onyango — Tue, 28 Oct 2025 20:25:33 +0000

Jenkins Conditional Pipeline Deployment for Nautilus Web App

Objective

The goal of this task was to configure a Jenkins Pipeline job that automatically deploys a static website from the Gitea repository depending on the parameters selected to the Nautilus Application Servers, using the Storage Server (ststor01) as the Jenkins agent.

The deployed web application should be accessible directly from the root URL:

https://8091-port-7l43zyf3btna3i6q.labs.kodekloud.com/

and not from a subdirectory like /web_app.

Step-by-Step Implementation

1. Install and Configure Jenkins Plugins

To ensure the pipeline could interact with Git and remote agents, the following plugins were verified and installed via Manage Jenkins → Plugins:

Git Plugin → enables Jenkins to clone and pull from Git repositories.
SSH Agent Plugin → required for communication between Jenkins and remote agents.
Pipeline Plugin → allows scripted and declarative pipelines to run.

After installation, Jenkins was restarted to apply changes.

2. Configure Jenkins Credentials

Instead of using an SSH key, the connection to the Storage Server was configured to use username and password authentication.

Steps:

Go to Manage Jenkins → Credentials → System → Global Credentials → Add Credentials
Select “Username and Password” as the credential type.
Enter:

Username: natasha
Password: (used password provided in the task)
ID: ststor01-password

4.Click Save.

These credentials were later linked to the Storage Server node so Jenkins could authenticate via SSH using natasha’s account.

3. Add Jenkins Agent Node (Storage Server)

A new node was created to allow Jenkins to deploy code directly on the Storage Server.

Steps:

Navigate to Manage Jenkins → Nodes → New Node
Configure the node with:

Name: Storage Server
Remote Root Directory: /var/www/html
Labels: ststor01
Launch method: Launch agents via SSH
Host: IP or hostname of the Storage Server
Credentials: select natasha (ststor01-password)

3.Save and verify the node connects successfully and shows “Online.”

4. Verify Environment on Storage Server

On the Storage Server, verify prerequisites and directory setup:

whoami
# natasha
cd /var/www/html
git --version   # confirm git installed

Apache was already running on port 8080 and serving from /var/www/html.

5. Access Jenkins and Gitea

Logged into both systems using provided credentials:

Jenkins:
- Username: admin
- Password: Adm!n321
Gitea:
- Repository URL: https://80-port-7l43zyf3btna3i6q.labs.kodekloud.com/sarah/web_app
- Username: sarah
- Password: (used as provided)

Confirmed repository contained master and feature branches.

6. Create the Jenkins Pipeline Job

Click New Item → Pipeline
Name it nautilus-webapp-job
Enable “This project is parameterized” and add a String Parameter:

Name: BRANCH
Default Value: master
Description: Branch to deploy (master or feature)

4.Under the Pipeline script section, paste the working Groovy script below.

7. Final Working Jenkins Pipeline Script

node('ststor01') {
    stage('Deploy') {
        def branchName = params.BRANCH?.trim()
        if (!branchName) {
            branchName = "master"
        }

        if (branchName != "master" && branchName != "feature") {
            error("Invalid BRANCH parameter: ${branchName}. Use 'master' or 'feature'.")
        }

        sh """
            set -e
            echo "=== Deployment started for branch: ${branchName} ==="

            cd /var/www/html

            if [ ! -d .git ]; then
                echo "Repository not found. Cloning..."
                git clone https://80-port-7l43zyf3btna3i6q.labs.kodekloud.com/sarah/web_app.git .
            fi

            echo "Fetching and resetting to ${branchName}"
            git fetch origin
            git checkout -f ${branchName} || git checkout -b ${branchName} origin/${branchName}
            git reset --hard origin/${branchName}

            echo "=== Deployment complete at /var/www/html ==="
        """
    }
}

This script:

Automatically clones the repository if missing.
Fetches and synchronizes the correct branch (master or feature).
Deploys directly to /var/www/html, ensuring no subdirectory path like /web_app.

8. Run and Verify the Pipeline

Triggered the job with parameter:

BRANCH = master

Expected Console Output:

=== Deployment started for branch: master ===
Fetching and resetting to master
HEAD is now at e12c8f4 Updated index.html
=== Deployment complete at /var/www/html ===

Job completed successfully with no workspace errors.

9. Validation

Opened the web app at:

https://8091-port-7l43zyf3btna3i6q.labs.kodekloud.com/

Confirmed the content loaded correctly from the root URL (no /web_app subpath), proving that deployment targeted the proper directory.

Key Notes

Installed and verified Git, SSH Agent, and Pipeline plugins before running jobs.
Used username + password authentication for the natasha account (no SSH key).
Always ensure node labels match (ststor01).
The workspace issues were avoided by deploying directly under /var/www/html.
The BRANCH parameter allows switching between master and feature easily.

100 Days of DevOps: Day 77

Wycliffe A. Onyango — Fri, 24 Oct 2025 14:38:19 +0000

CI/CD Deployment of Web Application using Jenkins Pipeline

Objective

Automate deployment of a static website from a Gitea repository to the shared document root on the Storage Server using a Jenkins Pipeline with a single stage named Deploy.

Work Completed

1. Jenkins UI Access

Jenkins was already installed and running. Configuration was performed through the Jenkins web interface:

Username: admin
Password: Adm!n321

No Jenkins server installation steps were required.

2. Required Jenkins Plugin Installation

Several plugins needed for source code retrieval and pipeline execution were installed from:

Manage Jenkins → Plugins → Available Plugins

Installed:

Git plugin
SSH Agent plugin
Pipeline plugin

Jenkins was restarted from the UI to apply the changes.

3. Java 21 Installation

Java was required for proper Jenkins agent execution. On the Storage Server, Java 21 was installed using:

sudo dnf install -y java-21-openjdk
java -version

Java installed successfully.

4. Add Storage Server as Jenkins Agent

Jenkins needed a remote execution environment to deploy directly to the shared site directory.

Performed via:
Manage Jenkins → Nodes → New Node

Configuration:

Node name: Storage Server
Remote root directory: /var/www/html/workspace
Label: ststor01
Launch method: Launch agent via execution of command on the agent node

Jenkins generated a command, which was executed on the Storage Server to bring the agent online.

Credentials Setup

Under:
Manage Jenkins → Credentials

A secure SSH credential was added to allow the controller to authenticate to the Storage Server. This ensured a reliable and secure connection for deployments.

5. Folder Permissions on Storage Server

To allow Jenkins agent to write deployed files:

sudo chown -R natasha:natasha /var/www/html
sudo chmod -R 755 /var/www/html

This ensured successful delivery of web content.

6. Create Jenkins Pipeline Job

Job Type: Pipeline
Job Name: xfusion-webapp-job
(Not a Multibranch Pipeline)

Pipeline Script Used

pipeline {
    agent { label 'ststor01' }
    stages {
        stage('Deploy') {
            steps {
                git url: 'https://80-port-qtjnzi2lylpawcus.labs.kodekloud.com/sarah/web_app'
                sh 'cp -r index.html /var/www/html/'
            }
        }
    }
}

Details:

Single stage named Deploy (case-sensitive requirement met)
Pulls source code from web_app repository in Gitea
Deployed directly to final document root

7. Successful Deployment Execution

Triggered via Build Now.

Console output confirmed:

Git repository successfully cloned
Deployment action executed on Storage Server
index.html delivered properly

Final status: SUCCESS

The website displayed correctly via the Load Balancer main URL without extra subdirectories.

Final Result

A complete CI/CD deployment pipeline now updates the website automatically with each build. The system uses:

A Jenkins pipeline job
SSH connected Storage Server agent
Secure credentials
Direct deployment to /var/www/html

This enables developers to publish updates efficiently and consistently.

100 Days of DevOps: Day 76

Wycliffe A. Onyango — Thu, 23 Oct 2025 06:07:34 +0000

Jenkins Security Configuration: Project-Based Authorization

Project Summary

This article documents the configuration process to grant fine-grained, job-specific permissions to new developers, sam and rohan, on the Packages job within the xFusionCorp Industries Jenkins instance. The task utilized the Project-based Matrix Authorization Strategy to ensure the Principle of Least Privilege.

Prerequisites

Users: admin, sam, rohan exist in the Jenkins Security Realm.
Job: Packages job exists.
Plugin: Matrix Authorization Strategy Plugin installed and Jenkins restarted.

Stage 1: Global Security Configuration (The Parent ACL)

The initial attempt failed because the users lacked the fundamental global permission to view the Jenkins UI. This step rectifies that to ensure successful login.

1.1 Activate Authorization Strategy

Log in as admin (Adm!n321).
Navigate to Manage Jenkins then Configure Global Security.
Under the Authorization section, select Project-based Matrix Authorization Strategy.

1.2 Grant Global Read Access

The Overall/Read permission is the minimum requirement for any user to successfully log in and see the Jenkins dashboard.

In the Global permission matrix:
Add user sam
Add user rohan
For both sam and rohan, check only the box for Overall then Read.
Click Save.

This configuration ensures the users can log in, thus resolving the "missing the Overall/Read permission" error.

Stage 2: Packages Job Configuration (The Child ACL)

This stage applies the specific job-level permissions as required by the development team.

Navigate to the Jenkins dashboard and open the Packages job.
Click Configure in the left sidebar.
Scroll to the Authorization section and check the box for "Enable project-based security."

2.1 Configure Inheritance Strategy (Requirement A)

Under the Authorization settings, the required inheritance rule was applied:

Select Inheritance Strategy then Inherit permissions from parent ACL.

This setting correctly combines the global Overall/Read permission with the project-specific permissions defined below.

2.2 Grant Specific Job Permissions (Requirements B & C)

The final, specific permissions were granted in the project-level matrix:

User	Requirement	Job/Read	Job/Build	Job/Configure	Job/Cancel	Job/Update	SCM/Tag
sam	Build, Configure, Read	✓	✓	✓
rohan	Build, Cancel, Configure, Read, Update, Tag	✓	✓	✓	✓	✓	✓

4.Click Save to apply the configuration to the Packages job.

Verification and Conclusion

The configuration is now complete and verified:

sam can log in and perform read, build, and configure actions on the Packages job.

rohan can log in and has full control over the Packages job, including the ability to cancel builds and tag SCM revisions.

Neither user has global administrative access, adhering to security best practices.

The successful implementation demonstrates the correct application of the Project-based Matrix Authorization Strategy for granular access control in the Jenkins environment.

100 Days of DevOps: Day 75

Wycliffe A. Onyango — Wed, 22 Oct 2025 07:19:12 +0000

Jenkins Agent Node Configuration

Project Goal

The primary goal was to successfully connect three Linux Application Servers (stapp01, stapp02, stapp03) as permanent Jenkins agent nodes to the Jenkins controller using the SSH method.

Final Status

SUCCESS. All three agent nodes (App_server_1, App_server_2, and App_server_3) are now online, connected to the Jenkins controller, and ready to accept build jobs.

Prerequisite

Step	Action
Install SSH Plugin	Navigate to Manage Jenkins then Manage Plugins then Available Plugins. Search for and install the "SSH Agents plugin" (or similar, depending on Jenkins version/naming).

Core Jenkins UI Configuration (Per Node)

The following settings were applied when creating each new permanent node in Jenkins (Manage Jenkins then Manage Nodes then New Node).

1. Credentials Setup

Before configuring the node, the SSH credentials for each agent user were added to Jenkins.

Navigate to Manage Jenkins then Credentials
Click Add Credentials.
Set Kind to Username with private key (or SSH Username with password).
Input the Username (tony, steve, or banner).
Provide the corresponding Private Key (or Password).
Assign an easily identifiable ID (e.g., tony-ssh-key). This ID is selected during node configuration.

2. Node Configuration Table

Configuration Field	App_server_1 (stapp01)	App_server_2 (stapp02)	App_server_3 (stapp03)
Node Name	`App_server_1`	`App_server_2`	`App_server_3`
Remote Root Directory	`/home/tony/jenkins-agent`	`/home/steve/jenkins-agent`	`/home/banner/jenkins-agent`
Labels	`stapp01`	`stapp02`	`stapp03`
Launch Method	`Launch agent via SSH`	`Launch agent via SSH`	`Launch agent via SSH`
Host	`stapp01` (or its IP address)	`stapp02` (or its IP address)	`stapp03` (or its IP address)
Credentials	Select the `tony` credential ID	Select the `steve` credential ID	Select the `banner` credential ID
Host Key Verification Strategy	`Non-verifying Verification Strategy` (or preferred method)	`Non-verifying Verification Strategy`	`Non-verifying Verification Strategy`
Usage	`Only build jobs with label expressions matching this node`	`Only build jobs with label expressions matching this node`	`Only build jobs with label expressions matching this node`

Key Challenge Resolution: Java 21 Configuration Steps

The initial failure was due to the Jenkins SSH agent session failing to find the correct Java executable. The resolution involved guaranteeing that Java 21 was explicitly set up for the system and the agent users on all three App Servers.

Install Java 21:

    sudo yum install java-21-openjdk -y

Final Step: Agent Launch

With all environment and Jenkins configurations complete, the nodes were successfully launched from the Jenkins UI, resolving the original dependency and credential errors, and transitioning all agents to an Online status.

100 Days of DevOps: Day 74

Wycliffe A. Onyango — Tue, 21 Oct 2025 06:57:33 +0000

Automating Database Backup in Jenkins

Overview

The Jenkins job, database-backup, has been successfully implemented to automate database backups for kodekloud_db01 and securely transfer the dump to the Backup Server. This solution successfully navigated a major administrative hurdle: the Jenkins Server lacked the mysqldump utility, and the jenkins user was blocked from using sudo to install it.

I. Problem & Solution Strategy

The Challenge	The Solution
`mysqldump: command not found` on Jenkins Server.	Remote Execution: Use SSH to execute `mysqldump` on the Database Server (`stdb01`) where the utility exists.
Password prompts break automated jobs.	Passwordless SSH: Configure key-based authentication from the Jenkins Server to both target servers.

Infrastructure Details Used

Server	Hostname	User	Password	Purpose
Jenkins	`jenkins.stratos.xfusioncorp.com`	`jenkins`	`j@rv!s`	CI/CD
Database	`stdb01.stratos.xfusioncorp.com`	`peter`	`Sp!dy`	DB Server
Backup	`stbkp01.stratos.xfusioncorp.com`	`clint`	`H@wk3y3`	Backup Server

II. Command Line Steps (Prerequisites)

All following commands are executed while SSHed into the Jenkins Server as the jenkins user.

Step 1: Generate the SSH Key Pair

# 1. Generate an RSA 4096-bit key pair.
jenkins@jenkins:~$ ssh-keygen -t rsa -b 4096

# IMPORTANT: Press ENTER twice to leave the passphrase EMPTY!

# Key files are saved to: /var/lib/jenkins/.ssh/

Step 2: Install Public Key on Target Servers

The public key (/var/lib/jenkins/.ssh/id_rsa.pub) is installed on both target machines to enable passwordless access.

Target	User	Command	Password to Enter
DB Server	`peter`	`ssh-copy-id -i /var/lib/jenkins/.ssh/id_rsa.pub peter@stdb01.stratos.xfusioncorp.com`	`Sp!dy`
Backup Server	`clint`	`ssh-copy-id -i /var/lib/jenkins/.ssh/id_rsa.pub clint@stbkp01.stratos.xfusioncorp.com`	`H@wk3y3`

III. Jenkins Job Configuration

Step 3: Job Setup and Scheduling

Create Job: Create a new Freestyle Project named database-backup.
Scheduling: In the Build Triggers section, enable "Build periodically" and set the schedule:
```
*/10 * * * *
```

Step 4: Execute Shell Script (Remote Execution)

In the Build section, add an "Execute shell" build step and use the following script. This script executes mysqldump remotely on the DB Server and pipes the output back to the Jenkins Server.

#!/bin/bash

# --- Database Details ---
DB_NAME="kodekloud_db01"
DB_USER="kodekloud_roy"
DB_PASS="asdfgdsd"
DB_HOST="stdb01.stratos.xfusioncorp.com"
DB_USER_SSH="peter" 

# --- Backup Details ---
BACKUP_HOST="stbkp01.stratos.xfusioncorp.com"
BACKUP_USER="clint"
BACKUP_DIR="/home/clint/db_backups"

# --- File Naming ---
DATE_FORMAT=$(date +%F)
DUMP_FILE="db_${DATE_FORMAT}.sql"

# 1. Execute DUMP REMOTELY on the DB Server and PIPE output to the Jenkins Server
echo "Executing remote database dump on ${DB_HOST} and piping output..."
ssh -T "${DB_USER_SSH}"@"${DB_HOST}" "mysqldump -u ${DB_USER} -p${DB_PASS} ${DB_NAME}" > "${DUMP_FILE}"

if [ $? -ne 0 ]; then
    echo "ERROR: Remote database dump failed. Check SSH key setup or DB credentials."
    rm -f "${DUMP_FILE}"
    exit 1
fi

echo "Database dump successful and saved locally: ${DUMP_FILE}"

# 2. Copy the dump file from the Jenkins Server to the Backup Server
echo "Copying ${DUMP_FILE} to Backup Server (${BACKUP_HOST})..."
scp "${DUMP_FILE}" "${BACKUP_USER}"@"${BACKUP_HOST}":"${BACKUP_DIR}/"

if [ $? -eq 0 ]; then
    echo "File successfully copied to ${BACKUP_HOST}:${BACKUP_DIR}/${DUMP_FILE}"
    # Clean up the local dump file
    rm "${DUMP_FILE}"
else
    echo "ERROR: Failed to copy the dump file via SCP."
    exit 1
fi

IV. Final Result

The job successfully ran and achieved the required outcome:

[database-backup] $ /bin/bash /tmp/jenkins...sh
Executing remote database dump on stdb01.stratos.xfusioncorp.com and piping output...
Database dump successful and saved locally: db_2025-10-21.sql
Copying db_2025-10-21.sql to Backup Server (stbkp01.stratos.xfusioncorp.com)...
File successfully copied to stbkp01.stratos.xfusioncorp.com:/home/clint/db_backups/db_2025-10-21.sql
Finished: SUCCESS

100 Days of DevOps: Day 73

Wycliffe A. Onyango — Mon, 20 Oct 2025 09:06:05 +0000

Automated Apache Log Collection for xFusionCorp Industries

I successfully implemented the copy-logs Jenkins job to automatically collect Apache access and error logs. This provides critical log data for immediate troubleshooting, bridging the gap until the full centralized logging system is complete.

1. Initial Access and Plugin Installation

The first step involves accessing the Jenkins UI and ensuring the necessary remote execution plugin is installed.

Access Jenkins: Log in using username admin and password Adm!n321.
Install Plugin:
- Navigate to Manage Jenkins then Manage Plugins.
- Go to the Available tab and search for Publish Over SSH.
- Select the plugin and click Install without restart.
- After installation, click Restart Jenkins (if necessary and no jobs are running).

2. Configure Global SSH Server Details

After the plugin is installed, the target servers must be configured in Jenkins' global settings.

Navigate to Manage Jenkins then Configure System.
Scroll down to the Publish over SSH section and click Add.

Server	Name	Hostname/IP	Username	Password
App Server 1	`app-server-1`	`172.16.238.10`	`tony`	`Ir0nN@M`
Storage Server	(Not strictly required for Jenkins connection, but credentials are needed for `scp`)	`172.16.238.15`	`natasha`	`Bl@kW`

Click Test Configuration to verify connectivity (for app-server-1).
Click Save at the bottom of the page.

3. Configure SSH Key Authentication (Prerequisite)

To ensure the non-interactive scp command works, SSH keys must be set up manually between the execution user (tony on stapp01) and the destination user (natasha on ststor01).

SSH into App Server 1 (stapp01) as user tony.
Generate Key Pair: If no key exists, generate one (use default file location and no passphrase for automation):
```
ssh-keygen -t rsa
```
Copy Public Key: Copy the key to the Storage Server's authorized keys file. You will be prompted for natasha's password (Bl@kW) for this one-time setup:
```
ssh-copy-id natasha@172.16.238.15
```

4. Create and Configure the Jenkins Job (`copy-logs`)

The final step is to build the Jenkins job using the established connectivity.

Create Job: On the Jenkins dashboard, click New Item, name it copy-logs, and select Freestyle project.
Schedule Build:

Go to the Build Triggers section.
Check Build periodically.
Enter the schedule: */5 * * * *

3.Configure Build Step:

Go to the Build section.
Click Add build step then Execute shell script on remote host using SSH.
SSH Server: Select app-server-1.

Command: Enter the following script to execute the file transfer:

# Define variables
LOG_DIR="/var/log/httpd" # Confirmed Apache log path on CentOS
DEST_USER="natasha"
DEST_HOST="172.16.238.15"
DEST_PATH="/usr/src/data/"

# Executes scp using the previously set up SSH keys
scp ${LOG_DIR}/access_log ${LOG_DIR}/error_log ${DEST_USER}@${DEST_HOST}:${DEST_PATH}

4.Save: Click Save to finalize the job configuration.

The job is now running every five minutes, securely transferring the required Apache logs and achieving a SUCCESS status.

100 Days of DevOps: Day 72

Wycliffe A. Onyango — Mon, 20 Oct 2025 07:48:57 +0000

Mastering Jenkins' Parameterized Builds

1. Introduction

Understanding Jenkins' core functionalities is crucial. Today's task is to create and run a simple parameterized Jenkins job. This exercise not only familiarizes us with the Jenkins UI but also demonstrates how to build jobs that accept user input, making them highly flexible and reusable.

This article details the step-by-step process of configuring and executing a parameterized Jenkins job, highlighting the configuration points and showcasing the successful execution.

2. Task Overview

The objective was to create a Jenkins Freestyle project named parameterized-job with two parameters:

String Parameter: Stage (default value: Build)
Choice Parameter: env (choices: Development, Staging, Production)

The job needed to execute a shell command that echoes the values passed to these parameters. Finally, we had to build the job at least once, specifically setting the env parameter to Production, to ensure its successful operation.

3. Step-by-Step Implementation

3.1. Accessing Jenkins and Creating a New Item

After logging into the Jenkins UI, the first step was to initiate the creation of a new job.

From the Jenkins dashboard, click on "New Item" in the left-hand navigation pane.
In the "Enter an item name" field, type parameterized-job.
Select "Freestyle project" as the item type.
Click "OK".

3.2. Configuring Parameters

With the job shell created, the next crucial step was to make it parameterized. This involved adding a String parameter and a Choice parameter.

On the job configuration page, check the box "This project is parameterized".
Click "Add Parameter" and select "String Parameter".

Set Name: Stage
Set Default Value: Build

3.Click "Add Parameter" again and select "Choice Parameter".

Set Name: env
Enter the choices (one per line):
```
Development
Staging
Production
```

3.3. Defining the Build Step (Shell Command)

To demonstrate that the parameters are being correctly received, a simple shell command was added to echo their values.

Scroll down to the "Build" section.
Click "Add build step" and select "Execute shell".

In the "Command" text area, enter the following:

echo "The 'Stage' parameter value is: $Stage"
echo "The 'env' parameter value is: $env"

Finally, click "Save" at the bottom of the page to apply all changes.

3.4. Building the Job with Specific Parameters

The final step was to execute the job, ensuring we passed Production as the value for the env parameter.

On the parameterized-job dashboard, click "Build with Parameters" in the left-hand menu.
On the build form, leave "Stage" as its default (Build).
For the "env" dropdown, select "Production".
Click the "Build" button.

4. Verification and Console Output

After the build was triggered, we could monitor its progress and review the output to confirm that the parameters were correctly passed and processed.

In the "Build History" on the left, click on the latest build number (e.g., #1).
Click "Console Output" to view the build logs.

The console output clearly shows the shell commands executing and echoing the parameter values as expected:

5. Conclusion

This exercise successfully demonstrated the creation and execution of a parameterized Jenkins job. We now understand how to define various types of parameters, integrate them into build steps, and trigger builds with specific inputs. This foundational knowledge is essential for developing more complex and dynamic CI/CD pipelines.

The job ran successfully, confirming that Jenkins correctly interpreted and utilized the provided parameters, marking the completion of this task.

100 Days of DevOps: Day 71

Wycliffe A. Onyango — Fri, 17 Oct 2025 06:04:46 +0000

Automating Package Installations with Jenkins

1. Introduction

The Nautilus DevOps team at Stratos Datacenter required an automated solution for installing and configuring packages on their storage server (ststor01). This article details the process of creating and configuring a Jenkins job, named install-packages, to fulfill this requirement, utilizing the Publish Over SSH plugin for remote execution.

2. Prerequisites

Access to Jenkins UI (URL provided by the lab environment).
Jenkins admin credentials: username: admin, password: Adm!n321.
Storage server (ststor01) credentials: username: natasha, password: Bl@kW.
Publish Over SSH Jenkins plugin installed and configured.

3. Step-by-Step Implementation

3.1. Access Jenkins and Initial Login

Open the Jenkins UI by clicking the Jenkins button in the top bar or navigating to the provided Jenkins URL.
Log in using the administrative credentials:
- Username: admin
- Password: Adm!n321

3.2. Configure Publish Over SSH Plugin for Remote Connectivity

The core of this task involves executing commands on a remote server (ststor01). The Publish Over SSH plugin facilitates this. The initial setup requires configuring the connection details for the target storage server, including its authentication.

Navigate to Manage Jenkins > Configure System.
Scroll down to the Publish over SSH section.
Click the "Add" button under SSH Servers.
Fill in the details for the ststor01 storage server:

Name: ststor01 (or a descriptive name like Nautilus_Storage)
Hostname: ststor01.stratos.xfusioncorp.com (as per infrastructure details)
Username: natasha (as per infrastructure details)
Remote Directory: /tmp (a common temporary directory)

5.Enable Password Authentication:

Click the "Advanced..." button to expand further options for the ststor01 entry.
Check the box: "Use password authentication, or use a different key".
In the Passphrase / Password field that appears, enter the password: Bl@kW (from infrastructure details).

6.Click the "Test Configuration" button for the ststor01 server. It should display "Success".

7.Click "Apply" and then "Save" at the bottom of the Configure System page.

3.3. Create the `install-packages` Jenkins Job

From the Jenkins Dashboard, click "New Item" on the left-hand navigation pane.
Item Name: Enter install-packages.
Type: Select "Freestyle project".
Click "OK".

3.4. Configure Job Parameters

To make the job flexible, a string parameter will be added to allow users to specify which package to install.

1.In the job configuration page, check the box: "This project is parameterized".

2.Click "Add Parameter" and select "String Parameter".

Name: PACKAGE
Default Value: net-tools (or httpd, git for initial testing)
Description: The name of the package to install on the storage server.

3.5. Configure the Build Step for Remote Execution

This is where the actual package installation command is defined, using the previously configured SSH connection.

Scroll down to the "Build" section of the job configuration.
Click "Add build step" and select "Send files or execute commands over SSH".
SSH Server: Select ststor01 (or the name you assigned) from the dropdown list.

In the "Exec command" textarea, enter the following shell script. This script passes the natasha user's password to sudo using sudo -S, which is crucial for privilege elevation on ststor01.

#!/bin/bash

# Define the password for sudo escalation (sensitive, but necessary for automation via script)
PACKAGE_PASSWORD="Bl@kW"

echo "Starting installation of package: $PACKAGE on ststor01..."

# Use 'echo $PACKAGE_PASSWORD | sudo -S' to pass the password to sudo
# The '-S' flag tells sudo to read the password from standard input.
# 'yum install -y' is used for CentOS/RHEL systems (like ststor01) to install packages.
echo $PACKAGE_PASSWORD | sudo -S yum install -y $PACKAGE

# Check the exit code of the 'yum install' command
if [ $? -eq 0 ]; then
    echo "SUCCESS: Package '$PACKAGE' installed successfully."
else
    echo "FAILURE: Package '$PACKAGE' installation failed. Check server logs."
    exit 1
fi

5.Click "Save" at the bottom of the job configuration page.

4. Testing and Verification

After configuring the job, it's essential to test its functionality and reliability.

Navigate to the install-packages job page.
Click "Build with Parameters" on the left menu.
In the PACKAGE field, enter a package name that is likely not installed (e.g., git, htop).
Click "Build".
Monitor the build in the Build History section. Once it completes, click on the build number (e.g., #1) and then select "Console Output".
Verify that the console output displays SUCCESS: Package '...' installed successfully. and Finished: SUCCESS.

7.Run the job again with a different package (e.g., net-tools) to confirm the job's reliability and repeated successful execution. This ensures the configuration is robust.

5. Conclusion

By following these steps, a robust Jenkins job named install-packages has been successfully created. This job automates the process of installing specified packages on the ststor01 storage server within the Stratos Datacenter infrastructure, significantly improving operational efficiency for the Nautilus DevOps team. The use of the Publish Over SSH plugin combined with parameterized builds offers a flexible and secure way to manage remote package installations.

100 Days of DevOps: Day 70 (New)

Wycliffe A. Onyango — Thu, 16 Oct 2025 06:31:33 +0000

Jenkins User Access Configuration

Objective

The goal of this task was to set up secure user access in Jenkins by:

Creating a new user named Jim.
Enabling Project-based Matrix Authorization Strategy for fine-grained permissions.
Granting read-only access to Jim.
Removing all permissions from Anonymous users.
Retaining full administrative privileges for the admin account.

This configuration ensures that only authenticated users can access Jenkins and that permissions are strictly role-based.

Steps Performed

Step 1: Login to Jenkins

Access Jenkins UI using your browser.
Log in using:

Username: admin
Password: Adm!n321

Step 2: Create a New User (Jim)

Navigate to: Manage Jenkins → Users → Create User
Fill in the details:

Username: jim
Password: YchZHRcLkL
Full Name: Jim

Click Create User.

Step 3: Install Matrix Authorization Plugin

Navigate to: Manage Jenkins → Plugins → Available Plugins
Search for: Matrix Authorization Strategy
Click Install without restart.
Once done, select: Restart Jenkins when installation is complete and no jobs are running.
Wait until the Jenkins login page reloads.

Step 4: Configure Global Security

Go to: Manage Jenkins → Security → Configure Global Security
Under Authorization, select: ✅ Project-based Matrix Authorization Strategy
In the permission table, assign as follows:

Click Save.

Step 5: Configure Job-level Access

Open any existing Jenkins job.
Click Configure.
Scroll down to Build Permissions or Enable project-based security.
Add user jim and grant only Read access.
Click Save.

Step 6: Verify Permissions

Log out from admin.
Log in as jim using:

Username: jim
Password: YchZHRcLkL

Confirm that Jim can only:

View dashboard and job details.
Cannot configure or trigger builds.

Results

User	Permissions	Status
admin	Full administrative control	✅
jim	Read-only (view jobs, no modification)	✅
anonymous	No access	✅

✅ Jenkins user access control successfully configured and verified.
This enhances the security and accountability within the Nautilus CI/CD environment.

Notes

Future team members should be added using the same controlled process.
Always ensure Matrix Authorization is active before modifying user roles.
It is recommended to take a full Jenkins configuration backup after major security changes.

100 Days of DevOps: Day 70

Wycliffe A. Onyango — Wed, 15 Oct 2025 08:10:48 +0000

Installing Git and GitLab Plugins on Jenkins via the UI

Overview

As part of the Nautilus DevOps setup, I configured a new Jenkins server to handle CI/CD jobs.
The initial goal was to install two essential plugins — Git and GitLab — which allow Jenkins to integrate with source control systems for continuous integration.

During installation via the Jenkins UI, I ran into several dependency errors, but eventually discovered that a simple Jenkins restart solved the issue completely.

Step 1: Accessing Jenkins

I started by logging in to Jenkins through the web interface:

Login credentials:

Username: admin
Password: Adm!n321

Once logged in, the Jenkins dashboard appeared — the starting point for all administrative actions.

Step 2: Navigating to Plugin Manager

From the left-hand sidebar, I selected:

Manage Jenkins → Plugins

This opened the Jenkins Plugin Manager, where plugins can be installed, updated, or removed.
I switched to the Available plugins tab and searched for:

Git
GitLab

I selected both and clicked Install without restart to begin installation.

Step 3: Encountering the Installation Errors

While the installation began, several red error messages appeared:

Failed to load: Jenkins Git client plugin (git-client 6.2.1)
 - Failed to load: Mina SSHD API :: Common (mina-sshd-api-common)

and later:

Failed to load: Mina SSHD API :: Common
 - Update required: BouncyCastle API Plugin to version 2.30.1.80 or higher

At first, this looked like a dependency issue — as if Jenkins was missing a required plugin.
However, after checking the Installed Plugins tab, I noticed that the BouncyCastle API plugin was already installed.

Step 4: The Fix — Restart Jenkins

Instead of downloading anything manually, I decided to try a restart directly from the Jenkins UI.

To do this, I navigated to:

Manage Jenkins → Restart Jenkins when installation is complete and no jobs are running

Jenkins restarted automatically.
After waiting for the login page to reappear, I signed in again and returned to the Plugin Manager.

Step 5: Reinstalling Plugins After Restart

Once Jenkins was back online, I retried the installation:

Manage Jenkins → Plugins → Available tab

I searched again for Git and GitLab, selected both, and clicked Install without restart.

This time, the installation completed successfully, with all plugins showing green checkmarks and no errors.

Step 6: Verification

After the installation finished, I went to:

Manage Jenkins → Plugins → Installed tab

I confirmed the following plugins were now active:

Git plugin
Git Client plugin
Mina SSHD API Common
BouncyCastle API plugin
GitLab plugin

All dependencies were properly loaded after the restart.

Step 7: Outcome

Jenkins now has Git and GitLab plugins installed and working.
All dependency errors resolved through a simple UI restart.
The environment is ready for setting up CI/CD pipelines and GitLab webhooks.

Forem: Wycliffe A. Onyango

You Bought a Domain. Now Why Does It Feel Like You Need Three?

The "Subdomain" Superpower

The "DNS Map" in Your Hands

The Final "Handshake" (CORS)

The Takeaway

100 Days of DevOps: Day 79

Automated CI/CD for Nautilus Application

Overview

I. Infrastructure Setup Commands (Prerequisites)

A. Jenkins Server Setup (to enable passwordless SSH)

B. Storage Server Setup (ststor01)

II. Jenkins Job Configuration & Execution

A. Build Trigger Setup (Webhook)

B. Execution Shell Script (deployment_script.sh)

III. Final Verification

100 Days of DevOps: Day 78

Jenkins Conditional Pipeline Deployment for Nautilus Web App

Objective

Step-by-Step Implementation

1. Install and Configure Jenkins Plugins

2. Configure Jenkins Credentials

3. Add Jenkins Agent Node (Storage Server)

4. Verify Environment on Storage Server

5. Access Jenkins and Gitea

6. Create the Jenkins Pipeline Job

7. Final Working Jenkins Pipeline Script

8. Run and Verify the Pipeline

9. Validation

Key Notes

100 Days of DevOps: Day 77

CI/CD Deployment of Web Application using Jenkins Pipeline

Objective

Work Completed

1. Jenkins UI Access

2. Required Jenkins Plugin Installation

3. Java 21 Installation

4. Add Storage Server as Jenkins Agent

Credentials Setup

5. Folder Permissions on Storage Server

6. Create Jenkins Pipeline Job

Pipeline Script Used

7. Successful Deployment Execution

Final Result

100 Days of DevOps: Day 76

Jenkins Security Configuration: Project-Based Authorization

Project Summary

Prerequisites

Stage 1: Global Security Configuration (The Parent ACL)

1.1 Activate Authorization Strategy

1.2 Grant Global Read Access

Stage 2: Packages Job Configuration (The Child ACL)

2.1 Configure Inheritance Strategy (Requirement A)

2.2 Grant Specific Job Permissions (Requirements B & C)

Verification and Conclusion

100 Days of DevOps: Day 75

Jenkins Agent Node Configuration

Project Goal

Final Status

Core Jenkins UI Configuration (Per Node)

1. Credentials Setup

2. Node Configuration Table

Key Challenge Resolution: Java 21 Configuration Steps

Final Step: Agent Launch

100 Days of DevOps: Day 74

Automating Database Backup in Jenkins

Overview

I. Problem & Solution Strategy

Infrastructure Details Used

II. Command Line Steps (Prerequisites)

Step 1: Generate the SSH Key Pair

Step 2: Install Public Key on Target Servers

III. Jenkins Job Configuration

Step 3: Job Setup and Scheduling

Step 4: Execute Shell Script (Remote Execution)

IV. Final Result

100 Days of DevOps: Day 73

Automated Apache Log Collection for xFusionCorp Industries

1. Initial Access and Plugin Installation

2. Configure Global SSH Server Details

B. Execution Shell Script (`deployment_script.sh`)

4. Create and Configure the Jenkins Job (`copy-logs`)

3.3. Create the `install-packages` Jenkins Job