DevOps Discussion Forum - All Forums

Extending LVM Logical Volume (LV) in Linux – Runbook

Wed, 22 Apr 2026 11:24:42 +0530

Purpose
Extend disk space on a Linux system using LVM without downtime.

Applies to
Systems using LVM (Logical Volume Manager)

Problem

Filesystem (e.g. /, /var) is running out of space and needs to be extended.

Step 1 — Check Current Disk Usage

Code:
df -h

Output:

Code:
/dev/mapper/rootvg-varlv    14G  13G  1.4G  91% /var

Outcome:

Identify which mount point is full (e.g /var)
This determines which LV needs extension

Step 2 — Verify LVM Setup (Build Context for Extension)

1. Map LV to Mount Point

Code:
lsblk

Output :

Code:
NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS

sda                8:0    0  256G  0 disk

├─sda4              8:4    0 63.3G  0 part

  ├─rootvg-varlv  253:3    0  14G  0 lvm  /var

└─sda5              8:5    0  100G  0 part

  ├─rootvg-varlv  253:3    0  14G  0 lvm  /var

Insight:

Identifies which LV is mounted where
Confirms LVM usage (TYPE = lvm)

2. Identify Target LV

Code:
lvs -o lv_name,vg_name,lv_path

Output:

Code:
LV    VG    Path

varlv  rootvg /dev/rootvg/varlv

Insight:

Confirms exact LV name to extend (e.g varlv)
Provides correct device path required for lvextend (e.g /dev/rootvg/varlv)

3. Check Available Space in VG

Code:
vgs

Output:

Code:
VG    #PV #LV #SN Attr  VSize    VFree

rootvg  2  5  0 wz--n- <163.31g 316.00m

Insight:

Determines if extension is possible

Interpretation:

VFree > 0
→ Extend directly
VFree = 0
→ Add disk first

4. Check Underlying Disks

Code:
pvs

Code:
PV        VG    Fmt  Attr PSize    PFree

/dev/sda4  rootvg lvm2 a--  63.31g    0

/dev/sda5  rootvg lvm2 a--  <100.00g 316.00m

Insight:

Shows disks backing the VG
Confirms whether storage is already fully utilized

Step 2 Outcome (What we now know)

Which LV to extend (varlv)
Its mount point (/var) and exact path (/dev/rootvg/varlv)
Whether free space exists in VG
Which disks are backing LVM

Decision Point

Case A: VG has free space
→ Extend LV directly

Case B: No free space
→ Add disk / extend storage first

Case A — Extend LV (VG has free space)

Step 3 — Extend Logical Volume

Code:
lvextend -L +316M /dev/rootvg/varlv

-L → size in GB/MB

OR use all free space:

Code:
lvextend -l +100%FREE /dev/rootvg/varlv

-l → extents / percentage

Outcome:

Code:
Size of logical volume rootvg/varlv changed from 14.00 GiB (3584 extents) to <14.31 GiB (3663 extents).

Logical volume rootvg/varlv successfully resized.

LV size increases
Filesystem unchanged (IMPORTANT)

Step 4 — Resize Filesystem

Check filesystem:

Code:
lsblk -f

For ext4:

Code:
resize2fs /dev/rootvg/varlv

For xfs:

Code:
xfs_growfs /var

Outcome:

Filesystem expands to use new space

Step 5 — Verify

Code:
df -h

Case B — No Free Space in VG

Step 3 — Add New Disk (Cloud / VM level)

Add a new disk from your cloud provider / hypervisor (e.g. AWS, Azure, VMware)
Example: New disk appears as /dev/sdb
Verify Disk is Added

Code:
lsblk
New disk should be visible (e.g. /dev/sdb)

Step 4 — Create PV

Code:
pvcreate /dev/sdb

Step 5 — Extend VG

Code:
vgextend rootvg /dev/sdb

Step 6 — Extend LV

Code:
lvextend -l +100%FREE /dev/rootvg/varlv

Step 7 — Resize Filesystem

Code:
xfs_growfs /var

# OR

Code:
resize2fs /dev/rootvg/varlv

Step 8 — Verify

Code:
df -h

Additional Note — Expanding Existing Disk

If the same disk is increased in size (no new disk added):

Code:
growpart /dev/sda 4

Code:
pvresize /dev/sda4

Outcome:

growpart → expands the partition
pvresize → makes new space available to LVM

You can now proceed with lvextend

Common Mistakes

Extending LV but not resizing filesystem
Using wrong filesystem command (resize2fs vs xfs_growfs)
Not checking vgs before starting
Using wrong device path
Confusing disk (/dev/sdb) with LV (/dev/rootvg/varlv)

Key Concepts and Takeaways

PV (Physical Volume) → Disk (/dev/sda4)
VG (Volume Group) → Storage pool (rootvg)
LV (Logical Volume) → Usable volume (/var)

Flow:
Disk → PV → VG → LV → Filesystem

Extension = LV resize + filesystem resize
vgs decides your approach (direct vs add disk)
LVM allows online resizing (no downtime)

Precautions

Take backup before changes
Double-check device names
Run carefully on production

Upgrade Guide: Ubuntu 22.04 LTS → 24.04.4 LTS (Noble Numbat)

Tue, 07 Apr 2026 17:01:54 +0530

Purpose: Upgrade Ubuntu systems from 22.04 LTS to 24.04 LTS with full step-by-step procedure (including what appears on screen during upgrade)
Document Type: Operational Runbook

? Step 1 — Check Current Version

Code:
cat /etc/os-release

? Confirm:

VERSION="22.04 LTS"
CODENAME=jammy

? Step 2 — Update Current System

Code:
sudo apt update && sudo apt upgrade

? During this step:

You may see package list fetching
If prompted:
- Press Y to continue

? Step 3 — Install update-manager-core

Code:
sudo apt install update-manager-core

? If prompted:

Press Y → continue installation

Edit Upgrade Configuration

Code:
sudo nano /etc/update-manager/release-upgrades

Find:

Code:
Prompt=normal

Change to:

Code:
Prompt=lts

? Save:

CTRL + X
Press Y
Press ENTER

⚙️ Step 4 — Prepare System (dist-upgrade)

Code:
sudo apt dist-upgrade

? During this step:

System may install/remove dependencies
If prompted:
- Press Y to continue

? Step 5 — Reboot System

Code:
sudo reboot

? Step 6 — Run Release Upgrade

Code:
sudo do-release-upgrade

? You will now see multiple interactive prompts:
1. Checking for new release

System checks availability of Ubuntu 24.04

2. Upgrade Summary Screen

Shows:
- Packages to install
- Packages to upgrade
- Packages to remove
Prompt:
- "Do you want to start the upgrade?"
- Press Y

3. Download Packages

Shows download progress
No input required unless interrupted

4. Configuration File Prompts
You may see:

"A new version of config file is available"

Options:

Press Y → install new version
Press N → keep existing version

? Recommendation:

Use N if unsure (safer)

5. Service Restart Prompt

"Restart services during package upgrades without asking?"

Options:

Select Yes → recommended

6. Obsolete Packages Prompt

"Remove obsolete packages?"

Options:

Press Y → clean system

7. Kernel/GRUB Prompt (if appears)

Keep current selection unless you know otherwise

8. Final Prompt

"System upgrade is complete. Restart required"
Press Y

? Step 7 — Final Reboot
? System reboots automatically or asks:

Press Y to reboot

✅ Step 8 — Verify Upgrade

Code:
cat /etc/os-release

Code:
lsb_release -a

? Confirm:

VERSION="24.04.4 LTS"
CODENAME=noble

? Optional Cleanup

Code:
sudo apt autoremove -y

⚠️ Important Notes

Always take backup before upgrade
Ensure stable internet connection
Do not interrupt upgrade
Recommended downtime window
Ensure at least 5–10 GB free disk space

? Troubleshooting
If upgrade not detected:

Code:
sudo do-release-upgrade -d

If upgrade fails midway:

Code:
sudo dpkg --configure -a

sudo apt -f install

How to fix "failed to authorize: failed to fetch oauth token: unauthorized" issue

Tue, 07 Apr 2026 16:20:13 +0530

[ERROR] failed to authorize: failed to fetch oauth token: unauthorized (Azure DevOps Pipeline)

Screenshot:
https://prnt.sc/NjRe-qyltGbV

---------------------------------------
ROOT CAUSE:
---------------------------------------
The issue is caused due to an invalid or expired Docker Registry Service Connection (OAuth token) in the Azure DevOps pipeline.

---------------------------------------
RESOLUTION STEPS:
---------------------------------------

1. Login to Azure DevOps:

https://dev.azure.com/

2. Navigate to the failed pipeline.

3. Click on the branch name

Example: master_preprod
Screenshot: https://prnt.sc/aG5XZoRORMpY

4. It will open the repository files.

5. Rename the existing pipeline file:

azure-pipelines-preprod.yml → azure-pipelines-preprod.yml-bak

6. Go back to "Repos" → Click on "Setup Build"

7. Configure new pipeline:

- Select Subscription: Sadad Azure
- Select Repository: Sadaddevrepo
- Click "Create Pipeline"

8. A new pipeline YAML file will be created automatically.

9. From the newly created pipeline file, copy the following field:

Example:
dockerRegistryServiceConnection: 'bc53aa1f-3499-4d92-ab29-7df77c562ada'

10. Paste this value into your original (renamed) pipeline YAML file.

11. Rename the pipeline file back to original:

azure-pipelines-preprod.yml-bak → azure-pipelines-preprod.yml

12. Commit the changes.

13. This will trigger the pipeline again.

14. Monitor the build progress and verify.

---------------------------------------
NOTES:
---------------------------------------
- This issue typically occurs when the service connection token expires or becomes invalid.
- Recreating the pipeline helps regenerate a valid service connection reference.

---------------------------------------
STATUS:
---------------------------------------
After updating the service connection, the pipeline should run successfully.

Let me know if anyone still faces the issue ?

AKS Namespace Migration + Azure DevOps DR Deployment (UK Environment)

Tue, 07 Apr 2026 15:52:46 +0530

Overview

This document explains the complete process to:

Migrate Kubernetes namespace resources
Configure Azure DevOps pipeline for DR (UK)
Deploy application in new AKS cluster
Validate and troubleshoot issues

Step 1: Navigate to Project Directory

Code:
cd /home/aks-live/24x7/AKS-Prod/sadad-POS-Queue-Consumer

ls -ltr

Identify the folder:

pos-queue-consumer-fileshare/

Step 2: Go to Fileshare Directory

Code:
cd pos-queue-consumer-fileshare/

ls -ltr

Important files:

[list]

[*]pos-queue-consumer-storage-secret.yaml

[*]azure-file-pvc.yaml

[*]azure-file-sc.yaml

[/list]

Step 3: Update Storage Secret

Code:
vi pos-queue-consumer-storage-secret.yaml

Update:

data:

  azurestorageaccountkey: 

  azurestorageaccountname:

Step 4: Verify Base64 Values

Code:
echo "" | base64 -d

Step 5: Create Namespace

Code:
kubectl create ns sadad-online-pos-queue-consumer

Step 6: Apply Resources (Order Important)

Code:
1. Apply Secret

kubectl apply -f pos-queue-consumer-storage-secret.yaml

2. Apply Storage Class & PVC

kubectl apply -f azure-file-sc.yaml -f  azure-file-pvc.yaml

Step 7: Apply Remaining Secrets

Code:
cd ..

kubectl apply -f az-repo-dev-secret.yaml

kubectl apply -f pos-queue-consumer-env-azure-secrets.yaml \

              -f pos-queue-consumer-env-config-secrets.yaml \

              -f pos-queue-consumer-env-email-secrets.yaml \

              -f sadad-online-pos-queue-consumer-secrets.yaml

Step 8: Azure DevOps – Download Deployment File

Go to:
Repos → Sadad-POS-Queue-Consumer → manifests

Download:
deploy-live.yaml

Step 9: Create UK Deployment File

Rename:
deploy-live.yaml → deploy-live-uk.yaml

Update DB:
- name: DB_HOST
value:

Step 10: Upload File to Repo

Upload to:
manifests/

Commit message:
Added deploy-live-uk for DR UK

Step 11: Clone Release Pipeline

Go to:
Pipelines → Releases → sadad-pos-queue-consumer

Click Edit
Clone Live Stage

Step 12: Rename Stage

Sadad-Live-Pos-Queue-Consumer-UK

Step 13: Configure Kubernetes Connection

Update:

Subscription: Sadad - Azure
Cluster: Sadad-Online-UK-AKS
Namespace: sadad-online-pos-queue-consumer
Service Connection: sadad-online-pos-queue-consumer-uk

Step 14: Update Deployment File Path

$(System.DefaultWorkingDirectory)/Sadad-POS-Queue-Consumer/drop/deploy-live-uk.yaml

Step 15: Update Print Tag Script

Replace:
deploy-live.yaml → deploy-live-uk.yaml

Step 16: Run Pipeline

After commit → pipeline triggers automatically

Step 17: Deploy Release

Go to Releases → Select new release
Click:

Deploy
Approve

Step 18: Verify Deployment

kubectl get pods -n sadad-online-pos-queue-consumer
kubectl logs

Common Issue: Volume Mount Error

Error:
MountVolume failed: No such file or directory

Fix:
az storage share create \
--name pos-queue-logs \
--account-name \
--account-key

Then restart pod:
kubectl delete pod

Final Validation

kubectl get pods

Expected:
Running

Summary

Setup namespace
Apply secrets + PVC
Modify deployment YAML
Update Azure DevOps pipeline
Deploy via release
Approve and validate

Best Practices

Always clone existing pipeline
Verify secrets before deployment
Keep naming consistent across environments
Validate storage before pod start

Migration Completed Successfully

HashiCorp Vault HA Deployment using Raft

Tue, 07 Apr 2026 15:31:40 +0530

Purpose: Deploy HashiCorp Vault in High Availability mode using Raft storage

? Prerequisite Infrastructure
Before deploying Vault, ensure:

HAProxy (Load Balancer)
Keepalived (Failover)
Virtual IP (VIP)

These ensure a single stable endpoint for clients.

? Overview
Vault HA cluster using Raft:

One node = Leader
Others = Standby replicas
Automatic failover

Provides:

High availability
Secure secret storage
TLS encryption

Ports:

8200 → API
8201 → Cluster communication

? Prerequisites

Minimum 3 Linux servers
Network connectivity
Root/sudo access
Internet access
Basic Linux knowledge

? Phase 1 — Create Vault User

Code:
sudo useradd --system --home /etc/vault.d --shell /bin/false vault

id vault

? Phase 2 — Create Directories

Code:
sudo mkdir -p /etc/vault.d

sudo mkdir -p /opt/vault/data

sudo mkdir -p /etc/vault.d/tls

sudo mkdir -p /var/log/vault

sudo chown -R vault:vault /etc/vault.d

sudo chown -R vault:vault /opt/vault

sudo chown vault:vault /var/log/vault

sudo chmod 750 /var/log/vault

? Phase 3 — Install Vault

Code:
sudo apt update

sudo apt install unzip -y

cd /tmp

wget [url=https://releases.hashicorp.com/vault/]https://releases.hashicorp.com/vault/[/url]/vault__linux_amd64.zip

unzip vault__linux_amd64.zip

sudo mv vault /usr/local/bin/

sudo chmod +x /usr/local/bin/vault

vault --version

which vault

? Phase 4 — Generate TLS Certificates

Code:
mkdir ~/vault-tls

cd ~/vault-tls

openssl genrsa -out vault-ca.key 4096

openssl req -x509 -new -nodes

-key vault-ca.key

-out vault-ca.crt

-days 3650

openssl genrsa -out vault.key 2048

? Phase 5 — Install TLS Certificates

Code:
sudo cp vault.crt vault.key vault-ca.crt /etc/vault.d/tls/

sudo chown vault:vault /etc/vault.d/tls/*

sudo chmod 600 /etc/vault.d/tls/vault.key

? Phase 6 — Trust CA

Code:
sudo cp /etc/vault.d/tls/vault-ca.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

⚙️ Phase 7 — Configure Vault
File:
/etc/vault.d/vault.hcl

Code:
ui = true

cluster_name = "vault-cluster"

listener "tcp" {

address = "0.0.0.0:8200"

cluster_address = "0.0.0.0:8201"

tls_cert_file = "/etc/vault.d/tls/vault.crt"

tls_key_file = "/etc/vault.d/tls/vault.key"

}

storage "raft" {

path = "/opt/vault/data"

node_id = "node-1"

}

api_addr = "https://:8200"

cluster_addr = "https://:8201"

disable_mlock = true

Code:
sudo chown vault:vault /etc/vault.d/vault.hcl

sudo chmod 640 /etc/vault.d/vault.hcl

⚙️ Phase 8 — Systemd Service
File:
/etc/systemd/system/vault.service

Code:
[Unit]

Description=HashiCorp Vault

After=network-online.target

[Service]

User=vault

Group=vault

ExecStart=/usr/local/bin/vault server -config=/etc/vault.d/vault.hcl

Restart=on-failure

LimitMEMLOCK=infinity

[Install]

WantedBy=multi-user.target

Code:
sudo systemctl daemon-reload

sudo systemctl enable vault

sudo systemctl start vault

sudo systemctl status vault

? Phase 9 — Initialize Vault

Code:
export VAULT_ADDR=https://:8200

export VAULT_CACERT=/etc/vault.d/tls/vault-ca.crt

vault operator init

⚠️ Save:

Unseal keys
Root token

? Phase 10 — Unseal Vault

Code:
vault operator unseal

vault operator unseal

vault operator unseal

vault status

? Phase 11 — Join Nodes

Code:
vault operator raft join https://:8200

vault operator unseal

vault operator unseal

vault operator unseal

? Phase 12 — Verify Cluster

Code:
vault operator raft list-peers

? Phase 13 — Enable Audit Logging

Code:
vault audit enable file file_path=/var/log/vault/audit.log

vault audit list

? Phase 14 — Log Rotation
File:
/etc/logrotate.d/vault

Code:
/var/log/vault/audit.log {

daily

rotate 7

compress

missingok

notifempty

}

? Common Commands

Code:
vault status

vault operator raft list-peers

vault operator unseal

vault operator raft snapshot save backup.snap

⚠️ Important Notes

Store unseal keys securely
Protect root token
Vault seals after reboot
Must unseal manually after restart
Renew TLS certificates before expiry

Disaster Recovery (DR) Replica Setup for MariaDB Galera Cluster

Tue, 07 Apr 2026 15:17:27 +0530

Purpose: Configure a standalone Disaster Recovery replica for a MariaDB Galera cluster to ensure data redundancy and failover capability.
Applies To: MariaDB 10.11 / Galera Cluster
Environment: Ubuntu 24.04

? Overview
This guide explains how to configure a Disaster Recovery (DR) replica node from an existing Galera cluster.
The DR node:

Replicates from a single Galera node
Does NOT join the cluster
Always remains read-only
Used for disaster recovery and reporting

⚙️ Key Characteristics

Replicates from one Galera node
Never becomes a master
Always read-only
Standalone replica (not part of cluster)

? Prerequisites

Ubuntu 24.04 VM
Disk space ≥ 2× database size
Network access to Galera node (port 3306)
Backup storage access
Backup encryption password
Replication user credentials
Private IP of Galera node

? Phase 1 — VM Setup
Step 1.1 — Verify Disk

Code:
lsblk

df -h

Step 1.2 — Update System

Code:
apt update

apt upgrade -y

apt install curl wget software-properties-common -y

? Phase 2 — Install MariaDB
Step 2.1 — Add Repository

Code:
curl -LsS [url=https://downloads.mariadb.com/MariaDB/mariadb_repo_setup]https://downloads.mariadb.com/MariaDB/mariadb_repo_setup[/url]

| bash -s -- --mariadb-server-version="mariadb-10.11"

Step 2.2 — Install

Code:
apt update

apt install mariadb-server mariadb-backup -y

Step 2.3 — Verify

Code:
mariadb --version

systemctl status mariadb

⚙️ Phase 3 — Configure DR Node
Step 3.1 — Create Config File
/etc/mysql/mariadb.conf.d/99-dr-replica.cnf

Code:
[mysqld]

server_id = 100

log_bin = mysql-bin

binlog_format = ROW

relay_log = relay-bin

relay_log_recovery = ON

log_slave_updates = ON

read_only = ON

skip_slave_start = ON

Step 3.2 — Disable Galera
Edit:

Code:
/etc/mysql/mariadb.conf.d/50-server.cnf

Ensure:

Code:
[mariadb]

wsrep_on = OFF

Step 3.3 — Restart

Code:
systemctl restart mariadb

Step 3.4 — Verify

Code:
SHOW VARIABLES LIKE 'server_id';

SHOW VARIABLES LIKE 'wsrep_on';

SHOW VARIABLES LIKE 'read_only';

? Phase 4 — Verify Galera Source Node

Code:
SHOW VARIABLES LIKE 'log_bin';

SHOW VARIABLES LIKE 'binlog_format';

SHOW VARIABLES LIKE 'server_id';

SHOW MASTER STATUS\G

Grant Replication Permissions

Code:
GRANT REPLICATION SLAVE, BINLOG MONITOR ON [i].[/i]

TO 'replication_user'@'';

FLUSH PRIVILEGES;

? Phase 5 — Download & Restore Backup
Download

Code:
az storage blob download

--account-name 

--container-name

--name ".tar.zst.enc"

--file "/mnt/.tar.zst.enc"

--auth-mode login

Decrypt

Code:
openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000

-in /mnt/.tar.zst.enc

-out /mnt/backup.tar.zst

-pass pass:''

Extract

Code:
cd /mnt

tar --use-compress-program=zstd -xf backup.tar.zst

Get Binlog Position

Code:
cat /mnt/xtrabackup_binlog_info

Example:

Code:
mysql-bin.002064 385

?️ Phase 6 — Restore Database
⚠️ WARNING: This overwrites existing data

Code:
systemctl stop mariadb

mv /var/lib/mysql /mnt/mysql_old

mkdir -p /var/lib/mysql

Prepare Backup

Code:
mariabackup --prepare --target-dir=/mnt/

Restore

Code:
mariabackup --copy-back

--target-dir=/mnt/

--datadir=/var/lib/mysql/

Fix Permissions

Code:
chown -R mysql:mysql /var/lib/mysql/

Start DB

Code:
systemctl start mariadb

? Phase 7 — Setup Replication

Code:
CHANGE MASTER TO

MASTER_HOST='',

MASTER_USER='',

MASTER_PASSWORD='',

MASTER_PORT=3306,

MASTER_LOG_FILE='',

MASTER_LOG_POS=;

Code:
START SLAVE;

Verify

Code:
SHOW SLAVE STATUS\G

❗ Phase 8 — Common Errors
Error 1032

Code:
STOP SLAVE;

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

START SLAVE;

Error 1526

Missing partition → add required partitions

Error 1146

Missing temporary table

✅ Phase 9 — Final Verification

Code:
SHOW VARIABLES LIKE 'server_id';

SHOW VARIABLES LIKE 'read_only';

SHOW VARIABLES LIKE 'wsrep_on';

SHOW SLAVE STATUS\G

? Key Rules

✔ Unique server_id
✔ wsrep must be OFF
✔ Always read_only = ON
✔ Use correct binlog position from backup
✔ Replicate from only ONE Galera node
✔ Do NOT leave error skipping enabled

Git Pull Script — Repo Secrets Update Guide (DEV Environment)

Tue, 07 Apr 2026 14:04:30 +0530

================================================================================
Git Pull Script — Repo Secrets Update Guide (DEV Environment)
================================================================================

================================================================================
OVERVIEW
================================================================================

This guide explains the process for updating repository credentials (repo secrets)
used in the automated git pull script running via cron jobs.

================================================================================
ISSUE
================================================================================
Developers' code changes are not getting updated in the DEV environment.

Root cause is usually:
- Expired / invalid repository credentials
- Git pull cron job failing due to authentication issues

================================================================================
STEP-BY-STEP PROCEDURE
================================================================================

--- Step 1: Login to DEV Server (Linode) ---
Login to the DEV server using SSH.

================================================================================

--- Step 2: Identify the Application Container ---
All projects are running inside Docker containers.

Code:
docker ps -a

Find the appropriate container for your application.

================================================================================

--- Step 3: Access the Container ---
Exec into the application container:

Code:
docker exec -it  bash

================================================================================

--- Step 4: Locate Git Pull Cron Job ---
Check existing cron jobs:

Code:
crontab -l

Also check system cron directory:

Code:
ls -l /etc/cron.d/

Look for file:
git-pull-cron

================================================================================

--- Step 5: Verify Cron Script and Logs ---
Read the cron configuration:

Code:
cat /etc/cron.d/git-pull-cron

Check logs for failures:

Code:
cat /var/log/git-pull.log

? If logs show authentication errors → credentials need update.

================================================================================

--- Step 6: Update Git Credentials ---
Open the git pull script:

Code:
vi /usr/local/bin/git-pull.sh

Replace old credentials with new ones.

================================================================================

--- Step 7: Generate New Repo Credentials (Azure DevOps) ---

1. Login to Azure DevOps
2. Navigate to the appropriate project
3. Open the required repository
4. Click on **Clone**

Reference:
https://prnt.sc/X5RGff0Z8pLG

5. Click on **Generate Credentials**

Reference:
https://prnt.sc/FA7t5X-oPgge

6. Copy the generated credentials

================================================================================

--- Step 8: Update Script with New Credentials ---

Update credentials in:

Code:
/usr/local/bin/git-pull.sh

Reference:
https://prnt.sc/BSdafqM5zDdk

Save the file.

================================================================================

--- Step 9: Re-run Script and Verify ---

Manually execute the script:

Code:
bash /usr/local/bin/git-pull.sh

Check logs:

Code:
cat /var/log/git-pull.log

Ensure:
- Git pull is successful
- No authentication errors

================================================================================
TROUBLESHOOTING
================================================================================

--- Git pull still failing ---
- Verify credentials are correct
- Ensure repo URL is correct
- Check network connectivity

--- Cron not running ---

Code:
systemctl status cron

--- Permission issues ---

Code:
chmod +x /usr/local/bin/git-pull.sh

================================================================================
QUICK SUMMARY
================================================================================

Issue: Code not updating in DEV
Cause: Expired repo credentials
Fix: Update credentials in git-pull script

Key Files:
- /etc/cron.d/git-pull-cron
- /usr/local/bin/git-pull.sh
- /var/log/git-pull.log

================================================================================

ArgoCD + Image Updater + GHCR Setup

Tue, 07 Apr 2026 12:24:18 +0530

Thread Title: ArgoCD + GHCR + Image Updater Setup (Production Guide)
? ArgoCD + Image Updater + GHCR Setup (Production)
This guide covers:

GHCR secret setup
ArgoCD repo registration
Application deployment
Image updater configuration
RBAC setup

⚠️ Important
Never expose real GitHub tokens in public threads.
Replace all tokens with placeholders before sharing.

? Step 1: Create GHCR Secret (App Namespace)

Code:
kubectl -n  create secret docker-registry ghcr-regcred

--docker-server=ghcr.io

--docker-username=''

--docker-password=''

? Step 2: Create GHCR Secret (ArgoCD Namespace)

Code:
kubectl -n  create secret docker-registry ghcr-regcred

--docker-server=ghcr.io

--docker-username=''

--docker-password=''

? Step 3: Create Git Credentials Secret

Code:
kubectl -n  create secret generic argocd-image-updater-git-creds

--from-literal=username=''

--from-literal=password=''

? Step 4: Register Git Repository in ArgoCD

Code:
apiVersion: v1

kind: Secret

metadata:

name: 

labels:

argocd.argoproj.io/secret-type: repository

type: Opaque

stringData:

type: git

url: [url=https://github.com/]https://github.com/[/url]/.git

username: ''

password: ''

Apply using:

Code:
kubectl -n  apply -f repo-secret.yaml

? Step 5: Create ArgoCD Application

Code:
apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

name: 

namespace: 

spec:

project: 

source:

repoURL: [url=https://github.com/]https://github.com/[/url]/.git

targetRevision:

path:

destination:

server: [url=https://kubernetes.default.svc/]https://kubernetes.default.svc[/url]

namespace: 

syncPolicy:

automated:

prune: true

selfHeal: true

syncOptions:

- CreateNamespace=true

? Step 6: Configure ArgoCD Image Updater

Code:
apiVersion: argocd-image-updater.argoproj.io/v1alpha1

kind: ImageUpdater

metadata:

name: 

namespace: 

spec:

namespace: 

applicationRefs:

- namePattern: 

images:

- alias:

imageName: ghcr.io//

commonUpdateSettings:

updateStrategy: newest-build

allowTags: regexp:^(sha-)?[0-9a-f]{7,40}$

pullSecret: pullsecret:/ghcr-regcred

manifestTargets:

kustomize:

name: ghcr.io//

writeBackConfig:

method: git

gitConfig:

branch:

writeBackTarget: kustomization:.

? Step 7: Create RBAC Role

Code:
apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: argocd-image-updater-secret-reader

namespace: 

rules:

[list]

[*]apiGroups: [""]

resources: ["secrets"]

verbs: ["get", "list"]

[/list]

? Step 8: Create RBAC RoleBinding

Code:
apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: argocd-image-updater-secret-reader

namespace: 

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: Role

name: argocd-image-updater-secret-reader

subjects:

[list]

[*]kind: ServiceAccount

name: argocd-image-updater-controller

namespace:

[/list]

✅ Final Notes

Verify:

Code:
kubectl get applications -n 

kubectl logs -n  deploy/argocd-image-updater

AKS Namespace Access Control – minesec (RBAC Implementation)

Tue, 07 Apr 2026 12:02:46 +0530

AKS Namespace-Restricted Access (minesec) — Production Implementation Guide

Objective
Provide a secure, production-ready method to grant a Linux user access strictly limited to the minesec namespace in an AKS cluster using Kubernetes RBAC and kubeconfig.

This approach ensures:

Zero cluster-wide exposure
Controlled namespace isolation
Auditable access model

Architecture Overview

Code:
Linux User (minesecuser)

│

▼

kubeconfig (Token-based auth)

│

▼

ServiceAccount (minesec namespace)

│

▼

Role (Namespace scoped permissions)

│

▼

RoleBinding (Access enforcement)

Key Principle:
Access is not tied to Linux user directly — it is mapped via ServiceAccount + Token.

Step 1: Create Linux User

Code:
sudo useradd -m minesecuser

sudo chsh -s /bin/bash minesecuser

Why this matters:
Separates OS-level identity from cluster-level permissions.

Step 2: Create ServiceAccount

Code:
apiVersion: v1

kind: ServiceAccount

metadata:

  name: minesecuser

  namespace: minesec

Code:
kubectl apply -f serviceaccount.yaml

Important:
Never reuse ServiceAccounts across users. One identity = one ServiceAccount.

Step 3: Create Role (Namespace Scoped)

Code:
apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: minesecuser-role

  namespace: minesec

rules:

- apiGroups: ["*"]

  resources: ["*"]

  verbs: ["*"]

Code:
kubectl apply -f role.yaml

Production Warning:
This gives full access inside the namespace.

In real environments, restrict it like:

Code:
resources: ["pods","deployments","services"]

verbs: ["get","list","watch"]

Step 4: Create RoleBinding

Code:
apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: minesecuser-binding

  namespace: minesec

subjects:

- kind: ServiceAccount

  name: minesecuser

  namespace: minesec

roleRef:

  kind: Role

  name: minesecuser-role

  apiGroup: rbac.authorization.k8s.io

Code:
kubectl apply -f rolebinding.yaml

What this does:
This is the enforcement layer — without RoleBinding, access = zero.

Step 5: Generate Token

Code:
kubectl -n minesec create token minesecuser --duration=8760h > /root/minesecuser.token

chmod 600 /root/minesecuser.token

Critical Insight:
This token is effectively a password to your cluster. Treat it as a secret.

Step 6: Extract Cluster Details

Code:
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'

Code:
kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}'

Step 7: Create kubeconfig file

Configure Linux User

Code:
mkdir -p /home/minesecuser/.kube

cp config /home/minesecuser/.kube/config

chown -R minesecuser:minesecuser /home/minesecuser/.kube

chmod 600 /home/minesecuser/.kube/config

Contents

Code:
apiVersion: v1

kind: Config

clusters:

- name: aks-cluster

  cluster:

    server: https://

    certificate-authority-data: 

users:

- name: minesecuser

  user:

    token: 

contexts:

- name: minesec-context

  context:

    cluster: aks-cluster

    user: minesecuser

    namespace: minesec

current-context: minesec-context

Key Design Point:
Namespace is hardcoded → prevents accidental cross-namespace access.

Step 8: Validation

Code:
su - minesecuser

kubectl get pods

Negative Testing (Important):

Code:
kubectl get pods -n default

kubectl get ns

kubectl get nodes

Expected:
All above should return Forbidden

Security Best Practices

Never share kubeconfig over email or chat
Rotate tokens periodically (recommended: 30–90 days)[]Avoid wildcard "" permissions in production
Use Azure AD + RBAC for enterprise identity integration
Audit access via Kubernetes audit logs / Azure Monitor
Store tokens securely (Azure Key Vault preferred)

Production Risks (Do Not Ignore)

Leaked token = full namespace compromise
Wildcard RBAC = privilege escalation risk
Long-duration tokens = security exposure
Manual kubeconfig distribution = audit gap

Recommended Enterprise Upgrade Path

Replace token-based auth with Azure AD RBAC
Use AAD Groups instead of ServiceAccounts
Use short-lived tokens (OIDC)
Implement Just-in-Time (JIT) access

Summary

Achieved strict namespace isolation using RBAC
Mapped Linux user → ServiceAccount via kubeconfig
Prevented cluster-wide access
Established secure and auditable access pattern

How to do OPENVAS migration (Docker Volume + Domain + SSL)

Tue, 07 Apr 2026 11:57:21 +0530

Environment

Source Server: Old server where OpenVAS container existed Destination Server: sadad-centralized-logging (Public IP: 20.21.137.88) Domain: online-openvas.sadadqa.com Container Image: immauss/openvas:latest Ports: 9392 (Web UI), 9390 (GMP)

Goal

1) Migrate OpenVAS Docker volume data from old server to new server 2) Run OpenVAS container on destination using same volume 3) Configure domain access via Nginx reverse proxy 4) Enable SSL using Let's Encrypt (Certbot) on Nginx 5) Validate OpenVAS users and reset passwords if needed

PART A — SOURCE SERVER (Backup OpenVAS Volume)

1) Check OpenVAS container docker ps -a | grep openvas
2) Confirm Docker volume docker volume ls | grep openvas
3) Inspect volume path docker volume inspect openvas
4) Create backup cd /var/lib/docker/volumes tar -czvf /root/openvas-volume-backup.tar.gz openvas
5) Transfer backup scp /root/openvas-volume-backup.tar.gz root@DESTINATION_IP:/home/rishi/

PART B — DESTINATION SERVER (Restore Volume)

1) Stop old container docker stop openvas
2) Rename old container docker rename openvas openvas-old
3) Remove old container docker rm openvas-old
4) Remove old volume docker volume rm openvas
5) Create new volume docker volume create openvas
6) Restore volume data cd /var/lib/docker/volumes tar -xzvf /home/rishi/openvas-volume-backup.tar.gz
7) Verify data ls -lah /var/lib/docker/volumes/openvas/_data

PART C — Start OpenVAS Container

docker run -d --name openvas --restart unless-stopped --ipc=host -p 9392:9392 -p 9390:9390 -e GMP=9390 -v openvas:/data immauss/openvas:latest
Verify container: docker ps
Check logs: docker logs -f openvas
Verify ports: ss -tulpn | grep 939

PART D — Nginx Reverse Proxy Setup

Create config: /etc/nginx/sites-available/online-openvas.sadadqa.com.conf
server {
listen 80;
server_name online-openvas.sadadqa.com;
location / {
proxy_pass http://127.0.0.1:9392;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;
client_max_body_size 50M;
}
}
Enable site: ln -s /etc/nginx/sites-available/online-openvas.sadadqa.com.conf /etc/nginx/sites-enabled/
Reload Nginx: nginx -t systemctl reload nginx

PART E — DNS Setup

Create DNS A record: online-openvas.sadadqa.com -> 20.21.137.88
Verify: nslookup online-openvas.sadadqa.com

PART F — SSL Setup using Certbot

certbot --nginx -d online-openvas.sadadqa.com
Certificate paths: /etc/letsencrypt/live/online-openvas.sadadqa.com/fullchain.pem /etc/letsencrypt/live/online-openvas.sadadqa.com/privkey.pem
Test renewal: certbot renew --dry-run

PART G — OpenVAS User Management

Enter container: docker exec -it openvas bash
List users: sudo -u gvm gvmd --get-users
Example users: admin rana akshay faisal sameer santosh harshal.kamble
Reset password: sudo -u gvm gvmd --user=admin --new-password='StrongPassword123'
Login URL: https://online-openvas.sadadqa.com/login

PART H — Security Recommendations

1) Do not expose port 9392 publicly. 2) Allow only Nginx (80/443) to internet. 3) Restrict portal access by office/VPN IP if required. 4) Enable firewall rules in Azure NSG accordingly.

MariaDB Galera Cluster — Backup & Restore Guide

Tue, 07 Apr 2026 11:56:56 +0530

================================================================================
MariaDB Galera Cluster — Backup Restore Guide
Step-by-Step Recovery Procedure for Ubuntu VMs
================================================================================

================================================================================
OVERVIEW
================================================================================
This guide explains how to restore a MariaDB Galera Cluster backup to a fresh Ubuntu VM. The backup is stored as an encrypted ZIP file in Azure Blob Storage.

--- Backup Details ---
Backup tool: mariabackup with Galera support
Compression: ZIP with password encryption
Storage: Azure Blob Storage
Retention: 7 daily backups
Original DB version: MariaDB 10.8.8

--- What This Guide Covers ---
- Preparing a fresh Ubuntu VM
- Mounting and using a secondary data disk
- Installing MariaDB 10.11
- Installing phpMyAdmin
- Extracting backup ZIP
- Disk space planning
- Restore using mariabackup
- Verification
- Troubleshooting

[!] WARNING: Never run this on a production server.

================================================================================
PREREQUISITES
================================================================================
* Ubuntu VM (20.04 / 22.04)
* 512GB data disk
* Backup ZIP file
* Root/sudo access
* Backup password

================================================================================
SECTION 1: PREPARE THE VM
================================================================================

--- Step 1.1 — Check disks ---

Code:
lsblk

--- Step 1.2 — Check filesystem ---

Code:
file -s /dev/sda1

If empty:

Code:
mkfs.ext4 /dev/sda1

--- Step 1.3 — Mount disk ---

Code:
mkdir -p /mnt/data

mount /dev/sda1 /mnt/data

df -h

--- Step 1.4 — Make persistent ---

Code:
echo '/dev/sda1 /mnt/data ext4 defaults 0 2' >> /etc/fstab

cat /etc/fstab

--- Step 1.5 — Check files ---

Code:
ls -lh /mnt/data/

--- Step 1.6 — Cleanup OS disk ---

Code:
apt clean

apt autoremove -y

================================================================================
SECTION 2: INSTALL MARIADB
================================================================================

--- Step 2.1 ---

Code:
apt update && apt upgrade -y

--- Step 2.2 ---

Code:
apt install curl wget unzip software-properties-common -y

--- Step 2.3 ---

Code:
curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | \

bash -s -- --mariadb-server-version="mariadb-10.11"

--- Step 2.4 ---

Code:
apt update

apt install mariadb-server mariadb-backup -y

--- Step 2.5 ---

Code:
mariadb --version

systemctl status mariadb

================================================================================
SECTION 3: INSTALL PHPMYADMIN (OPTIONAL)
================================================================================

--- Step 3.1 ---

Code:
apt install apache2 -y

--- Step 3.2 ---

Code:
apt install phpmyadmin -y

--- Step 3.3 ---

Code:
systemctl status apache2

--- Step 3.4 ---
Open port 80 in Azure NSG

--- Step 3.5 ---

Code:
mysql -u root

ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourPassword123';

FLUSH PRIVILEGES;

EXIT;

--- Step 3.6 ---

Code:
curl ifconfig.me

Access:
http://YOUR_PUBLIC_IP/phpmyadmin

================================================================================
SECTION 4: EXTRACT BACKUP
================================================================================

--- Step 4.1 ---

Code:
cd /mnt/data/24x7

ls -lh

--- Step 4.2 ---

Code:
df -h /mnt/data

--- Step 4.3 ---

Code:
unzip -P 'YOUR_PASSWORD' backup.zip -d /mnt/data/restored

--- Step 4.4 ---

Code:
watch -n 10 'du -sh /mnt/data/restored/'

--- Step 4.5 ---

Code:
ls -lh /mnt/data/restored/backup/mysql/

================================================================================
SECTION 5: DISK SPACE PLANNING
================================================================================

--- Step 5.1 ---

Code:
du -sh /mnt/data/restored/backup/mysql/

--- Step 5.2 ---

Code:
df -h /

df -h /var/lib/mysql

--- Option A (copy) ---

Code:
mariabackup --copy-back \

--target-dir=/mnt/data/restored/backup/mysql/ \

--datadir=/var/lib/mysql/

--- Option B (move) ---

Code:
mariabackup --move-back \

--target-dir=/mnt/data/restored/backup/mysql/ \

--datadir=/var/lib/mysql/

--- Option C (recommended) ---

Code:
mkdir -p /mnt/data/mysql

chown mysql:mysql /mnt/data/mysql

Edit config:

Code:
nano /etc/mysql/mariadb.conf.d/50-server.cnf

Set:

Code:
datadir = /mnt/data/mysql

================================================================================
SECTION 6: RESTORE DATABASE
================================================================================

--- Step 6.1 ---

Code:
systemctl stop mariadb

--- Step 6.2 ---

Code:
rm -rf /var/lib/mysql/*

--- Step 6.3 ---

Code:
mariabackup --copy-back \

--target-dir=/mnt/data/restored/backup/mysql/ \

--datadir=/var/lib/mysql/

--- Step 6.4 ---

Code:
chown -R mysql:mysql /var/lib/mysql/

--- Step 6.5 ---

Code:
nano /etc/mysql/mariadb.conf.d/50-server.cnf

Add:

Code:
[mariadb]

wsrep_on=OFF

--- Step 6.6 ---

Code:
systemctl start mariadb

================================================================================
SECTION 7: VERIFY RESTORE
================================================================================

--- Step 7.1 ---

Code:
mysql -u root -e "SHOW DATABASES;"

--- Step 7.2 ---

Code:
SELECT TABLE_SCHEMA, TABLE_NAME

FROM information_schema.TABLES

WHERE TABLE_NAME LIKE '%transaction%';

================================================================================
SECTION 8: SHUTDOWN
================================================================================

Code:
systemctl stop mariadb

systemctl stop apache2

shutdown -h now

================================================================================
SECTION 9: TROUBLESHOOTING
================================================================================

--- MariaDB not starting ---

Code:
journalctl -xe | grep mariadb

tail -100 /var/log/mysql/error.log

Fix:
- chown -R mysql:mysql /var/lib/mysql/
- wsrep_on=OFF
- re-run restore

--- Disk full ---

Code:
df -h

Fix:
- use --move-back
- use /mnt/data/mysql

--- Unzip error ---

Code:
unzip -P 'PASSWORD' file.zip

--- phpMyAdmin issue ---

Code:
systemctl status apache2

curl ifconfig.me

================================================================================
QUICK REFERENCE
================================================================================

Data disk: /dev/sda1
Mount: /mnt/data
Backup: /mnt/data/24x7/
Extract: /mnt/data/restored/
Datadir: /var/lib/mysql OR /mnt/data/mysql
MariaDB: 10.11

How to install Wazuh and Auditd on agent host

Tue, 07 Apr 2026 11:55:24 +0530

1) Install Wazuh agent prerequisites
apt-get update && apt-get install -y curl gnupg apt-transport-https

2) Add Wazuh repository key
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor | tee /usr/share/keyrings/wazuh.gpg > /dev/null

3) Add Wazuh repository
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list
apt-get update

4) Install Wazuh agent
WAZUH_MANAGER="10.200.10.38" apt-get install -y wazuh-agent

5) Start and enable Wazuh agent
systemctl daemon-reexec && systemctl enable wazuh-agent && systemctl start wazuh-agent && systemctl status wazuh-agent

6) Install auditd
apt-get install -y auditd audispd-plugins

7) Start and enable auditd
systemctl enable auditd && systemctl start auditd && systemctl status auditd

8) Verify audit log exists
ls -l /var/log/audit/audit.log

9) Create audit rules file
cat > /etc/audit/rules.d/wazuh.rules <<'EOF'
-w /etc/localtime -p wa -k audit_time_rules
-a always,exit -F arch=b32 -S stime,settimeofday,adjtimex -F key=audit_time_rules
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
-w /etc/group -p wa -k usergroup_mod
-w /etc/passwd -p wa -k usergroup_mod
-w /etc/gshadow -p wa -k usergroup_mod
-w /etc/shadow -p wa -k usergroup_mod
-w /etc/security/opasswd -p wa -k usergroup_mod
-a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/useradd -F key=user_mgmt
-a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/userdel -F key=user_mgmt
-a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/usermod -F key=user_mgmt
-a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/groupadd -F key=user_mgmt
-a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/groupdel -F key=user_mgmt
-a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/groupmod -F key=user_mgmt
-w /etc/issue.net -p wa -k netconfig
-w /etc/issue -p wa -k netconfig
-w /etc/hosts -p wa -k netconfig
-w /etc/netplan -p wa -k netconfig
-a always,exit -F arch=b32 -S sethostname,setdomainname -F key=netconfig
-a always,exit -F arch=b64 -S sethostname,setdomainname -F key=netconfig
-w /etc/apparmor -p wa -k MAC-policy
-w /etc/selinux -p wa -k MAC-policy
-w /var/log/tallylog -p wa -k logins
-w /var/log/lastlog -p wa -k logins
-w /var/log/faillog -p wa -k logins
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
-w /var/run/utmp -p wa -k session
-w /usr/sbin/insmod -p x -k modules
-w /usr/sbin/modprobe -p x -k modules
-w /usr/sbin/rmmod -p x -k modules
-a always,exit -F arch=b64 -S init_module,delete_module -F key=modules
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d -p wa -k sudoers
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b32 -S unlink,rename,rmdir,unlinkat,renameat -F auid>=1000 -F auid!=-1 -F key=delete
-a always,exit -F arch=b64 -S rename,rmdir,unlink,unlinkat,renameat -F auid>=1000 -F auid!=-1 -F key=delete
EOF

10) Load audit rules
augenrules --load

11) Verify audit rules are active
auditctl -l

12) Back up Wazuh agent config
cp -a /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf.bak.$(date +%F-%H%M%S)

13) Edit Wazuh config
vim /var/ossec/etc/ossec.conf
Add this block inside an section:

audit
/var/log/audit/audit.log

A safe place is near the other entries.

14) Verify the audit block is present
grep -nA3 -B3 '/var/log/audit/audit.log\|audit' /var/ossec/etc/ossec.conf

15) Restart Wazuh agent
systemctl restart wazuh-agent && systemctl status wazuh-agent

16) Confirm Wazuh is reading audit log
grep -i audit /var/ossec/logs/ossec.log | tail -n 20
You want to see:
Analyzing file: '/var/log/audit/audit.log'

17) Optional validation
Generate an audit event:
cat /etc/shadow >/dev/null
Check audit log:
tail -n 20 /var/log/audit/audit.log
Check Wazuh agent log again:
grep -i audit /var/ossec/logs/ossec.log | tail -n 20

Minimal post-checks on every server
systemctl is-active wazuh-agent && systemctl is-active auditd
auditctl -l | head
grep -i audit /var/ossec/logs/ossec.log | tail -n 5

How to Connect Azure Storage Explorer Using SAS URL

Tue, 07 Apr 2026 11:47:05 +0530

For e.g.

Storage Account: sadaddevapplogs

Step 1: Generate SAS URL from Azure Portal

1. Login to Microsoft Azure Portal
2. Search for your Storage Account: sadaddevapplogs

https://prnt.sc/g4vjm8Q__Lcx

3. Open the Storage Account

4. Navigate to:
Security + networking → Shared access signature

5. Configure the following:

https://prnt.sc/3PN24EGyoSCZ

Allowed Services:
- File

Allowed Resource Types:
- Service
- Container
- Object

Permissions:
- Read
- List

Start Time:
- Set current time

Expiry Time:
- Set as per requirement (recommended: short duration)

Allowed Protocol:
- HTTPS only

6. Click:
Generate SAS and connection string

7. Copy:
File service SAS URL

---

Step 2: Connect Using Azure Storage Explorer

1. Open Azure Storage Explorer

2. Click:
Open Connect Dialog (Plug icon)

3. Select:
Storage Account or directory

4. Choose:
Shared access signature (SAS)

5. Paste the SAS URL

6. Click:
Next → Connect

---

Common Issues & Fix

- Access Denied:
Ensure Read and List permissions are enabled

- Unable to view containers:
Ensure Service, Container, and Object are selected

- SAS expired:
Regenerate SAS token

- Firewall blocked:
Allow your IP in Azure Storage firewall settings

---

Best Practices

- Use short expiry duration for SAS
- Restrict access using IP whitelisting
- Avoid Write/Delete permissions unless required
- Rotate SAS tokens periodically

EDB PostgreSQL Advanced Server v15 Setup on Azure RHEL 9.4 with pgAdmin

Tue, 07 Apr 2026 09:38:37 +0530

EDB PostgreSQL Advanced Server v15 Setup on Azure RHEL 9.4 with pgAdmin

Overview
This guide covers installing and configuring EDB PostgreSQL Advanced Server v15 on Azure RHEL 9.4, setting up systemd service, configuring remote connections and connecting via pgAdmin.

Environment

OS: Red Hat Enterprise Linux 9.4 on Azure
Database: EDB PostgreSQL Advanced Server v15
Port: 5444
pgAdmin: Web-based pgAdmin interface
Database User: enterprisedb

Table of Contents

Step 1 - Install EDB PostgreSQL
Step 2 - Initialize the Database
Step 3 - Create Systemd Service
Step 4 - Configure Remote Connections
Step 5 - Setup Firewall Rules
Step 6 - Install PostgreSQL Client
Step 7 - Configure pgAdmin
Step 8 - Test Connectivity

Step 1 - Install EDB PostgreSQL Advanced Server
Run on: Azure RHEL 9.4 Server

Add the EDB repository:

Code:
curl -1sLf 'https://downloads.enterprisedb.com/YOUR_REPO_TOKEN/enterprise/setup.rpm.sh' | sudo -E bash

Install EDB PostgreSQL Advanced Server v15:

Code:
sudo dnf install edb-as15-server

Verify installation:

Code:
/usr/edb/as15/bin/postgres --version

Step 2 - Initialize the Database
Run on: Azure RHEL 9.4 Server

Create the data directory:

Code:
sudo mkdir -p /usr/edb/as15/data

sudo mkdir -p /usr/edb/as15/logs

Switch to enterprisedb user and initialize:

Code:
sudo su - enterprisedb

/usr/edb/as15/bin/initdb -D /usr/edb/as15/data

exit

Step 3 - Create Systemd Service
Run on: Azure RHEL 9.4 Server

Create the service file:

Code:
sudo nano /etc/systemd/system/edb-as15.service

Add the following configuration:

Code:
[Unit]

Description=EDB PostgreSQL Advanced Server 15

After=network.target

[Service]

Type=forking

User=enterprisedb

ExecStart=/usr/edb/as15/bin/pg_ctl -D /usr/edb/as15/data -l /usr/edb/as15/logs/server.log start

ExecStop=/usr/edb/as15/bin/pg_ctl -D /usr/edb/as15/data stop

ExecReload=/usr/edb/as15/bin/pg_ctl -D /usr/edb/as15/data reload

PIDFile=/usr/edb/as15/data/postmaster.pid

[Install]

WantedBy=multi-user.target

Reload systemd and start service:

Code:
sudo systemctl daemon-reload

sudo systemctl start edb-as15

sudo systemctl enable edb-as15

Verify service status:

Code:
sudo systemctl status edb-as15

Expected output:

Code:
edb-as15.service - EDB PostgreSQL Advanced Server 15

  Active: active (running)

Step 4 - Configure Remote Connections
Run on: Azure RHEL 9.4 Server

Edit postgresql.conf:

Code:
sudo nano /usr/edb/as15/data/postgresql.conf

Set the following values:

Code:
listen_addresses = '*'

port = 5444

Edit pg_hba.conf to allow remote access:

Code:
sudo nano /usr/edb/as15/data/pg_hba.conf

Add your bastion or client IP:

Code:
# Allow specific IP access

host    all    all    YOUR_BASTION_IP/32    md5

# Or allow entire subnet

host    all    all    10.170.0.0/24    md5

Reload PostgreSQL to apply changes:

Code:
sudo systemctl reload edb-as15

Step 5 - Setup Firewall Rules
Run on: Azure RHEL 9.4 Server

Open port 5444 in firewalld:

Code:
sudo firewall-cmd --permanent --add-port=5444/tcp

sudo firewall-cmd --reload

Verify port is open:

Code:
sudo firewall-cmd --list-all

Verify PostgreSQL is listening:

Code:
netstat -tuln | grep 5444

Expected output:

Code:
tcp    0    0 0.0.0.0:5444    0.0.0.0:*    LISTEN

Step 6 - Install PostgreSQL Client
Run on: Bastion Server

Install psql client:

Code:
sudo dnf install postgresql

Verify client installation:

Code:
psql --version

Step 7 - Configure pgAdmin
Run on: Web Browser

7.1 Access pgAdmin

Open your pgAdmin URL in browser
Login with your pgAdmin credentials

7.2 Add New Server

In left sidebar right-click on Servers
Select Create > Server

7.3 General Tab Settings

Name: EDB-Advanced-Server

7.4 Connection Tab Settings

Host name/address: YOUR_EDB_SERVER_IP
Port: 5444
Maintenance database: edb
Username: enterprisedb
Password: YOUR_ENTERPRISEDB_PASSWORD
Check Save password if desired

7.5 Save and Connect

Click Save
Server should appear under Servers in sidebar
Expand to browse databases

Step 8 - Test Connectivity
Run on: Bastion Server

Test connection using psql:

Code:
psql -h YOUR_EDB_SERVER_IP -p 5444 -U enterprisedb -d edb

If successful you will see the psql prompt:

Code:
edb=#

Test basic query:

Code:
SELECT version();

\l

\du

\q

Troubleshooting

Connection refused: Check firewall rules and port 5444 is open
Auth failed: Verify pg_hba.conf has correct IP and auth method
Service not starting: Check logs at /usr/edb/as15/logs/server.log
pgAdmin can't connect: Verify network connectivity between pgAdmin and EDB server

Check service logs:

Code:
sudo journalctl -u edb-as15 -f

tail -f /usr/edb/as15/logs/server.log

Additional Resources

pgAdmin Documentation: https://www.pgadmin.org/docs/
EDB Documentation: https://www.enterprisedb.com/docs/
EDB PostgreSQL Advanced Server v15 Release Notes

Summary

EDB PostgreSQL Advanced Server v15 installed on Azure RHEL 9.4
Database initialized and systemd service created
Remote connections configured on port 5444
Firewall rules configured to allow port 5444
pgAdmin configured to connect to EDB server
Connectivity tested successfully via psql
Always use strong passwords for database users
Restrict pg_hba.conf to specific IPs only
Monitor logs regularly for security and performance

NGINX Ingress + cert-manager + Let's Encrypt Setup on AKS Cluster

Tue, 07 Apr 2026 09:34:59 +0530

NGINX Ingress + cert-manager + Let's Encrypt Setup on AKS Cluster

Overview
This guide covers installing NGINX Ingress Controller, cert-manager and Let's Encrypt ClusterIssuer on Azure Kubernetes Service (AKS). This is specifically configured for AKS single-node clusters with CriticalAddonsOnly=true taint.

Environment

Platform: Azure Kubernetes Service (AKS)
Ingress: NGINX Ingress Controller
TLS: cert-manager with Let's Encrypt
Node Taint: CriticalAddonsOnly=true
OS: Linux nodes

Prerequisites

kubectl installed and configured
Helm v3 installed
AKS cluster running and accessible
Domain names pointed to cluster external IP
Valid email address for Let's Encrypt notifications

Step 1 - Add Helm Repositories
Run on: Local machine or CI/CD pipeline

Add required Helm repos:

Code:
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

helm repo add jetstack https://charts.jetstack.io

helm repo update

Verify repos added:

Code:
helm repo list

Step 2 - Install NGINX Ingress Controller
Run on: Local machine with kubectl access

Create namespace:

Code:
kubectl create namespace ingress-basic

Install NGINX Ingress with tolerations for CriticalAddonsOnly taint:

Code:
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \

  --namespace ingress-basic \

  --set controller.nodeSelector."kubernetes\.io/os"=linux \

  --set controller.tolerations[0].key="CriticalAddonsOnly" \

  --set controller.tolerations[0].operator="Exists" \

  --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \

  --set controller.admissionWebhooks.patch.tolerations[0].key="CriticalAddonsOnly" \

  --set controller.admissionWebhooks.patch.tolerations[0].operator="Exists"

Check Ingress Controller status:

Code:
kubectl get svc -n ingress-basic

kubectl get pods -n ingress-basic

Expected output:

Code:
NAME                                TYPE          CLUSTER-IP    EXTERNAL-IP      PORT(S)

ingress-nginx-controller            LoadBalancer  10.0.x.x      YOUR_EXTERNAL_IP 80:xxx/TCP,443:xxx/TCP

Important: Copy the EXTERNAL-IP and point your domain DNS records to it.
Example: yourdomain.com -> YOUR_EXTERNAL_IP

Step 3 - Install cert-manager
Run on: Local machine with kubectl access

Create namespace:

Code:
kubectl create namespace cert-manager

Install cert-manager with CRDs and tolerations:

Code:
helm install cert-manager jetstack/cert-manager \

  --namespace cert-manager \

  --set installCRDs=true \

  --set nodeSelector."kubernetes\.io/os"=linux \

  --set tolerations[0].key="CriticalAddonsOnly" \

  --set tolerations[0].operator="Exists" \

  --set cainjector.nodeSelector."kubernetes\.io/os"=linux \

  --set cainjector.tolerations[0].key="CriticalAddonsOnly" \

  --set cainjector.tolerations[0].operator="Exists" \

  --set webhook.nodeSelector."kubernetes\.io/os"=linux \

  --set webhook.tolerations[0].key="CriticalAddonsOnly" \

  --set webhook.tolerations[0].operator="Exists" \

  --set startupapicheck.tolerations[0].key="CriticalAddonsOnly" \

  --set startupapicheck.tolerations[0].operator="Exists" \

  --set startupapicheck.nodeSelector."kubernetes\.io/os"=linux

Verify all cert-manager pods are running:

Code:
kubectl get pods -n cert-manager

Expected outpu