Kategoria: Optymalizacja

  • Pełna Kontrola nad Aplikacjami w TrueNAS Scale przez SSH

    Pełna Kontrola nad Aplikacjami w TrueNAS Scale przez SSH

    TrueNAS Scale, dzięki swojemu potężnemu interfejsowi webowemu, sprawia, że instalacja i podstawowe zarządzanie aplikacjami jest proste i intuicyjne. Jednak każdy zaawansowany użytkownik prędzej czy później odkryje, że prawdziwa moc i elastyczność kryją się w wierszu poleceń. Warto zaznaczyć, że od wersji 24.04 (Electric Eel), TrueNAS Scale przeszło istotną transformację, rezygnując z dotychczasowego systemu k3s (lekka dystrybucja Kubernetes) na rzecz natywnego zarządzania kontenerami za pomocą Dockera. Ta zmiana znacząco uprościła architekturę i sprawiła, że bezpośrednia praca z kontenerami stała się bardziej przystępna.

    Prawdziwą swobodę daje bezpośrednie połączenie przez SSH, które omija ograniczenia terminala w przeglądarce. Pozwala ono przekształcić się ze zwykłego użytkownika w świadomego administratora, który potrafi zajrzeć „pod maskę” każdej aplikacji, diagnozować problemy w czasie rzeczywistym i zarządzać systemem z precyzją niedostępną z poziomu interfejsu graficznego. Ten artykuł to kompleksowy przewodnik po zarządzaniu aplikacjami w TrueNAS Scale przy użyciu terminala, oparty właśnie na natywnych komendach Dockera, które stały się nowym fundamentem systemu aplikacji.

    Krok 1: Identyfikacja Uruchomionych Aplikacji

    Zanim zaczniemy zarządzać aplikacjami, musimy wiedzieć, co w ogóle działa w naszym systemie. Interfejs graficzny pokazuje nam nazwy aplikacji, ale terminal da nam wgląd w faktyczne kontenery.

    Listowanie Kontenerów: docker ps

    Podstawowym poleceniem jest docker ps. Wyświetla ono listę wszystkich aktualnie uruchomionych kontenerów.

    docker ps
    
    

    Wynik tego polecenia to tabela z kluczowymi informacjami:

    • CONTAINER ID: Unikalny identyfikator.
    • IMAGE: Nazwa obrazu, z którego stworzono kontener.
    • STATUS: Informacja, jak długo kontener jest uruchomiony.
    • PORTS: Mapowanie portów.
    • NAMES: Najważniejsza dla nas informacja – przyjazna nazwa kontenera, której będziemy używać w kolejnych poleceniach (np. ix-jellyfin-jellyfin-1).

    Jeśli chcesz zobaczyć również zatrzymane kontenery, dodaj flagę -a: docker ps -a.

    Monitorowanie Zasobów w Czasie Rzeczywistym: docker stats

    Jeszcze lepszym sposobem na szybki przegląd jest docker stats. Ta komenda wyświetla dynamiczną, aktualizowaną na żywo tabelę pokazującą zużycie CPU, pamięci RAM i zasobów sieciowych przez każdy kontener. To idealne narzędzie, aby na pierwszy rzut oka zidentyfikować, która aplikacja obciąża system.

    docker stats
    
    

    Krok 2: Wejście do Wnętrza Kontenera – docker exec

    Gdy już zidentyfikujesz kontener, możesz wejść do jego środka, aby przeglądać pliki, edytować konfigurację czy prowadzić zaawansowaną diagnostykę.

    docker exec -it ix-jellyfin-jellyfin-1 /bin/bash
    
    

    Przeanalizujmy to polecenie:

    • docker exec: Wykonaj polecenie w działającym kontenerze.
    • -it: Kluczowe flagi oznaczające sesję interaktywną (-i) z przydzielonym pseudo-terminalem (-t).
    • ix-jellyfin-jellyfin-1: Nazwa naszego kontenera.
    • /bin/bash: Polecenie, które chcemy uruchomić wewnątrz – w tym przypadku powłokę Bash.

    Po wykonaniu polecenia, znak zachęty w terminalu zmieni się, informując, że jesteś teraz „wewnątrz”. Możesz swobodnie poruszać się po systemie plików kontenera za pomocą komend ls, cd itd. Aby wyjść i wrócić do TrueNAS, po prostu wpisz exit lub użyj skrótu Ctrl + D.

    Dlaczego Brakuje Narzędzi (top, ps, nano)?

    Podczas pracy wewnątrz kontenera możesz natknąć się na błędy typu command not found. Jest to celowe działanie. Wiele nowoczesnych obrazów Docker (w tym oficjalny Jellyfin) to tzw. obrazy minimalistyczne lub „distroless”. Nie zawierają one żadnych dodatkowych narzędzi, a jedynie samą aplikację i jej biblioteki. Jest to praktyka zwiększająca bezpieczeństwo i zmniejszająca rozmiar obrazu.

    W takim przypadku musisz polegać na narzędziach zewnętrznych, dostarczanych przez samego Dockera.

    Krok 3: Diagnostyka i Rozwiązywanie Problemów

    Gdy aplikacja nie działa poprawnie, terminal jest Twoim najlepszym przyjacielem.

    Przeglądanie Logów: docker logs

    To najważniejsza komenda diagnostyczna. Wyświetla ona wszystko, co aplikacja zapisała w swoich dziennikach.

    docker logs ix-nextcloud-nextcloud-1
    
    

    Jeśli chcesz śledzić logi na żywo, dodaj flagę -f (--follow):

    docker logs -f ix-nextcloud-nextcloud-1
    
    

    Szczegółowa Inspekcja: docker inspect

    Komenda docker inspect zwraca ogromną ilość szczegółowych informacji o kontenerze w formacie JSON – jego adres IP, podpięte wolumeny, zmienne środowiskowe i wiele więcej.

    docker inspect ix-tailscale-tailscale-1
    
    

    Krok 4: Zarządzanie Plikami i Cyklem Życia Aplikacji

    Terminal daje Ci pełną kontrolę nad plikami i stanem Twoich aplikacji.

    Kopiowanie Plików: docker cp

    To niezwykle użyteczna komenda do przenoszenia plików pomiędzy systemem TrueNAS a kontenerem, bez potrzeby wchodzenia do środka.

    • Kopiowanie z kontenera do TrueNAS (np. backup konfiguracji):docker cp ix-nginx-proxy-manager-npm-1:/data/nginx /mnt/TwojaPula/backupy/
    • Kopiowanie z TrueNAS do kontenera:docker cp /mnt/TwojaPula/dane/nowy-certyfikat.pem ix-nginx-proxy-manager-npm-1:/data/custom_ssl/

    Kontrolowanie Stanu Aplikacji

    Zamiast klikać w interfejsie graficznym, możesz szybko zarządzać aplikacjami:

    • Zatrzymanie aplikacji:docker stop ix-qbittorrent-qbittorrent-1
    • Uruchomienie zatrzymanej aplikacji:docker start ix-qbittorrent-qbittorrent-1
    • Restart aplikacji (najczęstsza operacja):docker restart ix-qbittorrent-qbittorrent-1

    Od Użytkownika do Administratora

    Opanowanie kilku podstawowych komend Dockera w terminalu SSH otwiera zupełnie nowy wymiar zarządzania TrueNAS Scale. Przestajesz być zależny od ograniczeń interfejsu graficznego i zyskujesz narzędzia, które pozwalają Ci zrozumieć, jak naprawdę działają Twoje aplikacje.

    Możliwość szybkiego sprawdzenia logów, monitorowania zasobów w czasie rzeczywistym, edycji dowolnego pliku konfiguracyjnego czy zrobienia błyskawicznego backupu – to wszystko sprawia, że praca z systemem staje się bardziej efektywna, a rozwiązywanie problemów szybsze. Połączenie przez SSH to nie tylko wygoda, to fundamentalne narzędzie każdego świadomego administratora, który chce mieć pełną kontrolę nad swoim serwerem.

  • Koniec z natrętnymi reklamami: Jak odzyskać kontrolę nad Internetem w domu i poza nim dzięki AdGuard Home.

    Koniec z natrętnymi reklamami: Jak odzyskać kontrolę nad Internetem w domu i poza nim dzięki AdGuard Home.

    Współczesny internet to pole bitwy o naszą uwagę, a główną amunicją stały się reklamy. Szczególnie dotkliwie odczuwamy to na smartfonach, gdzie nachalne banery i wyskakujące okna potrafią skutecznie zniechęcić do przeglądania treści. Istnieje jednak skuteczne i kompleksowe rozwiązanie, które pozwala stworzyć własną tarczę ochronną – nie tylko w domowej sieci, ale na każdym urządzeniu, gdziekolwiek jesteś.

    Problem: Cyfrowe zaśmiecenie i utrata prywatności

    Każdy, kto próbował przeczytać artykuł na smartfonie, zna ten scenariusz: treść jest regularnie przerywana przez reklamy, które zajmują znaczną część ekranu, spowalniają ładowanie strony i zużywają cenne dane mobilne. Problem ten, choć irytujący na komputerach stacjonarnych, na mniejszych ekranach urasta do rangi poważnej bariery w dostępie do informacji.

    Tradycyjne wtyczki do przeglądarek rozwiązują problem tylko częściowo i na jednym urządzeniu. Nie chronią nas w aplikacjach mobilnych, na telewizorach Smart TV czy konsolach do gier. Co gorsza, wszechobecne skrypty śledzące zbierają dane o naszej aktywności, tworząc szczegółowe profile marketingowe.

    Rozwiązanie: Centralne zarządzanie z AdGuard Home

    Odpowiedzią jest AdGuard Home – oprogramowanie działające jako serwer DNS, które filtruje ruch na poziomie całej sieci. Instalując je na domowym serwerze, takim jak popularny TrueNAS, zyskujemy centralny punkt kontroli nad wszystkimi urządzeniami podłączonymi do naszej sieci.

    AdGuard Dashboard

    Instalacja i konfiguracja AdGuard Home na TrueNAS jest prosta dzięki systemowi aplikacji (Apps). Kluczowym krokiem podczas instalacji jest zaznaczenie opcji „Host Network”. Dzięki temu AdGuard Home będzie widział rzeczywiste adresy IP urządzeń w Twojej sieci, co pozwoli na precycyjne monitorowanie i zarządzanie klientami w panelu administracyjnym. Bez tej opcji wszystkie zapytania wyglądałyby, jakby pochodziły z jednego adresu IP serwera.

    Po instalacji, kluczowym krokiem jest skierowanie zapytań DNS ze wszystkich urządzeń na adres naszego serwera AdGuard. Można to osiągnąć na kilka sposobów, jednak dzięki Tailscale proces ten staje się niezwykle prosty.

    Tradycyjne metody vs. podejście z Tailscale:

    W klasycznym podejściu, aby skierować ruch na AdGuard Home, musielibyśmy zmienić adresy DNS w ustawieniach routera. Gdy jest to niemożliwe (co często ma miejsce w przypadku sprzętu od dostawcy internetu), alternatywą jest skonfigurowanie AdGuard Home jako serwera DHCP, który automatycznie przekaże urządzeniom właściwy adres DNS (wymaga to wyłączenia serwera DHCP na routerze). Ostatecznością jest ręczna zmiana DNS na każdym urządzeniu w domu. Należy jednak podkreślić, że wszystkie te metody działają wyłącznie w sieci lokalnej i są całkowicie nieskuteczne dla urządzeń mobilnych korzystających z danych komórkowych poza domem.

    Jednakże, jeśli planujemy używać Tailscale do ochrony poza domem, możemy wykorzystać go również do konfiguracji sieci lokalnej. To niezwykle eleganckie rozwiązanie: jeśli zainstalujemy klienta Tailscale na wszystkich naszych urządzeniach (komputerach, telefonach) i w jego panelu administracyjnym ustawimy adres DNS naszego serwera AdGuard, włączając opcję „Override local DNS”, nie musimy wprowadzać żadnych zmian w routerze ani ręcznie na poszczególnych urządzeniach. Tailscale automatycznie zmusi każde urządzenie w naszej wirtualnej sieci do korzystania z AdGuard, niezależnie od tego, z jaką siecią fizyczną jest połączone.

    Tailscale DNS Settings

    Funkcje AdGuard Home to znacznie więcej niż blokowanie reklam:

    • Ochrona przed złośliwym oprogramowaniem: Automatycznie blokuje dostęp do stron znanych z phishingu, malware’u i oszustw.
    • Kontrola rodzicielska: Umożliwia włączenie blokady stron z treściami dla dorosłych, co jest nieocenioną funkcją w domach z dziećmi.
    • Personalizacja filtrów: Możemy korzystać z gotowych, regularnie aktualizowanych list filtrów lub dodawać własne reguły.
    • Szczegółowe statystyki: Panel pokazuje, jakie zapytania są blokowane, które urządzenia są najbardziej aktywne i jakie domeny generują najwięcej ruchu.

    Dla zaawansowanych użytkowników przydatna jest możliwość zarządzania klientami. Każdemu urządzeniu w sieci można nadać przyjazną nazwę (np. „Laptop-Ania”, „Telefon-Tomek”) i przypisać mu indywidualne reguły filtrowania. W moim przypadku, dla serwerów VPS, które nie wymagają blokowania reklam, ustawiłem domyślne serwery DNS (np. 1.1.1.1 i 8.8.8.8), dzięki czemu ich ruch jest ignorowany przez filtry AdGuard.

    Wyzwanie: Blokowanie reklam poza siecią domową

    O ile ochrona w sieci lokalnej jest już potężnym narzędziem, prawdziwa wolność od reklam pojawia się, gdy możemy korzystać z niej poza domem. Standardowo, gdy smartfon łączy się z siecią komórkową, traci kontakt z domowym serwerem AdGuard. Próba wystawienia serwera DNS na świat przez forwarding portów w routerze jest nie tylko niebezpieczna, ale i nieskuteczna. Większość systemów mobilnych, jak Android i iOS, nie pozwala na zmianę serwera DNS dla połączeń komórkowych, uniemożliwiając takie rozwiązanie. Tu z pomocą przychodzi Tailscale.

    Tailscale: Twoja prywatna sieć w dowolnym miejscu

    Tailscale to usługa oparta na protokole WireGuard, która tworzy bezpieczną, wirtualną sieć prywatną (tzw. Tailnet) pomiędzy Twoimi urządzeniami. Niezależnie od tego, gdzie się znajdują, komputery, serwery i telefony mogą komunikować się ze sobą tak, jakby były w tej samej sieci lokalnej.

    Instalacja Tailscale na TrueNAS oraz na urządzeniach mobilnych jest błyskawiczna. Po zalogowaniu się na to samo konto, wszystkie urządzenia widzą się nawzajem w panelu administracyjnym Tailscale. Aby połączyć moc obu narzędzi, należy wykonać kluczowe kroki:

    1. W panelu administracyjnym Tailscale, w zakładce DNS, włączamy opcję Override local DNS.
    2. Jako globalny serwer DNS wpisujemy adres IP naszego serwera TrueNAS w sieci Tailnet (np. 100.x.x.x).

    Dzięki tej konfiguracji, cały ruch DNS z naszego telefonu, nawet gdy korzysta on z sieci 5G na drugim końcu kraju, jest bezpiecznym tunelem przesyłany do serwera Tailscale na TrueNAS, a następnie przetwarzany przez AdGuard Home. Efekt? Reklamy, moduły śledzące i złośliwe strony są blokowane na Twoim telefonie zawsze i wszędzie.

    Zaawansowane funkcje Tailscale: Subnet Routes i Exit Node

    Tailscale oferuje dwie potężne funkcje, które dodatkowo rozszerzają możliwości naszej sieci:

    • Subnet routes: Pozwala udostępnić całą domową sieć LAN (np. 192.168.1.0/24) urządzeniom w sieci Tailnet. Po skonfigurowaniu serwera TrueNAS jako „routera podsieci”, Twój telefon będący poza domem może uzyskać dostęp nie tylko do samego serwera, ale także do drukarki, kamery IP czy innych urządzeń w sieci lokalnej, tak jakbyś był w domu.
    • Exit node: Ta funkcja zamienia Twój domowy serwer w pełnoprawny serwer VPN. Po aktywacji, cały ruch internetowy z z Twojej sieci tailnet (nie tylko zapytania DNS) jest tunelowany przez domowe łącze internetowe. To idealne rozwiązanie, gdy korzystasz z niezaufanych, publicznych sieci Wi-Fi (np. w hotelu czy na lotnisku), ponieważ cały ruch jest szyfrowany i chroniony. Jeśli Twój domowy serwer znajduje się w Polsce, zyskujesz też polski adres IP, będąc za granicą.

    Sprawdzenie skuteczności blokowania reklam

    Aby dowiedzieć się jak skuteczne są Twoje filtry antyreklamowe, możesz wejść na stronę https://adblock.turtlecute.org/ Tam dowiesz się jakiego typu reklamy są blokowane, a jakie są nadal wyświetlane. To pozwoli Ci lepiej dopasować Twoją listę filtrów w AdGuard Home.

    Turtlecute

    Podsumowanie: Zalety i wady

    Stworzenie takiego systemu to inwestycja czasu, ale korzyści są nie do przecenienia.

    Zalety:

    • Kompletna i ujednolicona ochrona: Blokowanie reklam i zagrożeń na wszystkich urządzeniach, w każdej sieci, przy minimalnej konfiguracji.
    • Centralne zarządzanie: Jedno miejsce do konfiguracji reguł dla całego domu.
    • Zwiększona prywatność i bezpieczeństwo: Ograniczenie śledzenia i szyfrowanie ruchu w publicznych sieciach.
    • Wydajność: Szybsze ładowanie stron i mniejsze zużycie danych mobilnych.

    Wady:

    • Wymóg posiadania serwera: Konieczność działania 24/7 urządzenia takiego jak TrueNAS.
    • Wstępna konfiguracja: Wymaga podstawowej wiedzy technicznej.
    • Zależność od domowego łącza: Prędkość odpowiedzi DNS i przepustowość (w trybie Exit Node) poza domem zależy od szybkości wysyłania danych (upload) Twojego internetu.

    Połączenie AdGuard Home i Tailscale to potężne narzędzie dla każdego, kto ceni sobie czysty, szybki i bezpieczny internet. To manifest cyfrowej niezależności, który oddaje kontrolę z rąk korporacji reklamowych z powrotem w ręce użytkownika.

  • Nginx Proxy Manager na TrueNAS Scale: Instalacja, Konfiguracja i Rozwiązywanie Problemów

    Nginx Proxy Manager na TrueNAS Scale: Instalacja, Konfiguracja i Rozwiązywanie Problemów

    Sekcja 1: Wprowadzenie: Upraszczanie Dostępu do Domowego Laboratorium za Pomocą Nginx Proxy Manager na TrueNAS Scale

    Współczesne domowe laboratoria (home labs) ewoluowały z prostych konfiguracji do złożonych ekosystemów, w których działają dziesiątki usług, od serwerów multimediów takich jak Plex czy Jellyfin, przez systemy automatyki domowej jak Home Assistant, po osobiste chmury i menedżery haseł. Zarządzanie dostępem do każdej z tych usług, z których każda operuje na unikalnej kombinacji adresu IP i numeru portu, szybko staje się niepraktyczne, niewygodne i, co najważniejsze, niebezpieczne. Ekspozycja wielu portów na świat zewnętrzny zwiększa powierzchnię ataku i komplikuje utrzymanie spójnej polityki bezpieczeństwa.

    Rozwiązaniem tego problemu, stosowanym od lat w środowiskach korporacyjnych, jest implementacja centralnej „bramy” lub „pojedynczego punktu wejścia” dla całego ruchu przychodzącego. W terminologii sieciowej rolę tę pełni odwrotne proxy (reverse proxy). Jest to serwer pośredniczący, który odbiera wszystkie żądania od klientów, a następnie, na podstawie nazwy domenowej, kieruje je do odpowiedniej usługi działającej w sieci wewnętrznej. Taka architektura nie tylko upraszcza dostęp, pozwalając na używanie łatwych do zapamiętania adresów (np.

    jellyfin.mojadomena.pl zamiast 192.168.1.50:8096), ale także stanowi kluczowy element strategii bezpieczeństwa.

    W tym kontekście dwie technologie zyskują na szczególnej popularności wśród entuzjastów: TrueNAS Scale i Nginx Proxy Manager. TrueNAS Scale, bazujący na systemie Debian Linux, przekształcił tradycyjne urządzenie NAS (Network Attached Storage) w potężną, hiperkonwergentną platformę (HCI), zdolną do natywnego uruchamiania aplikacji w kontenerach i maszyn wirtualnych. Z kolei Nginx Proxy Manager (NPM) to narzędzie, które demokratyzuje technologię odwrotnego proxy. Nakłada ono przyjazny dla użytkownika, graficzny interfejs na potężny, ale skomplikowany w konfiguracji serwer Nginx, czyniąc zaawansowane funkcje, takie jak automatyczne zarządzanie certyfikatami SSL, dostępnymi bez konieczności edycji plików konfiguracyjnych z linii poleceń.

    Niniejszy artykuł stanowi kompleksowe omówienie procesu wdrożenia Nginx Proxy Manager na platformie TrueNAS Scale. Celem jest nie tylko przedstawienie instrukcji „jak to zrobić”, ale przede wszystkim wyjaśnienie „dlaczego” poszczególne kroki są niezbędne. Analiza rozpocznie się od dogłębnego omówienia obu technologii i ich wzajemnych interakcji. Następnie, przeprowadzony zostanie szczegółowy proces instalacji, z uwzględnieniem specyficznych dla platformy wyzwań i ich rozwiązań, w tym znanego problemu z zawieszaniem się aplikacji w stanie „Deploying”. W dalszej części, na praktycznym przykładzie serwera mediów Jellyfin, zademonstrowana zostanie konfiguracja hosta proxy wraz z zaawansowanymi opcjami bezpieczeństwa. Raport zakończy się podsumowaniem korzyści i wskazaniem dalszych kroków w celu pełnego wykorzystania potencjału tego potężnego duetu.

    Sekcja 2: Analiza Narzędzi: Nginx Proxy Manager i Ekosystem Aplikacji TrueNAS Scale

    Zrozumienie fundamentalnych zasad działania Nginx Proxy Manager oraz architektury, w której jest on wdrażany – czyli systemu aplikacji TrueNAS Scale – jest kluczowe dla pomyślnej instalacji, efektywnej konfiguracji i, co najważniejsze, skutecznego diagnozowania ewentualnych problemów. Te dwa komponenty, choć zaprojektowane do współpracy, posiadają własną, unikalną specyfikę, której ignorowanie jest najczęstszą przyczyną niepowodzeń.

    Podsekcja 2.1: Zrozumieć Nginx Proxy Manager (NPM)

    U podstaw funkcjonalności NPM leży koncepcja odwrotnego proxy, która jest fundamentalna dla nowoczesnej architektury sieciowej. Zrozumienie jej działania pozwala docenić wartość, jaką wnosi NPM.

    Definicja i Funkcje Odwrotnego Proxy

    Odwrotne proxy to serwer, który działa jako pośrednik po stronie serwera. W przeciwieństwie do tradycyjnego (forward) proxy, które działa w imieniu klienta, odwrotne proxy działa w imieniu serwera (lub grupy serwerów). Odbiera ono żądania od klientów z Internetu i przekazuje je do odpowiednich serwerów w sieci lokalnej, które faktycznie przechowują treść. Dla klienta zewnętrznego odwrotne proxy jest jedynym widocznym punktem kontaktowym; wewnętrzna struktura sieci pozostaje ukryta.

    Kluczowe korzyści płynące z tego rozwiązania to:

    • Bezpieczeństwo: Ukrywanie topologii sieci wewnętrznej i rzeczywistych adresów IP serwerów aplikacyjnych znacząco utrudnia bezpośrednie ataki na te usługi.
    • Centralizacja zarządzania SSL/TLS (SSL Termination): Zamiast konfigurować certyfikaty SSL na każdym z kilkunastu serwerów aplikacyjnych, można zarządzać nimi w jednym miejscu – na odwrotnym proxy. Szyfrowanie i deszyfrowanie ruchu (SSL Termination) odbywa się na serwerze proxy, co odciąża serwery backendowe.
    • Równoważenie obciążenia (Load Balancing): W bardziej zaawansowanych scenariuszach, odwrotne proxy może rozdzielać ruch pomiędzy wiele identycznych serwerów aplikacyjnych, zapewniając wysoką dostępność i skalowalność usługi.
    • Uproszczony dostęp: Umożliwia dostęp do wielu usług za pośrednictwem standardowych portów 80 (HTTP) i 443 (HTTPS) przy użyciu różnych subdomen, eliminując potrzebę zapamiętywania i otwierania wielu portów.

    NPM jako Warstwa Zarządzania

    Należy podkreślić, że Nginx Proxy Manager nie jest nowym, konkurencyjnym dla Nginx serwerem WWW. Jest to aplikacja zarządzająca, zbudowana na bazie otwartego kodu źródłowego Nginx, która pełni rolę graficznej nakładki (GUI) na jego funkcje odwrotnego proxy. Zamiast ręcznie edytować złożone pliki konfiguracyjne Nginx, użytkownik może wykonywać te same operacje za pomocą kilku kliknięć w intuicyjnym interfejsie webowym.

    Główne cechy, które przyczyniły się do popularności NPM, to:

    • Graficzny interfejs użytkownika: Oparty na frameworku Tabler, interfejs jest przejrzysty i łatwy w obsłudze, co drastycznie obniża próg wejścia dla użytkowników niebędących ekspertami od Nginx.
    • Automatyzacja SSL: Wbudowana integracja z Let’s Encrypt pozwala na automatyczne, darmowe generowanie certyfikatów SSL oraz ich cykliczne odnawianie. To jedna z najważniejszych i najbardziej docenianych funkcji.
    • Wdrożenie oparte na Dockerze: NPM jest dystrybuowany jako gotowy do użycia obraz Docker, co sprawia, że jego instalacja na dowolnej platformie wspierającej kontenery jest niezwykle prosta.
    • Zarządzanie dostępem: Narzędzie oferuje funkcje tworzenia list kontroli dostępu (Access Control Lists, ACL) oraz zarządzania użytkownikami z różnymi poziomami uprawnień, co pozwala na granularne kontrolowanie dostępu do poszczególnych usług.

    Porównanie: NPM vs. Tradycyjny Nginx

    Wybór między Nginx Proxy Manager a ręczną konfiguracją Nginx to klasyczny kompromis między prostotą a elastycznością. Poniższa tabela zestawia kluczowe różnice między tymi dwoma podejściami.

    Tabela 1: Nginx Proxy Manager vs. Tradycyjny Nginx

    AspektNginx Proxy ManagerTradycyjny Nginx
    Interfejs ZarządzaniaGraficzny interfejs użytkownika (GUI) upraszczający konfigurację.Interfejs linii poleceń (CLI) i edycja plików tekstowych; wymaga wiedzy technicznej.
    Konfiguracja SSLW pełni zautomatyzowane generowanie i odnawianie certyfikatów Let’s Encrypt.Ręczna konfiguracja za pomocą narzędzi takich jak Certbot; większa kontrola.
    Krzywa uczeniaNiska; idealne dla początkujących i hobbystów.Stroma; wymaga zrozumienia dyrektyw Nginx i architektury serwerów WWW.
    ElastycznośćOgraniczona do funkcji dostępnych w GUI; zaawansowane reguły mogą być trudne do implementacji.Pełna elastyczność i możliwość tworzenia wysoce niestandardowych, złożonych konfiguracji.
    SkalowalnośćIdealny dla domowych laboratoriów, małych i średnich wdrożeń.Lepszy wybór dla środowisk korporacyjnych o dużej skali i wysokim obciążeniu.
    Docelowy użytkownikHobbysta, właściciel małej firmy, użytkownik domowego laboratorium.Administrator systemów, inżynier DevOps, programista.

    Tabela ta jasno pokazuje, że NPM jest narzędziem strategicznie dopasowanym do potrzeb docelowej publiczności – entuzjastów domowych laboratoriów. Użytkownicy ci świadomie rezygnują z części zaawansowanej elastyczności na rzecz ogromnych korzyści w postaci prostoty obsługi i szybkości wdrożenia.

    Podsekcja 2.2: Architektura Aplikacji w TrueNAS Scale

    Aby zrozumieć, dlaczego instalacja NPM na TrueNAS Scale może napotkać specyficzne problemy, konieczne jest poznanie sposobu, w jaki ta platforma zarządza aplikacjami. Nie jest to bowiem typowe środowisko Docker.

    Fundamenty: Linux i Hiperkonwergencja

    Kluczową zmianą architektoniczną w TrueNAS Scale w stosunku do jego poprzednika, TrueNAS CORE, było przejście z systemu operacyjnego FreeBSD na Debiana, dystrybucję Linuksa. Ta decyzja otworzyła drzwi do natywnego wsparcia dla technologii, które zdominowały świat chmury i konteneryzacji, przede wszystkim dla kontenerów Docker i wirtualizacji opartej na KVM. Dzięki temu TrueNAS Scale stał się platformą hiperkonwergentną, łączącą w sobie funkcje pamięci masowej, obliczeń i wirtualizacji.

    System Aplikacji

    Aplikacje są dystrybuowane za pośrednictwem katalogów (Catalogs), które działają na zasadzie repozytoriów. Te katalogi są z kolei podzielone na tzw. „trainy” (pociągi), które określają stabilność i źródło aplikacji:

    • stable: Domyślny „train” dla oficjalnych, przetestowanych przez iXsystems aplikacji.
    • enterprise: Aplikacje zweryfikowane pod kątem zastosowań biznesowych.
    • community: Aplikacje tworzone i utrzymywane przez społeczność. To tutaj domyślnie znajduje się Nginx Proxy Manager.
    • test: Aplikacje w fazie deweloperskiej.

    Przynależność NPM do katalogu community oznacza, że choć jest on łatwo dostępny, jego wsparcie techniczne opiera się na społeczności, a nie bezpośrednio na producencie TrueNAS.

    Zarządzanie Pamięcią Masową dla Aplikacji

    Zanim jakakolwiek aplikacja zostanie zainstalowana, TrueNAS Scale wymaga od użytkownika wskazania puli ZFS, która będzie dedykowana do przechowywania danych aplikacji. Kiedy aplikacja jest instalowana, jej dane (konfiguracja, bazy danych itp.) muszą być gdzieś zapisane w sposób trwały. TrueNAS Scale oferuje tu kilka opcji, ale domyślną i rekomendowaną dla prostoty jest

    ixVolume.

    ixVolume to specjalny typ woluminu, który automatycznie tworzy dedykowany, zarządzany przez system zbiór danych (ZFS dataset) wewnątrz wybranej puli aplikacji. Ten zbiór danych jest odizolowany, a system nadaje mu bardzo specyficzne uprawnienia. Domyślnie, właścicielem tego zbioru danych staje się użytkownik systemowy

    apps o identyfikatorze (UID) 568 i grupie (GID) 568. Kontener uruchomionej aplikacji również działa z uprawnieniami tego właśnie użytkownika.

    To jest sedno problemu. Standardowy obraz Docker dla Nginx Proxy Manager zawiera skrypty startowe (np. te pochodzące z Certbota, narzędzia do obsługi certyfikatów), które przy pierwszym uruchomieniu próbują zmienić właściciela (chown) katalogów z danymi, takich jak /data czy /etc/letsencrypt, aby upewnić się, że mają do nich odpowiednie uprawnienia. Kiedy kontener NPM startuje wewnątrz sandboksowego środowiska aplikacji TrueNAS, jego skrypt startowy, działając jako nieuprzywilejowany użytkownik apps (UID 568), próbuje wykonać operację chown na woluminie ixVolume. Operacja ta kończy się niepowodzeniem, ponieważ użytkownik apps nie jest właścicielem nadrzędnych katalogów i nie ma uprawnień do zmiany właściciela plików na woluminie zarządzanym przez K3s. Ten błąd uprawnień powoduje, że skrypt startowy kontenera zatrzymuje się, a sam kontener nigdy nie osiąga stanu „uruchomiony”, co w interfejsie TrueNAS Scale objawia się jako niekończący się stan „Deploying”.

    Sekcja 3: Instalacja i Konfiguracja Nginx Proxy Manager na TrueNAS Scale

    Proces instalacji Nginx Proxy Manager na TrueNAS Scale jest prosty, pod warunkiem zwrócenia uwagi na kilka kluczowych parametrów konfiguracyjnych, które są często źródłem problemów. Poniższa instrukcja krok po kroku przeprowadzi przez ten proces, podkreślając krytyczne decyzje, które należy podjąć.

    Krok 1: Przygotowanie TrueNAS Scale

    Przed przystąpieniem do instalacji jakiejkolwiek aplikacji, należy upewnić się, że usługa aplikacji w TrueNAS Scale jest poprawnie skonfigurowana.

    1. Należy zalogować się do interfejsu webowego TrueNAS Scale.
    2. Przejść do sekcji Apps.
    3. Jeśli usługa nie jest jeszcze skonfigurowana, system wyświetli monit o wybranie puli ZFS, która będzie używana do przechowywania danych wszystkich aplikacji. Należy wybrać odpowiednią pulę i zapisać ustawienia. Po chwili status usługi powinien zmienić się na „Running”.

    Krok 2: Znalezienie Aplikacji

    Nginx Proxy Manager jest dostępny w oficjalnym katalogu społecznościowym.

    1. W sekcji Apps należy przejść do zakładki Discover.
    2. W polu wyszukiwania wpisać nginx-proxy-manager.
    3. W wynikach powinna pojawić się aplikacja. Należy upewnić się, że pochodzi z katalogu community.
    4. Kliknąć przycisk Install, aby przejść do ekranu konfiguracji.

    Krok 3: Kluczowe Parametry Konfiguracji

    Ekran instalacji przedstawia wiele opcji. Większość z nich można pozostawić z domyślnymi wartościami, jednak kilka sekcji wymaga szczególnej uwagi.

    Application Name

    W polu Application Name należy wpisać nazwę dla instalacji, na przykład nginx-proxy-manager. Nazwa ta będzie używana do identyfikacji aplikacji w systemie.

    Network Configuration (Konfiguracja Sieci)

    To jest najważniejszy i najbardziej problematyczny etap konfiguracji. Domyślnie, interfejs zarządzania TrueNAS Scale używa standardowych portów webowych: 80 dla HTTP i 443 dla HTTPS. Ponieważ Nginx Proxy Manager, aby działać jako brama dla całego ruchu webowego, również powinien nasłuchiwać na tych portach, dochodzi do bezpośredniego konfliktu. Istnieją dwie główne strategie rozwiązania tego problemu, każda z własnym zestawem kompromisów.

    • Strategia A (Rekomendowana): Zmiana portów TrueNAS ScaleTa metoda jest uważana za „najczystszą” z perspektywy NPM, ponieważ pozwala mu działać w sposób, do jakiego został zaprojektowany.
      1. Należy anulować instalację NPM i przejść do System Settings -> General.W sekcji GUI SSL/TLS Certificate, zmienić Web Interface HTTP Port na niestandardowy, np. 880, oraz Web Interface HTTPS Port na np. 8443.Zapisać zmiany. Od tego momentu dostęp do interfejsu TrueNAS Scale będzie możliwy pod adresem http://<adres-ip-truenas>:880 lub https://<adres-ip-truenas>:8443.Powrócić do instalacji NPM i w sekcji Network Configuration przypisać HTTP Port do 80 i HTTPS Port do 443.
      • Zalety: NPM działa na standardowych portach, co upraszcza konfigurację i eliminuje potrzebę translacji portów na routerze.
      • Wady: Zmienia fundamentalny sposób dostępu do samego NAS-a. W rzadkich przypadkach, jak odnotowano na forach, może to powodować nieprzewidziane skutki uboczne, takie jak problemy z połączeniami SSH między systemami TrueNAS.
    • Strategia B (Alternatywna): Użycie wysokich portów dla NPMTa metoda jest mniej inwazyjna dla konfiguracji samego TrueNAS, ale przenosi złożoność na poziom routera.
      1. W konfiguracji NPM, w sekcji Network Configuration, należy pozostawić porty TrueNAS bez zmian i przypisać NPM wysokie, nieużywane porty, np. 30080 dla HTTP i 30443 dla HTTPS. TrueNAS Scale rezerwuje porty poniżej 9000 dla systemu, więc należy wybrać wartości powyżej tego progu.Po zainstalowaniu NPM, należy skonfigurować przekierowanie portów (port forwarding) na routerze brzegowym, tak aby ruch przychodzący z internetu na port 80 był kierowany na port 30080 adresu IP TrueNAS, a ruch z portu 443 na port 30443.
      • Zalety: Konfiguracja TrueNAS Scale pozostaje nienaruszona.
      • Wady: Wymaga dodatkowej konfiguracji na routerze. Każda usługa proxy będzie wymagała jawnego przekierowania, co może być mylące.

    Idealnym rozwiązaniem byłoby przypisanie NPM dedykowanego adresu IP w sieci lokalnej (np. za pomocą technologii macvlan), co całkowicie wyeliminowałoby konflikt portów. Niestety, interfejs graficzny instalatora aplikacji w TrueNAS Scale nie udostępnia tej opcji w prosty sposób.

    Storage Configuration (Konfiguracja Pamięci)

    Aby zapewnić, że konfiguracja NPM, w tym utworzone hosty proxy i certyfikaty SSL, przetrwa aktualizacje lub ponowne wdrożenie aplikacji, należy skonfigurować trwałą pamięć masową.

    1. W sekcji Storage Configuration należy skonfigurować dwa woluminy.
    2. Dla Nginx Proxy Manager Data Storage (ścieżka /data) oraz Nginx Proxy Manager Certs Storage (ścieżka /etc/letsencrypt), należy wybrać typ ixVolume.
    3. Pozostawienie tych ustawień zapewni, że TrueNAS utworzy dedykowane zbiory danych ZFS dla konfiguracji i certyfikatów, które będą niezależne od samego kontenera aplikacji.

    Krok 4: Pierwsze Uruchomienie i Zabezpieczenie

    Po skonfigurowaniu powyższych parametrów (i ewentualnym zastosowaniu poprawek z Sekcji 4), należy kliknąć Install. Po kilku chwilach aplikacja powinna przejść w stan „Running”.

    1. Dostęp do interfejsu NPM jest możliwy pod adresem http://<adres-ip-truenas>:PORT, gdzie PORT to port WebUI skonfigurowany podczas instalacji (domyślnie 81 wewnątrz kontenera, ale mapowany na wyższy port, np. 30020, jeśli nie zmieniono portów TrueNAS).
    2. Domyślne poświadczenia logowania to:
      • Email: admin@example.com
      • Password: changeme
    3. Po pierwszym zalogowaniu system natychmiast poprosi o zmianę tych danych. Jest to absolutnie kluczowy krok bezpieczeństwa i należy go wykonać niezwłocznie.

    Sekcja 4: Rozwiązywanie Problemu „Deploying”: Diagnostyka i Naprawa Błędów Instalacji

    Jednym z najczęściej napotykanych i najbardziej frustrujących problemów podczas wdrażania Nginx Proxy Manager na TrueNAS Scale jest sytuacja, w której aplikacja po instalacji na stałe zawiesza się w stanie „Deploying”. Użytkownik czeka, odświeża stronę, ale status nigdy nie zmienia się na „Running”. Podgląd logów kontenera często nie dostarcza jednoznacznej odpowiedzi. Ten problem nie jest błędem samego NPM, lecz, jak zdiagnozowano wcześniej, symptomem fundamentalnego konfliktu uprawnień między generycznym kontenerem a specyficznym, zabezpieczonym środowiskiem w TrueNAS Scale.

    Opis Problemu i Główna Przyczyna

    Po kliknięciu przycisku „Install” w kreatorze aplikacji, TrueNAS Scale rozpoczyna proces wdrażania. W tle pobierany jest obraz Docker, tworzone są woluminy ixVolume i uruchamiany jest kontener z zadaną konfiguracją. Skrypt startowy wewnątrz kontenera NPM próbuje wykonać operacje konserwacyjne, w tym zmianę właściciela kluczowych katalogów. Ponieważ kontener działa jako użytkownik o ograniczonych uprawnieniach (apps, UID 568) na systemie plików, którego nie kontroluje w pełni, operacja ta kończy się niepowodzeniem. Skrypt zatrzymuje swoje działanie, a kontener nigdy nie sygnalizuje systemowi, że jest gotowy do pracy. W rezultacie, z perspektywy interfejsu TrueNAS, aplikacja na zawsze pozostaje w fazie wdrażania.

    Na szczęście, dzięki pracy społeczności i deweloperów, istnieją sprawdzone i skuteczne rozwiązania tego problemu. Co ciekawe, ewolucja tych rozwiązań doskonale ilustruje dynamikę rozwoju oprogramowania open-source.

    Rozwiązanie 1: Użycie Zmiennej Środowiskowej (Metoda Rekomendowana)

    Jest to nowoczesne, precyzyjne i najbezpieczniejsze rozwiązanie problemu. Zostało ono wprowadzone przez twórców kontenera NPM właśnie w odpowiedzi na problemy zgłaszane przez użytkowników platform takich jak TrueNAS Scale. Zamiast eskalować uprawnienia, instruuje się kontener, aby pominął problematyczny krok.

    Aby zaimplementować to rozwiązanie, należy:

    1. Podczas instalacji aplikacji (lub podczas jej edycji, jeśli już została utworzona i zawisła), należy przejść do sekcji Application Configuration.
    2. Znaleźć podsekcję Nginx Proxy Manager Configuration i kliknąć Add przy Additional Environment Variables.
    3. Skonfigurować nową zmienną środowiskową w następujący sposób:
      • Variable Name: SKIP_CERTBOT_OWNERSHIP
      • Variable Value: true
    4. Zapisać konfigurację i zainstalować lub zaktualizować aplikację.

    Dodanie tej flagi informuje skrypt startowy Certbota wewnątrz kontenera, że ma on pominąć krok chown (zmiany właściciela) dla swoich plików konfiguracyjnych. Skrypt przechodzi dalej, kontener poprawnie się uruchamia i zgłasza gotowość, a aplikacja przechodzi w stan „Running”. Jest to metoda zalecana dla wszystkich nowszych wersji TrueNAS Scale (Electric Eel, Dragonfish i nowszych).

    Rozwiązanie 2: Zmiana Użytkownika na Root (Metoda Historyczna)

    To rozwiązanie było pierwszym, które odkryła społeczność. Jest to bardziej „brutalna” metoda, która rozwiązuje problem przez nadanie kontenerowi pełnych uprawnień. Choć skuteczna, jest uważana za mniej elegancką i potencjalnie mniej bezpieczną z perspektywy zasady minimalnych uprawnień.

    Aby zaimplementować to rozwiązanie, należy:

    1. Podczas instalacji lub edycji aplikacji, należy przejść do sekcji User and Group Configuration.
    2. Zmienić wartość w polu User ID z domyślnej 568 na 0.
    3. Pozostawić Group ID bez zmian lub również ustawić na 0.
    4. Zapisać konfigurację i wdrożyć aplikację.

    Ustawienie User ID na 0 powoduje, że proces wewnątrz kontenera jest uruchamiany z uprawnieniami użytkownika root. Użytkownik root ma nieograniczone uprawnienia, więc problematyczna operacja chown wykonuje się bezbłędnie, a kontener startuje poprawnie. Ta metoda była szczególnie potrzebna w starszych wersjach TrueNAS Scale (np. Dragonfish) i jest udokumentowana jako działające obejście. Chociaż nadal działa, metoda ze zmienną środowiskową jest preferowana, ponieważ nie wymaga eskalacji uprawnień dla całego kontenera.

    Weryfikacja

    Niezależnie od wybranej metody, po zapisaniu zmian i ponownym wdrożeniu aplikacji, należy obserwować jej status w zakładce Apps -> Installed. Po krótkiej chwili status powinien zmienić się z „Deploying” na „Running”, co oznacza, że problem został pomyślnie rozwiązany i Nginx Proxy Manager jest gotowy do konfiguracji.

    Sekcja 5: Praktyczne Zastosowanie: Zabezpieczanie Serwera Mediów Jellyfin

    Teoria i poprawna instalacja to dopiero początek. Prawdziwa moc Nginx Proxy Manager ujawnia się w praktyce, gdy zaczynamy go używać do zarządzania dostępem do naszych usług. Jellyfin, popularny, darmowy serwer multimediów, jest doskonałym przykładem do zademonstrowania tego procesu, ponieważ jego pełna funkcjonalność zależy od jednego, często pomijanego ustawienia w konfiguracji proxy. Poniższy przewodnik zakłada, że Jellyfin jest już zainstalowany i działa w sieci lokalnej, dostępny pod adresem IP:PORT (np. 192.168.1.10:8096).

    Krok 1: Konfiguracja DNS

    Zanim NPM będzie mógł kierować ruch, świat zewnętrzny musi wiedzieć, gdzie go wysłać.

    1. Należy zalogować się do panelu zarządzania swoją domeną internetową (np. u rejestratora domeny lub dostawcy DNS, jak Cloudflare).
    2. Utworzyć nowy rekord DNS typu A.
    3. W polu Name (lub Host) należy wpisać subdomenę, która będzie używana do dostępu do Jellyfin (np. jellyfin).
    4. W polu Value (lub Points to) należy wpisać publiczny adres IP swojej sieci domowej (routera).

    Krok 2: Uzyskanie Certyfikatu SSL w NPM

    Zabezpieczenie połączenia za pomocą HTTPS jest kluczowe. NPM sprawia, że ten proces jest trywialny, zwłaszcza przy użyciu metody DNS Challenge, która jest bezpieczniejsza, ponieważ nie wymaga otwierania żadnych portów na routerze.

    1. W interfejsie NPM należy przejść do SSL Certificates i kliknąć Add SSL Certificate, a następnie wybrać Let's Encrypt.
    2. W polu Domain Names należy wpisać swoją subdomenę, np. jellyfin.twojadomena.com. Można również od razu wygenerować certyfikat typu „wildcard” (np. *.twojadomena.com), który będzie pasował do wszystkich subdomen.
    3. Należy włączyć opcję Use a DNS Challenge.
    4. Z listy DNS Provider można wybrać swojego dostawcę DNS (np. Cloudflare).
    5. W polu Credentials File Content należy wkleić token API uzyskany od dostawcy DNS. W przypadku Cloudflare, należy wygenerować token z uprawnieniami do edycji strefy DNS (Zone:DNS:Edit).
    6. Należy zaakceptować warunki usługi Let’s Encrypt i zapisać formularz. Po chwili NPM użyje API do tymczasowego dodania rekordu TXT w DNS, co udowodni Let’s Encrypt, że jesteśmy właścicielami domeny. Certyfikat zostanie wygenerowany i zapisany.

    Krok 3: Tworzenie Hosta Proxy (Proxy Host)

    To jest serce konfiguracji, gdzie łączymy domenę, certyfikat i wewnętrzną usługę.

    1. W NPM należy przejść do Hosts -> Proxy Hosts i kliknąć Add Proxy Host.
    2. Otworzy się formularz z kilkoma zakładkami.

    Zakładka „Details”

    • Domain Names: Należy wpisać pełną nazwę domenową, która została skonfigurowana w DNS, np. jellyfin.twojadomena.com.
    • Scheme: Należy wybrać http, ponieważ komunikacja między NPM a Jellyfin w sieci lokalnej zazwyczaj nie jest szyfrowana.
    • Forward Hostname / IP: Należy wpisać lokalny adres IP serwera, na którym działa Jellyfin, np. 192.168.1.10.
    • Forward Port: Należy wpisać port, na którym nasłuchuje Jellyfin, np. 8096.
    • Websocket Support: To jest absolutnie krytyczne ustawienie. Należy zaznaczyć tę opcję. Jellyfin intensywnie korzysta z technologii WebSocket do komunikacji w czasie rzeczywistym, np. do aktualizacji statusu odtwarzania na pulpicie nawigacyjnym (dashboard) czy do działania funkcji Syncplay. Bez włączonego wsparcia dla WebSocket, strona główna Jellyfin załaduje się poprawnie, ale wiele kluczowych funkcji nie będzie działać, co prowadzi do trudnych do zdiagnozowania problemów.

    Zakładka „SSL”

    • SSL Certificate: Z rozwijanej listy należy wybrać certyfikat wygenerowany w poprzednim kroku dla domeny Jellyfin.
    • Force SSL: Należy włączyć tę opcję, aby wszystkie połączenia HTTP były automatycznie przekierowywane na bezpieczny HTTPS.
    • HTTP/2 Support: Włączenie tej opcji może poprawić wydajność ładowania strony.

    Po skonfigurowaniu obu zakładek należy zapisać hosta proxy.

    Krok 4: Testowanie

    Po zapisaniu konfiguracji, Nginx w tle przeładuje swoje ustawienia. Teraz powinno być możliwe otwarcie przeglądarki i wpisanie adresu https://jellyfin.twojadomena.com. Użytkownik powinien zobaczyć stronę logowania Jellyfin, a połączenie powinno być zabezpieczone certyfikatem SSL (widoczna kłódka w pasku adresu).

    Podsekcja 5.1: Zaawansowane Wzmacnianie Bezpieczeństwa (Opcjonalne)

    Domyślna konfiguracja jest w pełni funkcjonalna, ale dla zwiększenia bezpieczeństwa można dodać dodatkowe nagłówki HTTP, które instruują przeglądarkę, jak ma się zachowywać. W tym celu należy edytować utworzonego hosta proxy i przejść do zakładki Advanced. W polu Custom Nginx Configuration można wkleić dodatkowe dyrektywy.

    Warto zauważyć, że NPM ma pewne dziwactwo: dyrektywy add_header dodane bezpośrednio w tym polu mogą nie zostać zastosowane. Bezpieczniejszym podejściem jest utworzenie niestandardowej lokalizacji (Custom Location) dla ścieżki / i wklejenie nagłówków w jej polu konfiguracyjnym.

    Poniższa tabela przedstawia rekomendowane nagłówki bezpieczeństwa.

    Tabela 2: Rekomendowane Nagłówki Bezpieczeństwa dla Jellyfin w NPM

    NagłówekCelRekomendowana WartośćUwagi
    Strict-Transport-SecurityWymusza na przeglądarce komunikację wyłącznie przez HTTPS przez określony czas.add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;Należy wdrażać ostrożnie. Warto zacząć od niższego max-age i usunąć preload, dopóki nie ma się pewności co do konfiguracji.
    X-Frame-OptionsChroni przed atakami typu „clickjacking”, uniemożliwiając osadzenie strony w ramce <iframe> na innej witrynie.add_header X-Frame-Options "SAMEORIGIN" always;SAMEORIGIN pozwala na osadzanie tylko w ramach tej samej domeny.
    X-Content-Type-OptionsZapobiega atakom związanym z błędnym interpretowaniem typów MIME przez przeglądarkę („MIME-sniffing”).add_header X-Content-Type-Options "nosniff" always;Jest to standardowe i bezpieczne ustawienie.
    Referrer-PolicyKontroluje, jakie informacje o stronie odsyłającej są wysyłane podczas nawigacji.add_header 'Referrer-Policy' 'origin-when-cross-origin';Dobry kompromis między prywatnością a użytecznością.
    X-XSS-ProtectionHistoryczny nagłówek mający chronić przed atakami Cross-Site Scripting (XSS).add_header X-XSS-Protection "0" always;Nagłówek jest przestarzały i może tworzyć nowe wektory ataku. Nowoczesne przeglądarki mają lepsze, wbudowane mechanizmy. Zaleca się jego jawne wyłączenie (0).

    Zastosowanie tych nagłówków stanowi dodatkową warstwę obrony i jest uznawane za dobrą praktykę w zabezpieczaniu aplikacji webowych. Krytyczne jest jednak, aby korzystać z aktualnych rekomendacji, jak w przypadku X-XSS-Protection, którego ślepe kopiowanie ze starszych poradników mogłoby osłabić bezpieczeństwo.

    Sekcja 6: Wnioski i Dalsze Kroki

    Połączenie Nginx Proxy Manager z platformą TrueNAS Scale tworzy niezwykle potężne i elastyczne środowisko do zarządzania domowym laboratorium. Jak wykazano w niniejszym raporcie, ta synergia pozwala na centralizację zarządzania dostępem, drastyczne uproszczenie wdrożenia i utrzymania zabezpieczeń SSL/TLS oraz profesjonalizację sposobu, w jaki użytkownicy wchodzą w interakcję ze swoimi samo-hostowanymi usługami. Kluczem do sukcesu jest jednak nie tylko ślepe podążanie za instrukcjami, ale przede wszystkim zrozumienie fundamentalnych zasad działania obu technologii. Świadomość, że aplikacje w TrueNAS Scale działają w ramach restrykcyjnego ekosystemu, jest niezbędna do skutecznego diagnozowania i rozwiązywania specyficznych problemów, takich jak błąd zawieszania się w stanie „Deploying”.

    Podsumowanie Strategicznych Korzyści

    Wdrożenie NPM na TrueNAS Scale przynosi wymierne korzyści:

    • Centralizacja i prostota: Wszystkie przychodzące żądania są zarządzane z jednego, intuicyjnego panelu, co eliminuje chaos związany z wieloma adresami IP i portami.
    • Wzmocnione bezpieczeństwo: Automatyzacja certyfikatów SSL, ukrywanie wewnętrznej topologii sieci oraz możliwość implementacji zaawansowanych nagłówków bezpieczeństwa tworzą solidną pierwszą linię obrony.
    • Profesjonalny wizerunek i wygoda: Używanie łatwych do zapamiętania, spersonalizowanych subdomen (np. media.mojadomena.pl) zamiast technicznych adresów IP znacząco poprawia komfort użytkowania.

    Rekomendacje i Dalsze Kroki

    Po pomyślnym wdrożeniu Nginx Proxy Manager i zabezpieczeniu pierwszej aplikacji, warto zbadać jego dalsze możliwości, aby w pełni wykorzystać potencjał narzędzia.

    • Eksploracja List Dostępu (Access Lists): NPM pozwala na tworzenie list kontroli dostępu (ACL), które mogą ograniczać dostęp do określonych hostów proxy na podstawie adresu IP źródłowego. Jest to niezwykle użyteczna funkcja do zabezpieczania paneli administracyjnych. Można na przykład stworzyć regułę, która zezwala na dostęp do interfejsu TrueNAS Scale lub panelu samego NPM tylko z adresów IP w sieci lokalnej, blokując wszelkie próby dostępu z zewnątrz.
    • Strategia Kopii Zapasowych: Konfiguracja Nginx Proxy Manager, przechowywana w woluminie ixVolume, jest krytycznym zasobem. Jej utrata oznaczałaby konieczność ponownego konfigurowania wszystkich hostów proxy i certyfikatów. TrueNAS Scale oferuje wbudowane narzędzia do automatyzacji tworzenia kopii zapasowych. Należy skonfigurować zadanie Periodic Snapshot Task dla zbioru danych (dataset) zawierającego dane aplikacji NPM (ix-applications/releases/nginx-proxy-manager), aby regularnie tworzyć migawki jego stanu.
    • Zabezpieczanie Innych Aplikacji: Wiedza zdobyta podczas konfiguracji Jellyfin jest uniwersalna. Można ją teraz zastosować do zabezpieczenia praktycznie każdej innej usługi webowej działającej w domowym laboratorium, takiej jak Home Assistant, serwer plików, osobisty menedżer haseł (np. Vaultwarden, będący implementacją Bitwarden) czy system blokowania reklam AdGuard Home. Należy pamiętać, aby dla każdej aplikacji wymagającej komunikacji w czasie rzeczywistym włączyć opcję Websocket Support.
    • Monitorowanie i Diagnostyka: Interfejs NPM udostępnia dzienniki dostępu (access logs) i błędów (error logs) dla każdego hosta proxy. Regularne przeglądanie tych logów może pomóc w diagnozowaniu problemów z dostępem, identyfikowaniu prób nieautoryzowanych połączeń oraz optymalizacji konfiguracji.

    Opanowanie Nginx Proxy Manager na TrueNAS Scale to inwestycja, która zwraca się wielokrotnie w postaci zwiększonego bezpieczeństwa, wygody i kontroli nad cyfrowym ekosystemem. Jest to kolejny krok na drodze od prostego użytkownika do świadomego architekta własnej, domowej infrastruktury.

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

  • Jak Naprawić Błędy apt update na Serwerze VPS Contabo?

    Jak Naprawić Błędy apt update na Serwerze VPS Contabo?

    Jeśli korzystasz z serwera VPS od Contabo z systemem Ubuntu, po pewnym czasie lub aktualizacji systemu możesz natknąć się na serię frustrujących błędów podczas wykonywania polecenia sudo apt update. Komunikaty takie jak Missing Signed-By czy Target Packages configured multiple times są częstym zjawiskiem.

    Ten poradnik wyjaśni, dlaczego te błędy się pojawiają i jak je trwale naprawić, przywracając porządek w konfiguracji źródeł oprogramowania.

    Diagnoza Problemu: Skąd Biorą się Błędy?

    Problemy te wynikają zazwyczaj z jednego powodu: konfliktu w plikach konfiguracyjnych APT.

    Na serwerach Contabo, zwłaszcza po aktualizacji systemu (np. z Ubuntu 20.04 do 22.04 lub 24.04), często pozostają stare pliki konfiguracyjne, które używają lustrzanych serwerów Contabo (asi-fs-u.contabo.net). Jednocześnie, nowsze wersje Ubuntu wprowadzają standardowy, bardziej nowoczesny sposób zarządzania źródłami w pliku /etc/apt/sources.list.d/ubuntu.sources, który korzysta z oficjalnych serwerów Ubuntu.

    W rezultacie system próbuje wczytać te same repozytoria z dwóch różnych miejsc, co prowadzi do błędów:

    • W: Target Packages (...) is configured multiple times: Ten komunikat oznacza, że to samo repozytorium jest zdefiniowane w co najmniej dwóch różnych plikach. System nie wie, którego wpisu użyć.
    • N: Missing Signed-By in the sources.list(5) entry for...: To ostrzeżenie bezpieczeństwa. Nowsze wersje apt wymagają, aby każde repozytorium było jawnie powiązane z kluczem kryptograficznym (GPG), który potwierdza jego autentyczność. Stare pliki konfiguracyjne Contabo często nie mają tego wpisu.

    Rozwiązanie: Sprzątanie Konfiguracji Krok po Kroku

    Najlepszym i najczystszym rozwiązaniem jest wyłączenie starych, zbędnych plików konfiguracyjnych i pozostawienie tylko jednego, oficjalnego źródła prawdy.

    Krok 1: Zidentyfikuj wszystkie problematyczne pliki

    Użyj polecenia grep, aby znaleźć wszystkie pliki, które odwołują się do lustrzanego serwera Contabo.

    grep -r "contabo.net" /etc/apt/sources.list*
    

    Wynik tego polecenia pokaże Ci listę plików, które musimy zdezaktywować. Zazwyczaj będą to:

    • /etc/apt/sources.list.distUpgrade
    • /etc/apt/sources.list.d/third-party.sources

    Krok 2: Wyłącz zbędne pliki konfiguracyjne

    Zamiast usuwać pliki (co jest ryzykowne), bezpieczniej jest zmienić ich nazwę, dodając na końcu .disabled. Dzięki temu apt przestanie je wczytywać, ale w razie potrzeby będziesz mógł je łatwo przywrócić.

    Wykonaj poniższe polecenia:

    sudo mv /etc/apt/sources.list.distUpgrade /etc/apt/sources.list.distUpgrade.disabled
    sudo mv /etc/apt/sources.list.d/third-party.sources /etc/apt/sources.list.d/third-party.sources.disabled
    

    Jeśli grep pokazał inne pliki, je również zdezaktywuj w ten sam sposób.

    Krok 3: Zaktualizuj system

    Teraz, gdy pozostała tylko poprawna konfiguracja, uruchom apt update ponownie.

    sudo apt update
    

    Wszystkie błędy i ostrzeżenia powinny zniknąć. System będzie teraz pobierał pakiety wyłącznie z oficjalnych, bezpiecznych serwerów Ubuntu, zgodnie z najnowszymi standardami.

    Podsumowanie

    Problem z błędami apt na serwerach Contabo nie jest winą samego dostawcy, a raczej pozostałością po procesach aktualizacyjnych i starszych obrazach systemu. Poprzez wyłączenie zduplikowanych i przestarzałych plików konfiguracyjnych, przywracasz porządek, zwiększasz bezpieczeństwo i zapewniasz stabilne działanie menedżera pakietów.

  • Ubuntu Pro: Więcej niż Zwykły System. Kompleksowy Przewodnik po Usługach i Korzyściach

    Ubuntu Pro: Więcej niż Zwykły System. Kompleksowy Przewodnik po Usługach i Korzyściach

    Canonical, firma stojąca za najpopularniejszą na świecie dystrybucją Linuksa, oferuje rozszerzoną subskrypcję o nazwie Ubuntu Pro. Usługa ta, dostępna bezpłatnie dla użytkowników indywidualnych na maksymalnie pięciu maszynach, przenosi standardowe doświadczenie Ubuntu na poziom korporacyjnego bezpieczeństwa, zgodności z normami i wydłużonego wsparcia technicznego. Co dokładnie kryje się za tą ofertą i czy warto z niej skorzystać?

    Ubuntu Pro to odpowiedź na rosnące wymagania dotyczące cyberbezpieczeństwa i stabilności systemów operacyjnych, zarówno w środowiskach komercyjnych, jak i domowych. Subskrypcja integruje szereg zaawansowanych usług, które dotychczas były zarezerwowane głównie dla dużych przedsiębiorstw, udostępniając je szerokiemu gronu odbiorców. Kluczową korzyścią jest wydłużenie cyklu życia systemu (LTS) z 5 do 10 lat, co zapewnia krytyczne aktualizacje bezpieczeństwa dla tysięcy pakietów oprogramowania.

    Szczegółowy Przegląd Usług Oferowanych w Ramach Ubuntu Pro

    Aby w pełni zrozumieć wartość subskrypcji, należy przyjrzeć się jej poszczególnym komponentom. Użytkownik po aktywacji Pro zyskuje dostęp do panelu usług, które może dowolnie włączać i wyłączać w zależności od swoich potrzeb.

    1. ESM-Infra & ESM-Apps: Dziesięć Lat Spokoju

    Podstawą oferty Pro jest usługa Expanded Security Maintenance (ESM), podzielona na dwa filary:

    • esm-infra (Infrastructure): Gwarantuje poprawki bezpieczeństwa dla ponad 2300 pakietów z głównego repozytorium Ubuntu (main) przez 10 lat. Oznacza to, że system operacyjny i jego kluczowe komponenty są chronione przed nowo odkrytymi lukami (CVE) znacznie dłużej niż w standardowej wersji LTS.
    • esm-apps (Applications): Rozszerza ochronę na ponad 23 000 pakietów ze wspieranego przez społeczność repozytorium universe. To ogromna zaleta, ponieważ wiele popularnych aplikacji, bibliotek programistycznych i narzędzi, które instalujemy na co dzień, pochodzi właśnie stamtąd. Dzięki esm-apps one również otrzymują krytyczne aktualizacje bezpieczeństwa przez dekadę.

    W praktyce oznacza to, że serwer produkcyjny lub stacja robocza z systemem w wersji LTS mogą działać bezpiecznie i stabilnie przez 10 lat bez konieczności przeprowadzania dużej aktualizacji systemu.

    2. Livepatch: Aktualizacje Jądra Bez Restartu

    Usługa Canonical Livepatch to jedno z najbardziej docenianych narzędzi w środowiskach wymagających maksymalnej dostępności (uptime). Pozwala ona na instalowanie krytycznych i wysokiego ryzyka poprawek bezpieczeństwa jądra systemu (Linux kernel) w czasie jego pracy, bez potrzeby ponownego uruchamiania komputera. Dla administratorów serwerów, na których działają kluczowe usługi, jest to funkcja zmieniająca zasady gry – eliminuje przestoje i pozwala na natychmiastową reakcję na zagrożenia.

    Koniec z restartami serwerów. Usługa Livepatch rewolucjonizuje aktualizacje Linuksa

    Aktualizacje jądra systemu operacyjnego bez konieczności ponownego uruchamiania maszyny stają się standardem w środowiskach wymagających ciągłej dostępności. Usługa Canonical Livepatch pozwala na instalowanie krytycznych poprawek bezpieczeństwa w czasie rzeczywistym, eliminując przestoje i rewolucjonizując pracę administratorów systemów.

    W świecie cyfrowym, gdzie każda minuta niedostępności usługi może generować olbrzymie straty, planowane przestoje na aktualizacje systemowe stają się coraz większym wyzwaniem. Odpowiedzią na ten problem jest technologia Livepatch, oferowana przez firmę Canonical, twórców popularnej dystrybucji Ubuntu. Umożliwia ona wdrażanie najważniejszych poprawek bezpieczeństwa jądra Linuksa bez potrzeby restartowania serwera.

    Jak działa Livepatch?

    Usługa działa w tle, monitorując dostępne aktualizacje bezpieczeństwa oznaczone jako krytyczne lub o wysokim priorytecie. Gdy taka poprawka zostanie wydana, Livepatch aplikuje ją bezpośrednio do działającego jądra systemu. Proces ten jest niewidoczny dla użytkowników i aplikacji, które mogą działać bez żadnych przerw.

    „Dla administratorów zarządzających flotą serwerów, na których opiera się działalność firmy, jest to funkcja zmieniająca zasady gry” – komentuje ekspert ds. cyberbezpieczeństwa. „Zamiast planować okna serwisowe w środku nocy i ryzykować komplikacje, możemy natychmiastowo reagować na nowo odkryte zagrożenia, zachowując stuprocentową ciągłość działania”.

    Kto najbardziej korzysta?

    Rozwiązanie to jest szczególnie cenne w sektorach takich jak finanse, e-commerce, telekomunikacja czy opieka zdrowotna, gdzie systemy muszą działać w trybie 24/7. Dzięki Livepatch firmy mogą spełniać rygorystyczne wymogi umów o poziomie usług (SLA) i jednocześnie dbać o najwyższy standard bezpieczeństwa.

    Eliminacja konieczności restartu nie tylko oszczędza czas, ale również minimalizuje ryzyko związane z ponownym uruchamianiem złożonych środowisk aplikacyjnych.

    Technologia taka jak Canonical Livepatch wyznacza nowy kierunek w zarządzaniu infrastrukturą IT. Przesuwa akcent z reaktywnego usuwania problemów na proaktywne, ciągłe zabezpieczanie systemów. W dobie rosnącej liczby cyberzagrożeń możliwość natychmiastowego łatania luk w zabezpieczeniach, bez wpływu na dostępność usług, staje się nie tyle udogodnieniem, co koniecznością.

    3. Landscape: Centralne Zarządzanie Flotą Systemów

    Landscape to potężne narzędzie do zarządzania i administrowania wieloma systemami Ubuntu z jednego, centralnego panelu. Umożliwia zdalne przeprowadzanie aktualizacji, monitorowanie stanu maszyn, zarządzanie użytkownikami i uprawnieniami oraz automatyzację zadań. Chociaż w darmowym planie jego funkcjonalność może być ograniczona, w środowiskach komercyjnych pozwala zaoszczędzić setki godzin pracy administratorów.

    Landscape: Jak Opanować Flotę Systemów Ubuntu z Jednego Miejsca?

    W dzisiejszych środowiskach IT, gdzie liczba serwerów i stacji roboczych może sięgać setek, a nawet tysięcy, ręczne zarządzanie każdym systemem z osobna jest nie tylko nieefektywne, ale wręcz niemożliwe. Canonical, firma stojąca za najpopularniejszą dystrybucją Linuksa – Ubuntu, dostarcza rozwiązanie tego problemu: Landscape. To potężne narzędzie, które pozwala administratorom na centralne zarządzanie całą flotą maszyn, oszczędzając czas i minimalizując ryzyko błędów.

    Czym Jest Landscape?

    Landscape to platforma do zarządzania systemami, która działa jak centralny panel dowodzenia dla wszystkich maszyn z systemem Ubuntu w Twojej organizacji. Niezależnie od tego, czy są to serwery fizyczne w serwerowni, maszyny wirtualne w chmurze, czy komputery stacjonarne pracowników, Landscape umożliwia zdalne monitorowanie, zarządzanie i automatyzację kluczowych zadań administracyjnych z poziomu jednej, przejrzystej przeglądarki internetowej.

    Głównym celem narzędzia jest uproszczenie i zautomatyzowanie powtarzalnych czynności, które pochłaniają najwięcej czasu administratorów. Zamiast logować się do każdego serwera osobno w celu przeprowadzenia aktualizacji, można to zrobić dla całej grupy maszyn za pomocą kilku kliknięć.

    Kluczowe Funkcjonalności w Praktyce

    Siła Landscape tkwi w jego wszechstronności. Do najważniejszych funkcji należą:

    • Zdalne Aktualizacje i Zarządzanie Pakietami: Landscape pozwala na masowe wdrażanie aktualizacji bezpieczeństwa i oprogramowania na wszystkich podłączonych systemach. Administrator może tworzyć profile aktualizacji dla różnych grup serwerów (np. produkcyjnych, testowych) i planować ich instalację w dogodnym czasie, minimalizując ryzyko przestojów.
    • Monitoring i Alerty w Czasie Rzeczywistym: Platforma na bieżąco monitoruje kluczowe parametry systemów, takie jak obciążenie procesora, zużycie pamięci RAM, dostępność miejsca na dysku czy temperatura podzespołów. W przypadku przekroczenia zdefiniowanych progów, system automatycznie wysyła alerty, co pozwala na szybką reakcję, zanim problem przerodzi się w poważną awarię.
    • Zarządzanie Użytkownikami i Uprawnieniami: Tworzenie, modyfikowanie i usuwanie kont użytkowników na wielu maszynach jednocześnie staje się trywialnie proste. Landscape umożliwia centralne zarządzanie uprawnieniami, co znacząco podnosi poziom bezpieczeństwa i ułatwia audyty.
    • Automatyzacja Zadań: Jedną z najpotężniejszych funkcji jest możliwość zdalnego uruchamiania skryptów na dowolnej liczbie maszyn. Dzięki temu można zautomatyzować niemal każde zadanie – od rutynowych kopii zapasowych, przez instalację specyficznego oprogramowania, po kompleksowe audyty konfiguracji.

    Darmowy Plan a Środowiska Komercyjne

    Canonical oferuje Landscape w modelu subskrypcyjnym, ale udostępnia również darmowy plan „Landscape On-Premises”, który pozwala na zarządzanie maksymalnie 10 maszynami bez opłat. Jest to doskonała opcja dla małych firm, entuzjastów czy do celów testowych. Choć funkcjonalność w tym planie może być ograniczona w porównaniu do pełnych wersji komercyjnych, daje on solidny wgląd w możliwości platformy.

    Jednak to w dużych, komercyjnych środowiskach Landscape pokazuje swoją prawdziwą moc. Dla firm zarządzających dziesiątkami lub setkami serwerów, inwestycja w licencję szybko się zwraca. Zredukowanie czasu potrzebnego na rutynowe zadania z dni do minut przekłada się na realne oszczędności finansowe i pozwala administratorom skupić się na bardziej strategicznych projektach. Jak szacują eksperci, wdrożenie centralnego zarządzania może zaoszczędzić setki godzin pracy w skali roku.

    Landscape to niezbędne narzędzie dla każdej organizacji, która poważnie traktuje zarządzanie swoją infrastrukturą opartą na Ubuntu. Centralizacja, automatyzacja i proaktywny monitoring to kluczowe elementy, które nie tylko zwiększają wydajność i bezpieczeństwo, ale także pozwalają na skalowanie operacji bez proporcjonalnego wzrostu kosztów i zasobów ludzkich. W dobie cyfrowej transformacji, efektywne zarządzanie flotą systemów to już nie luksus, a konieczność.

    4. Real-time Kernel: Precyzja w Czasie Rzeczywistym

    Dla specyficznych zastosowań, takich jak automatyka przemysłowa, robotyka, telekomunikacja czy systemy giełdowe, kluczowa jest przewidywalność i determinizm działania. Real-time Kernel to specjalna wersja jądra Ubuntu z zintegrowanymi łatami PREEMPT_RT, która minimalizuje opóźnienia i gwarantuje, że zadania o najwyższym priorytecie zostaną wykonane w ściśle określonych ramach czasowych.

    W świecie, w którym decyzje maszyn muszą zapadać w ułamkach sekund, standardowe systemy operacyjne często nie są w stanie sprostać rygorystycznym wymaganiom czasowym. Odpowiedzią na te wyzwania jest jądro systemu operacyjnego czasu rzeczywistego (RTOS). Ubuntu, jedna z najpopularniejszych dystrybucji Linuksa, wkracza na ten wysoce wyspecjalizowany rynek z nowym produktem: Real-time Kernel.

    Czym jest i dlaczego to ważne?

    Real-time Kernel to specjalna wersja jądra Ubuntu, w której zaimplementowano zestaw łatek o nazwie PREEMPT_RT. Ich głównym zadaniem jest modyfikacja sposobu, w jaki jądro zarządza zadaniami, tak aby procesy o najwyższym priorytecie mogły wywłaszczać (przerywać) te o niższym priorytecie niemal natychmiast. W praktyce eliminuje to nieprzewidywalne opóźnienia (tzw. latencję) i gwarantuje, że krytyczne operacje zostaną wykonane w ściśle określonym, powtarzalnym oknie czasowym.

    „Jądro Ubuntu w czasie rzeczywistym zapewnia wydajność i odporność klasy przemysłowej dla zdefiniowanego programowo wytwarzania, monitorowania i technologii operacyjnych” – mówił Mark Shuttleworth, CEO Canonical.

    Dla sektorów takich jak automatyka przemysłowa, oznacza to, że sterowniki PLC na linii montażowej mogą przetwarzać dane z absolutną precyzją, zapewniając ciągłość i integralność produkcji. W robotyce, od ramion montażowych po autonomiczne pojazdy, determinizm czasowy jest kluczowy dla bezpieczeństwa i płynności ruchu. Podobnie w telekomunikacji, zwłaszcza w kontekście sieci 5G, infrastruktura musi obsługiwać ogromne ilości danych z ultra-niskimi opóźnieniami, co jest warunkiem koniecznym dla niezawodności usług. Systemy giełdowe, w których milisekundy decydują o milionowych transakcjach, również należą do grona beneficjentów tej technologii.

    Jak to działa? Kontekst techniczny

    Łaty PREEMPT_RT, rozwijane od lat przez społeczność Linuksa, przekształcają standardowe jądro w pełni wywłaszczalne. Mechanizmy takie jak spinlocki (blokady chroniące przed jednoczesnym dostępem do danych), które w tradycyjnym jądrze nie mogą być przerwane, w wersji RT stają się wywłaszczalne. Ponadto, procedury obsługi przerwań sprzętowych są przekształcane w wątki o określonym priorytecie, co pozwala na bardziej precyzyjne zarządzanie czasem procesora.

    Dzięki tym zmianom system jest w stanie zagwarantować, że zadanie o wysokim priorytecie uzyska dostęp do zasobów w przewidywalnym, krótkim czasie, niezależnie od obciążenia systemu innymi, mniej ważnymi procesami.

    Integracja PREEMPT_RT z oficjalnym jądrem Ubuntu (dostępnym w ramach subskrypcji Ubuntu Pro) to znaczący krok w kierunku demokratyzacji systemów czasu rzeczywistego. Upraszcza to wdrożenie zaawansowanych rozwiązań w przemyśle, obniżając barierę wejścia dla firm, które do tej pory musiały polegać na niszowych, często zamkniętych i drogich systemach RTOS. Dostępność stabilnego i wspieranego jądra czasu rzeczywistego w popularnym systemie operacyjnym może przyspieszyć innowacje w dziedzinie Internetu Rzeczy (IoT), pojazdów autonomicznych i inteligentnych fabryk, gdzie precyzja i niezawodność nie są opcją, a koniecznością.

    5. USG (Ubuntu Security Guide): Audyt i Wzmacnianie Bezpieczeństwa

    USG to narzędzie do automatyzacji procesów wzmacniania (hardening) i audytu systemu pod kątem zgodności z rygorystycznymi standardami bezpieczeństwa, takimi jak CIS Benchmarks czy DISA-STIG. Zamiast ręcznie konfigurować setki ustawień systemowych, administrator może użyć USG do automatycznego zastosowania rekomendowanych polityk i wygenerowania raportu zgodności.

    W dobie rosnących zagrożeń cybernetycznych i coraz bardziej rygorystycznych wymogów zgodności, administratorzy systemów stają przed wyzwaniem ręcznego konfigurowania setek ustawień w celu zabezpieczenia infrastruktury IT. Canonical, firma stojąca za popularną dystrybucją Linuksa, oferuje narzędzie Ubuntu Security Guide (USG), które automatyzuje procesy wzmacniania (hardening) i audytu systemu, zapewniając zgodność z kluczowymi standardami bezpieczeństwa, takimi jak CIS Benchmarks i DISA-STIG.


    Czym jest i jak działa Ubuntu Security Guide?

    Ubuntu Security Guide to zaawansowane narzędzie wiersza poleceń, dostępne w ramach subskrypcji Ubuntu Pro. Jego głównym celem jest uproszczenie i zautomatyzowanie żmudnych zadań związanych z zabezpieczaniem systemów operacyjnych Ubuntu. Zamiast manualnie edytować pliki konfiguracyjne, zmieniać uprawnienia i weryfikować polityki, administratorzy mogą skorzystać z gotowych profili zabezpieczeń.

    USG wykorzystuje jako swój backend uznane w branży narzędzie OpenSCAP (Security Content Automation Protocol), co zapewnia spójność i wiarygodność przeprowadzanych audytów. Proces działania jest prosty i opiera się na dwóch kluczowych komendach:

    • usg audit [profil] – Skanuje system pod kątem zgodności z wybranym profilem (np. cis_level1_server) i generuje szczegółowy raport w formacie HTML. Raport ten wskazuje, które reguły bezpieczeństwa są spełnione, a które wymagają interwencji.
    • usg fix [profil] – Automatycznie aplikuje zmiany konfiguracyjne, aby dostosować system do zaleceń zawartych w profilu.

    Jak podkreśla Canonical w swojej oficjalnej dokumentacji, USG zostało zaprojektowane, by „uprościć proces wzmacniania DISA-STIG, wykorzystując automatyzację”.


    Zgodność z CIS i DISA-STIG w Zasięgu Ręki

    Dla wielu organizacji, zwłaszcza w sektorze publicznym, finansowym i obronnym, zgodność z międzynarodowymi standardami bezpieczeństwa jest nie tylko dobrą praktyką, ale obowiązkiem prawnym i kontraktowym. CIS Benchmarks, opracowywane przez Center for Internet Security, oraz DISA-STIG (Security Technical Implementation Guides), wymagane przez Departament Obrony USA, to zbiory setek szczegółowych wytycznych konfiguracyjnych.

    Ręczne wdrożenie tych standardów jest niezwykle czasochłonne i podatne na błędy. USG adresuje ten problem, dostarczając predefiniowane profile, które mapują te złożone wymagania na konkretne, zautomatyzowane działania. Przykładowe konfiguracje zarządzane przez USG obejmują:

    • Polityki haseł: Wymuszanie odpowiedniej długości, złożoności i okresu ważności haseł.
    • Konfiguracja firewalla: Blokowanie nieużywanych portów i ograniczanie dostępu do usług sieciowych.
    • Zabezpieczenia SSH: Wymuszanie uwierzytelniania opartego na kluczach i wyłączanie logowania na konto roota.
    • System plików: Ustawianie restrykcyjnych opcji montowania, takich jak noexec czy nosuid na krytycznych partycjach.
    • Dezaktywacja zbędnych usług: Wyłączanie niepotrzebnych demonów i usług w celu minimalizacji powierzchni ataku.

    Możliwość dostosowywania profili za pomocą tzw. „tailoring files” pozwala administratorom na elastyczne wdrażanie polityk, z uwzględnieniem specyficznych potrzeb ich środowiska, bez utraty zgodności z ogólnym standardem.

    Konsekwencje Braku Zgodności i Rola Automatyzacji

    Ignorowanie standardów takich jak CIS czy DISA-STIG niesie za sobą poważne konsekwencje. Poza oczywistym wzrostem ryzyka udanego cyberataku, organizacje narażają się na dotkliwe kary finansowe, utratę certyfikacji, a także poważne szkody wizerunkowe. Niezgodność może prowadzić do utraty kluczowych kontraktów, zwłaszcza w sektorze rządowym.

    Eksperci ds. bezpieczeństwa są zgodni, że narzędzia do automatyzacji zgodności są kluczowe w nowoczesnym zarządzaniu IT. Pozwalają one nie tylko na jednorazowe wdrożenie polityk, ale także na ciągły monitoring i utrzymanie pożądanego stanu bezpieczeństwa w dynamicznie zmieniających się środowiskach.

    Ubuntu Security Guide stanowi odpowiedź na rosnącą złożoność w dziedzinie cyberbezpieczeństwa i regulacji. Przenosząc ciężar ręcznej konfiguracji na zautomatyzowany i powtarzalny proces, USG pozwala administratorom oszczędzać czas, minimalizować ryzyko błędu ludzkiego i zapewniać mierzalny dowód zgodności ze światowymi standardami. W erze, gdzie bezpieczeństwo jest fundamentem zaufania cyfrowego, narzędzia takie jak USG stają się nieodzownym elementem arsenału każdego profesjonalisty IT zarządzającego infrastrukturą opartą na systemie Ubuntu.

    6. Anbox Cloud: Android w Chmurze na Dużą Skalę

    Anbox Cloud to platforma pozwalająca na uruchamianie systemu Android w kontenerach chmurowych. Jest to rozwiązanie skierowane głównie do deweloperów aplikacji mobilnych, firm z branży gier (cloud gaming) czy motoryzacji (systemy inforozrywki). Umożliwia masowe testowanie aplikacji, automatyzację procesów i streaming aplikacji Androida z ultra-niskimi opóźnieniami.

    Jak Zainstalować i Skonfigurować Ubuntu Pro? Przewodnik Krok po Kroku

    Aktywacja Ubuntu Pro jest prosta i zajmuje zaledwie kilka minut.

    Wymagania:

    • System Ubuntu w wersji LTS (np. 18.04, 20.04, 22.04, 24.04).
    • Dostęp do konta z uprawnieniami sudo.
    • Konto Ubuntu One (można je założyć bezpłatnie).

    Krok 1: Uzyskaj swój token subskrypcji

    1. Przejdź na stronę ubuntu.com/pro i zaloguj się na swoje konto Ubuntu One.
    2. Zostaniesz automatycznie przekierowany do swojego panelu Ubuntu Pro.
    3. W panelu znajdziesz darmowy token dla użytku osobistego (Free Personal Token). Skopiuj go.

    Krok 2: Podłącz swój system do Ubuntu Pro

    Otwórz terminal na swoim komputerze i wykonaj poniższą komendę, wklejając w miejsce [TWÓJ_TOKEN] skopiowany wcześniej ciąg znaków:

    sudo pro attach [TWÓJ_TOKEN]
    

    System połączy się z serwerami Canonical i automatycznie włączy domyślne usługi, takie jak esm-infra i livepatch.

    Krok 3: Zarządzaj usługami

    Możesz w każdej chwili sprawdzić status swoich usług komendą:

    pro status --all
    

    Zobaczysz listę wszystkich dostępnych usług wraz z informacją, czy są włączone (enabled) czy wyłączone (disabled).

    Aby włączyć konkretną usługę, użyj komendy enable. Na przykład, aby aktywować esm-apps:

    sudo pro enable esm-apps
    
    Ubuntu Pro CLI

    Analogicznie, aby wyłączyć usługę, użyj komendy disable:

    sudo pro disable landscape
    

    Alternatywa: Konfiguracja przez interfejs graficzny

    Na systemach Ubuntu Desktop można również zarządzać subskrypcją przez interfejs graficzny. Otwórz aplikację „Oprogramowanie i aktualizacje” (Software & Updates), przejdź do zakładki „Ubuntu Pro” i postępuj zgodnie z instrukcjami, aby aktywować subskrypcję za pomocą tokena.

    Ubuntu Pro Settings

    Podsumowanie

    Ubuntu Pro to potężny zestaw narzędzi, który znacząco podnosi poziom bezpieczeństwa, stabilności i możliwości zarządzania systemem Ubuntu. Dzięki hojnej ofercie darmowej subskrypcji dla użytkowników indywidualnych, każdy może teraz skorzystać z funkcji, które do niedawna były domeną korporacji. Niezależnie od tego, czy jesteś deweloperem, administratorem małego serwera, czy po prostu świadomym użytkownikiem dbającym o długoterminowe wsparcie, aktywacja Ubuntu Pro jest krokiem, który zdecydowanie warto rozważyć.

  • Kluczowa Aktualizacja OpenLiteSpeed 1.8.4: Wzmocnienie Jądra Serwera

    Kluczowa Aktualizacja OpenLiteSpeed 1.8.4: Wzmocnienie Jądra Serwera

    1 sierpnia 2025 r. — Nowa wersja popularnego serwera WWW OpenLiteSpeed (OLS) oznaczona numerem 1.8.4 została opublikowana, przynosząc szereg istotnych poprawek. Aktualizacja skupia się na ulepszeniach w „Core” serwera, co oznacza, że zmiany dotyczą fundamentalnych, kluczowych komponentów, odpowiadających za jego bezpieczeństwo, stabilność i wydajność.


    Poprawki w Bezpieczeństwie i Stabilności

    Jedną z najważniejszych zmian jest usunięcie krytycznej luki w protokole HTTP/3, która powodowała wyciek pamięci. Błąd ten mógł prowadzić do stopniowego spowalniania, a nawet awarii serwera, co czyni jego naprawę priorytetem dla administratorów.

    Ponadto, deweloperzy wprowadzili ulepszoną walidację żądań HTTP/2. Ma to na celu lepsze blokowanie złośliwych i źle sformatowanych zapytań, które mogą być elementem ataków typu „denial of service” (DoS). Dzięki temu serwer staje się bardziej odporny na potencjalne zagrożenia i stabilniejszy w obsłudze dużego ruchu.


    Optymalizacja Wydajności

    Aktualizacja 1.8.4 to również szereg usprawnień, które bezpośrednio wpływają na wydajność. Wprowadzono poprawioną obsługę przestrzeni nazw, co jest szczególnie ważne w złożonych środowiskach serwerowych i ułatwia deweloperom zarządzanie kontenerami.

    Usunięto również błąd, który powodował uszkodzenie odpowiedzi serwera z powodu AIO (Asynchronous I/O). AIO jest kluczową techniką, która pozwala serwerowi na jednoczesne przetwarzanie wielu operacji, co jest niezbędne dla płynnego działania witryn o dużym ruchu. Naprawienie tego błędu gwarantuje, że OpenLiteSpeed będzie działał bardziej stabilnie i dostarczał poprawne dane użytkownikom, eliminując ryzyko błędów w ładowaniu treści.


    Jak zaktualizować OpenLiteSpeed?

    Dla administratorów systemów, proces aktualizacji do nowej wersji 1.8.4 jest prosty i zautomatyzowany. OpenLiteSpeed dostarcza skrypt lsup.sh, który zarządza procesem aktualizacji.

    Aby przeprowadzić aktualizację, wystarczy wykonać następujące kroki w terminalu:

    1. Przejdź do katalogu instalacyjnego OpenLiteSpeed:cd /usr/local/lsws
    2. Uruchom skrypt aktualizujący:./lsup.sh

    Skrypt automatycznie pobierze i zainstaluje najnowszą wersję, zachowując istniejące ustawienia serwera. Pełna dokumentacja dotycząca procesu aktualizacji jest dostępna na oficjalnej stronie projektu OpenLiteSpeed.


    Podsumowanie

    Wydanie OpenLiteSpeed 1.8.4 to sygnał, że deweloperzy koncentrują się na solidnych fundamentach swojego oprogramowania. Zmiany w „Core” serwera, skupione na bezpieczeństwie i optymalizacji, sprawiają, że aktualizacja jest niezbędna dla każdego, kto chce utrzymać swoje serwery w optymalnej kondycji.

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

  • OpenLiteSpeed (OLS) z Redis. Szybka pamięć Cache dla stron WordPress.

    OpenLiteSpeed (OLS) z Redis. Szybka pamięć Cache dla stron WordPress.

    Zarządzanie serwerem WWW wymaga zrozumienia komponentów, które składają się na jego architekturę. Każdy element odgrywa kluczową rolę w dostarczaniu treści użytkownikom w sposób szybki i niezawodny. Ten artykuł stanowi dogłębną analizę nowoczesnej konfiguracji serwerowej opartej na OpenLiteSpeed (OLS), wyjaśniając jego podstawowe mechanizmy, współpracę z systemem buforowania Redis oraz metody komunikacji z aplikacjami zewnętrznymi.

    Sekcja 1: OpenLiteSpeed (OLS) – Rdzeń Systemu

    Fundamentem każdej witryny jest serwer WWW – oprogramowanie odpowiedzialne za przyjmowanie żądań HTTP od przeglądarek i zwracanie im odpowiednich zasobów, takich jak pliki HTML, CSS, JavaScript czy obrazy.

    Czym jest OpenLiteSpeed?

    OpenLiteSpeed (OLS) to wysokowydajny, lekki serwer WWW o otwartym kodzie źródłowym, rozwijany przez LiteSpeed Technologies. Jego kluczową przewagą nad tradycyjnymi serwerami, takimi jak Apache w domyślnej konfiguracji, jest architektura sterowana zdarzeniami (event-driven).

    • Model procesowy (np. Apache prefork): Dla każdego jednoczesnego połączenia tworzony jest oddzielny proces lub wątek. Model ten jest prosty, ale przy dużym ruchu prowadzi do znacznego zużycia pamięci RAM i zasobów procesora, ponieważ każdy proces, nawet nieaktywny, rezerwuje zasoby.
    • Model sterowany zdarzeniami (OpenLiteSpeed, Nginx): Jeden proces roboczy serwera jest w stanie obsługiwać setki lub tysiące połączeń jednocześnie. Wykorzystuje on nieblokujące operacje wejścia/wyjścia (non-blocking I/O) i pętlę zdarzeń (event loop) do zarządzania żądaniami. Gdy proces czeka na operację (np. odczyt z dysku), nie blokuje się, lecz przechodzi do obsługi innego połączenia. Taka architektura zapewnia znacznie lepszą skalowalność i mniejsze zużycie zasobów.

    Kluczowe Funkcje OpenLiteSpeed

    OLS oferuje zestaw funkcji, które czynią go potężnym i elastycznym narzędziem:

    • Graficzny Interfejs Administracyjny (WebAdmin GUI): OLS posiada wbudowany panel administracyjny dostępny przez przeglądarkę, który umożliwia konfigurację wszystkich aspektów serwera – od wirtualnych hostów, przez ustawienia PHP, po reguły bezpieczeństwa – bez konieczności bezpośredniej edycji plików konfiguracyjnych.
    • Wbudowany Moduł Buforujący (LSCache): Jedną z najważniejszych funkcji OLS jest LSCache, zaawansowany i wysoce konfigurowalny mechanizm buforowania pełnych stron (full-page cache). W połączeniu z dedykowanymi wtyczkami dla systemów CMS (np. WordPress), LSCache przechowuje w pamięci w pełni wyrenderowane strony HTML. Gdy nadchodzi kolejne żądanie o tę samą stronę, serwer dostarcza ją bezpośrednio z bufora, całkowicie omijając wykonanie kodu PHP i zapytania do bazy danych.
    • Wsparcie dla Nowoczesnych Protokołów (HTTP/3): OLS natywnie wspiera najnowsze protokoły sieciowe, w tym HTTP/3 (oparty na QUIC). Zapewnia to mniejsze opóźnienia i lepszą wydajność, zwłaszcza na niestabilnych połączeniach mobilnych.
    • Kompatybilność z Regułami Apache: OLS potrafi interpretować dyrektywy mod_rewrite z plików .htaccess, co jest standardem w ekosystemie Apache. Upraszcza to znacząco proces migracji istniejących aplikacji bez konieczności przepisywania złożonych reguł przepisywania adresów URL.

    Sekcja 2: Redis – Akcelerator Danych w Pamięci Operacyjnej

    Buforowanie (caching) to fundamentalna technika optymalizacyjna, polegająca na przechowywaniu wyników kosztownych operacji w szybszym medium dostępowym. W kontekście aplikacji webowych, Redis jest jednym z najpopularniejszych narzędzi do realizacji tego zadania.

    Czym jest Redis?

    Redis (REmote DIctionary Server) to działająca w pamięci operacyjnej (in-memory) struktura danych, używana najczęściej jako baza danych typu klucz-wartość, bufor lub broker wiadomości. Jego potęga wynika z faktu, że wszystkie dane przechowuje w pamięci RAM, a nie na dysku twardym. Dostęp do RAM jest o rzędy wielkości szybszy niż dostęp do dysków SSD czy HDD, ponieważ jest to operacja czysto elektroniczna, omijająca wolniejsze interfejsy I/O.

    W typowej aplikacji webowej Redis pełni rolę bufora obiektów (object cache). Przechowuje on wyniki zapytań do bazy danych, fragmenty wyrenderowanego kodu HTML lub złożone obiekty PHP, które są kosztowne do ponownego wygenerowania.

    Jak Działa Współpraca OpenLiteSpeed i Redis?

    Mechanizmy buforowania LSCache i Redis nie wykluczają się, lecz doskonale uzupełniają, tworząc wielowarstwową strategię optymalizacji.

    Przepływ żądania (uproszczony):

    1. Użytkownik wysyła żądanie o dynamiczną stronę (np. wpis na blogu).
    2. OpenLiteSpeed odbiera żądanie. Pierwszym krokiem jest sprawdzenie bufora LSCache.
      • TRAFIENIE w LSCache (Cache Hit): Jeśli w LSCache znajduje się aktualna, w pełni wyrenderowana wersja strony, OLS natychmiast ją zwraca. Proces kończy się w tym miejscu. Jest to najszybszy możliwy scenariusz.
      • BRAK w LSCache (Cache Miss): Jeśli strony nie ma w buforze, OLS przekazuje żądanie do odpowiedniej aplikacji zewnętrznej (np. interpretera PHP) w celu jej wygenerowania.
    3. Aplikacja PHP rozpoczyna budowanie strony. Aby to zrobić, musi pobrać dane z bazy danych (np. MySQL).
    4. Zanim PHP wykona kosztowne zapytania do bazy danych, najpierw sprawdza bufor obiektów w Redis.
      • TRAFIENIE w Redis: Jeśli potrzebne dane (np. wyniki zapytań SQL) znajdują się w Redis, są one zwracane natychmiast. PHP używa tych danych do zbudowania strony, omijając komunikację z bazą danych.
      • BRAK w Redis: Jeśli danych nie ma w buforze, PHP wykonuje zapytania do bazy danych, pobiera wyniki, a następnie zapisuje je w Redis na potrzeby przyszłych żądań.
    5. PHP kończy generowanie strony HTML i zwraca ją do OpenLiteSpeed.
    6. OLS wysyła stronę do użytkownika, a jednocześnie zapisuje ją w buforze LSCache, aby kolejne żądania mogły być obsłużone znacznie szybciej.

    Ta dwuwarstwowa strategia zapewnia, że zarówno pierwsze, jak i kolejne odwiedziny strony są maksymalnie zoptymalizowane. LSCache eliminuje potrzebę uruchamiania PHP, a Redis drastycznie przyspiesza sam proces generowania strony, gdy jest to konieczne.

    Sekcja 3: Delegowanie Zadań – Aplikacje Zewnętrzne w OLS

    Nowoczesne serwery WWW są zoptymalizowane do obsługi połączeń sieciowych i dostarczania plików statycznych (obrazy, CSS). Wykonywanie kodu aplikacji (treści dynamicznej) jest delegowane do wyspecjalizowanych programów zewnętrznych. Taki podział obowiązków zwiększa stabilność i bezpieczeństwo.

    OpenLiteSpeed zarządza tymi programami poprzez system Aplikacji Zewnętrznych. Poniżej opisano najważniejsze typy:

    • Aplikacja LSAPI (LiteSpeed SAPI App): Najbardziej wydajna i zalecana metoda komunikacji z aplikacjami PHP, Python czy Ruby. LSAPI to autorski, zoptymalizowany protokół, który minimalizuje narzut komunikacyjny między serwerem a interpreterem aplikacji.
    • Aplikacja FastCGI: Bardziej uniwersalny, standardowy protokół do komunikacji z zewnętrznymi procesami aplikacji. Jest to dobre rozwiązanie dla aplikacji, które nie wspierają LSAPI. Działa na podobnej zasadzie co LSAPI (utrzymując stałe procesy robocze), ale z nieco większym narzutem protokołu.
    • Serwer WWW (Proxy): Ten typ konfiguruje OLS do działania jako odwrotne proxy (reverse proxy). OLS przyjmuje żądanie od klienta, a następnie przekazuje je w całości do innego serwera działającego w tle (tzw. backend), np. serwera aplikacji napisanego w Node.js, Javie czy Go. Jest to kluczowe do budowania architektur opartych na mikroserwisach.
    • Aplikacja CGI: Historyczna i najwolniejsza metoda. Dla każdego żądania uruchamiany jest nowy proces aplikacji, który jest zamykany po zwróceniu odpowiedzi. Ze względu na ogromny narzut wydajnościowy, jest używana tylko dla starszych aplikacji, które nie wspierają nowszych protokołów.

    OLS kieruje ruch do odpowiedniej aplikacji za pomocą Obsługi Skryptów (Script Handlers), która mapuje rozszerzenia plików (np. .php) na konkretną aplikację, lub Kontekstów (Contexts), które mapują ścieżki URL (np. /api/) na aplikację typu proxy.

    Sekcja 4: Język Komunikacji – Porównanie Architektur SAPI

    SAPI (Server Application Programming Interface) to interfejs definiujący, w jaki sposób serwer WWW komunikuje się z interpreterem aplikacji (np. PHP). Wybór implementacji SAPI ma fundamentalny wpływ na wydajność i stabilność całego systemu.

    Ewolucja SAPI

    1. CGI (Common Gateway Interface): Pierwszy standard. Stabilny, ale niewydajny z powodu uruchamiania nowego procesu dla każdego żądania.
    2. Moduł wbudowany (np. mod_php w Apache): Interpreter PHP jest ładowany bezpośrednio do procesu serwera. Zapewnia to bardzo szybką komunikację, ale kosztem stabilności (awaria PHP powoduje awarię serwera) i bezpieczeństwa.
    3. FastCGI: Kompromis między wydajnością a stabilnością. Utrzymuje pulę niezależnych, długo działających procesów PHP, co eliminuje koszt ich ciągłego uruchamiania. Komunikacja odbywa się przez gniazdo, co zapewnia izolację od serwera WWW.
    4. LSAPI (LiteSpeed SAPI): Ewolucja modelu FastCGI. Wykorzystuje tę samą architekturę z oddzielnymi procesami, ale sam protokół komunikacyjny został zaprojektowany od podstaw w celu minimalizacji narzutu, co przekłada się na jeszcze wyższą wydajność niż w przypadku standardowego FastCGI.

    Tabela Porównawcza Architektur SAPI

    CechaCGIModuł Wbudowany (mod_php)FastCGILiteSpeed SAPI (LSAPI)
    Model ProcesuNowy proces na żądanieWspółdzielony proces z serweremStałe procesy zewnętrzneStałe procesy zewnętrzne
    WydajnośćNiskaBardzo wysokaWysokaNajwyższa
    Stabilność / IzolacjaDoskonałaNiskaWysokaWysoka
    Zużycie ZasobówBardzo wysokieUmiarkowaneNiskieBardzo niskie
    Narzut KomunikacyjnyWysoki (uruchamianie procesu)Minimalny (wspólna pamięć)Umiarkowany (protokół)Niski (zoptymalizowany protokół)
    Główna ZaletaPełna izolacjaSzybkość komunikacjiZrównoważona wydajność i stabilnośćZoptymalizowana wydajność i stabilność
    Główna WadaBardzo niska wydajnośćNiestabilność, problemy z bezpieczeństwemBardziej złożona konfiguracjaTechnologia specyficzna dla LiteSpeed

    Porównanie Gniazd Komunikacyjnych

    Komunikacja między procesami (np. OLS a Redis, lub OLS a procesy PHP) odbywa się za pośrednictwem gniazd (sockets). Wybór typu gniazda ma wpływ na wydajność.

    CechaGniazdo TCP/IP (na localhost)Gniazdo Domeny Uniksowej (UDS)
    AdresowanieAdres IP + Port (np. 127.0.0.1:6379)Ścieżka pliku (np. /var/run/redis.sock)
    ZasięgTa sama maszyna lub przez siećTylko ta sama maszyna (IPC)
    Wydajność (lokalnie)NiższaWyższa
    Narzut (Overhead)Wyższy (przechodzi przez stos sieciowy)Minimalny (omija stos sieciowy)
    Model BezpieczeństwaReguły zapory sieciowej (firewall)Uprawnienia systemu plików

    W przypadku komunikacji lokalnej, UDS jest rozwiązaniem wydajniejszym, ponieważ omija cały stos sieciowy systemu operacyjnego, co redukuje opóźnienia i narzut procesora. Dlatego w zoptymalizowanych konfiguracjach jest preferowany do połączeń między OLS, Redis i procesami LSAPI.

    Sekcja 5: Praktyczna Implementacja i Zarządzanie

    Aby przełożyć teorię na praktykę, przeanalizujmy rzeczywistą konfigurację serwera dla wirtualnego hosta solutionsinc.co.uk .

    5.1 Analiza Konfiguracji na Przykładzie solutionsinc.co.uk

    OLS External App2
    1. Definicja Aplikacji Zewnętrznej (External App):
      • W panelu „External App” zdefiniowano aplikację typu LiteSpeed SAPI App o nazwie solutionsinc.co.uk. Jest to centralny punkt konfiguracji dla dynamicznej obsługi strony.
      • Adres (Address): UDS://tmp/lshttpd/solutionsinc.co.uk.sock. Ta linia jest kluczowa. Informuje OLS, że do komunikacji z aplikacją PHP będzie używane Gniazdo Domeny Uniksowej (UDS), a nie gniazdo sieciowe TCP/IP. Plik .sock pod tą ścieżką jest fizycznym punktem końcowym tego wydajnego kanału komunikacji.
      • Polecenie (Command): /usr/local/lsws/lsphp84/bin/lsphp. To jest bezpośrednia ścieżka do pliku wykonywalnego interpretera LiteSpeed PHP w wersji 8.4. OLS wie, że ma uruchomić ten właśnie program do przetwarzania skryptów.
      • Pozostałe parametry, jak LSAPI_CHILDREN=50 czy limity pamięci, służą do precyzyjnego zarządzania zasobami i wydajnością puli procesów PHP.
    2. Powiązanie z Plikami PHP (Script Handler):
      • Sama definicja aplikacji nie wystarczy. W panelu „Script Handler” mówimy OLS, kiedy ma jej używać.
      • Dla sufiksu (rozszerzenia) php ustawiono obsługę przez LiteSpeed SAPI.
      • Jako Handler Name wybrano [VHost Level]: solutionsinc.co.uk, co bezpośrednio wskazuje na aplikację zdefiniowaną w poprzednim kroku.
      • Wniosek: Od tej pory każde żądanie pliku z rozszerzeniem .php na tej stronie zostanie przekazane przez gniazdo UDS do jednego z procesów lsphp84.
    OLS Script Handler2
    OLS

    Ta konfiguracja jest doskonałym przykładem zoptymalizowanego i bezpiecznego środowiska: OLS obsługuje połączenia, a dedykowane, odizolowane procesy lsphp84 wykonują kod aplikacji, komunikując się przez najszybszy dostępny kanał – gniazdo domeny uniksowej.

    5.2 Zarządzanie Gniazdami Domeny Uniksowej (.sock) i Rozwiązywanie Problemów

    Plik .sock, jak widać w przykładzie solutionsinc.co.uk.sock, nie jest zwykłym plikiem. Jest to specjalny plik w systemach uniksowych, który działa jako punkt końcowy dla komunikacji międzyprocesowej (IPC). Zamiast komunikować się przez warstwę sieciową (nawet lokalną), procesy mogą zapisywać i odczytywać dane bezpośrednio z tego pliku, co jest znacznie szybsze.

    Kiedy OpenLiteSpeed uruchamia aplikację zewnętrzną LSAPI, tworzy taki plik gniazda. Procesy PHP nasłuchują na tym gnieździe na przychodzące żądania od OLS.

    Praktyczna porada: „Uparty” plik .sock

    Czasami po wprowadzeniu zmian w konfiguracji PHP (np. modyfikacji pliku php.ini lub instalacji nowego rozszerzenia) i restarcie serwera OpenLiteSpeed (lsws), zmiany mogą nie być widoczne na stronie. Dzieje się tak, ponieważ procesy lsphp mogły nie zostać poprawnie zrestartowane wraz z serwerem, a OLS wciąż komunikuje się ze starymi procesami przez istniejący, „stary” plik .sock.

    W takiej sytuacji, gdy standardowy restart nie pomaga, skutecznym rozwiązaniem jest:

    1. Zatrzymać serwer OpenLiteSpeed.
    2. Ręcznie usunąć odpowiedni plik .sock, np. za pomocą polecenia w terminalu:rm /tmp/lshttpd/solutionsinc.co.uk.sock
    3. Ponownie uruchomić serwer OpenLiteSpeed.

    Po ponownym uruchomieniu OLS, nie znajdując istniejącego pliku gniazda, zostanie zmuszony do stworzenia go na nowo. Co ważniejsze, uruchomi przy tym nową pulę procesów lsphp, które wczytają świeżą konfigurację z pliku php.ini. Usunięcie pliku .sock działa jak twardy reset kanału komunikacyjnego między serwerem a aplikacją PHP, gwarantując, że wszystkie komponenty zostaną zainicjowane od zera z aktualnymi ustawieniami.

    Sekcja 6: Podsumowanie

    Przedstawiona konfiguracja serwera to precyzyjnie zaprojektowany system, w którym każdy element odgrywa istotną rolę.

    • OpenLiteSpeed działa jako wydajny, sterowany zdarzeniami rdzeń, zarządzający połączeniami.
    • LSCache zapewnia błyskawiczne dostarczanie stron z bufora pełnej strony.
    • Redis działa jako bufor obiektów, drastycznie przyspieszając generowanie treści dynamicznych, gdy jest to potrzebne.
    • LSAPI i UDS tworzą zoptymalizowane kanały komunikacyjne, minimalizując narzut i opóźnienia.

    Zrozumienie tych zależności pozwala na świadome zarządzanie serwerem i jego optymalizację w celu osiągnięcia maksymalnej wydajności i niezawodności.

  • CyberPanel i brak  miejsca na dysku. XCP-ng, LVM zwiększenie rozmiaru dysku.

    CyberPanel i brak miejsca na dysku. XCP-ng, LVM zwiększenie rozmiaru dysku.

    Czasami zdarza się, że przydzielona wcześniej przestrzeń dyskowa na nasze strony internetowe na naszym serwerze okazuje się w końcu zbyt mała. Jeśli nasz system operacyjny zainstalowany jest na LVM (Logical Volume Manager), to stosunkowo łatwo możemy rozszerzyć rozmiar dysku do potrzebnych nam rozmiarów. W niniejszym artykule pokażę jak to zrobić.

    Nasze środowisko robocze:

    • Maszyna wirtualna pracująca na XCP-ng
    • System operacyjny Ubuntu 20.04 Server Edition
    • Serwer www OpenLiteSpeed
    • Panel do zarządzania CyberPanel
    • Przestrzeń dyskowa oparta na LVM (Logical Volume Manager)

    Przydzielone jakiś czas temu 64GB na strony internetowe na naszym serwerze po pewnym czasie okazało się zbyt mało. Po przekroczeniu 80% zajętości dysku serwer zwolnił i otwieranie stron przestało być komfortowe.

    CyberPanel Low disk space

    Co to jest LVM (Logical Volume Manager)

    LVM to niezwykle elastyczne narzędzie pozwalające wygodnie zarządzać przestrzenią dyskową na naszych serwerach. LVM może znajdować na różnych dyskach twardych i różnych partycjach o różnej pojemności, a wielkość powierzchni dyskowej możemy zmieniać w locie nawet bez konieczności restartowania komputera lub maszyny wirtualnej.

    Sprawdzenie zajętości dysku twardego

    By sprawdzić zajętość naszego dysku twardego, skorzystaj z komendy df z parametrem -h, który pokazuje rozmiar dysków w formie przyjaznej człowiekowi.

    W przypadku naszego systemu rozmiar dysku LVM (/dev/mapper/ubuntu–vg-ubuntu–lv) to 62GB, a zajęte jest 56GB, co daje 95% zajętości powierzchni dysku. To zdecydowanie zbyt mało wolnego miejsca by serwer działał wydajnie. Czas by przydzielić serwerowi więcej miejsca.

    Zwiększamy rozmiar dysku w XCP-ng

    Dla naszej maszyny wirtualnej na której jest zainstalowany system Ubuntu z serwerem www przydzieliliśmy jedynie 64GB, więc pierwszym krokiem będzie zwiększenie wirtualnego dysku twardego dla naszej maszyny wirtualnej. Aby wykonać tę operację będziemy musieli wyłączyć na chwilę naszą maszynę wirtualną. W tym celu uruchamiamy aplikację XCP-ng center. Następnie wybieramy interesująca nas maszynę wirtualną, i wyłączamy ją. Przechodzimy do zakładki Storage, klikamy w nasz Storage który chcemy powiększyć i klikamy Properties. Wybieramy Size and Location i zwiększamy rozmiar wirtualnego dysku twardego. Następnie możemy ponownie uruchomić naszą maszynę wirtualną.

    Sprawdzenie wolnego miejsca w Grupie Woluminów

    Aby wyświetlić informacje o posiadanych przez nas grupach woluminów, wpisz vgs.

    Nasza grupa woluminów to ubuntu-vg o nowym rozmiarze 126.50GB i posiada ona 63.25GB wolnego miejsca. Aby wyświetlić więcej informacji o grupie woluminów, skorzystaj z polecenia vgdisplay.

    Widzimy tutaj, że przydzielone miejsce do naszej grupy woluminów to 63.25GB i mamy do dyspozycji jeszcze kolejne 63.25GB, które możemy dołączyć do naszej grupy woluminów.

    Wyświetlanie listy woluminów logicznych

    Aby wyświetlić nasze woluminy logiczne wpisz lvs.

    W naszym przypadku wolumin logiczny ubuntu -lv należy do grupy woluminów ubuntu-vg.

    UWAGA: Pamiętaj, żeby wpisując komendy zamieniać nasze nazwy woluminów, na swoje własne.

    Zwiększamy rozmiar naszego woluminu logicznego

    Aby przypisać więcej przestrzeni dyskowej naszej grupie woluminów skorzystamy z polecenia lvextend. Pamiętaj, aby zamienić ubuntu-vg, oraz ubuntu-lv na woluminy wykorzystywane w Twoim systemie.

    Parametr -L pozwala nam podać rozmiar o jaki chcemy zwiększyć nasz wolumen logiczny – w naszym przypadku zwiększamy o 63.25GB.

    Uwaga: Należy pamiętać, że nie podajemy jednostek TB, GB, MB itd, ale P dla Petabajtów, T dla Terabajtów, G dla Gigabajtów, M dla Megabajtów itd.

    Po ponownym wpisaniu komendy vgdisplay, widzimy w polu Alloc PE / Size, że zostało poprawnie przydzielone dodatkowe miejsce na dysku.

    Powiększenie systemu plików

    Nasze nowe miejsce na dysku nie jest jeszcze widoczne dla systemu. Musimy najpierw powiększyć system plików komendą resize2fs

    Podając komendę resize2fs musimy wskazać gdzie jest zamontowany nasz wolumin logiczny – w naszym przypadku jest to /dev/mapper/ubuntu–vg-ubuntu–lv

    Po tej operacji nasza nowa przestrzeń dyskowa jest już widoczna dla systemu operacyjnego i CyberPanel. 47% zajętości dysku to całkiem przyzwoity rezultat i powinno to wystarczyć na jakiś czas.

    CyberPanel Low disk usage

    Podsumowanie

    Jak widzicie, LVM ma wiele zalet. Gdybyście mieli zainstalowany system operacyjny na normalnych dyskach i partycjach, pewnie nie obyło by się bez formatowania dysków i instalacji systemu od nowa. Podczas gdy  LVM pozwala Wam na dołożenie nowego dysku do komputera, utworzenie na nim partycji i dodanie ich do już istniejącej grupy woluminów i woluminów logicznych. Łatwo, szybko i przyjemnie.

    Gdybyście mieli jakieś pytania odnośnie zwiększania pojemności woluminów LVM, to nie wahajcie się zadawać ich w komentarzach.