| Welcome, Guest |
You have to register before you can post on our site.
|
| 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: 17
|
Upgrade Guide: Ubuntu 22....
Forum: Linux
Last Post: aniket.pitre
04-07-2026, 11:31 AM
» Replies: 0
» Views: 9
|
How to fix "failed to aut...
Forum: DevOps
Last Post: rishi
04-07-2026, 10:50 AM
» Replies: 0
» Views: 17
|
AKS Namespace Migration +...
Forum: DevOps
Last Post: rishi
04-07-2026, 10:22 AM
» Replies: 0
» Views: 13
|
HashiCorp Vault HA Deploy...
Forum: DevOps
Last Post: aniket.pitre
04-07-2026, 10:01 AM
» Replies: 0
» Views: 9
|
Disaster Recovery (DR) Re...
Forum: DevOps
Last Post: aniket.pitre
04-07-2026, 09:47 AM
» Replies: 0
» Views: 10
|
Git Pull Script — Repo Se...
Forum: DevOps
Last Post: Amey Bhargave
04-07-2026, 08:34 AM
» Replies: 0
» Views: 5
|
ArgoCD + Image Updater + ...
Forum: DevOps
Last Post: Amey Bhargave
04-07-2026, 06:54 AM
» Replies: 0
» Views: 7
|
AKS Namespace Access Cont...
Forum: DevOps
Last Post: rana
04-07-2026, 06:32 AM
» Replies: 0
» Views: 17
|
How to do OPENVAS migrati...
Forum: DevOps
Last Post: rishi
04-07-2026, 06:27 AM
» Replies: 0
» Views: 6
|
|
|
| Extending LVM Logical Volume (LV) in Linux – Runbook |
|
Posted by: Kalyani - 04-22-2026, 05:54 AM - Forum: Linux
- No Replies
|
 |
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
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
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
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
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: 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
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:
For ext4:
Code: resize2fs /dev/rootvg/varlv
For xfs:
Outcome:
- Filesystem expands to use new space
Step 5 — Verify
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
- New disk should be visible (e.g. /dev/sdb)
Step 4 — Create PV
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
# OR
Code: resize2fs /dev/rootvg/varlv
Step 8 — Verify
Additional Note — Expanding Existing Disk
If the same disk is increased in size (no new disk added):
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) |
|
Posted by: aniket.pitre - 04-07-2026, 11:31 AM - Forum: Linux
- No Replies
|
 |
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
? Confirm:- VERSION="22.04 LTS"
- CODENAME=jammy
? Step 2 — Update Current System
Code: sudo apt update && sudo apt upgrade
- You may see package list fetching
- If prompted:
? Step 3 — Install update-manager-core
Code: sudo apt install update-manager-core
- Press Y → continue installation
Edit Upgrade Configuration
Code: sudo nano /etc/update-manager/release-upgrades
Change to:
? Save:- CTRL + X
- Press Y
- Press ENTER
⚙️ Step 4 — Prepare System (dist-upgrade)
Code: sudo apt dist-upgrade
- System may install/remove dependencies
- If prompted:
? Step 5 — Reboot System
? Step 6 — Run Release Upgrade
Code: sudo do-release-upgrade
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:
5. Service Restart Prompt- "Restart services during package upgrades without asking?"
Options:
6. Obsolete Packages Prompt- "Remove obsolete packages?"
Options:
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:
✅ Step 8 — Verify Upgrade
OR
? 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
Code: sudo dpkg --configure -a
sudo apt -f install
|
|
|
|
| How to fix "failed to authorize: failed to fetch oauth token: unauthorized" issue |
|
Posted by: rishi - 04-07-2026, 10:50 AM - Forum: DevOps
- No Replies
|
 |
[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) |
|
Posted by: rishi - 04-07-2026, 10:22 AM - Forum: DevOps
- No Replies
|
|
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: <BASE64_KEY>
azurestorageaccountname: <BASE64_NAME>
Step 4: Verify Base64 Values
Code: echo "<value>" | 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: <UK_DB_IP>
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:
Step 18: Verify Deployment
kubectl get pods -n sadad-online-pos-queue-consumer
kubectl logs <pod>
Common Issue: Volume Mount Error
Error:
MountVolume failed: No such file or directory
Fix:
az storage share create \
--name pos-queue-logs \
--account-name <storage_account> \
--account-key <key>
Then restart pod:
kubectl delete pod <pod-name>
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 |
|
Posted by: aniket.pitre - 04-07-2026, 10:01 AM - Forum: DevOps
- No Replies
|
|
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
? 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 |
|
Posted by: aniket.pitre - 04-07-2026, 09:47 AM - Forum: DevOps
- No Replies
|
|
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
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"
Code: apt update
apt install mariadb-server mariadb-backup -y
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
Edit:
Code: /etc/mysql/mariadb.conf.d/50-server.cnf
Code: [mariadb]
wsrep_on = OFF
Code: systemctl restart mariadb
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
Code: GRANT REPLICATION SLAVE, BINLOG MONITOR ON [i].[/i]
TO 'replication_user'@'<dr_node_ip>';
FLUSH PRIVILEGES;
? Phase 5 — Download & Restore Backup
Download
Code: az storage blob download
--account-name <storage_account>
--container-name
--name ".tar.zst.enc"
--file "/mnt/.tar.zst.enc"
--auth-mode login
Code: openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000
-in /mnt/.tar.zst.enc
-out /mnt/backup.tar.zst
-pass pass:''
Code: cd /mnt
tar --use-compress-program=zstd -xf backup.tar.zst
Code: cat /mnt/xtrabackup_binlog_info
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
Code: mariabackup --prepare --target-dir=/mnt/
Code: mariabackup --copy-back
--target-dir=/mnt/
--datadir=/var/lib/mysql/
Code: chown -R mysql:mysql /var/lib/mysql/
Code: systemctl start mariadb
? Phase 7 — Setup Replication
Code: CHANGE MASTER TO
MASTER_HOST='<galera_node_ip>',
MASTER_USER='<replication_user>',
MASTER_PASSWORD='',
MASTER_PORT=3306,
MASTER_LOG_FILE='<binlog_file>',
MASTER_LOG_POS=<binlog_position>;
❗ Phase 8 — Common Errors
Error 1032
Code: STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;
- Missing partition → add required partitions
Error 1146
✅ 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) |
|
Posted by: Amey Bhargave - 04-07-2026, 08:34 AM - Forum: DevOps
- No Replies
|
 |
================================================================================
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.
Find the appropriate container for your application.
================================================================================
--- Step 3: Access the Container ---
Exec into the application container:
Code: docker exec -it <container_name> bash
================================================================================
--- Step 4: Locate Git Pull Cron Job ---
Check existing cron jobs:
Also check system cron directory:
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 |
|
Posted by: Amey Bhargave - 04-07-2026, 06:54 AM - Forum: DevOps
- No Replies
|
|
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 <APP_NAMESPACE> create secret docker-registry ghcr-regcred
--docker-server=ghcr.io
--docker-username='<GITHUB_USERNAME>'
--docker-password='<GITHUB_TOKEN>'
? Step 2: Create GHCR Secret (ArgoCD Namespace)
Code: kubectl -n <ARGOCD_NAMESPACE> create secret docker-registry ghcr-regcred
--docker-server=ghcr.io
--docker-username='<GITHUB_USERNAME>'
--docker-password='<GITHUB_TOKEN>'
? Step 3: Create Git Credentials Secret
Code: kubectl -n <ARGOCD_NAMESPACE> create secret generic argocd-image-updater-git-creds
--from-literal=username='<GITHUB_USERNAME>'
--from-literal=password='<GITHUB_TOKEN>'
? Step 4: Register Git Repository in ArgoCD
Code: apiVersion: v1
kind: Secret
metadata:
name: <REPO_SECRET_NAME>
labels:
argocd.argoproj.io/secret-type: repository
type: Opaque
stringData:
type: git
url: [url=https://github.com/]https://github.com/[/url]/.git
username: '<GITHUB_USERNAME>'
password: '<GITHUB_TOKEN>'
Code: kubectl -n <ARGOCD_NAMESPACE> apply -f repo-secret.yaml
? Step 5: Create ArgoCD Application
Code: apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: <APPLICATION_NAME>
namespace: <ARGOCD_NAMESPACE>
spec:
project: <PROJECT_NAME>
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: <APP_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: <IMAGE_UPDATER_NAME>
namespace: <ARGOCD_NAMESPACE>
spec:
namespace: <ARGOCD_NAMESPACE>
applicationRefs:
- namePattern: <APPLICATION_NAME>
images:
- alias:
imageName: ghcr.io//<IMAGE_NAME>
commonUpdateSettings:
updateStrategy: newest-build
allowTags: regexp:^(sha-)?[0-9a-f]{7,40}$
pullSecret: pullsecret:<ARGOCD_NAMESPACE>/ghcr-regcred
manifestTargets:
kustomize:
name: ghcr.io//<IMAGE_NAME>
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: <APP_NAMESPACE>
rules:
[list]
[*]apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"]
? Step 8: Create RBAC RoleBinding
Code: apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: argocd-image-updater-secret-reader
namespace: <APP_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: <ARGOCD_NAMESPACE>
✅ Final Notes
Verify:
Code: kubectl get applications -n <ARGOCD_NAMESPACE>
kubectl logs -n <ARGOCD_NAMESPACE> deploy/argocd-image-updater
|
|
|
|
| AKS Namespace Access Control – minesec (RBAC Implementation) |
|
Posted by: rana - 04-07-2026, 06:32 AM - Forum: DevOps
- No Replies
|
 |
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://<AKS-API-SERVER>
certificate-authority-data: <BASE-64-CA>
users:
- name: minesecuser
user:
token: <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) |
|
Posted by: rishi - 04-07-2026, 06:27 AM - Forum: DevOps
- No Replies
|
|
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.
|
|
|
|
|
