DevOps Discussion Forum
Portal

Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  

Search Forums

(Advanced Search)

Forum Statistics
» Members: 8
» Latest member: admin
» Forum threads: 21
» Forum posts: 21

Full Statistics

Online Users
There is currently 1 user online
» 0 Member(s) | 1 Guest(s)

Latest Threads
Extending LVM Logical Vol...
Forum: Linux
Last Post: Kalyani
04-22-2026, 05:54 AM
» Replies: 0
» Views: 20
Upgrade Guide: Ubuntu 22....
Forum: Linux
Last Post: aniket.pitre
04-07-2026, 11:31 AM
» Replies: 0
» Views: 11
How to fix "failed to aut...
Forum: DevOps
Last Post: rishi
04-07-2026, 10:50 AM
» Replies: 0
» Views: 21
AKS Namespace Migration +...
Forum: DevOps
Last Post: rishi
04-07-2026, 10:22 AM
» Replies: 0
» Views: 17
HashiCorp Vault HA Deploy...
Forum: DevOps
Last Post: aniket.pitre
04-07-2026, 10:01 AM
» Replies: 0
» Views: 12
Disaster Recovery (DR) Re...
Forum: DevOps
Last Post: aniket.pitre
04-07-2026, 09:47 AM
» Replies: 0
» Views: 13
Git Pull Script — Repo Se...
Forum: DevOps
Last Post: Amey Bhargave
04-07-2026, 08:34 AM
» Replies: 0
» Views: 8
ArgoCD + Image Updater + ...
Forum: DevOps
Last Post: Amey Bhargave
04-07-2026, 06:54 AM
» Replies: 0
» Views: 10
AKS Namespace Access Cont...
Forum: DevOps
Last Post: rana
04-07-2026, 06:32 AM
» Replies: 0
» Views: 20
How to do OPENVAS migrati...
Forum: DevOps
Last Post: rishi
04-07-2026, 06:27 AM
» Replies: 0
» Views: 9

 
  MariaDB Galera Cluster — Backup & Restore Guide
Posted by: Amey Bhargave - 04-07-2026, 06:26 AM - Forum: DevOps - No Replies

================================================================================
                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

Print this item

  How to install Wazuh and Auditd on agent host
Posted by: rishi - 04-07-2026, 06:25 AM - Forum: DevOps - No Replies

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 <ossec_config> section:
<localfile>
 <log_format>audit</log_format>
 <location>/var/log/audit/audit.log</location>
</localfile>
A safe place is near the other <localfile> entries.

14) Verify the audit block is present
grep -nA3 -B3 '/var/log/audit/audit.log\|<log_format>audit</log_format>' /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

Print this item

  How to Connect Azure Storage Explorer Using SAS URL
Posted by: rishi - 04-07-2026, 06:17 AM - Forum: DevOps - No Replies

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

Print this item

  EDB PostgreSQL Advanced Server v15 Setup on Azure RHEL 9.4 with pgAdmin
Posted by: santosh - 04-07-2026, 04:08 AM - Forum: DevOps - No Replies

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
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
Print this item

  NGINX Ingress + cert-manager + Let's Encrypt Setup on AKS Cluster
Posted by: santosh - 04-07-2026, 04:04 AM - Forum: DevOps - No Replies

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

Print this item

  gdrive v3.9.1 - Linux Server Setup with Google API and OAuth Authentication
Posted by: santosh - 04-07-2026, 04:04 AM - Forum: DevOps - No Replies

gdrive v3.9.1 - Linux Server Setup with Google API and OAuth Authentication

Overview
This guide covers installing gdrive v3.9.1 on a Linux server, enabling the Google Drive API, configuring OAuth, and authenticating on a headless server.

Prerequisites

  • Linux server with root or sudo access
  • Google Cloud Console account
  • SSH access to the server

Step 0 - Download and Install gdrive Binary
Run on: Linux Server

Download for x64:
Code:
wget https://github.com/glotlabs/gdrive/releases/download/3.9.1/gdrive_linux-x64.tar.gz

For ARM64 servers use:
Code:
wget https://github.com/glotlabs/gdrive/releases/download/3.9.1/gdrive_linux-arm64.tar.gz

Verify the tarball:
Code:
file gdrive_linux-x64.tar.gz

Extract and install:
Code:
tar -xzf gdrive_linux-x64.tar.gz
sudo install -m 0755 ./gdrive /usr/local/bin/gdrive

Confirm installation:
Code:
gdrive version

Step 1 - Enable Google Drive API
Run on: Google Cloud Console (one-time setup)
  • Open Google Cloud Console and select your project
  • Go to APIs & Services > Library
  • Search for Google Drive API and click Enable
  • Optionally enable Drive Activity API
  • Wait 2-3 minutes for changes to propagate

Step 2 - Configure OAuth Consent Screen
Run on: Google Cloud Console
  • Go to APIs & Services > OAuth consent screen
  • Select User type - External for typical use or Internal for Google Workspace
  • Fill in App name, User support email and Developer contact information
  • Click Save
  • Set Publishing status to Testing
  • Go to Audience > Test users and add the Google account you will sign in with
  • Note: If your email is not added as a test user you will get 403 access_denied during auth

Step 3 - Create OAuth Client
Run on: Google Cloud Console
  • Go to APIs & Services > Credentials
  • Click Create Credentials > OAuth client ID
  • Set Application type to Desktop app - this is critical for loopback redirect
  • Copy the Client ID and Client Secret

Step 4 - Authenticate gdrive on Headless Linux Server

Option A - SSH Port Forward (Recommended)
Run on: Your local laptop first, then server

On your local laptop open a terminal and run:
Code:
ssh -N -L 8085:127.0.0.1:8085 root@YOUR_SERVER_IP

Keep this terminal open. Then open a new SSH session to your server:
Code:
gdrive account add

Paste your Desktop Client ID and Secret when prompted. Copy the Google URL that is printed and open it in your laptop browser. Sign in as a Test user and click Allow. Google will redirect to http://127.0.0.1:8085 and the SSH tunnel will forward it back to the server completing the auth.

Verify on the server:
Code:
gdrive account list
gdrive files list

Option B - Export Token from Laptop and Import to Server
Run on: Your local laptop first, then server

On your laptop:
Code:
gdrive account add
gdrive account export > token.json

Copy token to server:
[c

Print this item

  Grafana + Loki + Promtail + Node Exporter Setup with Docker Compose
Posted by: santosh - 04-07-2026, 04:02 AM - Forum: DevOps - No Replies

Grafana + Loki + Promtail + Node Exporter Setup with Docker Compose

Overview
This guide covers setting up a complete monitoring and logging stack using Grafana, Loki, Promtail and Node Exporter inside Docker with Docker Compose.

Stack Components

  • Grafana - Visualization and dashboards (Port 3000)
  • Loki - Log aggregation (Port 3100)
  • Promtail - Log collector and shipper
  • Node Exporter - System metrics (Port 9100)

Step 1 - Prerequisites
Run on: Monitoring Server

Install Docker:
Code:
curl -fsSL https://get.docker.com | sh
docker --version

Install Docker Compose:
Code:
sudo apt install docker-compose -y
docker-compose --version

Step 2 - Directory Structure
Run on: Monitoring Server

Create the monitoring directory:
Code:
mkdir -p /root/24x7/monitoring/grafana-lok
cd /root/24x7/monitoring/grafana-lok

Directory structure:
Code:
grafana-lok/
├── docker-compose.yml
├── loki-config.yml
├── promtail-config.yml

Step 3 - Create Docker Compose File
Run on: Monitoring Server
Code:
nano docker-compose.yml

Add the following content:
Code:
version: '3.8'

networks:
  monitoring_network:
    driver: bridge

services:
  loki:
    image: grafana/loki:latest
    container_name: loki
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yml:/etc/loki/local-config.yaml
    command: -config.file=/etc/loki/local-config.yaml
    networks:
      - monitoring_network
    restart: unless-stopped

  promtail:
    image: grafana/promtail:latest
    container_name: promtail
    volumes:
      - /var/log:/var/log
      - ./promtail-config.yml:/etc/promtail/config.yml
    command: -config.file=/etc/promtail/config.yml
    networks:
      - monitoring_network
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=YOUR_GRAFANA_PASSWORD
    volumes:
      - grafana_data:/var/lib/grafana
    networks:
      - monitoring_network
    restart: unless-stopped

  node_exporter:
    image: prom/node-exporter:latest
    container_name: node_exporter
    ports:
      - "9100:9100"
    networks:
      - monitoring_network
    restart: unless-stopped

volumes:
  grafana_data:

Step 4 - Create Loki Configuration
Run on: Monitoring Server
Code:
nano loki-config.yml

Add the following content:
Code:
auth_enabled: false

server:
  http_listen_port: 3100

ingester:
  lifecycler:
    address: 127.0.0.1
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1
    final_sleep: 0s
  chunk_idle_period: 5m
  chunk_retain_period: 30s
  max_transfer_retries: 0

schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

storage_config:
  boltdb_shipper:
    active_index_directory: /tmp/loki/index
    cache_location: /tmp/loki/index_cache
    shared_store: filesystem
  filesystem:
    directory: /tmp/loki/chunks

limits_config:
  enforce_metric_name: false
  reject_old_samples: true
  reject_old_samples_max_age: 168h
  ingestion_rate_mb: 50
  ingestion_burst_size_mb: 100

compactor:
  working_directory: /tmp/loki/compactor
  shared_store: filesystem
  compaction_interval: 10m

Step 5 - Create Promtail Configuration
Run on: Monitoring Server
Code:
nano promtail-config.yml

Add the following content:
Code:
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: varlogs
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__: /var/log/**/*.log

Step 6 - Start All Services
Run on: Monitoring Server

Start the stack:
Code:
docker-compose up -d

Verify containers are running:
Code:
docker ps

Check logs:
Code:
docker-compose logs -f grafana
docker-compose logs -f loki
docker-compose logs -f promtail
docker-compose logs -f node_exporter

Step 7 - Access Grafana
Step 8 - Add Loki as Data Source
  • Login to Grafana
  • Go to Settings > Data Sources
  • Click Add Data Source
  • Select Loki
  • Set URL to: http://loki:3100
  • Click Save & Test

Step 9 - Add Node Exporter Metrics
  • Go to Settings > Data Sources
  • Click Add Data Source
  • Select Prometheus
  • Set URL to: http://node_exporter:9100
  • Click Save & Test

Step 10 - Managing Services
Run on: Monitoring Server

Restart all services:
Code:
docker-compose restart

Stop all services:
Code:
docker-compose down

Port Reference
  • Grafana: Port 3000
  • Loki: Port 3100
  • Promtail: Port 9080
  • Node Exporter: Port 9100

Summary
  • Grafana, Loki, Promtail and Node Exporter running inside Docker
  • All services connected via monitoring_network bridge
  • Loki and Promtail handle log collection and aggregation
  • Node Exporter provides system metrics to Grafana
  • Grafana accessible at http://YOUR_SERVER_IP:3000
  • Always use strong passwords for Grafana admin account
  • Consider adding Nginx reverse proxy with SSL for production
Print this item

  PostgreSQL with Barman Backup Setup Guide
Posted by: santosh - 04-07-2026, 03:58 AM - Forum: DevOps - No Replies

PostgreSQL with Barman Backup Setup Guide

Environment Setup

  • PostgreSQL Database Server IP: 10.10.x.x
  • Barman Backup Server IP: 10.10.x.x
  • PostgreSQL Version: 14
  • Barman Version: 3.11.1
  • OS: Ubuntu 20.04 / 22.04

Architecture Overview
Code:
[ PostgreSQL Server 10.10.x.x ]  ----WAL Archive---->  [ Barman Server 10.10.x.x ]
        (Database)                                          (Backup)

Step 1 - Install PostgreSQL
Run on: PostgreSQL Server (10.10.x.x)
Code:
sudo apt update
sudo apt install postgresql-14

Step 2 - Configure postgresql.conf
Run on: PostgreSQL Server (10.10.x.x)
Code:
sudo nano /etc/postgresql/14/main/postgresql.conf
Add the following lines:
Code:
wal_level = replica
archive_mode = on
archive_command = 'rsync -a %p barman@BARMAN_IP:/var/lib/barman/main-db-server/incoming/%f'
max_wal_senders = 3
wal_keep_size = 256MB

Step 3 - Configure pg_hba.conf
Run on: PostgreSQL Server (10.10.x.x)
Code:
sudo nano /etc/postgresql/14/main/pg_hba.conf
Add the following line:
Code:
host    all    barman    BARMAN_IP/32    md5

Step 4 - Restart PostgreSQL
Run on: PostgreSQL Server (10.10.x.x)
Code:
sudo systemctl restart postgresql
sudo systemctl status postgresql

Step 5 - Install Barman
Run on: Barman Backup Server (10.10.x.x)
Code:
sudo apt update
sudo apt install barman

Step 6 - SSH Key Setup
Run on: Barman Backup Server (10.10.x.x)

Generate SSH key on Barman server:
Code:
sudo -i -u barman
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""

Copy key to PostgreSQL server:
Code:
ssh-copy-id -i ~/.ssh/id_rsa.pub postgres@POSTGRES_IP

Test SSH connection:
Code:
ssh postgres@POSTGRES_IP

Step 7 - Configure Barman
Run on: Barman Backup Server (10.10.x.x)
Code:
sudo nano /etc/barman.d/main-db-server.conf
Add the following:
Code:
[main-db-server]
description = "Main PostgreSQL Server"
conninfo = host=POSTGRES_IP user=barman password=YOUR_PASSWORD port=5432 dbname=postgres
ssh_command = ssh postgres@POSTGRES_IP
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
backup_method = rsync
archiver = on
compression = gzip
parallel_jobs = 4

Step 8 - Create Barman User in PostgreSQL
Run on: PostgreSQL Server (10.10.x.x)
Code:
sudo -i -u postgres
psql -c "CREATE USER barman WITH REPLICATION LOGIN ENCRYPTED PASSWORD 'YOUR_PASSWORD';"
psql -c "ALTER USER barman WITH SUPERUSER;"

Step 9 - Verify Setup
Run on: Barman Backup Server (10.10.x.x)
Code:
sudo -u barman barman check main-db-server

Expected Output:
Code:
Server main-db-server:
    PostgreSQL: OK
    superuser or standard user with backup privileges: OK
    wal_level: OK
    directories: OK
    retention policy settings: OK
    archive_mode: OK
    archive_command: OK
    continuous archiving: OK
    ssh: OK

Step 10 - Take First Backup
Run on: Barman Backup Server (10.10.x.x)
Code:
sudo -u barman barman backup main-db-server

List backups:
Code:
sudo -u barman barman list-backup main-db-server

Summary
  • PostgreSQL Server - Sends WAL logs to Barman via rsync
  • Barman Server - Receives and stores backups with 7 day retention
  • SSH - Used for secure communication between both servers
  • Always test restore procedure after setup
Print this item

  WildFly Keystore Generation & HTTPS Setup Guide
Posted by: santosh - 04-07-2026, 03:57 AM - Forum: DevOps - No Replies

WildFly Keystore Generation & HTTPS Setup Guide

Overview
This guide covers generating a keystore and configuring HTTPS in WildFly including ports 8443 for applications and 9993 for the admin console.

Step 1 - Generate the Keystore
Run on: WildFly Application Server

Use the keytool command to generate the keystore:

Code:
keytool -genkeypair \
  -alias wildfly \
  -keyalg RSA \
  -keystore wildfly.keystore \
  -storetype JKS \
  -storepass YOUR_STORE_PASSWORD \
  -keypass YOUR_KEY_PASSWORD \
  -validity 365 \
  -dname "CN=yourdomain.com, OU=YourOrgUnit, O=YourOrg, L=YourCity, ST=YourState, C=YourCountry"

Parameter explanation:
  • -alias: Alias name for the key e.g. wildfly
  • -keyalg: Encryption algorithm e.g. RSA
  • -keystore: Keystore filename e.g. wildfly.keystore
  • -storepass: Password for the keystore. Must match the TLS config in standalone.xml
  • -keypass: Password for the key. Must match the keystore password
  • -validity: Number of days the certificate remains valid e.g. 365
  • -dname: Distinguished Name for the certificate. Replace with your actual domain and org details

Step 2 - Place Keystore in WildFly Directory
Run on: WildFly Application Server

Move the keystore to WildFly configuration directory:
Code:
mv wildfly.keystore /opt/wildfly/standalone/configuration/

Set correct ownership and permissions:
Code:
chown wildfly:wildfly /opt/wildfly/standalone/configuration/wildfly.keystore
chmod 600 /opt/wildfly/standalone/configuration/wildfly.keystore

Step 3 - Verify the Keystore
Run on: WildFly Application Server

Inspect the generated keystore to ensure it is valid:
Code:
keytool -list -v \
  -keystore /opt/wildfly/standalone/configuration/wildfly.keystore \
  -storepass YOUR_STORE_PASSWORD

Step 4 - Configure TLS in standalone.xml
Run on: WildFly Application Server

Edit the standalone.xml file:
Code:
sudo nano /opt/wildfly/standalone/configuration/standalone.xml

Add the following TLS configuration:
Code:
<tls>
    <key-stores>
        <key-store name="SSLKeyStore">
            <credential-reference clear-text="YOUR_STORE_PASSWORD"/>
            <implementation type="JKS"/>
            <file path="wildfly.keystore" relative-to="jboss.server.config.dir"/>
        </key-store>
    </key-stores>
    <key-managers>
        <key-manager name="SSLKeyManager" key-store="SSLKeyStore">
            <credential-reference clear-text="YOUR_STORE_PASSWORD"/>
        </key-manager>
    </key-managers>
    <server-ssl-contexts>
        <server-ssl-context name="SSLContext" key-manager="SSLKeyManager"/>
    </server-ssl-contexts>
</tls>

Step 5 - Restart WildFly
Run on: WildFly Application Server
Code:
/opt/wildfly/bin/standalone.sh

Or if running as a service:
Code:
sudo systemctl restart wildfly
sudo systemctl status wildfly

Step 6 - Verify HTTPS Ports
Run on: WildFly Application Server

Check if HTTPS ports are active:
Code:
netstat -tuln | grep -E '8443|9993'

Expected output:
Code:
tcp    0    0 0.0.0.0:8443    0.0.0.0:*    LISTEN
tcp    0    0 0.0.0.0:9993    0.0.0.0:*    LISTEN

Step 7 - Test Access

Test the following URLs in your browser:
Summary
  • Keystore generated using Java keytool command
  • Keystore placed in WildFly configuration directory with correct permissions
  • TLS configuration added to standalone.xml
  • WildFly restarted to apply changes
  • HTTPS now active on port 8443 for apps and 9993 for admin console
  • Always use strong passwords for keystore in production
  • Consider using a proper SSL certificate from Let's Encrypt for production instead of self-signed
Print this item

  How to Reset Sentry User Password via Docker Compose
Posted by: santosh - 04-07-2026, 03:57 AM - Forum: DevOps - No Replies

How to Reset Sentry User Password via Docker Compose

Overview
This guide explains how to reset a user password in Sentry when it is running via Docker Compose.

Prerequisites

  • Sentry running via Docker Compose
  • Root or sudo access to the server
  • Sentry self-hosted directory available

Step 1 - Navigate to Sentry Directory
Run on: Sentry Server
Code:
cd /root/24x7/sentry.io/self-hosted

Step 2 - Access the Sentry Shell
Run on: Sentry Server

Access the Sentry shell inside the running container:
Code:
docker-compose exec web sentry shell

Step 3 - Reset the Password
Run inside: Sentry Shell

Run the following Python commands to reset the user password:
Code:
from django.contrib.auth.models import User

email = 'user@yourdomain.com'
new_password = 'YOUR_NEW_PASSWORD'

try:
    user = User.objects.get(email=email)
    user.set_password(new_password)
    user.save()
    print(f"Password reset successful for {email}")
except User.DoesNotExist:
    print(f"User with email {email} does not exist.")

Expected Output:
Code:
Password reset successful for user@yourdomain.com

Step 4 - Exit the Shell
Run inside: Sentry Shell
Code:
exit()

Step 5 - Verify Login
  • Open your Sentry URL in browser
  • Login with the email and new password
  • Confirm access is working

Summary
  • Navigate to Sentry self-hosted directory
  • Access container shell using docker-compose exec
  • Use Django ORM to find user by email and reset password
  • Exit shell and verify login
  • Always use a strong password in production
  • Store passwords securely in a password manager
Print this item