Jeśli korzystasz z serwera Linux z Nginx, SSH lub WordPressem, prawdopodobnie znasz już Fail2Ban. Jest to dobre narzędzie, ale działa lokalnie — blokuje tylko adresy IP, które zaatakowały Twój serwer.

CrowdSec działa zupełnie inaczej. To system ochrony oparty o współdzieloną reputację IP. Jeśli tysiące serwerów na świecie wykryją atakujące IP, Twój serwer może je zablokować zanim jeszcze spróbują ataku.

Jak działa CrowdSec?

• analizuje logi systemowe (nginx, ssh, wordpress)
• wykrywa podejrzane zachowanie
• wymienia informacje o atakujących IP z innymi serwerami
• blokuje ruch na poziomie firewalla

Efekt? Większość botów i skanerów internetu nigdy nie dociera do Twojego Nginxa.

Instalacja CrowdSec na Debian / Ubuntu

Instalacja CrowdSec jest bardzo prosta i dostępna bezpośrednio z repozytoriów Debiana.

apt update
apt install crowdsec

Podczas instalacji CrowdSec automatycznie:

• tworzy lokalne API (LAPI)
• rejestruje serwer w CrowdSec Central API
• pobiera podstawowe scenariusze bezpieczeństwa

Instalacja firewall bouncer

CrowdSec sam wykrywa zagrożenia, ale potrzebuje komponentu wykonawczego — tzw. bouncera, który blokuje ruch w firewallu.

apt install crowdsec-firewall-bouncer

Domyślnie bouncer korzysta z nftables i automatycznie dodaje reguły blokujące adresy IP.

Instalacja kolekcji bezpieczeństwa

Kolekcje zawierają parsery logów oraz scenariusze wykrywania ataków.

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

Po instalacji przeładuj konfigurację:

systemctl reload crowdsec

Konfiguracja logów Nginx

Aby CrowdSec analizował ruch HTTP, należy wskazać logi Nginx.

Edytuj plik:

nano /etc/crowdsec/acquis.yaml

Dodaj konfigurację:

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

Następnie uruchom ponownie usługę:

systemctl restart crowdsec

Sprawdzenie działania CrowdSec

Status usługi:

systemctl status crowdsec

Lista aktywnych banów:

cscli decisions list

Statystyki działania:

cscli metrics

Efekt końcowy

Po poprawnej instalacji CrowdSec:

• serwer automatycznie blokuje znane botnety
• ataki WordPress i brute-force SSH są zatrzymywane na firewallu
• Nginx obsługuje mniej złośliwego ruchu
• CPU i IO serwera są znacząco odciążone

CrowdSec można traktować jako ewolucję Fail2Ban — system, który nie tylko reaguje lokalnie, ale korzysta z globalnej inteligencji zagrożeń.

Artykuł CrowdSec – dodatkowa ochrona serwera Linux, Nginx i SSH przed botami oraz atakami brute-force pochodzi z serwisu soban.

Jeśli korzystasz z Fail2Ban przy Nginx i WordPress, to prędzej czy później zauważysz jedną rzecz: te same adresy IP wracają. Dostają bana na kilka minut albo godzinę, znikają… i po chwili znowu próbują /.env, /wp-login.php, /phpmyadmin czy inne popularne ścieżki ataku.

Rozwiązaniem nie jest agresywne podkręcanie filtrów. Rozwiązaniem jest recidive — drugi poziom ochrony w Fail2Ban, który analizuje historię banów i długoterminowo blokuje recydywistów.

Nawiązanie do wcześniejszej konfiguracji

Jeśli nie masz jeszcze podstawowej konfiguracji Fail2Ban dla Nginx i WordPress, opisałem ją tutaj:

Fail2Ban + Nginx + WordPress – konfiguracja podstawowa

W tamtym artykule konfigurujemy jail’e typu nginx-exploit, nginx-secure czy sshd. Recidive nie zastępuje tej konfiguracji — on ją wzmacnia.

Jak znaleźć recydywistów w logach

Najpierw warto sprawdzić, czy problem faktycznie występuje. Wyciągamy z logów Fail2Ban listę IP, które były banowane najczęściej:

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

Przykładowy wynik (adresy częściowo anonimizowane):

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

Jeśli widzisz liczby typu 8, 9, 13 — to znaczy, że te IP wracają po zdjęciu bana. Krótki bantime jest dla nich tylko przerwą techniczną.

Dlaczego recidive jest lepszy niż zwiększanie bantime

• Nie musisz banować każdego na 24h za jedną literówkę w URL.
• Nie zwiększasz ryzyka blokady normalnych użytkowników.
• Kara jest progresywna i dotyczy tylko powracających adresów.

Recidive analizuje /var/log/fail2ban.log i liczy, ile razy dane IP zostało zbanowane przez inne jail’e. Dzięki temu “dobić” można tylko tych, którzy już wcześniej wielokrotnie trafiali na blokadę.

Konfiguracja recidive (5 banów w 24h = 7 dni bana)

Dodaj poniższy blok do /etc/fail2ban/jail.local:

nano /etc/fail2ban/jail.local

Na końcu pliku wklej:

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

Zapisz plik i zrestartuj Fail2Ban:

systemctl restart fail2ban

Sprawdź status jaila:

fail2ban-client status recidive

Jak sprawdzić kto jest blisko progu recidive

Jeśli chcesz zobaczyć IP, które już mają kilka banów i zbliżają się do progu recidive:

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

Podsumowanie

Recidive to jeden z najprostszych i najbardziej skutecznych sposobów na ograniczenie powracających skanerów i botów. Zamiast agresywnie banować wszystkich — blokujesz tylko tych, którzy wracają wielokrotnie.

W środowisku z wieloma domenami, Nginx reverse proxy i WordPress to praktycznie obowiązkowy element konfiguracji: mniej szumu w logach, mniej powtarzalnych ataków i mniej ręcznej analizy.

Artykuł Fail2Ban: jak wyłapać recydywistów i banować ich na tydzień (recidive) pochodzi z serwisu soban.

Proxmox VE 9 bazuje na Debianie 13 (Trixie) i wprowadza nowsze jądro systemu, zaktualizowane LXC, QEMU oraz ulepszony stos wirtualizacji. Ten poradnik przedstawia uproszczoną i zautomatyzowaną metodę instalacji Proxmox VE 9 na czystym systemie Debian 13 przy użyciu dwóch skryptów instalacyjnych.

Metoda opiera się na tym samym podejściu, co mój wcześniejszy poradnik instalacji Proxmox 8 na Debianie 12, ale została dostosowana do Debiana 13 oraz Proxmox VE 9.

Wymagania wstępne

• Świeża instalacja Debian 13 (Trixie)
• Dostęp root
• Połączenie z Internetem

Wszystkie polecenia należy wykonywać jako użytkownik root.

Część 1 – Przygotowanie systemu i instalacja jądra Proxmox

Pobierz pierwszy skrypt:

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

Ten skrypt:

• Ustawia hostname i aktualizuje plik /etc/hosts
• Instaluje keyring archiwum Proxmox (weryfikowany przez SHA512)
• Dodaje repozytorium Proxmox VE 9 dla Debian 13
• Wykonuje pełną aktualizację systemu
• Instaluje proxmox-default-kernel
• Restartuje system

Zawartość 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 <

Część 2 – Instalacja Proxmox VE 9

Po restarcie pobierz i uruchom:

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

Zawartość 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"
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)"
apt remove -y linux-image-amd64 || true

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"

Dostęp do interfejsu webowego

Po zakończeniu działania drugiego skryptu otwórz:

https://YOUR_SERVER_IP:8006

Zaloguj się użytkownikiem root oraz swoim hasłem roota. Możesz zobaczyć ostrzeżenie o certyfikacie — jest to normalne przy świeżych instalacjach.

Rozwiązywanie problemów – błąd 401 Unauthorized (repozytorium pve-enterprise)

Jeśli po instalacji lub podczas wykonywania apt update pojawi się następujący błąd:

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.

Oznacza to, że aktywne jest repozytorium enterprise, ale system nie posiada ważnej subskrypcji Proxmox. W tym poradniku korzystamy z repozytorium pve-no-subscription, więc należy wyłączyć repozytorium enterprise.

Naprawa jest bardzo prosta – wykonaj:

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

apt update

Po wyłączeniu repozytorium aktualizacja powinna zakończyć się poprawnie:

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

Jeśli wszystko jest w porządku, zobaczysz komunikat:

All packages are up to date.

Podsumowanie

Ta metoda zapewnia czysty i kontrolowany sposób wdrożenia Proxmox VE 9 bezpośrednio na Debianie 13, bez używania instalatora ISO. Jest szczególnie przydatna w środowiskach zautomatyzowanych, laboratoriach oraz niestandardowych konfiguracjach infrastruktury.

Artykuł Debian 13 (Trixie) → Proxmox VE 9 – Uproszczona instalacja na czystym Debianie pochodzi z serwisu soban.

Ten poradnik pokazuje kompletną instalację i konfigurację Fail2Ban dla Nginx, zaprojektowaną tak, aby:

• blokować rzeczywiste skanery i próby exploitów (np. żądania do /.env, /.git, /phpmyadmin itp.),
• unikać przypadkowego blokowania administratorów (częsty problem przy banowaniu wyłącznie na podstawie błędów HTTP),
• blokować adresy IP dopiero po powtarzającej się podejrzanej aktywności,
• stosować krótki czas bana (5 minut), aby zmniejszyć ryzyko zablokowania samego siebie.

Dlaczego banowanie wyłącznie na podstawie błędów HTTP może być problematyczne

Wiele poradników sugeruje blokowanie adresów IP jedynie na podstawie kodów statusu HTTP (4xx/499). W praktyce bardzo często prowadzi to do samoblokady, ponieważ nowoczesne aplikacje generują serie zapytań (AJAX, panel administracyjny, przebudowa cache), przez co podczas normalnej pracy mogą pojawiać się błędy HTTP.

Ta konfiguracja wykorzystuje bezpieczniejsze podejście:

• ścieżki exploitów są zawsze traktowane jako podejrzane,
• błędy HTTP są liczone tylko wtedy, gdy zapytanie nie posiada nagłówka Referer (typowe zachowanie skanerów),
• znane złośliwe User-Agenty są uwzględniane.

Krok 1: Instalacja Fail2Ban

Zainstaluj Fail2Ban:

apt update
apt install -y fail2ban

Włącz oraz uruchom usługę:

systemctl enable fail2ban
systemctl start fail2ban

Sprawdź status działania:

fail2ban-client ping
systemctl status fail2ban

Krok 2: Utworzenie filtra nginx-secure

Utwórz plik filtra:

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

Wklej poniższą konfigurację:

[Definition]

failregex =
    ^<HOST> - .* "(?: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} .*

    ^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) [^"]*" (?:400|403|404|405|408|413|414|429|444) [^"]* "-" ".*"

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

ignoreregex =

Krok 3: Utworzenie jail nginx-secure

Utwórz plik konfiguracji jail:

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

Wklej konfigurację:

[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

Krok 4: Restart Fail2Ban

fail2ban-server -t
systemctl restart fail2ban

Krok 5: Sprawdzenie integracji z firewallem

Sprawdź czy łańcuch Fail2Ban istnieje:

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

Test z zewnętrznej maszyny

Test ścieżki exploita:

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

Test logiki błędów bez Referer:

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

Po wykryciu powtarzających się podejrzanych żądań adres IP zostanie zablokowany na 5 minut.

Sprawdzenie zbanowanych adresów IP

fail2ban-client status nginx-secure

Odblokowanie adresu IP

Ręczne zdjęcie bana:

fail2ban-client set nginx-secure unbanip YOUR_IP

Podsumowanie

• blokuje rzeczywiste próby exploitów i skanery,
• minimalizuje ryzyko samoblokady administratora,
• stosuje krótki 5-minutowy ban,
• działa z iptables-nft,
• łatwy test oraz szybkie odblokowanie adresu IP.

Artykuł Konfiguracja Fail2Ban dla Nginx – blokowanie skanerów i exploitów bez blokowania administratora WordPress pochodzi z serwisu soban.

Upgrade Debiana z wersji 12 (bookworm) do 13 (trixie) to operacja, która na serwerach i kontenerach (np. Proxmox LXC / VM) powinna być robiona powtarzalnie i bez niespodzianek. Poniżej masz prosty poradnik oraz gotowe komendy do pobrania i uruchomienia skryptu.

Zanim odpalisz upgrade: zrób backup / snapshot. W Proxmoxie najlepiej vzdump lub snapshot. Na bare-metal chociaż kopia /etc, aplikacji i baz danych.

• Proxmox LXC / VM: backup (vzdump) albo snapshot.
• Serwer: backup /etc, /var/www, bazy danych (MySQL/PostgreSQL), certyfikaty SSL.

Skrypt do pobrania:

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

1) Backup przed upgradem (przykłady)

Przykład backupu w Proxmox (na hoście Proxmox, podmień CTID/VMID):

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

Przykład prostego backupu katalogów na serwerze (to nie zastąpi pełnego snapshotu, ale lepsze to niż nic):

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

2) Pobranie skryptu (wget / curl)

Najprościej: użyj wget. Jeśli komenda wget nie działa mimo zainstalowanego pakietu, użyj wariantu z pełną ścieżką /usr/bin/wget.

Wariant A (standardowy 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

Wariant B (wget z pełną ścieżką – pomaga gdy PATH jest skopany):

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

Wariant 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) Pomoc skryptu (parametry)

Zanim odpalisz upgrade, zobacz listę parametrów i przykłady użycia:

cd /root
./upgrade_to_debian13.sh --help

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

Jeśli jesteś na Debian 12 (bookworm) i chcesz wykonać tylko upgrade systemu:

cd /root
./upgrade_to_debian13.sh

Skrypt zrobi backup /etc/apt/sources.list, podmieni repozytoria na trixie, wykona apt update oraz apt full-upgrade, a na końcu autoremove i autoclean.

5) Auto-detekcja PHP/nginx i aktualizacja jeśli potrzeba

Jeśli kontener/VM jest webowy i chcesz, żeby skrypt sam wykrył użycie PHP (nginx + fastcgi_pass) i w razie potrzeby zaktualizował PHP oraz nginx:

cd /root
./upgrade_to_debian13.sh --auto

6) Wymuszona aktualizacja PHP i nginx (PHP-FPM socket fix)

Jeśli chcesz wymusić instalację/upgrade PHP oraz automatyczne przestawienie konfiguracji nginx na poprawny socket PHP-FPM:

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

To polecenie instaluje PHP 8.2 (php-fpm + popularne moduły) i podmienia w konfiguracjach nginx stare ścieżki socketów na /run/php/php8.2-fpm.sock. Następnie wykonuje nginx -t oraz restart/reload usług.

7) Debian 13 już jest? Tryb tylko PHP/nginx (bez release upgrade)

Jeżeli system jest już na Debian 13 (trixie) i chcesz wykonać tylko aktualizację PHP/nginx bez ruszania repozytoriów systemowych:

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

8) Tryb testowy (dry-run)

Jeśli chcesz zobaczyć co skrypt zrobi, ale bez wykonywania zmian:

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

9) Diagnostyka: wget jest zainstalowany, a nie działa

Jeżeli apt mówi, że wget jest zainstalowany, a shell krzyczy command not found, to najczęściej problem z PATH. Najprostsza obejściówka to użycie pełnej ścieżki: /usr/bin/wget.

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

Podsumowanie

To rozwiązanie jest wygodne, bo w jednym miejscu masz upgrade Debian 12 → Debian 13 oraz (opcjonalnie) ogarnięcie problemów z PHP/nginx po upgrade (socket PHP-FPM, test konfiguracji nginx i restart usług). Najważniejsze: zrób backup przed upgradem i zawsze zacznij od --help, żeby widzieć dostępne opcje.

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

Artykuł Automatyczny upgrade Debian 12 → Debian 13 z opcjonalną aktualizacją PHP i nginx pochodzi z serwisu soban.

Proxmox: Automatyczne aktualizacje VM (qm + vzdump) z testami sieci i auto-przywracaniem

W tym artykule opisuję prosty (ale bardzo skuteczny) skrypt automatyzujący aktualizacje maszyn wirtualnych na Proxmox VE. Skrypt potrafi:

• utworzyć backup maszyny (opcjonalnie),
• uruchomić VM, jeśli wcześniej była wyłączona,
• zrobić pełny upgrade systemu przez apt i wykonać reboot,
• zrobić testy sieciowe przed i po aktualizacji,
• w razie problemów automatycznie przywrócić VM z backupu (opcjonalnie),
• na końcu wyłączyć VM, jeśli wcześniej była wyłączona.

Skąd pobrać skrypt

Skrypt możesz pobrać bezpośrednio z mojej strony:

soban.pl/bash/upgrade_proxmox_qm.sh

Wymagane katalogi

Zanim uruchomisz automatyzację, utwórz dwa katalogi: jeden na skrypty i jeden na logi:

mkdir -p /root/automate_scripts /root/logs

Instalacja skryptu

Pobierz skrypt do /root/automate_scripts/ i nadaj mu prawa wykonywania:

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

Jak to działa (w skrócie)

• Najpierw wykonywany jest backup (vzdump snapshot + zstd) – jeśli backup jest włączony.
• Jeśli VM była stopped, skrypt ją uruchamia i czeka WAIT_TIME sekund.
• Następnie wykonywane są testy sieciowe PRZED aktualizacją:
• Skrypt wykonuje apt update/upgrade/dist-upgrade/autoremove/clean i na końcu robi reboot VM.
• Po reboocie czeka ponownie (WAIT_TIME) i uruchamia te same testy PO aktualizacji.
• Jeśli testy nie przejdą i istnieje backup, skrypt wykonuje qmrestore automatycznie.
• Na końcu (opcjonalnie) wyłącza VM, jeśli wcześniej była wyłączona.

Uruchomienie (manualnie)

Skrypt przyjmuje dokładnie dwa argumenty:

• VMID – ID maszyny wirtualnej na Proxmox
• TIME_SEC – czas oczekiwania po starcie/reboocie (w sekundach)

/root/automate_scripts/upgrade_proxmox_qm.sh 901 500

Wskazówka: dobierz WAIT_TIME do realnego czasu bootowania VM oraz czasu trwania aktualizacji. Najczęściej sprawdza się 300 do 1000 sekund (zależnie od maszyny).

Pełny skrypt (do wklejenia / podglądu)

Poniżej wrzucam całość w jednym miejscu – dokładnie w takiej formie, w jakiej jest używana w tej automatyzacji:

#!/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 <VMID> <TIME_SEC>"
    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 (harmonogram tygodniowy + osobne logi per VM)

Poniżej masz przykład crontaba, który uruchamia aktualizacje raz w tygodniu (inna VM każdego dnia roboczego) i zapisuje logi do osobnych plików w /root/logs/.

Edytuj crona roota:

crontab -e

Wklej reguły (komentarze są po angielsku):

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)

Szybkie checklisty / troubleshooting

• Upewnij się, że root z hosta Proxmox może łączyć się po SSH do VM po hostname (skrypt używa ssh root@<vm-hostname>).
• Sprawdź czy DNS (albo /etc/hosts) poprawnie rozwiązuje hostname VM na hoście Proxmox.
• Jeśli apt potrafi pytać o potwierdzenia, zadbaj o tryb non-interactive albo „trzymaj” pakiety, które robią problemy podczas upgrade.

To wszystko. Umieść skrypt w /root/automate_scripts/, wyślij logi do /root/logs/, a cotygodniowa konserwacja maszyny wirtualnej stanie się praktycznie niezauważalna.

Artykuł Proxmox Automatyczne aktualizacje VM (qm + vzdump) z testami sieci i auto-przywracaniem pochodzi z serwisu soban.

Jeśli próbujesz aktualizować firmware stacji dokującej Dell WD19/WD19S na Proxmoxie (albo Debianie) przez fwupdmgr, możesz trafić na klasyczny błąd typu Operation timed out podczas etapu Erasing…. W praktyce update sypie się przez zarządzanie energią USB (autosuspend). Poniżej masz prosty, skuteczny fix oraz gotowy skrypt do odpalenia na serwerze/laptopie.

Objawy problemu

Najczęściej w trakcie aktualizacji docka (WD19/WD19S) pojawia się błąd podobny do:

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

Wtedy fwupdmgr może pokazywać urządzenie WD19S jako Update State: Failed albo stale informować o pending activation, ale sam flash nie przechodzi do końca.

Dlaczego tak się dzieje?

Dock podczas flashowania wykonuje długie operacje, a gdy system próbuje oszczędzać energię na USB (autosuspend), kontrolne transfery USB mogą się wysypywać. Efekt: timeout dokładnie na etapie kasowania banku flash (erase bank).

Szybki fix: wyłącz autosuspend USB na czas aktualizacji

Najprostsze rozwiązanie to tymczasowe ustawienie autosuspend na -1 (czyli wyłączenie). To ustawienie obowiązuje do rebootu (chyba że zrobisz je na stałe w kernel cmdline), ale w zupełności wystarczy na czas update.

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

Następnie uruchom aktualizację:

fwupdmgr refresh --force
fwupdmgr update

Po update: „pending activation” i wymagane odłączenie kabla

Po udanej instalacji firmware dla WD19/WD19S fwupdmgr często wypisuje komunikat:

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

Wtedy zrób to w tej kolejności:

• Odłącz kabel USB-C od docka (od laptopa).
• (Opcjonalnie) Odłącz zasilanie docka na 10–15 sekund i podepnij ponownie.
• Podepnij USB-C z powrotem.
• Wykonaj aktywację:

fwupdmgr activate

Na końcu sprawdź status:

fwupdmgr get-updates
fwupdmgr get-devices | less

Gotowy skrypt: install + update + wyłączenie autosuspend (z restore)

Poniżej masz gotowy skrypt, który:

• instaluje fwupd
• odświeża metadane LVFS
• tymczasowo wyłącza autosuspend USB (żeby WD19S nie wywalał timeoutów)
• uruchamia aktualizacje
• przywraca poprzednią wartość autosuspend po zakończeniu (nawet jeśli update się wywali)

Skrypt możesz wkleić ręcznie z artykułu, ale jeśli wolisz szybciej: możesz go pobrać bezpośrednio z:

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

Przykład pobrania i uruchomienia:

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

Jeśli chcesz, możesz też podejrzeć treść przed uruchomieniem:

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

Jeżeli nie masz less w systemie:

apt update
apt install -y less

Skrypt (pełna treść)

#!/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 "Czy chcesz zaktualizowac wszystkie urzadzenia? (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."

Uruchomienie skryptu

Najprościej:

chmod +x dell_updage.sh
./dell_updage.sh

Najczęstsze pytania i tipy

• Update dalej się sypie? Odłącz wszystkie peryferia od docka (monitory/LAN/USB), zostaw tylko zasilanie i USB-C, zrób hard reset docka (odłącz prąd na 30s) i spróbuj ponownie.
• „pending activation” po update – to normalne dla WD19/WD19S. Musisz wypiąć USB-C, podpiąć ponownie i zrobić fwupdmgr activate.
• To aktualizuje BIOS laptopa? Nie zawsze. fwupdmgr pokaże osobno „System Firmware” (BIOS/UEFI) i osobno dock. W tym artykule skupiamy się na docku i problemie z USB timeout.

Podsumowanie

Jeśli firmware Dell WD19/WD19S wywala się na Proxmox/Debian podczas Erasing…, to w większości przypadków wystarczy na czas aktualizacji wyłączyć autosuspend USB. Skrypt powyżej robi to automatycznie, a potem przywraca poprzednie ustawienie, żeby system dalej działał normalnie.

Artykuł Dell WD19/WD19S: aktualizacja firmware na Proxmox/Debian bez timeoutów USB (fwupd + autosuspend fix) pochodzi z serwisu soban.

Wprowadzenie

Proxmox VE 9.0 (oparty na Debian 13 „Trixie”) został wydany i przynosi zaktualizowane pakiety, nowy kernel oraz ulepszoną stabilność. Ten poradnik przeprowadzi Cię przez aktualizację w miejscu z Proxmox VE 8.4.x (Debian 12 „Bookworm”) do Proxmox VE 9.0.

Proces będzie zautomatyzowany przy użyciu gotowego skryptu aktualizacyjnego, który:

• Sprawdza aktualną wersję
• Uruchamia pve8to9 w celu weryfikacji przed aktualizacją
• Tworzy kopię zapasową źródeł APT
• Aktualizuje repozytoria z Bookworm do Trixie
• Wykonuje pełny dist-upgrade
• Loguje wszystkie zmiany przed i po aktualizacji

Pobranie i uruchomienie skryptu aktualizacyjnego

Możesz pobrać gotowy skrypt aktualizacyjny bezpośrednio z naszego serwera, nadać mu uprawnienia i uruchomić:

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
/root/upgrade-pve8-to-9.sh

Jeśli stracisz połączenie (a to może się zdarzyć podczas aktualizacji Proxmoxa), możesz śledzić logi poleceniem:

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

Spokojnie poczekaj, aż skrypt zakończy działanie — może to potrwać.

Pełny kod źródłowy skryptu

Poniżej znajduje się pełna treść skryptu do wglądu. Zaleca się jednak pobranie najnowszej wersji z powyższego linku, aby mieć pewność, że zawiera wszystkie aktualne poprawki.

#!/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.<ts>.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

Weryfikacja po aktualizacji

pveversion

Oczekiwany wynik powinien wyglądać tak:

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

Sprawdź wersję uruchomionego jądra:

uname -a

Przejrzyj log z aktualizacji, aby upewnić się, że nie wystąpiły błędy:

less /root/pve-upgrade-*.log

Jeśli użyłeś usługi post-check utworzonej przez skrypt, możesz zobaczyć jej wyniki:

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

Artykuł Jak zaktualizować Proxmox VE 8.x do wersji 9.0 (Debian 12 do Debian 13) – krok po kroku za pomocą skryptu pochodzi z serwisu soban.

Dynamiczne nazwy zakładek w Tmuxie z SSH i hostname

Chcesz, aby Twoje zakładki (okna) w Tmuxie automatycznie pokazywały hostname serwera, do którego się logujesz przez SSH? A po wylogowaniu wracały do nazwy lokalnego hosta? Ten poradnik pokaże Ci, jak to skonfigurować krok po kroku.

1. Konfiguracja Tmux – ~/.tmux.conf

W pliku konfiguracyjnym Tmuxa ustaw domyślną komendę startową na specjalny plik Bash (.bash_tmux), który załatwi całą magię.

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

2. Skrypt startowy Bash – ~/.bash_tmux

Ten plik wykonuje się przy każdym starcie okna Tmux. Ustawia nazwę okna na hostname oraz nadpisuje polecenie ssh, aby aktualizowało zakładkę przy połączeniu i po rozłączeniu.

#!/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. Przeładowanie konfiguracji Tmux bez restartu

Aby zastosować zmiany bez restartowania całej sesji Tmux, użyj następującego polecenia:

tmux source-file ~/.tmux.conf

Dodatkowo możesz przeładować bieżącą powłokę z .bash_tmux ręcznie:

exec bash --rcfile ~/.bash_tmux

4. Efekt końcowy

• Nowe okno Tmux ma automatycznie nazwę lokalnego hosta
• Po połączeniu przez SSH — zakładka zmienia się na nazwę zdalnego hosta
• Po wylogowaniu — zakładka wraca do lokalnego hostname

Prosto, czytelnie i mega wygodnie — idealne dla adminów, devopsów i fanów porządku w Tmuxie 💪

Artykuł Dynamiczne nazwy zakładek w Tmuxie z SSH i hostname pochodzi z serwisu soban.

System Linux to potężne narzędzie, które oferuje użytkownikom ogromną elastyczność i kontrolę nad ich środowiskiem pracy. Jednak aby w pełni wykorzystać jego potencjał, warto poznać kluczowe polecenia, które są niezbędne zarówno dla początkujących, jak i zaawansowanych użytkowników. W tym artykule przedstawimy i omówimy najważniejsze polecenia w systemie Linux, które każdy użytkownik powinien znać.

1. Podstawowe polecenia nawigacyjne

• pwd – Wyświetla bieżącą ścieżkę katalogu, w którym się znajdujesz:

pwd

• ls – Listuje zawartość katalogu. Można użyć opcji -l dla szczegółowego widoku lub -a aby pokazać ukryte pliki:

ls -a

• cd – Zmienia katalog. Na przykład cd /home/user przeniesie Cię do katalogu /home/user:

cd ~

• mkdir – Tworzy nowy katalog:

mkdir projekty

• rmdir – Usuwa pusty katalog:

rmdir stare_pliki

2. Zarządzanie plikami

• cp – Kopiuje pliki lub katalogi:

cp dokument.txt nowy_katalog/

• mv – Przenosi lub zmienia nazwę plików/katalogów:

mv plik.txt /home/user/nowy_katalog/

• rm – Usuwa pliki lub katalogi. Użyj opcji -r aby usunąć katalog z zawartością:

rm -r stare_dane

• touch – Tworzy pusty plik lub aktualizuje czas modyfikacji istniejącego pliku:

touch raport.txt

3. Zarządzanie procesami

• ps – Wyświetla aktualnie uruchomione procesy. Użyj opcji -aux aby zobaczyć wszystkie procesy:

ps -aux

• top – Wyświetla dynamiczną listę procesów w czasie rzeczywistym:

top

• kill – Zatrzymuje proces o podanym ID:

kill 1234

• bg i fg – Zarządzanie procesami w tle i na pierwszym planie:

fg

4. Zarządzanie użytkownikami i uprawnieniami

• sudo – Pozwala na wykonanie polecenia z uprawnieniami administratora:

sudo apt update

• chmod – Zmienia uprawnienia do plików/katalogów:

chmod 755 skrypt.sh

• chown – Zmienia właściciela pliku/katalogu:

chown admin:admin plik.txt

• useradd i userdel – Dodaje i usuwa użytkowników:

useradd janek

5. Sieć i komunikacja

• ping – Sprawdza połączenie z innym hostem:

ping 192.168.1.1

• ifconfig – Wyświetla informacje o interfejsach sieciowych:

ifconfig

• ssh – Łączy się zdalnie z innym komputerem:

ssh user@192.168.1.2

• scp – Kopiuje pliki przez SSH:

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

6. Przykłady użycia poleceń

Poniżej znajduje się przykład użycia kilku omówionych poleceń:

• chmod – Zmienia uprawnienia do plików/katalogów:

chmod 755 skrypt.sh

• chown – Zmienia właściciela pliku/katalogu:

chown admin:developers logi.txt

• useradd i userdel – Dodaje i usuwa użytkowników:

useradd janek

7. Zarządzanie dyskami i systemem plików

• df – Wyświetla informacje o dostępnej przestrzeni na dyskach:

df -h

• du – Pokazuje rozmiar plików i katalogów:

du -sh documents

• mount – Montuje system plików:

mount /dev/sdb1 /mnt/external

• umount – Odmontowuje system plików:

umount /mnt/external

8. Wyszukiwanie plików

• find – Wyszukuje pliki w systemie:
• locate – Szybkie wyszukiwanie plików w systemie:
• grep – Wyszukuje wzorce w plikach:
• which – Znajduje pełną ścieżkę do wykonywalnego pliku:

9. Komunikacja z systemem

• echo – Wyświetla tekst na ekranie:
• cat – Wyświetla zawartość pliku:
• more – Wyświetla zawartość pliku strona po stronie:
• less – Zawiera funkcje podobne do more, ale oferuje więcej opcji nawigacji:
• man – Wyświetla podręcznik użytkownika dla polecenia:

10. Praca z archiwami

• tar – Tworzy archiwum lub rozpakowuje je:
• zip – Tworzy archiwum ZIP:
• unzip – Rozpakowuje pliki ZIP:
• tar -xvzf – Rozpakowuje archiwum TAR.GZ:
• gzip – Kompresuje pliki w formacie .gz:
• gunzip – Rozpakowuje pliki .gz:

11. Monitorowanie systemu

• uptime – Wyświetla czas działania systemu oraz obciążenie:
• dmesg – Wyświetla komunikaty systemowe związane z rozruchem i sprzętem:
• iostat – Pokazuje statystyki wejścia/wyjścia systemu:
• free – Pokazuje informacje o pamięci RAM:
• netstat – Wyświetla informacje o połączeniach sieciowych:
• ss – Nowoczesna wersja netstat, służy do monitorowania połączeń sieciowych:

12. Praca z logami systemowymi

• journalctl – Przegląda logi systemowe:
• tail – Wyświetla ostatnie linie pliku:
• logrotate – Automatycznie zarządza logami:

13. Zaawansowane operacje na plikach

• ln – Tworzy dowiązanie do pliku:
• xargs – Przesyła argumenty z wejścia do innych poleceń:
• chmod – Zmienia uprawnienia do plików/katalogów:
• chattr – Zmienia atrybuty plików:

System Linux oferuje szeroki zestaw poleceń, które pozwalają na pełną kontrolę nad komputerem. Kluczowe polecenia, jak ls, cd, cp, czy rm, są używane na co dzień do nawigacji po systemie plików, zarządzania plikami oraz katalogami. Aby skutecznie opanować te komendy, najlepiej zacząć od tych, które są najbardziej przydatne w codziennej pracy. Przykładowo, polecenia do nawigacji po katalogach i zarządzania plikami są fundamentalne i wymagają praktyki, aby stały się intuicyjne. Inne polecenia, takie jak ps do monitorowania procesów, ping do testowania połączeń sieciowych, czy chmod do zmiany uprawnień, również warto poznać, aby móc w pełni wykorzystać moc systemu Linux.

Aby uczyć się skutecznie, warto zacząć od eksperymentowania z poleceniami w praktyce. Tworzenie plików, katalogów, kopiowanie i usuwanie danych pozwala na zapoznanie się z ich działaniem. Z czasem warto zacząć łączyć różne polecenia, by rozwiązywać bardziej zaawansowane problemy, jak monitorowanie procesów, zarządzanie użytkownikami czy praca z logami systemowymi. Można także korzystać z dokumentacji, np. man lub stron internetowych, aby zgłębiać szczegóły każdego polecenia i jego opcji.

Pamiętaj, że regularne korzystanie z terminala pozwala na naukę nawyków, które sprawią, że obsługa systemu Linux stanie się bardziej naturalna. Częste korzystanie z poleceń, rozwiązywanie problemów oraz eksperymentowanie z nowymi komendami to najlepszy sposób na opanowanie systemu i wykorzystywanie go w pełni.

Linux to naprawdę potężne narzędzie, które daje ogromną kontrolę nad systemem… ale pamiętaj, nie eksperymentuj na produkcji! W końcu, eksperymentowanie na serwerze produkcyjnym to trochę jak gra w rosyjską ruletkę — tylko że z większymi konsekwencjami. Jeśli chcesz poczuć się jak prawdziwy Linuxowy magik, zawsze testuj swoje komendy na środowisku deweloperskim. Tylko wtedy będziesz w stanie uczyć się na błędach, zamiast szukać przyczyny zniknięcia kilku gigabajtów danych. A jeśli nie wiesz, co robisz, po prostu wezwij swoją niezawodną broń: man!

Artykuł Najważniejsze polecenia Linuxa, które każdy użytkownik powinien znać pochodzi z serwisu soban.