soban

CrowdSec – Intelligent Linux Server Protection Against Botnets, Brute-Force Attacks and Internet Scanning

soban — Fri, 27 Feb 2026 10:46:55 +0000

If you run a Linux server with Nginx, SSH, or WordPress, you probably already know Fail2Ban. It is a solid tool, but it works locally — it blocks only the IP addresses that attacked your server.

CrowdSec works in a completely different way. It is a protection system based on shared IP reputation. If thousands of servers worldwide detect a malicious IP address, your server can block it before an attack even happens.

How Does CrowdSec Work?

analyzes system logs (nginx, ssh, wordpress)
detects suspicious behavior
shares attacker IP intelligence with other servers
blocks traffic at the firewall level

The result? Most bots and internet scanners never even reach your Nginx server.

Installing CrowdSec on Debian / Ubuntu

CrowdSec installation is very simple and available directly from Debian repositories.

apt update
apt install crowdsec

During installation, CrowdSec automatically:

creates a local API (LAPI)
registers the server in CrowdSec Central API
downloads default security scenarios

Installing Firewall Bouncer

CrowdSec detects threats, but it requires an enforcement component — called a bouncer — which blocks traffic at the firewall level.

apt install crowdsec-firewall-bouncer

By default, the bouncer uses nftables and automatically adds blocking rules for malicious IP addresses.

Installing Security Collections

Collections include log parsers and attack detection scenarios.

cscli collections install crowdsecurity/nginx
cscli collections install crowdsecurity/wordpress
cscli collections install crowdsecurity/base-http-scenarios
cscli collections install crowdsecurity/sshd

Reload configuration after installation:

systemctl reload crowdsec

Configuring Nginx Logs

To allow CrowdSec to analyze HTTP traffic, you must specify Nginx log files.

Edit the file:

nano /etc/crowdsec/acquis.yaml

Add the following configuration:

filenames:
  - /var/log/nginx/access*.log
  - /var/log/nginx/error*.log
labels:
  type: nginx

Then restart the service:

systemctl restart crowdsec

Verifying CrowdSec Operation

Service status:

systemctl status crowdsec

Active bans list:

cscli decisions list

Operational metrics:

cscli metrics

Final Result

After proper CrowdSec installation:

the server automatically blocks known botnets
WordPress attacks and SSH brute-force attempts are stopped at the firewall
Nginx handles significantly less malicious traffic
server CPU and IO usage are noticeably reduced

CrowdSec can be considered an evolution of Fail2Ban — a system that not only reacts locally but also benefits from global threat intelligence.

Artykuł CrowdSec – Intelligent Linux Server Protection Against Botnets, Brute-Force Attacks and Internet Scanning pochodzi z serwisu soban.

Fail2Ban: How to Detect Repeat Offenders and Ban Them for a Week (Recidive)

soban — Thu, 26 Feb 2026 12:09:28 +0000

If you use Fail2Ban with Nginx and WordPress, sooner or later you’ll notice one thing: the same IP addresses keep coming back. They get banned for a few minutes or an hour, disappear… and shortly after try again /.env, /wp-login.php, /phpmyadmin, or other common attack paths.

The solution is not to aggressively tighten the filters. The solution is recidive — a second layer of protection in Fail2Ban that analyzes the ban history and blocks repeat offenders long-term.

Reference to the previous configuration

If you don’t yet have a basic Fail2Ban configuration for Nginx and WordPress, I described it here:

Fail2Ban + Nginx + WordPress – basic configuration

In that article, we configure jails such as nginx-exploit, nginx-secure, and sshd. Recidive does not replace that configuration — it strengthens it.

How to find repeat offenders in the logs

First, it’s worth checking whether the issue actually exists. We extract from the Fail2Ban logs the list of IP addresses that were banned most frequently:

grep "Ban " /var/log/fail2ban.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head

Example output (addresses partially anonymized):

13 204.76.203.18
9 41.142.XXX.XXX
8 64.89.XXX.XXX
8 50.82.XXX.XXX
8 35.243.XXX.XXX
8 34.24.XXX.XXX
7 45.166.XXX.XXX
7 34.83.XXX.XXX
7 176.42.XXX.XXX
6 49.36.XXX.XXX

If you see numbers like 8, 9, or 13 — it means those IPs are coming back after the ban expires. A short bantime is just a technical pause for them.

Why recidive is better than increasing bantime

You don’t have to ban everyone for 24 hours because of a single typo in a URL.
You don’t increase the risk of blocking legitimate users.
The penalty is progressive and applies only to returning addresses.

Recidive analyzes /var/log/fail2ban.log and counts how many times a given IP has been banned by other jails. This way, you only “finish off” those that have already been blocked multiple times before.

Recidive configuration (5 bans in 24h = 7 days ban)

Add the following block to /etc/fail2ban/jail.local:

nano /etc/fail2ban/jail.local

At the end of the file, paste:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 7d
findtime = 1d
maxretry = 5

Save the file and restart Fail2Ban:

systemctl restart fail2ban

Check the jail status:

fail2ban-client status recidive

How to check who is close to the recidive threshold

If you want to see IPs that already have several bans and are approaching the recidive threshold:

grep "Ban " /var/log/fail2ban.log | awk '{print $NF}' | sort | uniq -c | awk '$1 >= 3 {print}' | sort -nr

Summary

Recidive is one of the simplest and most effective ways to limit recurring scanners and bots. Instead of aggressively banning everyone — you block only those who repeatedly come back.

In an environment with multiple domains, Nginx reverse proxy, and WordPress, it’s practically a must-have configuration element: less noise in logs, fewer repeated attacks, and less manual analysis.

Artykuł Fail2Ban: How to Detect Repeat Offenders and Ban Them for a Week (Recidive) pochodzi z serwisu soban.

Debian 13 (Trixie) → Proxmox VE 9 – Simplified Installation on Pure Debian

soban — Mon, 23 Feb 2026 16:18:39 +0000

Proxmox VE 9 is based on Debian 13 (Trixie) and introduces a newer kernel, updated LXC, QEMU and improved virtualization stack. This guide presents a simplified and automated method to install Proxmox VE 9 on a clean Debian 13 system using two installation scripts.

The method follows the same approach as my previous Proxmox 8 on Debian 12 guide, but adapted for Debian 13 and Proxmox VE 9.

Prerequisites

Fresh Debian 13 (Trixie) installation
Root access
Internet connectivity

All commands must be executed as root.

Part 1 – System Preparation & Proxmox Kernel Installation

Download the first script:

wget http://soban.pl/bash/install-proxmox9-part1.sh
chmod +x install-proxmox9-part1.sh
./install-proxmox9-part1.sh

This script:

Sets hostname and updates /etc/hosts
Installs Proxmox archive keyring (verified via SHA512)
Adds Proxmox VE 9 repository for Debian 13
Performs full system upgrade
Installs proxmox-default-kernel
Reboots the system

Content of install-proxmox9-part1.sh

#!/usr/bin/env bash
set -euo pipefail

# Part 1/2: Debian 13 (Trixie) -> Proxmox VE 9
# - sets /etc/hosts
# - adds PVE repo + installs Proxmox archive keyring (verified by SHA512)
# - full-upgrade
# - installs proxmox-default-kernel
# - reboots

log() { echo "[$(date '+%F %T')] $*"; }
die() { echo "ERROR: $*" >&2; exit 1; }

if [[ "$(id -u)" -ne 0 ]]; then
  die "Run as root."
fi

log "=== Proxmox VE 9 install (part 1/2) on Debian 13 Trixie ==="

if ! grep -qi 'trixie' /etc/os-release; then
  log "WARNING: This does not look like Debian 13 (Trixie). Continue at your own risk."
fi

log "Network interfaces (for reference):"
ip -br -c a || true

CURRENT_HOSTNAME="$(hostname)"
CURRENT_IP="$(hostname -I | awk '{print $1}')"

read -r -p "Hostname for this node [${CURRENT_HOSTNAME}]: " HOSTNAME
HOSTNAME="${HOSTNAME:-$CURRENT_HOSTNAME}"

read -r -p "Primary IP for /etc/hosts [${CURRENT_IP}]: " IPADDR
IPADDR="${IPADDR:-$CURRENT_IP}"

if [[ -z "${HOSTNAME}" || -z "${IPADDR}" ]]; then
  die "Hostname/IP cannot be empty."
fi

log "Setting hostname to: ${HOSTNAME}"
hostnamectl set-hostname "${HOSTNAME}"

log "Backing up /etc/hosts -> /etc/hosts.backup"
cp -a /etc/hosts /etc/hosts.backup

log "Writing /etc/hosts (makes hostname resolvable locally)"
cat > /etc/hosts < /etc/apt/sources.list.d/pve-install-repo.list <

Part 2 – Proxmox VE 9 Installation

After reboot, download and execute:

wget http://soban.pl/bash/install-proxmox9-part2.sh
chmod +x install-proxmox9-part2.sh
./install-proxmox9-part2.sh

Content of install-proxmox9-part2.sh

#!/usr/bin/env bash
set -euo pipefail

# Part 2/2: Debian 13 (Trixie) -> Proxmox VE 9
# - verifies running PVE kernel (unless FORCE=1)
# - installs proxmox-ve + required packages
# - removes Debian kernel packages (keeps pve)
# - updates grub
# - removes os-prober
# - prints URL to GUI

log() { echo "[$(date '+%F %T')] $*"; }
die() { echo "ERROR: $*" >&2; exit 1; }

FORCE="${FORCE:-0}"

if [[ "$(id -u)" -ne 0 ]]; then
  die "Run as root."
fi

log "=== Proxmox VE 9 install (part 2/2) ==="

KERNEL="$(uname -r || true)"
if ! echo "${KERNEL}" | grep -qi 'pve'; then
  if [[ "${FORCE}" != "1" ]]; then
    die "You are NOT running a PVE kernel (uname -r: ${KERNEL}).
Reboot and select the Proxmox kernel first.
If you really want to continue anyway: FORCE=1 ./install-proxmox9-part2.sh"
  else
    log "WARNING: Continuing despite not running PVE kernel because FORCE=1"
  fi
else
  log "OK: running PVE kernel: ${KERNEL}"
fi

log "Update package lists"
apt update

log "Install Proxmox VE packages"
# postfix is optional but commonly installed by docs; choose config during prompts
DEBIAN_FRONTEND=readline apt install -y proxmox-ve postfix open-iscsi chrony

log "Upgrade remaining packages"
apt full-upgrade -y

log "Removing Debian kernel meta-package and non-PVE kernels (best-effort)"
# Remove Debian meta kernel (keeps proxmox kernel)
apt remove -y linux-image-amd64 || true

# Purge any installed linux-image-* that is NOT a pve kernel
mapfile -t KPKGS < <(dpkg -l | awk '/^ii  linux-image-/{print $2}' | grep -vE 'pve|proxmox' || true)
if (( ${#KPKGS[@]} > 0 )); then
  log "Purging non-PVE kernel packages: ${KPKGS[*]}"
  apt purge -y "${KPKGS[@]}" || true
fi

log "Update grub"
update-grub || true

log "Remove os-prober (recommended for servers; avoids odd grub side effects)"
apt remove -y os-prober || true

log "Done. Proxmox UI should be available at:"
IP="$(hostname -I | awk '{print $1}')"
echo "https://${IP}:8006"

log "Login: root + your root password"

Accessing the Web Interface

After completing the second script, open:

https://YOUR_SERVER_IP:8006

Login with the root user and your root password. You may see a certificate warning — this is normal for fresh installations.

Troubleshooting – 401 Unauthorized (pve-enterprise repository)

If after installation or during apt update you encounter the following error:

Err:8 https://enterprise.proxmox.com/debian/pve trixie InRelease
  401  Unauthorized [IP: 2001:41d0:b00:5900::34 443]
Error: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/trixie/InRelease  401  Unauthorized
Error: The repository 'https://enterprise.proxmox.com/debian/pve trixie InRelease' is not signed.
Notice: Updating from such a repository can't be done securely, and is therefore disabled by default.

This means the enterprise repository is enabled but your system does not have a valid Proxmox subscription. If you are using the no-subscription repository (as shown in this guide), you should disable the enterprise repository.

Fix it by running:

mv /etc/apt/sources.list.d/pve-enterprise.sources \
   /etc/apt/sources.list.d/pve-enterprise.sources.disabled

apt update

After this, the update should complete successfully:

apt update && apt dist-upgrade -y && apt autoremove -y

If everything is correct, you should see:

All packages are up to date.

Conclusion

This method provides a clean and controlled way to deploy Proxmox VE 9 directly on Debian 13 without using the ISO installer. It is especially useful for automated environments, labs, and custom infrastructure setups.

Artykuł Debian 13 (Trixie) → Proxmox VE 9 – Simplified Installation on Pure Debian pochodzi z serwisu soban.

Fail2Ban Nginx Setup – Block Scanners and Exploits Without Blocking WordPress Admin

soban — Mon, 16 Feb 2026 23:10:10 +0000

This guide shows a complete Fail2Ban installation and configuration for Nginx, designed to:

block real scanners and exploit attempts (e.g. requests to /.env, /.git, /phpmyadmin, etc.),
avoid blocking administrators by accident (common issue when banning only by HTTP errors),
ban IP addresses after repeated suspicious activity,
use a short ban time (5 minutes) to reduce the risk of locking yourself out.

Why banning by HTTP errors alone can backfire

Many guides suggest banning by HTTP status codes (4xx/499) only. In real life this often causes self-bans, because modern apps generate bursts of requests (AJAX, admin panels, cache rebuilds), and you can hit error statuses during normal work.

This setup uses a safer approach:

exploit paths are always suspicious,
HTTP errors are counted only when the request has no Referer (typical for scanners),
known bad User-Agents are counted.

Step 1: Install Fail2Ban

Install Fail2Ban:

apt update
apt install -y fail2ban

Enable and start the service:

systemctl enable fail2ban
systemctl start fail2ban

Verify that it is running:

fail2ban-client ping
systemctl status fail2ban

Step 2: Create the nginx-secure filter

Create the filter file:

nano /etc/fail2ban/filter.d/nginx-secure.conf

Paste the following configuration:

[Definition]

failregex =
    # exploit paths
    ^ - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) (?:/\.env|/wp-config\.php|/phpinfo\.php|/(?:phpmyadmin|adminer)(?:/|$)|/(?:\.git|\.svn|\.hg)(?:/|$)|/vendor/phpunit/|/cgi-bin/).*" \d{3} .*

    # errors without referer (real scanners)
    ^ - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) [^"]*" (?:400|403|404|405|408|413|414|429|444) [^"]* "-" ".*"

    # bad user agents
    ^ - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT).*" \d{3} .* "(?:[^"]*)" "(?:[^"]*(?:sqlmap|nikto|masscan|zgrab|nmap|acunetix|wpscan|dirbuster|gobuster)[^"]*)"

ignoreregex =

Step 3: Create the nginx-secure jail

Create the jail configuration file:

nano /etc/fail2ban/jail.d/nginx-secure.conf

Paste the following configuration:

[nginx-secure]
enabled  = true
port     = http,https
filter   = nginx-secure

logpath  = /var/log/nginx/access.log
           /var/log/nginx/access-*.log

findtime = 600
maxretry = 20
bantime  = 300

action   = iptables-multiport[name=nginx-secure, port="http,https"]

ignoreip = 127.0.0.1/8 ::1

Step 4: Restart Fail2Ban

fail2ban-server -t
systemctl restart fail2ban

Step 5: Verify firewall integration

Check that the Fail2Ban chain exists:

iptables -S | grep f2b-nginx-secure
iptables -L f2b-nginx-secure -n -v

External test

Run from another machine (exploit path test):

for i in 1 2 3 4 5; do
  curl -I https://soban.pl/.env
done

Test “errors without Referer” logic (scanner-like request – no referer header):

for i in 1 2 3 4 5; do
  curl -sS -o /dev/null -w "%{http_code}\n" https://soban.pl/this-path-should-not-exist-$i
done

After repeated suspicious requests, the IP address will be banned for 5 minutes.

Check banned IPs

fail2ban-client status nginx-secure

Unban IP address

Unban an IP manually:

fail2ban-client set nginx-secure unbanip YOUR_IP

Summary

blocks exploit paths and real scanners,
reduces self-bans by counting HTTP errors only when the Referer is missing,
uses a short 5-minute ban duration,
works with iptables-nft,
easy to test and easy to unban IP addresses.

Artykuł Fail2Ban Nginx Setup – Block Scanners and Exploits Without Blocking WordPress Admin pochodzi z serwisu soban.

Automatic upgrade Debian 12 → Debian 13 with optional PHP and nginx update

soban — Mon, 16 Feb 2026 11:15:42 +0000

Upgrading Debian from version 12 (bookworm) to 13 (trixie) is an operation that should be performed in a repeatable and predictable way, especially on servers and containers (for example Proxmox LXC or virtual machines). Below you will find a simple guide and ready-to-use commands to download and run the upgrade script.

Before running the upgrade: create a backup or snapshot. In Proxmox, the best option is vzdump or a snapshot. On bare metal, at minimum back up /etc, applications, and databases.

Proxmox LXC / VM: backup using vzdump or create a snapshot.
Server: backup /etc, /var/www, databases (MySQL/PostgreSQL), and SSL certificates.

Script download:

https://soban.pl/bash/upgrade_to_debian13.sh

1) Backup before upgrade (examples)

Example backup in Proxmox (run on Proxmox host, replace CTID/VMID):

vzdump 101 --mode snapshot --compress zstd --storage local

Example simple filesystem backup on a server (this does not replace a full snapshot, but it’s better than nothing):

tar czf /root/backup_before_upgrade.tar.gz /etc /var/www /root

2) Download the script (wget / curl)

The easiest way is to use wget. If the wget command does not work even though the package is installed, use the full path /usr/bin/wget.

Variant A (standard wget):

apt update
apt install -y wget
cd /root
wget -O upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

Variant B (wget with full path – useful if PATH is broken):

apt update
apt install -y wget
cd /root
/usr/bin/wget -O upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

Variant C (curl):

apt update
apt install -y curl
cd /root
curl -fsSL -o upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

3) Script help (parameters)

Before running the upgrade, display available parameters and usage examples:

cd /root
./upgrade_to_debian13.sh --help

4) Upgrade Debian 12 → Debian 13 (system only)

If you are currently running Debian 12 (bookworm) and want to perform a system upgrade:

cd /root
./upgrade_to_debian13.sh

The script will create a backup of /etc/apt/sources.list, switch repositories to trixie, run apt update and apt full-upgrade, and finally execute autoremove and autoclean.

5) Auto-detect PHP/nginx and update if needed

If the container or VM is running a web stack and you want the script to automatically detect PHP usage (nginx + fastcgi_pass) and upgrade PHP and nginx if necessary:

cd /root
./upgrade_to_debian13.sh --auto

6) Force PHP and nginx upgrade (PHP-FPM socket fix)

If you want to force installation or upgrade of PHP and automatically fix nginx configuration to use the correct PHP-FPM socket:

cd /root
./upgrade_to_debian13.sh --with-php --with-nginx --php-version 8.2

This command installs PHP 8.2 (php-fpm and common modules) and replaces old PHP-FPM socket paths in nginx configuration with /run/php/php8.2-fpm.sock. Then it runs nginx -t and reloads or restarts services.

7) Already running Debian 13? PHP/nginx only mode

If the system is already running Debian 13 (trixie) and you only want to upgrade PHP and nginx without modifying system repositories:

cd /root
./upgrade_to_debian13.sh --php-nginx-only --with-php --with-nginx --php-version 8.2

8) Dry-run mode (test mode)

If you want to see what the script will do without making any changes:

cd /root
./upgrade_to_debian13.sh --auto --dry-run

9) Troubleshooting: wget installed but not working

If apt reports wget is installed but the shell shows command not found, it is usually a PATH issue. The easiest workaround is to use the full path: /usr/bin/wget.

echo "$PATH"
command -v wget || true
ls -l /usr/bin/wget || true
/usr/bin/wget --version || true

Summary

This solution provides a convenient way to upgrade Debian 12 → Debian 13 and optionally fix common PHP/nginx issues after upgrade (PHP-FPM socket paths, nginx config testing, and service restart). Always create a backup before upgrading and start by running --help to review available options.

Script: https://soban.pl/bash/upgrade_to_debian13.sh

Artykuł Automatic upgrade Debian 12 → Debian 13 with optional PHP and nginx update pochodzi z serwisu soban.

Proxmox VM Auto-Upgrade Script (qm + vzdump) with Network Tests and Auto-Restore

soban — Fri, 23 Jan 2026 15:56:05 +0000

Proxmox VM Auto-Upgrade Script (qm + vzdump) with Network Tests and Auto-Restore

This article describes a simple (but effective) automation script for Proxmox VE that:

creates a backup of a VM (optional),
starts the VM if it was originally stopped,
runs apt upgrade + reboot inside the VM,
performs network tests before and after the update,
restores from backup automatically if tests fail (optional),
shuts down the VM again if it was originally stopped.

Where to download the script

You can download the script directly from my website:

soban.pl/bash/upgrade_proxmox_qm.sh

Required folders

Before you run anything, create two folders for scripts and logs:

mkdir -p /root/automate_scripts /root/logs

Install the script

Download the file into /root/automate_scripts/ and make it executable:

cd /root/automate_scripts
curl -fsSL -o upgrade_proxmox_qm.sh "https://soban.pl/bash/upgrade_proxmox_qm.sh"
chmod +x /root/automate_scripts/upgrade_proxmox_qm.sh

How it works (high level)

Backup (vzdump snapshot + zstd) is executed first (if enabled).
If the VM was stopped, the script starts it and waits WAIT_TIME seconds.
Runs network tests BEFORE update:
Executes apt update/upgrade/dist-upgrade/autoremove/clean and finally reboots the VM.
Waits again (WAIT_TIME) and runs the same tests AFTER update.
If tests fail and a backup exists, it performs qmrestore automatically.
If the VM was originally stopped, it shuts down the VM at the end.

Usage

The script expects exactly two arguments:

VMID – the Proxmox VM ID
TIME_SEC – how long to wait after start/reboot (in seconds)

/root/automate_scripts/upgrade_proxmox_qm.sh 901 500

Tip: choose a WAIT_TIME that matches your VM boot time and apt upgrade duration. Typical values are 300 to 1000 seconds depending on the VM.

Full script (for reference)

If you prefer to keep everything in one place, below is the full script exactly as used in this setup:

#!/bin/bash

WAIT_TIME=$2  # wait time for VM start/restart (in seconds)
DO_BACKUP="y" # 'y' - create backup, 'n' - skip backup
DO_UPDATE="y" # 'y' - run system update, 'n' - skip update

echo "---------------START---------------"
date
echo "-----------------------------------"

# Argument check
if [ "$#" -ne 2 ]; then
    echo "Usage: $0  "
    exit 1
fi

VMID="$1"
TARGET_HOSTNAME=$(/usr/sbin/qm list | grep -w "$VMID" | awk '{print $2}')
VM_STATUS=$(/usr/sbin/qm status "$VMID" | awk '{print $2}')
HOST_MACHINE=$(hostname)
WAS_STOPPED=0

if [ "$VM_STATUS" = "stopped" ]; then
    WAS_STOPPED=1
else
    WAS_STOPPED=0
fi

# Create backup if DO_BACKUP is set to 'y'
backup_result="Backup not attempted"
if [ "$DO_BACKUP" = "y" ]; then
    echo "Creating backup for VM $VMID..."
    BACKUP_OUTPUT=$(/usr/bin/vzdump "$VMID" --storage local --mode snapshot --compress zstd)
    BACKUP_FILE=$(echo "$BACKUP_OUTPUT" | grep -oP 'vzdump-qemu-[^\s]+' | tr -d "'")

    if [ -z "$BACKUP_FILE" ]; then
        echo "Backup failed: No backup file created."
        backup_result="Backup created: NOK"
        exit 1
    else
        echo "Backup created successfully: $BACKUP_FILE"
        backup_result="Backup created: OK"
    fi
else
    echo "Backup not attempted (backup is disabled)."
fi

# Start VM if it was originally stopped
if [ "$WAS_STOPPED" -eq 1 ]; then
    echo "Starting VM $VMID for update..."
    /usr/sbin/qm start "$VMID"
    echo "Waiting $WAIT_TIME seconds for VM to start..."
    sleep "$WAIT_TIME"
fi

# Test functions
perform_ping_test() {
    source="$1"
    target="$2"
    if ssh root@"$source" "ping -c 3 -W 2 $target" >/dev/null 2>&1; then
        echo "Ping from $source to $target: OK"
        return 0
    else
        echo "Ping from $source to $target: NOK"
        return 1
    fi
}

test_curl() {
    source="$1"
    target="$2"
    if ssh root@"$source" "curl -s --head --connect-timeout 5 $target" >/dev/null 2>&1; then
        echo "Curl from $source to $target: OK"
        return 0
    else
        echo "Curl from $source to $target: NOK"
        return 1
    fi
}

perform_local_ping_test() {
    source="$1"
    target="$2"
    if ping -c 3 -W 2 "$target" >/dev/null 2>&1; then
        echo "Ping from $source to $target: OK"
        return 0
    else
        echo "Ping from $source to $target: NOK"
        return 1
    fi
}

DEFAULT_GW=$(/sbin/ip route | grep default | awk '{print $3}')

perform_tests() {
    status=0
    perform_local_ping_test "$HOST_MACHINE" "$TARGET_HOSTNAME" || status=1
    perform_ping_test "$TARGET_HOSTNAME" "8.8.8.8" || status=1
    perform_ping_test "$TARGET_HOSTNAME" "$DEFAULT_GW" || status=1
    test_curl "$TARGET_HOSTNAME" "http://google.com" || status=1
    return ${status:-0}
}

# General tests before update
echo "--- General tests BEFORE update ---"
if perform_tests; then
    echo "All network tests before update: OK"
    echo "$backup_result"

    if [ "$backup_result" == "Backup created: OK" ] || [ "$backup_result" == "Backup not attempted" ]; then
        echo "BEFORE status: OK"
    else
        echo "BEFORE status: NOK"
    fi
else
    echo "Some network tests before update: NOK"
    echo "$backup_result"
    echo "BEFORE status: NOK"
    [ "$WAS_STOPPED" -eq 1 ] && /usr/sbin/qm shutdown "$VMID"
    exit 1
fi
echo "-----------------------------------"

# System update and reboot
update_result="Upgrade system: NOK"
if [ "$DO_UPDATE" = "y" ]; then
    echo "--- Updating VM $VMID ---"
    if ssh root@"$TARGET_HOSTNAME" "/usr/bin/apt update && \
                          /usr/bin/apt upgrade -y && \
                          /usr/bin/apt dist-upgrade -y && \
                          /usr/bin/apt autoremove -y && \
                          /usr/bin/apt autoclean && \
                          /usr/bin/apt clean && \
                          /usr/bin/apt --purge autoremove && \
                          /sbin/reboot"; then
        echo "---END Updating VM $VMID ---"
        echo "Upgrade system: OK"
        update_result="Upgrade system: OK"
    else
        echo "Upgrade system: NOK"
        update_result="Upgrade system: NOK"
        [ "$WAS_STOPPED" -eq 1 ] && /usr/sbin/qm shutdown "$VMID"
        echo "Update failed. Exiting."
        exit 1
    fi
fi

# Wait for VM reboot if update was performed
if [ "$DO_UPDATE" = "y" ]; then
    echo "Waiting $WAIT_TIME seconds for VM to reboot..."
    sleep "$WAIT_TIME"
fi

# Tests after reboot if update was performed
if [ "$DO_UPDATE" = "y" ]; then
    echo "--- Network tests AFTER update ---"
    if perform_tests; then
        echo "All network tests after update: OK"
        echo "$update_result"
        echo "AFTER status: OK"
    else
        echo "Some network tests after update: NOK"
        echo "$update_result"
        echo "Attempting to restore from backup..."

        if [ "$DO_BACKUP" = "y" ]; then
            /usr/sbin/qm stop "$VMID"
            /usr/sbin/qmrestore "/var/lib/vz/dump/$BACKUP_FILE" "$VMID" --force

            if [ "$WAS_STOPPED" -eq 1 ]; then
                /usr/sbin/qm shutdown "$VMID"
            fi

            echo "Restore attempt finished. Please check VM status."
            echo "AFTER status: NOK"
        else
            echo "No backup available for restoration. The VM might not function properly after failed update."
            echo "AFTER status: NOK"
        fi
    fi
    echo "-----------------------------------"
fi

# Shut down VM if it was originally stopped
if [ "$WAS_STOPPED" -eq 1 ]; then
    echo "Shutting down VM $VMID (originally stopped)."
    /usr/sbin/qm shutdown "$VMID"
fi

echo "---------------END---------------"
date
echo "-----------------------------------"

Cron jobs (weekly schedule + per-VM logs)

Below is an example crontab that runs upgrades once a week (different VM each weekday) and writes separate logs to /root/logs/.

Edit root crontab:

crontab -e

Paste rules like these (comments in English):

15 0 * * 1 /root/automate_scripts/upgrade_proxmox_qm.sh 901 500 > /root/logs/kali.log 2>&1                 # Monday: upgrade Kali Linux (VMID 901)
15 0 * * 2 /root/automate_scripts/upgrade_proxmox_qm.sh 903 500 > /root/logs/proxmox-test-01.log 2>&1      # Tuesday: upgrade proxmox-test-01 (VMID 903)
15 0 * * 3 /root/automate_scripts/upgrade_proxmox_qm.sh 904 500 > /root/logs/ubuntu-lte.log 2>&1           # Wednesday: upgrade ubuntu-lte (VMID 904)
15 0 * * 4 /root/automate_scripts/upgrade_proxmox_qm.sh 905 1000 > /root/logs/backup-machine.log 2>&1      # Thursday: upgrade backup-machine (VMID 905)

Quick checks / troubleshooting

Make sure root can SSH into the VM by hostname (the script uses ssh root@).
Make sure DNS (or /etc/hosts) resolves the VM hostname correctly from the Proxmox host.
If apt needs user interaction, ensure your VMs are set up for non-interactive upgrades (or pin/hold packages that prompt).

That’s it. Drop the script into /root/automate_scripts/, send logs into /root/logs/, and your weekly VM maintenance becomes mostly fire-and-forget.

Artykuł Proxmox VM Auto-Upgrade Script (qm + vzdump) with Network Tests and Auto-Restore pochodzi z serwisu soban.

Dell WD19/WD19S: firmware update on Proxmox/Debian without USB timeouts (fwupd + autosuspend fix)

soban — Sun, 18 Jan 2026 21:06:13 +0000

If you’re trying to update the firmware of a Dell WD19/WD19S docking station on Proxmox (or Debian) using fwupdmgr, you may hit the classic Operation timed out error during the Erasing… stage. In practice, the update fails due to USB power management (autosuspend). Below you’ll find a simple, effective fix and a ready-to-run script you can use on a server or laptop.

Symptoms

Most commonly, during a dock firmware update (WD19/WD19S), you’ll see an error similar to:

failed to write-firmware: failed to erase bank: failed after 5 retries: failed to SetReport: USB error: Operation timed out [-7]

At this point, fwupdmgr may show the WD19S device as Update State: Failed or keep reporting pending activation, but the flash process never completes.

Why does this happen?

During flashing, the dock performs long-running operations. If the system tries to save power on USB (autosuspend), control transfers can fail. The result is a timeout exactly during the flash bank erase stage (erase bank).

Quick fix: disable USB autosuspend during the update

The simplest solution is to temporarily set autosuspend to -1 (disabled). This setting lasts until reboot (unless you make it permanent in the kernel cmdline), but it’s more than enough for the update process.

echo -1 > /sys/module/usbcore/parameters/autosuspend

Then run the firmware update:

fwupdmgr refresh --force
fwupdmgr update

After the update: “pending activation” and unplug requirement

After a successful firmware installation for WD19/WD19S, fwupdmgr often prints the following message:

The update will continue when the device USB cable has been unplugged.
WD19S is pending activation; use fwupdmgr activate to complete the update.

Do the following in this exact order:

Unplug the USB-C cable from the dock (from the laptop).
(Optional) Unplug the dock power for 10–15 seconds and plug it back in.
Plug the USB-C cable back in.
Run the activation step:

fwupdmgr activate

Finally, verify the status:

fwupdmgr get-updates
fwupdmgr get-devices | less

Ready-to-use script: install + update + autosuspend disable (with restore)

Below is a ready-to-run script that:

installs fwupd
refreshes LVFS metadata
temporarily disables USB autosuspend (so WD19S won’t fail with timeouts)
runs firmware updates
restores the previous autosuspend value afterwards (even if the update fails)

You can copy the script directly from this article, but if you prefer a faster way, you can download it from:

https://soban.pl/bash/dell_updage.sh

Example download and run:

cd /root/scripts
curl -fsSL https://soban.pl/bash/dell_updage.sh -o dell_updage.sh
chmod +x dell_updage.sh
./dell_updage.sh

If you want to preview the script before running it:

curl -fsSL https://soban.pl/bash/dell_updage.sh | less

If you don’t have less installed:

apt update
apt install -y less

Script (full content)

#!/bin/bash
set -euo pipefail

# dell upgrade:
# - installs fwupd
# - refreshes metadata
# - runs fwupdmgr update
# - TEMPORARILY disables USB autosuspend to avoid WD19/WD19S timeouts
# - restores autosuspend setting after update

echo "[INFO] Installing fwupd..."
apt update
apt install -y fwupd

echo "[INFO] Refreshing firmware metadata..."
fwupdmgr refresh --force
fwupdmgr get-updates || true

# Save current autosuspend value (if exists)
AUTOSUSPEND_PATH="/sys/module/usbcore/parameters/autosuspend"
OLD_AUTOSUSPEND=""

if [[ -f "$AUTOSUSPEND_PATH" ]]; then
  OLD_AUTOSUSPEND="$(cat "$AUTOSUSPEND_PATH" || true)"
  echo "[INFO] Current usbcore autosuspend: ${OLD_AUTOSUSPEND}"
else
  echo "[WARN] autosuspend sysfs file not found: $AUTOSUSPEND_PATH"
fi

restore_autosuspend() {
  if [[ -f "$AUTOSUSPEND_PATH" && -n "${OLD_AUTOSUSPEND}" ]]; then
    echo "[INFO] Restoring usbcore autosuspend back to: ${OLD_AUTOSUSPEND}"
    echo "${OLD_AUTOSUSPEND}" > "$AUTOSUSPEND_PATH" || true
  fi
}
trap restore_autosuspend EXIT

# Disable autosuspend to prevent USB timeout during dock firmware erase/write
if [[ -f "$AUTOSUSPEND_PATH" ]]; then
  echo "[INFO] Disabling USB autosuspend (set to -1) to avoid dock update timeouts..."
  echo -1 > "$AUTOSUSPEND_PATH"
fi

read -p "Do you want to update the entire device? (y/n): " answer
if [[ "$answer" == "y" || "$answer" == "Y" ]]; then
  echo "[INFO] Running fwupdmgr update..."
  fwupdmgr update || {
    echo "[ERROR] fwupdmgr update failed."
    echo "[HINT] If this is Dell dock (WD19/WD19S), try: unplug USB-C, replug, then run: fwupdmgr activate"
    exit 1
  }

  echo "[INFO] Update finished."
  echo "[INFO] If you updated a Dell dock and it says 'pending activation':"
  echo "       1) Unplug USB-C cable from the dock"
  echo "       2) (Optional) Unplug dock power for 10 seconds, plug back"
  echo "       3) Run: fwupdmgr activate"
else
  echo "[INFO] Skipping firmware update."
fi

echo "[INFO] Done."

Running the script

The simplest way:

chmod +x dell_updage.sh
./dell_updage.sh

FAQ & tips

The update still fails? Disconnect all peripherals from the dock (monitors/LAN/USB), leave only power and USB-C, do a hard reset of the dock (unplug power for 30s), and try again.
“pending activation” after update – this is normal for WD19/WD19S. You must unplug USB-C, plug it back in, then run fwupdmgr activate.
Does this update the laptop BIOS? Not always. fwupdmgr shows “System Firmware” (BIOS/UEFI) separately from the dock. This article focuses on the dock and the USB timeout issue.

Summary

If Dell WD19/WD19S firmware updates fail on Proxmox/Debian during the Erasing… stage, in most cases it’s enough to disable USB autosuspend temporarily. The script above does that automatically and restores the previous setting afterwards, so your system keeps working normally.

Artykuł Dell WD19/WD19S: firmware update on Proxmox/Debian without USB timeouts (fwupd + autosuspend fix) pochodzi z serwisu soban.

How to Upgrade Proxmox VE 8.x to 9.0 (Debian 12 to Debian 13) – Step-by-Step with Script

soban — Mon, 11 Aug 2025 11:51:58 +0000

Introduction

Proxmox VE 9.0 (based on Debian 13 “Trixie”) has been released, and it brings updated packages, a new kernel, and improved stability. This guide will walk you through the in-place upgrade from Proxmox VE 8.4.x (Debian 12 “Bookworm”) to Proxmox VE 9.0.

The process will be automated using a ready-made upgrade script that:

Checks your current version
Runs the pve8to9 pre-upgrade check
Backs up your current APT sources
Updates repositories from Bookworm to Trixie
Performs a full dist-upgrade
Logs all changes before and after the upgrade

Download and run the upgrade script

You can download the ready upgrade script directly from our server, make it executable, and run it:

wget https://soban.pl/bash/upgrade-pve8-to-9.sh -O /root/upgrade-pve8-to-9.sh
chmod +x /root/upgrade-pve8-to-9.sh
LOGF="/root/pve8to9.$(date +%F-%H%M%S).nohup.log"; nohup env NO_REBOOT=0 SKIP_PRECHECK=0 /root/upgrade-pve8-to-9.sh > "$LOGF" 2>&1 & echo $! >/run/pve8to9.pid
tail -f "$LOGF"

If you lose connection (which can happen during a Proxmox upgrade), you can follow the logs with:

tail -f /root/pve-upgrade-latest.log

Be patient and wait for the script to finish — it may take some time.

Full script source

#!/bin/bash
# Proxmox VE 8 -> 9 in-place upgrade (Debian 12 "bookworm" -> Debian 13 "trixie")
# Hardened: nuke/lock Enterprise repo, move backups OUT of APT dir, ensure single no-sub,
# robust pve8to9 detection/installation, switch to trixie, non-interactive upgrade, post-boot check.
set -euo pipefail

LOG="/root/pve-upgrade-$(date +%Y%m%d-%H%M%S).log"
SINK="/etc/apt/disabled-sources"        # OUTSIDE of APT scan path
APT_BACKUP_DIR="/root/apt-sources-backup-$(date +%Y%m%d-%H%M%S)"
NO_REBOOT="${NO_REBOOT:-0}"
FORCE_UPGRADE="${FORCE_UPGRADE:-0}"
SKIP_PRECHECK="${SKIP_PRECHECK:-0}"

# Ensure sane PATH for non-interactive shells
export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:${PATH:-}"
export DEBIAN_FRONTEND=noninteractive
export APT_LISTCHANGES_FRONTEND=none
export UCF_FORCE_CONFFOLD=1

shopt -s nullglob

msg() { echo "$*" | tee -a "$LOG"; }
die() { echo "ERROR: $*" | tee -a "$LOG"; exit 1; }
ts()  { date +%F-%H%M%S; }

sink() { # move file out of sources.list.d safely
  local f="$1" base
  [[ -e "$f" ]] || return 0
  base="$(basename "$f")"
  mkdir -p "$SINK"
  mv -f "$f" "$SINK/$base.bak.$(ts)"
}

divert_add() {
  local p="$1"
  if ! dpkg-divert --list | grep -Fq "diversion of $p"; then
    dpkg-divert --quiet --local --rename --add "$p" || true
  fi
  rm -f "$p" || true
}

cleanup_nonlist_sources() {
  mkdir -p "$SINK"
  find /etc/apt/sources.list.d -maxdepth 1 -type f \
    ! -name '*.list' ! -name '*.sources' \
    -exec mv -f {} "$SINK"/ \; || true
}

# STRICT verify: only fail on ACTIVE enterprise refs
verify_no_enterprise() {
  local bad=0
  # 1) Active lines in *.list (not commented)
  if grep -RIsn '^[[:space:]]*deb[[:space:]].*enterprise\.proxmox\.com' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null; then
    bad=1
  fi
  # 2) Deb822 .sources that mention enterprise AND are effectively enabled
  while IFS= read -r -d '' f; do
    if grep -qi 'enterprise\.proxmox\.com' "$f"; then
      # treat missing Enabled as enabled, only "Enabled: no" is safe
      if ! grep -qi '^[[:space:]]*Enabled:[[:space:]]*no[[:space:]]*$' "$f"; then
        echo "[VERIFY] Enabled enterprise in: $f" | tee -a "$LOG"
        bad=1
      fi
    fi
  done < <(find /etc/apt/sources.list.d -maxdepth 1 -type f -name '*.sources' -print0 2>/dev/null)
  (( bad == 0 )) || die "Enterprise repo still detected. Clean failed."
}

# Disabled deb822 stub WITHOUT enterprise domain (so greps never trip)
write_disabled_enterprise_sources() {
  cat > /etc/apt/sources.list.d/pve-enterprise.sources <<'EOF'
Types: deb
URIs: https://example.invalid/proxmox           # placeholder to avoid enterprise domain
Suites: trixie
Components: pve-enterprise
Enabled: no
EOF
  chmod 0644 /etc/apt/sources.list.d/pve-enterprise.sources
}

# --------- FIXED: robust locator for pve8to9 + debug ----------
locate_pve8to9() {
  hash -r 2>/dev/null || true
  local tool=""
  tool="$(type -P pve8to9 2>/dev/null || true)"
  [[ -z "$tool" ]] && tool="$(command -v pve8to9 2>/dev/null || true)"
  [[ -z "$tool" && -x /usr/bin/pve8to9 ]] && tool="/usr/bin/pve8to9"
  [[ -z "$tool" && -x /usr/sbin/pve8to9 ]] && tool="/usr/sbin/pve8to9"
  [[ -z "$tool" ]] && tool="$(/usr/bin/which pve8to9 2>/dev/null || true)"
  if [[ -z "$tool" ]] && command -v dpkg >/dev/null 2>&1; then
    local cand
    cand="$(dpkg -L pve-manager 2>/dev/null | grep -E '/pve8to9$' || true)"
    [[ -n "$cand" && -x "$cand" ]] && tool="$cand"
  fi
  echo "$tool"
}

run_pve8to9_precheck() {
  [[ "$SKIP_PRECHECK" == "1" ]] && { msg "SKIP_PRECHECK=1 set — skipping pve8to9."; return 0; }

  msg "Running pve8to9 --full precheck..."
  msg "PATH=$PATH"
  type -a pve8to9 2>&1 | sed 's/^/[type] /' | tee -a "$LOG" || true
  [[ -e /usr/bin/pve8to9 ]] && ls -l /usr/bin/pve8to9 | sed 's/^/[ls] /' | tee -a "$LOG" || true

  local tool; tool="$(locate_pve8to9)"

  if [[ -z "$tool" ]]; then
    msg "pve8to9 not found — attempting to ensure 'pve-manager' is installed..."
    apt-get update -y >> "$LOG" 2>&1 || true
    apt-get install -y pve-manager >> "$LOG" 2>&1 || true
    cleanup_nonlist_sources; verify_no_enterprise
    hash -r 2>/dev/null || true
    tool="$(locate_pve8to9)"
  fi

  if [[ -z "$tool" ]]; then
    msg "pve8to9 still not available on this system. Continuing without precheck."
    return 0
  fi

  msg "pve8to9 found at: $tool"
  local tmp rc
  tmp="$(mktemp)"
  set +e
  "$tool" --full | tee -a "$LOG" | tee "$tmp" >/dev/null
  rc=${PIPESTATUS[0]}
  set -e
  if grep -qE 'FAILURES:\s*[1-9]+' "$tmp"; then
    rm -f "$tmp"
    die "pve8to9 reported FAILURES. Check log above."
  fi
  rm -f "$tmp"
  msg "pve8to9 executed (rc=$rc). No FAILURES."
}
# ---------------------------------------------------------------

# ----- header / live log hint -----
echo "== Proxmox VE 8 -> 9 upgrade started: $(date) ==" | tee -a "$LOG"
echo "$$" > /run/pve8to9.pid
ln -sfn "$LOG" /root/pve-upgrade-latest.log
echo "Live log: tail -f /root/pve-upgrade-latest.log" | tee -a "$LOG"
echo "If started via nohup, also watch its file (example: /root/pve8to9..nohup.log)" | tee -a "$LOG"

# 0) PRE-NUKE ENTERPRISE + move backups OUT of APT dir
msg "[PRE-NUKE] Backup APT lists and clean directory..."
mkdir -p "$APT_BACKUP_DIR"
cp -a /etc/apt/sources.list "$APT_BACKUP_DIR"/ 2>/dev/null || true
cp -a /etc/apt/sources.list.d "$APT_BACKUP_DIR"/ 2>/dev/null || true
cleanup_nonlist_sources

# Remove any *.sources referencing Enterprise
for s in /etc/apt/sources.list.d/*.sources; do
  [[ -f "$s" ]] || continue
  grep -qi 'enterprise\.proxmox\.com' "$s" && { msg " -> removing: $s"; sink "$s"; }
done
# Remove typical filenames
sink /etc/apt/sources.list.d/pve-enterprise.sources
sink /etc/apt/sources.list.d/pve-enterprise.list

# For *.list with Enterprise: comment lines or remove if Enterprise-only
for l in /etc/apt/sources.list.d/*.list; do
  [[ -f "$l" ]] || continue
  if grep -qi 'enterprise\.proxmox\.com' "$l"; then
    if awk 'BEGIN{IGNORECASE=1} /^[[:space:]]*deb/ && $0 !~ /enterprise\.proxmox\.com/ {ok=1} END{exit ok?0:1}' "$l"; then
      msg " -> commenting Enterprise lines in: $l"
      sed -ri 's|^\s*deb\s+https?://enterprise\.proxmox\.com|#DISABLED-BY-SCRIPT &|I' "$l"
    else
      msg " -> removing Enterprise-only list: $l"
      sink "$l"
    fi
  fi
done

# Comment Enterprise in main sources.list
[[ -f /etc/apt/sources.list ]] && sed -ri 's|^\s*deb\s+https?://enterprise\.proxmox\.com|#DISABLED-BY-SCRIPT &|I' /etc/apt/sources.list || true

# Diversions + disabled deb822 file (with example.invalid), then re-clean any .distrib/.bak
divert_add /etc/apt/sources.list.d/pve-enterprise.list
divert_add /etc/apt/sources.list.d/pve-enterprise.sources
write_disabled_enterprise_sources
cleanup_nonlist_sources
verify_no_enterprise

# 1) Sanity checks
if [[ $EUID -ne 0 ]]; then die "Run as root."; fi
if ! command -v pveversion >/dev/null 2>&1; then die "Not a Proxmox VE host."; fi
CUR_VER_RAW="$(pveversion || true)"; msg "Current pveversion: $CUR_VER_RAW"
if ! echo "$CUR_VER_RAW" | grep -qE 'pve-manager/8\.'; then
  msg "Expected Proxmox 8.x. Detected: $CUR_VER_RAW"
  [[ "$FORCE_UPGRADE" == "1" ]] || die "Set FORCE_UPGRADE=1 to override."
fi

# BEFORE snapshot
{
  echo; echo "===== BEFORE UPGRADE ====="; date
  echo "# uname -a"; uname -a || true
  echo; echo "# pveversion"; pveversion || true
  echo; echo "# qm list"; qm list || true
  echo; echo "# pct list"; pct list || true
} >> "$LOG" 2>&1

# 2) pve8to9 precheck (robust)
run_pve8to9_precheck

# 3) Keyring + initial apt refresh
apt-get update -y >> "$LOG" 2>&1 || true
apt-get install -y proxmox-archive-keyring >> "$LOG" 2>&1 || true
verify_no_enterprise
cleanup_nonlist_sources

# 4) Switch bookworm -> trixie
msg "Switching Debian repositories: bookworm -> trixie ..."
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list || true
find /etc/apt/sources.list.d -maxdepth 1 -type f -exec sed -i 's/bookworm/trixie/g' {} \; || true

# 5) Ensure single no-subscription entry
sed -ri '/download\.proxmox\.com\/debian\/pve.*pve-no-subscription/s/^/#DUPLICATE-BY-SCRIPT /' /etc/apt/sources.list || true
for l in /etc/apt/sources.list.d/*.list; do
  [[ -f "$l" ]] || continue
  [[ "$l" == "/etc/apt/sources.list.d/pve-no-subscription.list" ]] && continue
  sed -ri '/download\.proxmox\.com\/debian\/pve.*pve-no-subscription/s/^/#DUPLICATE-BY-SCRIPT /' "$l" || true
done
cat > /etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb http://download.proxmox.com/debian/pve trixie pve-no-subscription
EOF
chmod 0644 /etc/apt/sources.list.d/pve-no-subscription.list

verify_no_enterprise
cleanup_nonlist_sources

# 6) Full non-interactive upgrade
msg "Running apt-get update + non-interactive upgrade/dist-upgrade..."
TMPU="$(mktemp)"
apt-get update 2>&1 | tee -a "$LOG" | tee "$TMPU" >/dev/null
if grep -q 'enterprise\.proxmox\.com' "$TMPU"; then rm -f "$TMPU"; die "APT tried to reach Enterprise during update."; fi
rm -f "$TMPU"

apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" upgrade -y | tee -a "$LOG"
apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade -y | tee -a "$LOG"

# Second cleanup pass
cleanup_nonlist_sources

apt-get autoremove -y | tee -a "$LOG" || true
apt-get update -y >> "$LOG" 2>&1 || true

# 7) One-shot post-boot verification
POST_SH="/root/pve-postcheck.sh"
POST_SVC="/etc/systemd/system/pve-upgrade-postcheck.service"
cat > "$POST_SH" <<'EOS'
#!/bin/bash
set -euo pipefail
LOG_FILE="/root/pve-upgrade-post-$(date +%Y%m%d-%H%M%S).log"
{
  echo "===== AFTER UPGRADE (first boot) ====="; date
  echo "# uname -a"; uname -a || true
  echo; echo "# pveversion"; pveversion || true
  echo; echo "# apt policy (trixie check)"; apt-cache policy | sed -n '1,120p' || true
} >> "$LOG_FILE" 2>&1
systemctl disable --now pve-upgrade-postcheck.service >/dev/null 2>&1 || true
rm -f /root/pve-postcheck.sh
EOS
chmod +x "$POST_SH"
cat > "$POST_SVC" <<'EOS'
[Unit]
Description=Proxmox upgrade post-check (one-shot)
After=multi-user.target pvedaemon.service pve-cluster.service
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/bin/bash /root/pve-postcheck.sh
[Install]
WantedBy=multi-user.target
EOS
systemctl daemon-reload
systemctl enable pve-upgrade-postcheck.service >> "$LOG" 2>&1 || true

# 8) Pre-reboot snapshot
{
  echo; echo "===== PRE-REBOOT SNAPSHOT ====="; date
  echo "# Installed pve kernels:"; dpkg -l | grep -E '^ii\s+pve-kernel' | sort -V || true
} >> "$LOG" 2>&1

msg "Upgrade phase completed. Log: $LOG"
if [[ "$NO_REBOOT" == "1" ]]; then
  msg "NO_REBOOT=1 set — skipping reboot. Please reboot manually."
else
  msg "Rebooting now to complete the upgrade..."
  sleep 3
  reboot
fi

Below is the full content of the script for reference. It is recommended to download the latest version from the link above to ensure you have the most up-to-date fixes.

Post-upgrade verification

pveversion

Expected output should look like:

pve-manager/9.x.x/xxxxxxxx (running kernel: 6.x.x-x-pve)
Check the running kernel version:

uname -a

Review the upgrade log to confirm no errors occurred:

less /root/pve-upgrade-*.log

If you used the post-check service created by the script, you can view its results:

less /root/pve-upgrade-post-*.log

Artykuł How to Upgrade Proxmox VE 8.x to 9.0 (Debian 12 to Debian 13) – Step-by-Step with Script pochodzi z serwisu soban.

Dynamic Tmux Window Titles with SSH and Hostname

soban — Tue, 15 Apr 2025 14:55:56 +0000

Want your Tmux window titles to automatically show the hostname you connect to via SSH — and restore the local name after you disconnect? This guide will walk you through setting that up step by step.

1. Tmux configuration – ~/.tmux.conf

In your Tmux configuration file, set the default shell command to a custom Bash init file (.bash_tmux) that will handle window title updates.

set-option -g default-command 'bash --rcfile ~/.bash_tmux'

2. Bash init script – ~/.bash_tmux

This file runs at shell startup inside Tmux. It sets the window name to your local hostname and overrides the ssh command to change the window title dynamically.

#!/bin/bash
# ~/.bash_tmux
# Custom Bash init file for Tmux sessions with dynamic tab naming

# Override the default ssh command to dynamically rename the Tmux window
ssh() {
  if [ -n "$TMUX" ]; then
    # Loop through arguments to find the target host (first non-flag argument)
    for arg in "$@"; do
      if [[ "$arg" != -* ]]; then
        if [[ "$arg" == *@* ]]; then
          host="${arg#*@}"  # extract host from user@host
        else
          host="$arg"
        fi
        break
      fi
    done

    # Strip any trailing junk or whitespace
    host="$(echo "$host" | cut -d' ' -f1)"

    # Rename the Tmux window to the SSH target
    [ -n "$host" ] && tmux rename-window "$host"

    # Save the local hostname to restore later
    local_host="$(hostname -s)"

    # Run the actual SSH command
    command ssh "$@"

    # Restore the original window name after logout
    tmux rename-window "$local_host"
  else
    # Not in Tmux — just run ssh normally
    command ssh "$@"
  fi
}

# Load the user's regular bash configuration
source ~/.bashrc

# On shell start, if in Tmux, set the window name to the current hostname
if [ -n "$TMUX" ]; then
  tmux rename-window "$(hostname -s)"
fi

3. Reload Tmux config without restarting

To apply the changes without restarting the Tmux session, run the following:

tmux source-file ~/.tmux.conf

To manually reload the current shell with the new .bash_tmux configuration:

exec bash --rcfile ~/.bash_tmux

4. Final result

New Tmux windows automatically show the local hostname
When connecting via SSH, the window is renamed to the remote host
When disconnecting, the original local name is restored

Clean, readable, and perfect for sysadmins, devops engineers, and Tmux lovers who appreciate automatic order in their terminal tabs 💪

Artykuł Dynamic Tmux Window Titles with SSH and Hostname pochodzi z serwisu soban.

The most important Linux commands that every user should know

soban — Thu, 20 Feb 2025 10:56:30 +0000

The Linux system is a powerful tool that offers users tremendous flexibility and control over their working environment. However, to fully harness its potential, it is worth knowing the key commands that are essential for both beginners and advanced users. In this article, we will present and discuss the most important Linux commands that every user should know.

1. Basic Navigation Commands

pwd – Displays the current directory path you are in:

pwd

ls – Lists the contents of a directory. You can use the -l option for a detailed view or -a to show hidden files:

ls -a

cd – Changes the directory. For example, cd /home/user will move you to the /home/user directory:

cd ~

mkdir – Creates a new directory:

mkdir projects

rmdir – Removes an empty directory:

rmdir old_files

2. File Management

cp – Copies files or directories:

cp document.txt new_directory/

mv – Moves or renames files/directories:

mv file.txt /home/user/new_directory/

rm – Removes files or directories. Use the -r option to remove a directory with its contents:

rm -r old_data

touch – Creates an empty file or updates the modification time of an existing file:

touch report.txt

3. Process Management

ps – Displays currently running processes. Use the -aux option to see all processes:

ps -aux

top – Displays a dynamic list of processes in real time:

top

kill – Stops a process by its ID:

kill 1234

bg and fg – Manage background and foreground processes:

fg

4. User and Permission Management

sudo – Allows a command to be executed with administrator privileges:

sudo apt update

chmod – Changes permissions for files/directories:

chmod 755 script.sh

chown – Changes the owner of a file/directory:

chown admin:admin file.txt

useradd and userdel – Adds and removes users:

useradd janek

5. Networking and Communication

ping – Checks the connection with another host:

ping 192.168.1.1

ifconfig – Displays information about network interfaces:

ifconfig

ssh – Connects remotely to another computer:

ssh user@192.168.1.2

scp – Copies files over SSH:

scp file.txt user@host:/home/user/

6. Command Usage Examples

Below is an example of using several discussed commands:

chmod – Changes permissions for files/directories:

chmod 755 script.sh

chown – Changes the owner of a file/directory:

chown admin:developers logs.txt

useradd and userdel – Adds and removes users:

useradd janek

7. Disk and File System Management

df – Displays information about disk space availability:

df -h

du – Shows the size of files and directories:

du -sh documents

mount – Mounts a file system:

mount /dev/sdb1 /mnt/external

umount – Unmounts a file system:

umount /mnt/external

8. Searching for Files

find – Searches for files in the system:
locate – Quickly searches for files in the system:
grep – Searches for patterns in files:
which – Finds the full path to an executable file:

9. Communicating with the System

echo – Displays text on the screen:
cat – Displays the contents of a file:
more – Displays the contents of a file page by page:
less – Similar to more, but offers more navigation options:
man – Displays the user manual for a command:

10. Working with Archives

tar – Creates or extracts archives:
zip – Creates a ZIP archive:
unzip – Extracts ZIP files:
tar -xvzf – Extracts a TAR.GZ archive:
gzip – Compresses files in .gz format:
gunzip – Extracts .gz files:

11. System Monitoring

uptime – Displays the system uptime and load:
dmesg – Displays system messages related to boot and hardware:
iostat – Shows input/output system statistics:
free – Displays information about RAM:
netstat – Displays information about network connections:
ss – A modern version of netstat, used for monitoring network connections:

12. Working with System Logs

journalctl – Reviews system logs:
tail – Displays the last lines of a file:
logrotate – Automatically manages logs:

13. Advanced File Operations

ln – Creates a link to a file:
xargs – Passes arguments from input to other commands:
chmod – Changes permissions for files/directories:
chattr – Changes file attributes:

Linux offers a wide array of commands that allow for complete control over the computer. Key commands such as ls, cd, cp, and rm are used daily to navigate through the file system, manage files, and directories. To effectively master these commands, it’s best to start with those that are most useful in everyday work. For instance, commands for navigating directories and managing files are fundamental and require practice to become intuitive. Other commands, such as ps for monitoring processes, ping for testing network connections, or chmod for changing permissions, are also worth knowing to fully leverage the power of the Linux system.

To learn effectively, it’s advisable to start by experimenting with commands in practice. Creating files, directories, copying, and deleting data allows for familiarity with their operation. Over time, it’s worthwhile to start combining different commands to solve more advanced problems, such as monitoring processes, managing users, or working with system logs. One can also use documentation, such as man or websites, to delve into the details of each command and its options.

Remember, regular use of the terminal allows for learning habits that make handling the Linux system more natural. Frequent use of commands, solving problems, and experimenting with new commands is the best way to master the system and fully utilize it.

Linux is indeed a powerful tool that provides great control over the system… but remember, don’t experiment on production! After all, experimenting on a production server is a bit like playing Russian roulette — only with bigger consequences. If you want to feel like a true Linux wizard, always test your commands in a development environment. Only then will you be able to learn from mistakes instead of searching for the cause of several gigabytes of data disappearance. And if you don’t know what you’re doing, simply summon your trusty weapon: man!

Artykuł The most important Linux commands that every user should know pochodzi z serwisu soban.