CrowdSec – dodatkowa ochrona serwera Linux, Nginx i SSH przed botami oraz atakami brute-force

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.

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.

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.

Po instalacji przeładuj konfigurację:

Konfiguracja logów Nginx

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

Edytuj plik:

Dodaj konfigurację:

Następnie uruchom ponownie usługę:

Sprawdzenie działania CrowdSec

Status usługi:

Lista aktywnych banów:

Statystyki działania:

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ń.

Fail2Ban: jak wyłapać recydywistów i banować ich na tydzień (recidive)


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:

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

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:

Na końcu pliku wklej:

Zapisz plik i zrestartuj Fail2Ban:

Sprawdź status jaila:

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:

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.

Debian 13 (Trixie) → Proxmox VE 9 – Uproszczona instalacja na czystym Debianie

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:

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

Część 2 – Instalacja Proxmox VE 9

Po restarcie pobierz i uruchom:

Zawartość install-proxmox9-part2.sh

Dostęp do interfejsu webowego

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

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:

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:

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

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

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.

Konfiguracja Fail2Ban dla Nginx – blokowanie skanerów i exploitów bez blokowania administratora WordPress

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:

Włącz oraz uruchom usługę:

Sprawdź status działania:

Krok 2: Utworzenie filtra nginx-secure

Utwórz plik filtra:

Wklej poniższą konfigurację:

Krok 3: Utworzenie jail nginx-secure

Utwórz plik konfiguracji jail:

Wklej konfigurację:

Krok 4: Restart Fail2Ban

Krok 5: Sprawdzenie integracji z firewallem

Sprawdź czy łańcuch Fail2Ban istnieje:

Test z zewnętrznej maszyny

Test ścieżki exploita:

Test logiki błędów bez Referer:

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

Sprawdzenie zbanowanych adresów IP

Odblokowanie adresu IP

Ręczne zdjęcie bana:

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.

Automatyczny upgrade Debian 12 → Debian 13 z opcjonalną aktualizacją PHP i nginx

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):

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

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):

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

Wariant C (curl):

3) Pomoc skryptu (parametry)

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

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

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

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:

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:

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:

8) Tryb testowy (dry-run)

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

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.

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

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

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:

Instalacja skryptu

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

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)

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:

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:

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

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.

Dell WD19/WD19S: aktualizacja firmware na Proxmox/Debian bez timeoutów USB (fwupd + autosuspend fix)


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:

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.

Następnie uruchom aktualizację:

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

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

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ę:

Na końcu sprawdź status:

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:

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

Jeżeli nie masz less w systemie:

Skrypt (pełna treść)

Uruchomienie skryptu

Najprościej:

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.

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

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ć:

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

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.

Weryfikacja po aktualizacji

Oczekiwany wynik powinien wyglądać tak:

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

Sprawdź wersję uruchomionego jądra:

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

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

Dynamiczne nazwy zakładek w Tmuxie z SSH i hostname


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ę.

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.

3. Przeładowanie konfiguracji Tmux bez restartu

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

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

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 💪

Najważniejsze polecenia Linuxa, które każdy użytkownik powinien znać

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:
  • ls – Listuje zawartość katalogu. Można użyć opcji -l dla szczegółowego widoku lub -a aby pokazać ukryte pliki:
  • cd – Zmienia katalog. Na przykład cd /home/user przeniesie Cię do katalogu /home/user:
  • mkdir – Tworzy nowy katalog:
  • rmdir – Usuwa pusty katalog:

2. Zarządzanie plikami

  • cp – Kopiuje pliki lub katalogi:
  • mv – Przenosi lub zmienia nazwę plików/katalogów:
  • rm – Usuwa pliki lub katalogi. Użyj opcji -r aby usunąć katalog z zawartością:
  • touch – Tworzy pusty plik lub aktualizuje czas modyfikacji istniejącego pliku:

3. Zarządzanie procesami

  • ps – Wyświetla aktualnie uruchomione procesy. Użyj opcji -aux aby zobaczyć wszystkie procesy:
  • top – Wyświetla dynamiczną listę procesów w czasie rzeczywistym:
  • kill – Zatrzymuje proces o podanym ID:
  • bg i fg – Zarządzanie procesami w tle i na pierwszym planie:

4. Zarządzanie użytkownikami i uprawnieniami

  • sudo – Pozwala na wykonanie polecenia z uprawnieniami administratora:
  • chmod – Zmienia uprawnienia do plików/katalogów:
  • chown – Zmienia właściciela pliku/katalogu:
  • useradd i userdel – Dodaje i usuwa użytkowników:

5. Sieć i komunikacja

  • ping – Sprawdza połączenie z innym hostem:
  • ifconfig – Wyświetla informacje o interfejsach sieciowych:
  • ssh – Łączy się zdalnie z innym komputerem:
  • scp – Kopiuje pliki przez SSH:

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:
  • chown – Zmienia właściciela pliku/katalogu:
  • useradd i userdel – Dodaje i usuwa użytkowników:

7. Zarządzanie dyskami i systemem plików

  • df – Wyświetla informacje o dostępnej przestrzeni na dyskach:
  • du – Pokazuje rozmiar plików i katalogów:
  • mount – Montuje system plików:
  • umount – Odmontowuje system plików:

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!