Kategoria: Cron

  • Cyfrowa Arka Noego: Jak UrBackup i TrueNAS chronią Twoje dane

    Cyfrowa Arka Noego: Jak UrBackup i TrueNAS chronią Twoje dane

    W dzisiejszym cyfrowym świecie nasze życie – zarówno prywatne, jak i zawodowe – zapisane jest w postaci danych. Od zdjęć rodzinnych po kluczowe bazy danych firmowych, utrata tych informacji może być katastrofalna. Mimo to, wiele osób i firm wciąż traktuje kopie zapasowe po macoszemu. Przedstawiamy kompletny przewodnik po budowie potężnego, zautomatyzowanego i bezpiecznego systemu backupu przy użyciu darmowych narzędzi: UrBackup, TrueNAS Scale i Tailscale.

    Dlaczego potrzebujesz planu B? Znaczenie kopii zapasowych

    Wyobraź sobie, że pewnego ranka dysk twardy w Twoim laptopie odmawia posłuszeństwa. Albo serwer, na którym działa Twoja firma, pada ofiarą ataku ransomware, a wszystkie pliki zostają zaszyfrowane. To nie są scenariusze z filmów science-fiction, ale codzienna rzeczywistość. Awaria sprzętu, błąd ludzki, złośliwe oprogramowanie czy nawet kradzież – zagrożeń jest wiele.

    Kopia zapasowa to Twoja polisa ubezpieczeniowa. To jedyny sposób, aby w razie katastrofy szybko i bezboleśnie odzyskać cenne dane, minimalizując przestoje i straty finansowe. Bez niej, odbudowa utraconych informacji jest często niemożliwa lub astronomicznie kosztowna.

    Złota zasada: Strategia 3-2-1

    W świecie bezpieczeństwa danych istnieje prosta, ale niezwykle skuteczna zasada, znana jako strategia 3-2-1. Mówi ona, że powinieneś posiadać:

    • TRZY kopie swoich danych (oryginał i dwie kopie zapasowe).
    • Na DWÓCH różnych nośnikach (np. dysk w komputerze i dysk w serwerze NAS).
    • JEDNĄ kopię w innej lokalizacji (off-site), na wypadek pożaru, powodzi czy kradzieży w głównej siedzibie.

    Posiadanie trzech egzemplarzy danych drastycznie zmniejsza ryzyko ich jednoczesnej utraty. Jeśli jeden dysk zawiedzie, masz drugi. Jeśli całe biuro ulegnie zniszczeniu, masz kopię w chmurze lub w domu.

    Pułapka myślenia: Dlaczego RAID to NIE jest kopia zapasowa?

    Wielu użytkowników serwerów NAS mylnie uważa, że konfiguracja RAID zwalnia ich z obowiązku robienia backupu. To niebezpieczny błąd.

    RAID (Redundant Array of Independent Disks) to technologia zapewniająca redundancję i wysoką dostępność, a nie bezpieczeństwo danych. Chroni ona przed fizyczną awarią dysku twardego. W zależności od konfiguracji (np. RAID 1, RAID 5, RAID 6 lub ich odpowiedniki RAID-Z w systemie TrueNAS), macierz może przetrwać awarię jednego, a nawet dwóch dysków jednocześnie, pozwalając na ich wymianę bez utraty danych i przerwy w działaniu systemu.

    Jednak RAID nie ochroni Cię przed:

    • Błędem ludzkim: Przypadkowe usunięcie pliku jest natychmiast replikowane na wszystkie dyski w macierzy.
    • Atakiem ransomware: Zaszyfrowane pliki są natychmiast synchronizowane na wszystkich dyskach.
    • Awarią zasilania lub kontrolera RAID: Może to doprowadzić do uszkodzenia całej macierzy.
    • Kradzieżą lub katastrofą naturalną: Utrata całego urządzenia oznacza utratę wszystkich danych.

    Pamiętaj: Redundancja chroni przed awarią sprzętu, kopia zapasowa chroni przed utratą danych.

    HDD Replacement RAID5

    Twoje centrum backupu: UrBackup na TrueNAS Scale

    Stworzenie solidnego systemu backupu nie musi wiązać się z drogimi subskrypcjami. Idealnym rozwiązaniem jest połączenie systemu operacyjnego TrueNAS Scale z aplikacją UrBackup.

    • TrueNAS Scale: To potężny, darmowy system operacyjny do budowy serwerów NAS. Bazuje na Linuksie i oferuje zaawansowane funkcje, takie jak system plików ZFS oraz obsługę aplikacji w kontenerach.
    • UrBackup: To oprogramowanie open-source typu klient-serwer do tworzenia kopii zapasowych. Jest niezwykle wydajne i elastyczne, pozwalając na backup zarówno pojedynczych plików, jak i całych obrazów dysków.

    Tarcza ochronna TrueNAS: Migawki (Snapshots) ZFS

    Jedną z najpotężniejszych funkcji TrueNAS, wynikającą z użycia systemu plików ZFS, są migawki (snapshots). Migawka to błyskawicznie tworzony, tylko do odczytu obraz całego systemu plików w danym momencie. Działa to jak zamrożenie danych w czasie.

    Dlaczego to jest tak ważne w kontekście ransomware?

    Gdy ransomware atakuje i szyfruje pliki na udziale sieciowym, zmiany te dotyczą „żywej” wersji danych. Jednak wcześniej wykonane migawki pozostają nietknięte i niezmienione, ponieważ są z natury tylko do odczytu. W przypadku ataku możesz w ciągu kilku sekund przywrócić cały zbiór danych (dataset) do stanu sprzed infekcji, całkowicie niwelując jej skutki.

    Możesz skonfigurować w TrueNAS automatyczne tworzenie migawek (np. co godzinę) i ich przechowywanie przez określony czas. To tworzy dodatkową, niezwykle potężną warstwę ochrony, która doskonale uzupełnia kopie zapasowe wykonywane przez UrBackup.

    Zalety i wady rozwiązania

    Zalety:

    ✅ Pełna kontrola i prywatność: Twoje dane są przechowywane na Twoim własnym sprzęcie.

    ✅ Brak opłat licencyjnych: Oprogramowanie jest w pełni darmowe.

    ✅ Niezwykła wydajność: Kopie przyrostowe oszczędzają miejsce i czas.

    ✅ Elastyczność: Obsługa Windows, macOS, Linux, serwerów fizycznych i VPS.

    ✅ Kopie obrazów dysku: Możliwość odtworzenia całego systemu „od zera” (bare-metal restore).

    Wady:

    ❌ Wymaga własnego sprzętu: Konieczność posiadania serwera NAS.

    ❌ Wstępna konfiguracja: Wymaga pewnej wiedzy technicznej.

    ❌ Pełna odpowiedzialność: Użytkownik odpowiada za bezpieczeństwo i działanie serwera.

    Krok po kroku: Instalacja i konfiguracja

    1. Instalacja UrBackup na TrueNAS Scale

    1. Zaloguj się do interfejsu webowego TrueNAS.
    2. Przejdź do sekcji Apps.
    3. Wyszukaj aplikację UrBackup i kliknij Install.
    4. W najważniejszym kroku konfiguracji musisz wskazać ścieżkę, gdzie będą przechowywane kopie zapasowe (np. /mnt/TwojaPula/backups).
    5. Po zakończeniu instalacji, uruchom aplikację i przejdź do jej interfejsu webowego.

    2. Podstawowa konfiguracja serwera

    W interfejsie UrBackup przejdź do Ustawienia. Najważniejsze opcje na start to:

    • Ścieżka do magazynu kopii: Powinna być już ustawiona podczas instalacji.
    • Interwały wykonywania kopii: Ustaw, jak często mają być robione kopie przyrostowe (np. co kilka godzin) i pełne (np. co kilka tygodni).
    • Ustawienia poczty e-mail: Skonfiguruj wysyłanie powiadomień, aby otrzymywać raporty o stanie backupów.

    3. Instalacja klienta na komputerach

    Proces dodawania komputera do systemu backupu składa się z dwóch etapów: zarejestrowania go na serwerze i instalacji oprogramowania na maszynie klienckiej.

    a) Dodawanie nowego klienta na serwerze:

    1. W interfejsie UrBackup przejdź do zakładki Status.
    2. Kliknij niebieski przycisk „+ Dodaj nowego klienta”.
    3. Wybierz opcję „Dodaj nowego klienta internetowego/aktywnego”. Jest to zalecane, ponieważ działa zarówno w sieci lokalnej, jak i przez internet (np. przez Tailscale).
    4. Wpisz unikalną nazwę dla nowego klienta (np. „Laptop-Ania” lub „Serwer-WWW”) i kliknij „Dodaj klienta”.

    b) Instalacja oprogramowania na maszynie klienckiej:

    1. Po dodaniu klienta na serwerze, pozostając w zakładce Status, zobaczysz przyciski „Pobierz klienta dla Windows” oraz „Pobierz klienta dla systemu Linux”.
    2. Kliknij odpowiedni przycisk i wybierz z listy rozwijanej nazwę klienta, którego właśnie dodałeś.
    3. Pobierz przygotowany plik instalacyjny (.exe lub .sh). Jest on już w pełni skonfigurowany do połączenia z Twoim serwerem.
    4. Uruchom instalator na komputerze klienckim i postępuj zgodnie z instrukcjami.

    Po kilku minutach nowy klient powinien połączyć się z serwerem i pojawić się na liście ze statusem „Online”, gotowy do pierwszej kopii.

    Bezpieczeństwo ponad wszystko: Tailscale wkracza do gry

    Jak bezpiecznie backupować komputery znajdujące się poza Twoją siecią lokalną? Idealnym rozwiązaniem jest Tailscale. Tworzy on bezpieczną, prywatną sieć (mesh VPN) pomiędzy wszystkimi Twoimi urządzeniami, niezależnie od tego, gdzie się znajdują.

    Dlaczego warto używać Tailscale z UrBackup?

    • Prostota: Instalacja i konfiguracja zajmują minuty.
    • Bezpieczeństwo „Zero Trust”: Każde połączenie jest szyfrowane end-to-end.
    • Stabilne adresy IP: Każde urządzenie otrzymuje stały adres IP z puli 100.x.x.x, który nie zmienia się, nawet gdy urządzenie zmienia fizyczną lokalizację.

    Co zrobić, gdy zmieni się adres IP?

    Jeśli z jakiegoś powodu musisz zmienić adres IP serwera UrBackup (np. po przejściu z innej sieci VPN na Tailscale), procedura jest prosta:

    1. Zaktualizuj adres na serwerze UrBackup: W Ustawienia -> Klienci internetowi/aktywni wpisz nowy, poprawny adres serwera (np. urbackup://100.x.x.x).
    2. Pobierz zaktualizowany instalator: W zakładce Status, kliknij „Pobierz klienta”, wybierz z listy klienta, który jest offline, i pobierz dla niego nowy skrypt instalacyjny.
    3. Uruchom instalator na kliencie: Uruchomienie nowego instalatora automatycznie zaktualizuje konfigurację na maszynie klienckiej.

    Zarządzanie i monitorowanie kopii

    Interfejs UrBackup dostarcza wszystkich niezbędnych narzędzi do nadzorowania systemu.

    • Status: Główny pulpit, na którym widać listę wszystkich klientów, ich status online/offline oraz stan ostatniej kopii.
    • Zadania: Podgląd na żywo aktualnie wykonywanych operacji, takich jak indeksowanie plików czy transfer danych.
    • Kopie zapasowe: Lista wszystkich wykonanych backupów dla każdego klienta, z możliwością przeglądania plików i ich odtwarzania.
    • Dziennik: Szczegółowy rejestr wszystkich zdarzeń, błędów i ostrzeżeń – nieocenione narzędzie podczas diagnozowania problemów.
    • Statystyki: Wykresy i tabele pokazujące wykorzystanie przestrzeni dyskowej przez poszczególnych klientów w czasie.

    Backup baz danych: Zrób to dobrze!

    Nigdy nie rób backupu poprzez zwykłe kopiowanie plików bazy danych z dysku, gdy usługa jest uruchomiona! Grozi to wykonaniem niespójnej kopii, która będzie bezużyteczna. Prawidłowym sposobem jest wykonanie „zrzutu” (dump) za pomocą narzędzi takich jak mysqldump lub mariadb-dump.

    Metoda 1: Wszystkie bazy do jednego pliku

    Proste podejście, idealne dla małych środowisk.

    Polecenie: mysqldump –all-databases -u [uzytkownik] -p[haslo] > /sciezka/do/backupu/wszystkie_bazy.sql

    Metoda 2: Każda baza do osobnego pliku (zalecane)

    Bardziej elastyczne rozwiązanie. Poniższy skrypt automatycznie zapisze każdą bazę danych w osobnym, skompresowanym pliku. Należy go uruchamiać cyklicznie (np. przez cron) tuż przed zaplanowanym backupem przez UrBackup.

    #!/bin/bash
    
    # --- Konfiguracja ---
    BACKUP_DIR="/var/backups/mysql"
    DB_USER="root"
    DB_PASS="TwojeSuperTajneHaslo"
    # --------------------
    
    # Sprawdzenie, czy użytkownik i hasło są podane
    if [ -z "$DB_USER" ] || [ -z "$DB_PASS" ]; then
      echo "Błąd: Zmienne DB_USER lub DB_PASS nie są ustawione w skrypcie."
      exit 1
    fi
    
    # Utworzenie katalogu na backup, jeśli nie istnieje
    mkdir -p "$BACKUP_DIR"
    
    # Pobranie listy wszystkich baz danych, z wyłączeniem baz systemowych
    DATABASES=$(mysql -u "$DB_USER" -p"$DB_PASS" -e "SHOW DATABASES;" | tr -d "| " | grep -v -E "(Database|information_schema|performance_schema|mysql|sys)")
    
    # Pętla przez każdą bazę danych
    for db in $DATABASES; do
      echo "Wykonywanie zrzutu bazy danych: $db"
      
      # Wykonanie zrzutu i kompresja w locie
      mysqldump -u "$DB_USER" -p"$DB_PASS" --databases "$db" | gzip > "$BACKUP_DIR/$db-$(date +%Y-%m-%d).sql.gz"
      
      if [ $? -eq 0 ]; then
        echo "Zrzut bazy $db zakończony sukcesem."
      else
        echo "Błąd podczas wykonywania zrzutu bazy $db."
      fi
    done
    
    # Opcjonalnie: Usuwanie starych backupów (starszych niż 7 dni)
    find "$BACKUP_DIR" -type f -name "*.sql.gz" -mtime +7 -exec rm {} \;
    
    echo "Zakończono proces backupu wszystkich baz danych."
    

    Twoja cyfrowa twierdza

    Posiadanie solidnej, zautomatyzowanej strategii tworzenia kopii zapasowych to nie luksus, a absolutna konieczność. Połączenie mocy TrueNAS Scale z jego migawkami ZFS, elastyczności UrBackup i bezpieczeństwa Tailscale pozwala zbudować wielowarstwowy system obronny klasy korporacyjnej przy zerowych kosztach oprogramowania.

    To inwestycja czasu, która zapewnia bezcenny spokój ducha. Pamiętaj jednak, że żaden system nie jest w pełni bezobsługowy. Regularne monitorowanie logów, sprawdzanie raportów e-mail i, co najważniejsze, okresowe przeprowadzanie testowych odtworzeń plików to ostatni, kluczowy element, który zamienia dobry system backupu w niezawodną twierdzę chroniącą Twoje najcenniejsze zasoby – dane.

  • Twój serwer jest bezpieczny. Poradnik, jak trwale blokować ataki

    Twój serwer jest bezpieczny. Poradnik, jak trwale blokować ataki

    Trwała czarna lista IP z Fail2ban, UFW i Ipset

    Wstęp: Poza tymczasową ochroną

    W cyfrowym świecie, gdzie ataki na serwery są na porządku dziennym, sama reakcja nie wystarczy. Choć narzędzia takie jak Fail2ban stanowią podstawową linię obrony, ich tymczasowe blokady pozostawiają lukę – uporczywi atakujący, po upływie czasu bana, mogą wrócić i próbować ponownie. Ten artykuł stanowi szczegółowy przewodnik po budowie w pełni zautomatyzowanego, dwuwarstwowego systemu, który zamienia efemeryczne bany w trwałe, globalne blokady. Połączenie Fail2ban, UFW oraz potężnego narzędzia Ipset tworzy mechanizm, który trwale chroni serwer przed znanymi recydywistami.

    Warstwa pierwsza: Reakcja z Fail2ban

    Na początku każdego ataku stoi Fail2ban. Ten daemon monitoruje pliki logów (np. sshd.log, apache.log) w poszukiwaniu wzorców świadczących o próbach włamania – na przykład wielu nieudanych prób logowania. Gdy wykryje taką aktywność, natychmiastowo blokuje adres IP atakującego, dodając go do reguł firewalla na zdefiniowany czas (np. 10 minut, 30 dni). Jest to skuteczna, ale krótkotrwała reakcja.

    Warstwa druga: Trwałość z UFW i Ipset

    Aby ban stał się trwały, potrzebujemy silniejszej, scentralizowanej metody zarządzania adresami IP. W tym miejscu wkraczają UFW i Ipset.

    Czym jest Ipset?Ipset to rozszerzenie do jądra Linuksa, które pozwala na zarządzanie zbiorami (setami) adresów IP, sieci, czy portów. Jest to znacznie bardziej wydajne rozwiązanie niż dodawanie tysięcy pojedynczych reguł do firewalla. Zamiast tego, firewall może odwołać się do całego zestawu za pomocą jednej reguły.

    Instalacja i konfiguracja IpsetPierwszym krokiem jest instalacja Ipset w systemie. Używamy do tego standardowych menedżerów pakietów:sudo apt updatesudo apt install ipsetNastępnie tworzymy dwa zestawy: blacklist dla adresów IPv4 i blacklist_v6 dla IPv6.

    sudo ipset create blacklist hash:ip hashsize 4096
    sudo ipset create blacklist_v6 hash:net family inet6 hashsize 4096

    Parametr hashsize określa maksymalną liczbę wpisów, co jest kluczowe dla wydajności.

    Integracja Ipset z Firewallem UFWAby UFW zaczął korzystać z naszych zestawów, musimy dodać do jego reguł odpowiednie polecenia. Edytujemy pliki konfiguracyjne UFW, dodając reguły blokujące ruch, który pochodzi z adresów zawartych w naszych zestawach Ipset. Dla IPv4 edytujemy

    sudo nano /etc/ufw/before.rules:

    Zaraz po:

    *filter
    :ufw-before-input - [0:0]

    dodajemy:

    # =======================================================
    # Reguły dla trwałej czarnej listy (ipset)
    # Blokuj każdy przychodzący ruch od adresów IP z zestawu 'blacklist' (IPv4)
    -A ufw-before-input -m set --match-set blacklist src -j DROP
    # =======================================================
    

    Dla IPv6 edytujemy

    sudo nano /etc/ufw/before6.rules

    Zaraz po

    *filter
    :ufw6-before-input - [0:0]

    dodajemy:

    # =======================================================
    # Reguły dla trwałej czarnej listy (ipset) - IPv6
    # Blokuj każdy przychodzący ruch od adresów IP z zestawu 'blacklist_v6'
    -A ufw6-before-input -m set --match-set blacklist_v6 src -j DROP
    # =======================================================
    

    Po dodaniu reguł, przeładowujemy UFW, aby weszły w życie:

    sudo ufw reload

    Skrypt do automatycznej aktualizacji czarnej listy

    Sednem systemu jest skrypt, który działa jako pomost między Fail2ban a Ipset. Jego zadaniem jest zbieranie zbanowanych adresów, unikalizowanie ich i synchronizowanie z zestawami Ipset.

    sudo nano /usr/local/bin/update-blacklist.sh

    Poniżej przedstawiono zawartość skryptu. Działa on w kilku krokach:

    1. Tworzy tymczasową, unikalną listę adresów IP z logów Fail2ban oraz istniejącej czarnej listy.
    2. Tworzy tymczasowe zestawy Ipset.
    3. Czyta adresy z unikalnej listy i dodaje je do odpowiednich zestawów tymczasowych (rozróżniając IPv4 i IPv6).
    4. Atomowo zamienia stare zestawy Ipset na nowe, tymczasowe, minimalizując ryzyko przerw w ochronie.
    5. Niszczy stare, tymczasowe zestawy.
    6. Zwraca podsumowanie liczby zablokowanych adresów.
    #!/bin/bash
    BLACKLIST_FILE="/etc/fail2ban/blacklist.local"
    IPSET_NAME_V4="blacklist"
    IPSET_NAME_V6="blacklist_v6"
    touch "$BLACKLIST_FILE"
    (grep 'Ban' /var/log/fail2ban.log | awk '{print $(NF)}' && cat "$BLACKLIST_FILE") | sort -u > "$BLACKLIST_FILE.tmp"
    mv "$BLACKLIST_FILE.tmp" "$BLACKLIST_FILE"
    
    sudo ipset create "${IPSET_NAME_V4}_tmp" hash:ip hashsize 4096 --exist
    sudo ipset create "${IPSET_NAME_V6}_tmp" hash:net family inet6 hashsize 4096 --exist
    
    while IFS= read -r ip; do
      if [[ "$ip" == *":"* ]]; then
        sudo ipset add "${IPSET_NAME_V6}_tmp" "$ip"
      else
        sudo ipset add "${IPSET_NAME_V4}_tmp" "$ip"
      fi
    done < "$BLACKLIST_FILE"
    
    sudo ipset swap "${IPSET_NAME_V4}_tmp" "$IPSET_NAME_V4"
    sudo ipset swap "${IPSET_NAME_V6}_tmp" "$IPSET_NAME_V6"
    
    sudo ipset destroy "${IPSET_NAME_V4}_tmp"
    sudo ipset destroy "${IPSET_NAME_V6}_tmp"
    
    COUNT_V4=$(sudo ipset list "$IPSET_NAME_V4" | wc -l)
    COUNT_V6=$(sudo ipset list "$IPSET_NAME_V6" | wc -l)
    let COUNT_V4=$COUNT_V4-7
    let COUNT_V6=$COUNT_V6-7
    [ $COUNT_V4 -lt 0 ] && COUNT_V4=0
    [ $COUNT_V6 -lt 0 ] && COUNT_V6=0
    
    echo "Czarna lista i ipset zaktualizowane. Zablokowane IPv4: $COUNT_V4, Zablokowane IPv6: $COUNT_V6"
    exit 0
    
    

    Po utworzeniu skryptu, należy nadać mu uprawnienia do wykonania:

    sudo chmod +x /usr/local/bin/update-blacklist.sh

    Automatyzacja i trwałość po restarcie

    Aby skrypt działał bez ingerencji, używamy harmonogramu cron. Otwieramy edytor crontab dla użytkownika root i dodajemy regułę, która uruchomi skrypt co godzinę:

    sudo crontab -e
    0 * * * * /usr/local/bin/update-blacklist.sh

    lub raz dziennie o 6 rano:

    0 6 * * * /usr/local/bin/update-blacklist.sh

    Ostatni, ale kluczowy krok, to zapewnienie, że zestawy Ipset przetrwają restart. Zestawy te są domyślnie przechowywane w pamięci RAM. Tworzymy więc usługę systemd, która zapisze ich stan przed zamknięciem serwera i wczyta go ponownie przy starcie.

    sudo nano /etc/systemd/system/ipset-persistent.service
    [Unit]
    Description=Zapisuje i wczytuje zestawy ipset przy starcie/zamknięciu systemu
    Before=network-pre.target
    ConditionFileNotEmpty=/etc/ipset.rules
    
    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=/bin/bash -c "/sbin/ipset create blacklist hash:ip --exist; /sbin/ipset create blacklist_v6 hash:net family inet6 --exist; /sbin/ipset flush blacklist; /sbin/ipset flush blacklist_v6; /sbin/ipset restore -f <(grep -v ' create' /etc/ipset.rules)"
    ExecStop=/sbin/ipset save -f /etc/ipset.rules
    
    [Install]
    WantedBy=multi-user.target
    
    

    Na koniec włączamy i uruchamiamy usługę:

    sudo systemctl daemon-reload
    sudo systemctl enable --now ipset-persistent.service

    Jak to działa w praktyce?

    Cały system to zautomatyzowany łańcuch zdarzeń, który działa w tle, chroniąc serwer przed atakami. Oto, jak wygląda przepływ informacji i działań:

    1. Reakcja na atak (Fail2ban):
      • Ktoś próbuje się włamać na serwer (np. wielokrotnie podając błędne hasło przez SSH).
      • Fail2ban, monitorując logi systemowe (/var/log/fail2ban.log), wykrywa ten wzorzec.
      • Natychmiast dodaje adres IP atakującego do tymczasowej reguły firewalla, blokując mu dostęp na określony czas.
    2. Trwałe banowanie (Skrypt i cron):
      • Co godzinę (zgodnie z ustawieniem w cron), system uruchamia skrypt update-blacklist.sh.
      • Skrypt czyta logi Fail2ban, znajduje wszystkie adresy, które zostały zbanowane (linijki zawierające „Ban”), a następnie porównuje je z istniejącą, lokalną czarną listą (/etc/fail2ban/blacklist.local).
      • Tworzy unikalną listę wszystkich zbanowanych adresów.
      • Tworzy tymczasowe zestawy ipset (blacklist_tmp i blacklist_v6_tmp) i dodaje do nich wszystkie adresy z unikalnej listy.
      • Wykonuje operację ipset swap, która atomowo zamienia stare, aktywne zestawy na nowe, zaktualizowane.
      • UFW, dzięki zdefiniowanym wcześniej regułom, natychmiast zaczyna blokować nowe adresy, które pojawiły się w zaktualizowanych zestawach ipset.
    3. Trwałość po restarcie (Usługa systemd):
      • Działanie Ipset jest ulotne – zestawy istnieją tylko w pamięci. Usługa ipset-persistent.service rozwiązuje ten problem.
      • Przed wyłączeniem/restartem serwera: systemd uruchamia polecenie ExecStop=/sbin/ipset save -f /etc/ipset.rules. Zapisuje ono aktualny stan wszystkich zestawów ipset do pliku na dysku.
      • Po włączeniu/restarcie serwera: systemd uruchamia polecenie ExecStart=/sbin/ipset restore.... Wczytuje ono z pliku /etc/ipset.rules wszystkie zablokowane adresy i automatycznie odtwarza zestawy ipset w pamięci.
      • Dzięki temu, nawet jeśli serwer zostanie zrestartowany, czarna lista IP pozostaje nienaruszona, a ochrona jest aktywna od pierwszych chwil po uruchomieniu systemu.

    Podsumowanie i weryfikacja

    Zbudowany system to w pełni zautomatyzowana, wielowarstwowa ochrona. Atakujący są tymczasowo banowani przez Fail2ban, a ich adresy są automatycznie dodawane do trwałej czarnej listy, która jest natychmiastowo blokowana przez UFW i Ipset. Usługa systemd zapewnia, że czarna lista przetrwa restarty serwera, chroniąc przed recydywistami na stałe. Aby zweryfikować działanie, można użyć poniższych komend:

    • sudo ufw status verbose
    • sudo ipset list blacklist oraz sudo ipset list blacklist_v6
    • sudo systemctl status ipset-persistent.service

    Jak Stworzyć Niezawodną Białą Listę (Whitelist) Adresów IP w UFW i Ipset

    Wprowadzenie: Dlaczego Biała Lista Jest Kluczowa?

    Podczas konfigurowania zaawansowanych reguł firewalla, zwłaszcza tych, które automatycznie blokują adresy IP (jak w systemach z Fail2ban), istnieje ryzyko przypadkowego zablokowania samego siebie lub kluczowych usług. Biała lista (whitelist) to mechanizm, który działa jak przepustka VIP dla Twojego firewalla – adresy IP umieszczone na tej liście zawsze będą miały dostęp, niezależnie od innych, bardziej restrykcyjnych reguł blokujących.

    Ten poradnik pokaże Ci, jak krok po kroku stworzyć solidną i trwałą białą listę, używając UFW (Uncomplicated Firewall) oraz ipset. Jako przykładu użyjemy adresu IP 111.222.333.444, który chcemy dodać jako zaufany.

    Krok 1: Stworzenie Dedykowanego Zestawu ipset dla Białej Listy

    Pierwszym krokiem jest utworzenie osobnego „kontenera” na nasze zaufane adresy IP. Użycie ipset jest znacznie wydajniejsze niż dodawanie wielu pojedynczych reguł do iptables.

    Otwórz terminal i wpisz następujące polecenie:

    sudo ipset create whitelist hash:ip
    

    Co zrobiliśmy?

    • ipset create: Polecenie tworzące nowy zestaw.
    • whitelist: Nazwa naszego zestawu. Jest krótka i jednoznaczna.
    • hash:ip: Typ zestawu. hash:ip jest zoptymalizowany do przechowywania i bardzo szybkiego wyszukiwania pojedynczych adresów IPv4.

    Krok 2: Dodanie Zaufanego Adresu IP

    Teraz, gdy mamy już gotowy kontener, dodajmy do niego nasz przykładowy, zaufany adres IP.

    sudo ipset add whitelist 111.222.333.444
    

    Możesz powtórzyć to polecenie dla każdego adresu, który chcesz dodać do białej listy. Aby sprawdzić zawartość listy, użyj polecenia:

    sudo ipset list whitelist
    

    Krok 3: Modyfikacja Firewalla – Nadanie Priorytetu Białej Liście

    To jest najważniejszy krok. Musimy zmodyfikować reguły UFW tak, aby połączenia z adresów na białej liście były akceptowane natychmiast, zanim firewall zacznie przetwarzać jakiekolwiek reguły blokujące (w tym te z czarnej listy ipset czy Fail2ban).

    Otwórz plik konfiguracyjny before.rules:Jest to plik, w którym znajdują się reguły przetwarzane przed głównymi regułami UFW.

    sudo nano /etc/ufw/before.rules

    Dodaj regułę ACCEPT na samej górze: Przejdź na początek pliku i znajdź sekcję *filter. Zaraz pod linią

    :ufw-before-input - [0:0]

    , dodaj nasz nowy fragment. Umieszczenie go na samej górze gwarantuje, że zostanie przetworzony jako pierwszy.

    *filter
    :ufw-before-input - [0:0]
    # =======================================================
    # Reguła dla białej listy (ipset) - ZAWSZE MA PIERWSZEŃSTWO
    # Akceptuj każdy ruch od adresów IP z zestawu 'whitelist'
    -A ufw-before-input -m set --match-set whitelist src -j ACCEPT
    # =======================================================
    

    -A ufw-before-input: Dodajemy regułę do łańcucha ufw-before-input.

    -m set --match-set whitelist src: Warunek: „jeśli źródłowy (src) adres IP pasuje do zestawu whitelist„.

    -j ACCEPT: Akcja: „natychmiast zaakceptuj (ACCEPT) pakiet i przestań przetwarzać dalsze reguły dla tego pakietu”.

    Zapisz plik i przeładuj UFW:

    sudo ufw reload
    Od tego momentu każde połączenie z adresu 111.222.333.444 będzie natychmiast akceptowane.

    Krok 4: Zapewnienie Trwałości Białej Listy

    Zestawy ipset są przechowywane w pamięci i znikają po restarcie serwera. Aby nasza biała lista była trwała, musimy upewnić się, że jest ona automatycznie wczytywana przy każdym starcie systemu. Wykorzystamy do tego naszą wcześniej stworzoną usługę

    ipset-persistent.service.

    Zaktualizuj usługę systemd: Musimy ją „nauczyć” o istnieniu nowego zestawu whitelist.

    sudo nano /etc/systemd/system/ipset-persistent.service

    Znajdź linię ExecStart i dodaj do niej polecenia create i flush dla whitelist. Jeśli masz już inne zestawy, po prostu dodaj whitelist na początku.

    # Przykład zaktualizowanej linii
    ExecStart=/bin/bash -c "/sbin/ipset create whitelist hash:ip --exist; /sbin/ipset create blacklist hash:ip --exist; /sbin/ipset create blacklist_v6 hash:net family inet6 --exist; /sbin/ipset create blacklist_nets hash:net --exist; /sbin/ipset flush whitelist; /sbin/ipset flush blacklist; /sbin/ipset flush blacklist_v6; /sbin/ipset flush blacklist_nets; /sbin/ipset restore -f <(grep -v '^create' /etc/ipset.rules)"
    


    Najprościej jest zastąpić całą linię ExecStart jej kompletną wersją, uwzględniającą wszystkie Twoje zestawy.

    Przeładuj konfigurację systemd:

    sudo systemctl daemon-reload

    Zapisz aktualny stan wszystkich zestawów do pliku: To polecenie nadpisze stary plik /etc/ipset.rules nową wersją, która zawiera już informacje o Twojej białej liście.

    sudo ipset save > /etc/ipset.rules

    Zrestartuj usługę, aby upewnić się, że działa z nową konfiguracją:

    sudo systemctl restart ipset-persistent.service

    Podsumowanie

    Gratulacje! Stworzyłeś solidny i niezawodny mechanizm białej listy. Dzięki niemu możesz bezpiecznie zarządzać swoim serwerem, mając pewność, że zaufane adresy IP, takie jak 111.222.333.444, nigdy nie zostaną przypadkowo zablokowane. Pamiętaj, aby dodawać do tej listy tylko w pełni zaufane adresy, takie jak Twój domowy lub biurowy adres IP.

    Jak efektywnie blokować adresy IP i podsieci na serwerze Linux

    Blokowanie pojedynczych adresów IP jest łatwe, ale co, jeśli atakujący używają wielu adresów z tej samej sieci? Ręczne banowanie każdego z nich jest nieefektywne i czasochłonne.

    W tym artykule dowiesz się, jak wykorzystać narzędzia ipset i iptables, aby skutecznie blokować całe podsieci, automatyzując ten proces i oszczędzając cenny czas.

    Dlaczego blokowanie całych podsieci jest lepsze?

    Wiele ataków, zwłaszcza tych typu „brute-force”, jest przeprowadzanych z wielu adresów IP należących do tego samego operatora lub z tej samej puli adresów (podsieci). Blokowanie tylko jednego z nich jest jak łatanie małej dziury w dużej zaporze — reszta ruchu wciąż może się przedostać.

    Zamiast tego, możesz zablokować całą podsieć, na przykład 45.148.10.0/24. Taki zapis oznacza, że blokujesz aż 256 adresów jednocześnie, co jest znacznie skuteczniejsze.

    Skrypt do automatycznego blokowania podsieci

    Aby zautomatyzować proces, możesz użyć poniższego skryptu bash. Skrypt ten jest interaktywny — prosi Cię o podanie podsieci do zablokowania, a następnie dodaje ją do listy ipset oraz zapisuje w pliku, dzięki czemu będzie trwale zablokowana.

    Przeanalizujmy skrypt krok po kroku:

    #!/bin/bash
    
    # Nazwa listy ipset, do której będą dodawane podsieci
    BLACKLIST_NAME="blacklist_nets"
    
    # Plik, do którego będą dopisywane zablokowane podsieci
    BLACKLIST_FILE="/etc/fail2ban/blacklistnet.local"
    
    # 1. Tworzy plik z czarną listą, jeśli jeszcze nie istnieje
    touch "$BLACKLIST_FILE"
    
    # 2. Sprawdza, czy lista ipset już istnieje. Jeśli nie, tworzy ją.
    # Użycie "hash:net" pozwala na przechowywanie podsieci, co jest kluczowe.
    ipset list $BLACKLIST_NAME >/dev/null 2>&1
    if [ $? -ne 0 ]; then
        sudo ipset create $BLACKLIST_NAME hash:net maxelem 65536
    fi
    
    # 3. W pętli prosi użytkownika o podanie podsieci do zablokowania.
    # Pętla kończy się, gdy użytkownik wpisze "koniec".
    while true; do
        read -p "Podaj adres podsieci do zablokowania (np. 192.168.1.0/24) lub wpisz 'koniec': " subnet
        
        if [ "$subnet" == "koniec" ]; then
            break
        elif [[ "$subnet" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}\/[0-9]{1,2}$ ]]; then
            # Sprawdza, czy wprowadzony format jest poprawny
            
            # Sprawdza, czy podsieć nie jest już w pliku, aby uniknąć duplikatów
            if ! grep -q "^$subnet$" "$BLACKLIST_FILE"; then
                echo "$subnet" | sudo tee -a "$BLACKLIST_FILE" > /dev/null
            fi
            
            # Dodaje podsieć do listy ipset
            sudo ipset add $BLACKLIST_NAME $subnet
        else
            echo "Błąd: Nieprawidłowy format. Podaj adres w formacie 'X.X.X.X/Y'."
        fi
    done
    
    # 4. Dodaje regułę w iptables, która blokuje cały ruch z adresów na liście ipset.
    # Upewnia się, że reguła jest dodawana tylko raz.
    if ! sudo iptables -C INPUT -m set --match-set $BLACKLIST_NAME src -j DROP >/dev/null 2>&1; then
        sudo iptables -A INPUT -m set --match-set $BLACKLIST_NAME src -j DROP
    fi
    
    # 5. Zapisuje reguły iptables, aby przetrwały restart serwera.
    # Ten fragment sprawdza, z jakiego narzędzia korzysta system
    if command -v netfilter-persistent &> /dev/null; then
        sudo netfilter-persistent save
    elif command -v service &> /dev/null && service iptables status >/dev/null 2>&1; then
        sudo service iptables save
    fi
    
    echo "Skrypt zakończył działanie. Lista '$BLACKLIST_NAME' została zaktualizowana, a reguły iptables są aktywne."
    
    

    Jak używać skryptu

    1. Zapisz skrypt: Zapisz powyższy kod w pliku, np. block_nets.sh
    2. Nadaj uprawnienia: Upewnij się, że plik ma uprawnienia do wykonania: chmod +x block_nets.sh
    3. Uruchom skrypt: Wykonaj skrypt z uprawnieniami roota: sudo ./block_nets.sh
    4. Podawaj podsieci: Skrypt poprosi Cię o podanie adresów podsieci. Po prostu wpisuj je w formacie X.X.X.X/Y i zatwierdzaj Enterem. Po zakończeniu wpisz koniec.

    Zapewnienie trwałości po restarcie serwera

    Zestawy ipset są domyślnie przechowywane w pamięci RAM i znikają po ponownym uruchomieniu serwera. Aby zablokowane adresy pozostały aktywne, musisz użyć usługi systemd, która wczyta je przy starcie systemu.

    Jeśli masz już taką usługę (np. ipset-persistent.service), musisz ją zaktualizować, aby uwzględniała nową listę blacklist_nets.

    Edytuj plik usługi: Otwórz plik konfiguracyjny swojej usługi:

    sudo nano /etc/systemd/system/ipset-persistent.service

    Zaktualizuj linię ExecStart: Znajdź linię ExecStart i dodaj do niej polecenia create i flush dla zestawu blacklist_nets.Przykładowa, zaktualizowana linia ExecStart powinna wyglądać następująco:

    ExecStart=/bin/bash -c "/sbin/ipset create whitelist hash:ip --exist; /sbin/ipset create blacklist hash:ip --exist; /sbin/ipset create blacklist_v6 hash:net family inet6 --exist; /sbin/ipset create blacklist_nets hash:net --exist; /sbin/ipset flush whitelist; /sbin/ipset flush blacklist; /sbin/ipset flush blacklist_v6; /sbin/ipset flush blacklist_nets; /sbin/ipset restore -f <(grep -v ' create' /etc/ipset.rules)"

    Przeładuj konfigurację systemd:

    sudo systemctl daemon-reload

    Zapisz aktualny stan wszystkich zestawów do pliku: To polecenie nadpisze stary plik /etc/ipset.rules nową wersją, która zawiera już informacje o wszystkich Twoich listach, w tym blacklist_nets.

    sudo ipset save > /etc/ipset.rules

    Zrestartuj usługę:

    sudo systemctl restart ipset-persistent.service

    Dzięki tej metodzie możesz w prosty i wydajny sposób zarządzać bezpieczeństwem swojego serwera, skutecznie blokując całe podsieci, które wykazują podejrzaną aktywność, i mieć pewność, że te reguły pozostaną aktywne po każdym restarcie.

  • WordPress i błąd „A scheduled event has failed”?

    WordPress i błąd „A scheduled event has failed”?

    Każdy administrator strony na WordPressie zna to uczucie. Logujesz się do panelu, a tam czeka na Ciebie komunikat: „A scheduled event has failed”. Serce na chwilę staje. Czy strona padła? Czy to poważna awaria?

    Spokojnie! Zanim zaczniesz panikować, weź głęboki oddech. Ten błąd, choć brzmi poważnie, rzadko oznacza katastrofę. Najczęściej jest to po prostu sygnał, że wewnętrzny mechanizm harmonogramu zadań w WordPressie nie działa optymalnie.

    W tym artykule wyjaśnimy, czym jest ten błąd, dlaczego się pojawia i jak go profesjonalnie naprawić w różnych konfiguracjach serwerowych.

    Czym jest WP-Cron?

    WordPress musi wykonywać cykliczne zadania w tle: publikować zaplanowane posty, tworzyć kopie zapasowe czy skanować witrynę w poszukiwaniu wirusów (jak w przypadku błędu wf_scan_monitor od wtyczki Wordfence). Do obsługi tych operacji używa wbudowanego mechanizmu o nazwie WP-Cron.

    Problem polega na tym, że WP-Cron nie jest prawdziwym demonem cron znanym z systemów uniksowych. To „pseudo-cron”, który ma fundamentalną wadę: uruchamia się tylko wtedy, gdy ktoś odwiedzi Twoją stronę internetową.

    • Na stronach o małym ruchu: Jeśli nikt nie wchodzi na witrynę, zadania nie są wykonywane o czasie, co prowadzi do błędów.
    • Na stronach o dużym ruchu: WP-Cron jest wywoływany przy każdym załadowaniu strony, co generuje niepotrzebne obciążenie serwera.

    W obu przypadkach rozwiązanie jest takie samo: wyłączyć wbudowany WP-Cron i zastąpić go stabilnym, systemowym zadaniem cron.

    Scenariusz 1: Pojedyncza strona WordPress

    To podstawowa i najczęstsza konfiguracja. Rozwiązanie problemu jest proste i sprowadza się do dwóch kroków.

    Krok 1: Wyłącz wbudowany mechanizm WP-Cron

    Edytuj plik wp-config.php w głównym katalogu swojej strony i dodaj poniższą linię:

    define('DISABLE_WP_CRON', true);
    

    Krok 2: Skonfiguruj systemowy cron

    Zaloguj się do swojego serwera przez SSH i wpisz crontab -e, aby edytować listę zadań systemowych. Następnie dodaj jedną z poniższych linii, która co 5 minut będzie wywoływać mechanizm crona WordPressa we właściwy sposób.

    • Metoda z wget:*/5 * * * * wget -q -O - https://twojadomena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1
    • Metoda z curl:*/5 * * * * curl -s https://twojadomena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1

    Pamiętaj, aby podmienić twojadomena.pl na właściwy adres. Od teraz zadania będą wykonywane regularnie, niezależnie od ruchu na stronie.

    Scenariusz 2: Wiele stron na standardowym serwerze

    Jeśli zarządzasz wieloma stronami, dodawanie osobnej linii w crontab dla każdej z nich jest niepraktyczne i trudne w utrzymaniu. Lepszym rozwiązaniem jest stworzenie jednego skryptu, który automatycznie znajdzie wszystkie instalacje WordPressa i uruchomi dla nich zadania.

    Krok 1: Stwórz plik skryptu

    Utwórz plik, np. /usr/local/bin/run_all_wp_crons.sh, i wklej do niego poniższą zawartość. Skrypt przeszukuje katalog /var/www/ w poszukiwaniu plików wp-config.php.

    #!/bin/bash
    
    # =================================================================
    # Skrypt do uruchamiania zadań cron dla wszystkich stron WordPress
    # Zoptymalizowany dla struktury katalogów ISPConfig
    # =================================================================
    
    # Główny katalog, w którym znajdują się FAKTYCZNE pliki stron w ISPConfig
    SITES_ROOT="/var/www/clients/"
    
    # Ścieżka do interpretera PHP (może wymagać dostosowania)
    PHP_EXECUTABLE="/usr/bin/php"
    
    # Logowanie (opcjonalne, ale przydatne do debugowania)
    LOG_FILE="/var/log/wp_cron_runner.log"
    echo "Rozpoczynam uruchamianie zadań cron (ISPConfig): $(date)" >> $LOG_FILE
    
    # Znajdź wszystkie pliki wp-config.php i uruchom dla nich wp-cron.php
    find "$SITES_ROOT" -name "wp-config.php" -print0 | while IFS= read -r -d '' config_file; do
    
        # Wyodrębnij katalog, w którym znajduje się WordPress
        WP_DIR=$(dirname "$config_file")
    
        # Wyodrębnij nazwę użytkownika (np. web4) z ścieżki
        # Jest to siódmy element w ścieżce /var/www/clients/client4/web4/web/
        WP_USER=$(echo "$WP_DIR" | awk -F'/' '{print $6}')
    
        if [ -z "$WP_USER" ]; then
            echo "-> OSTRZEŻENIE: Nie udało się określić użytkownika dla: $WP_DIR" >> $LOG_FILE
            continue
        fi
    
        # Sprawdź, czy plik wp-cron.php istnieje w tym katalogu
        if [ -f "$WP_DIR/wp-cron.php" ]; then
            echo "-> Uruchamiam cron dla: $WP_DIR jako użytkownik: $WP_USER" >> $LOG_FILE
            # Uruchom wp-cron.php używając PHP CLI, przełączając się na właściwego użytkownika
            su -s /bin/sh "$WP_USER" -c "(cd '$WP_DIR' && '$PHP_EXECUTABLE' wp-cron.php)"
        else
            echo "-> OSTRZEŻENIE: Znaleziono wp-config, ale brak wp-cron.php w: $WP_DIR" >> $LOG_FILE
        fi
    
    done
    
    echo "Zakończono: $(date)" >> $LOG_FILE
    echo "---" >> $LOG_FILE

    Krok 2: Nadaj skryptowi uprawnienia do wykonania

    chmod +x /usr/local/bin/run_all_wp_crons.sh
    

    Krok 3: Stwórz jedno zadanie cron do zarządzania wszystkim

    Teraz Twój crontab -e może zawierać tylko jedną linię:

    */5 * * * * /usr/local/bin/run_all_wp_crons.sh >/dev/null 2>&1
    

    Scenariusz 3: Wiele stron z panelem ISPConfig

    Panel ISPConfig używa specyficznej struktury katalogów z dowiązaniami symbolicznymi (symlinkami), np. /var/www/twojadomena.pl wskazuje na /var/www/clients/client1/web1/. Użycie powyższego skryptu mogłoby spowodować podwójne wykonanie zadań.

    Aby tego uniknąć, należy zmodyfikować skrypt tak, by przeszukiwał tylko docelowy katalog clients.

    Krok 1: Stwórz skrypt zoptymalizowany dla ISPConfig

    Utwórz plik /usr/local/bin/run_ispconfig_crons.sh. Zwróć uwagę na zmianę w zmiennej SITES_ROOT.

    #!/bin/bash
    
    # Skrypt do uruchamiania zadań cron dla wszystkich stron WordPress
    # Zoptymalizowany dla struktury katalogów ISPConfig
    
    # Przeszukujemy tylko katalog z faktycznymi plikami stron
    SITES_ROOT="/var/www/clients/"
    
    # Ścieżka do interpretera PHP
    PHP_EXECUTABLE="/usr/bin/php"
    
    # Opcjonalny plik logu do śledzenia postępów
    LOG_FILE="/var/log/wp_cron_runner.log"
    echo "Rozpoczynam uruchamianie zadań cron (ISPConfig): $(date)" >> $LOG_FILE
    
    find "$SITES_ROOT" -name "wp-config.php" -print0 | while IFS= read -r -d '' config_file; do
        
        WP_DIR=$(dirname "$config_file")
    
        if [ -f "$WP_DIR/wp-cron.php" ]; then
            echo "-> Uruchamiam cron dla: $WP_DIR" >> $LOG_FILE
            (cd "$WP_DIR" && "$PHP_EXECUTABLE" wp-cron.php)
        fi
    
    done
    
    echo "Zakończono: $(date)" >> $LOG_FILE
    echo "---" >> $LOG_FILE
    

    Krok 2 i 3 są analogiczne jak w scenariuszu 2: nadaj skryptowi uprawnienia (chmod +x) i dodaj jedną linię do crontab -e, wskazując na nowy plik skryptu.

    Podsumowanie

    Błąd „A scheduled event has failed” to nie powód do paniki, a raczej zaproszenie do ulepszenia swojej infrastruktury. To szansa, by przejść z zawodnego, wbudowanego mechanizmu WordPressa na solidne, profesjonalne rozwiązanie systemowe, które gwarantuje stabilność i wydajność.

    Niezależnie od konfiguracji serwera, teraz masz narzędzia, by spać spokojnie, wiedząc, że Twoje zaplanowane zadania wykonują się jak w szwajcarskim zegarku.

  • Jak uruchomić zadanie CRON co godzinę

    Jak uruchomić zadanie CRON co godzinę

    Istnieją pewne zadania na komputerze, które musimy wykonywać regularnie – na przykład wykonywanie kopii bezpieczeństwa. Do wykonywaniu takich powtarzalnych zadań w systemie Linux służy polecenie Cron – jest nieoceniony w wykonywaniu zadań które wymagają planowania. W tym artykule pokażemy Ci, jak skonfigurować crontab, by uruchamiał zadanie cron co godzinę. 

    Co to jest cron?

    Cron, to narzędzie, aplikacja służąca do planowania zadań, uruchamiania aplikacji i skryptów w określonym czasie w systemach operacyjnych typu Unix. Umożliwia on planowanie zadań (cykliczne uruchamianie aplikacji, lub skryptów powłoki) które będą się automatycznie uruchamiać o określonej godzinie i dacie. Zadania te nazywane są zadaniami cron.

    Cron w systemach Linux i Unix jest powszechnie używany do zadań konserwacyjnych lub administracyjnych, jak uruchamianie kopii zapasowych (z możliwością wysłania ich później na przykład na serwer FTP), czy wysyłanie zautomatyzowanych wiadomości e-mail. Cron można również stosować na przykład do sprawdzania dostępności aktualizacji systemu i wielu innych rzeczy.

    Cron do pracy wykorzystuje plik konfiguracyjny o nazwie crontab. Crontab, to zwykły plik tekstowy którego możemy edytować dowolnym edytorem tekstu. Administrator systemu ma możliwość skonfigurować globalny plik crontab z uprawnieniami root, a ponadto każdy z użytkowników może mieć własne ustawienia, ograniczone jednak prawami użytkownika.

    Zadanie cron jest zwykle wykonywane w tle, a jeśli występują jakieś dane wyjściowe, to mogą być wysyłane do użytkownika pocztą e-mail, lub zapisywane do pliku. Cron to potężne narzędzie pozwalające zautomatyzować praktycznie każde zadanie, jednak dla początkujących użytkowników może być trudny w obsłudze, jeśli nie znają składni potrzebnych poleceń.

    Do czego przyda nam się cron?

    Przy pomocy cron, możemy zarządzać praktycznie każdą funkcją komputera, czy serwera i uruchamiać cykliczne zadania o określonej godzinie i dacie. Możemy go wykorzysta na przykład do:

    • Automatyzacja powtarzalnych zadań. Zadanie cron może być używane do automatyzacji zadań w regularnych odstępach czasu, takich jak na przykład uruchamianie kopii zapasowych, lub wysyłania cyklicznych wiadomości e-mail, na przykład z przypomnieniami.
    • Uruchamianie zadań systemowych zgodnie z harmonogramem. Zadanie cron może nam sprawdzać, czy są dostępne aktualizacje systemu operacyjnego, bądź aplikacji, albo na przykład może regularnie czyścić komputer z plików tymczasowych i niepotrzebnych  logów systemowych.
    • Automatyczne wykonywanie aktualizacji systemu, aktualizowanie zabezpieczeń i instalacja nowego oprogramowania. Może to pomóc w lepszym zabezpieczeniu systemu i dzięki temu mamy pewność, że na naszym komputerze, czy serwerze zawsze mamy zainstalowane najnowsze wersje aplikacji i bibliotek.
    • Poprawa wydajności. Dzięki cron, możemy tak skonfigurować uruchamianie zadań mocno obciążających komputer, aby uruchamiały się w godzinach gdy komputer jest najmniej używany, na przykład w nocy.

    Ogólnie rzecz biorąc, cron może nam znacznie usprawnić wykonywanie cyklicznych zadań poprzez ich automatyzację.

    Stwórz zadanie cron w terminalu Linux

    Do tworzenia zadań cron służy polecenie crontab. Aby utworzyć nowe zadanie cron:

    • Otwórz okno terminala
    • Wpisz polecenie crontab -e aby otworzyć plik konfiguracyjne cron.
    • Dodaj nowy wpis do pliku crontab, pamiętając, aby zachować odpowiedni format, gdyż inaczej zadanie nie uruchomi się:

    minuta godzina dzień-miesiąca miesiąc dzień-tygodnia polecenie-do-wykonania

    Gwiazdka zamiast minut, godzin, czy miesiąca oznacza, że to zadanie będzie się uruchamiać każdej godziny, minuty, czy każdego miesiąca. Na przykład, jeśli chcemy, by polecenie, lub skrypt uruchamiał się o każdej pełnej godzinie (czyli w minucie 0) każdego dnia każdego miesiąca, musimy wpisać:

    0 * * * * polecenie-do-wykonania

    • Zapisz plik crontab  i zamknij.
    • Użyj polecenia crontab -l aby wyświetlić listę zapisanych zadań cron do wykonania.

    UWAGA: Składnia poleceń zadań cron może się różnić w zależności od wersji systemu Linux. My bazujemy na systemie Ubuntu. Aby dowiedzieć się więcej o aplikacji cron, wpisz w terminalu man cron

    Jak utworzyć zadanie cron w CyberPanel

    Jeśli Twój serwer www oparty jest na LiteSpeed, to powinieneś zainstalować nakładkę CyberPanel. Tworzenie zadań cron w CyberPanel jest o wiele prostsze i przyjemniejsze niż w pliku crontab.

    • Zaloguj się do Dashboard swojego CyberPanel.
    • Kliknij po lewej stronie Websites, a następnie List Websites i wybierz swoją stronę internetową i kliknij Manage
    CyberPanel Website manage
    • Przewiń w dół i kliknij na Cron Jobs
    CyberPanel WordPress cron jobs
    • Aby dodać nowe zadanie cron, naciśnij ADD CRON. Aby zobaczyć listę istniejących zadań, kliknij FETCH CURRENT CRON JOBS
    CyberPanel Add cron job Fetch
    • Aby dane zadanie uruchamiało się co tydzień, wybierz z listy Every week. W poniższym przykładzie cron uruchomi napisany wcześniej skrypt do wykonywania kopii bezpieczeństwa co tydzień, każdej środy o godzinie 4:16 w nocy. W oknie Day of week wpisujemy cyfry od 0 do 7.
    • 0 i 7 oznacza niedzielę, 1 poniedziałek, 2 wtorek itd
    • Możemy również wpisać dni tygodnia słownie po angielsku: mon, tue, wed, thu, fri, sat, lub sun
    • Naciśnij Add cron aby zapisać utworzone zadanie
    CyberPanel WordPress cron weekly

    Prawda, że w CyberPanel konfiguruje się cron przyjemniej?