Bądź na bieżąco - RSS

BIND9 w Dockerze jako secondary DNS i cache DNS – schemat działania

28 lutego, 2026 | Brak Komentarzy | Kategoria: Linux, Porady

BIND9 w Dockerze

BIND9 w Dockerze może działać jednocześnie jako secondary DNS (slave) dla Twoich stref oraz jako cache DNS (rekurencja + cache) dla intranetu. Poniżej dostajesz gotowy, praktyczny setup oparty o obraz ubuntu/bind9:latest z konfiguracją w jednym pliku (named.conf) oraz danymi przykładowymi (zanonimizowanymi).

Najważniejsze założenie bezpieczeństwa: rekurencja działa wyłącznie dla zaufanych sieci, żeby serwer nie stał się otwartym resolverem.

Spis treści


Wymagania

  • Docker na serwerze (Linux).
  • Porty 53/TCP i 53/UDP dostępne w sieci, z której pytają klienci.
  • Na master DNS masz włączone transfery stref (AXFR/IXFR) dla secondary.
  • Znasz sieci intranet/VPN, które mają prawo do rekurencji.

Uwaga o anonimizacji: w przykładach używam domen typu corp.example i adresów z puli dokumentacyjnej (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24). Podmień na własne.

Katalogi na hoście

Trzymamy na hoście jeden plik konfiguracyjny oraz osobno cache i pliki stref slave.

sudo mkdir -p /srv/bind9
sudo mkdir -p /srv/bind9/cache
sudo mkdir -p /srv/bind9/cache/slaves

sudo nano /srv/bind9/named.conf

named.conf – secondary DNS + cache DNS w jednym pliku

Poniżej kompletna konfiguracja: ACL, rekurencja/caching, forwardery oraz strefy typu slave. Wszystko jest krótkie liniowo i nie „wyjeżdża” poza ramkę.

// /srv/bind9/named.conf
// BIND9: secondary DNS (slave) + cache DNS
// Dane przykładowe (zanonimizowane) – podmień na własne.

acl "trusted" {
    127.0.0.1;
    10.10.0.0/16;
    192.168.50.0/24;
};

options {
    directory "/var/cache/bind";

    // Rekurencja i cache tylko dla intranetu
    recursion yes;
    allow-query { trusted; };
    allow-recursion { trusted; };
    allow-query-cache { trusted; };

    // Forwardery upstream (przykładowe IP)
    forwarders {
        203.0.113.53;
        198.51.100.53;
    };
    forward only;

    dnssec-validation auto;

    listen-on { any; };
    listen-on-v6 { any; };

    auth-nxdomain no;
};

// RFC1918 (standardowy plik w obrazie)
include "/etc/bind/zones.rfc1918";

// ---- Strefy secondary (slave) ----

zone "corp.example" {
    type slave;
    file "/var/cache/bind/slaves/db.corp.example";
    masters { 203.0.113.10; };
    allow-notify { 203.0.113.10; };
};

zone "50.168.192.in-addr.arpa" {
    type slave;
    file "/var/cache/bind/slaves/db.192.168.50";
    masters { 203.0.113.10; };
    allow-notify { 203.0.113.10; };
};

// Domyślne strefy (krótki include zamiast inline’owania długich nazw)
include "/etc/bind/named.conf.default-zones";

// Minimalne logowanie (ciszej)
logging {
    category lame-servers { null; };
    category edns-disabled { null; };
};

Dlaczego tak? To nadal jest „jednoplikowa konfiguracja” w sensie: wszystko, co konfigurujesz (secondary + cache), jest w jednym pliku. A długie, systemowe definicje default-zones zostają w obrazie — dzięki temu unikasz linii, których nie da się sensownie złamać.

Uruchomienie kontenera

Najważniejsze: montujemy tylko named.conf (read-only) oraz katalog cache. Dzięki temu pliki systemowe (named.conf.default-zones, zones.rfc1918, bazy db.*) zostają w kontenerze i nie musisz ich kopiować na hosta.

docker run -d \
  --name bind9-container \
  --restart unless-stopped \
  -e TZ=Europe/Warsaw \
  -p 53:53/tcp \
  -p 53:53/udp \
  -v /srv/bind9/named.conf:/etc/bind/named.conf:ro \
  -v /srv/bind9/cache:/var/cache/bind \
  ubuntu/bind9:latest

Jeśli wolisz Compose:

services:
  bind9:
    image: ubuntu/bind9:latest
    container_name: bind9-container
    restart: unless-stopped
    environment:
      - TZ=Europe/Warsaw
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - /srv/bind9/named.conf:/etc/bind/named.conf:ro
      - /srv/bind9/cache:/var/cache/bind

Uprawnienia (UID/GID bind)

Secondary zapisuje pliki stref do cache. Jeśli brakuje praw, zobaczysz błędy typu „permission denied”. Sprawdź UID/GID użytkownika bind w kontenerze i ustaw właściciela katalogu cache na hoście.

docker exec -it bind9-container id bind

Przykład (u Ciebie może być inny):

uid=101(bind) gid=101(bind) groups=101(bind)

Ustaw właściciela (podmień UID:GID z wyniku):

sudo chown -R 101:101 /srv/bind9/cache
docker restart bind9-container

Testy działania

1) Sprawdzenie składni

docker exec -it bind9-container \
  named-checkconf /etc/bind/named.conf

2) Czy strefy slave się pobrały?

ls -la /srv/bind9/cache/slaves
docker logs --since=10m bind9-container

3) Test secondary (autorytatywnie)

dig @192.0.2.53 corp.example SOA \
  +noall +answer

4) Test cache DNS (rekurencja)

dig @192.0.2.53 example.org A +stats
dig @192.0.2.53 example.org A +stats

Tipy i pułapki

  • Nie montuj całego /etc/bind z hosta, jeśli nie kopiujesz plików systemowych —
    wtedy najczęściej „znika” named.conf.default-zones i zones.rfc1918.
  • Zawsze ogranicz rekurencję (allow-recursion, allow-query-cache) do intranetu.
  • Jeśli master wysyła NOTIFY, dodaj allow-notify tylko z IP mastera.
  • Chcesz twardsze bezpieczeństwo? Kolejny krok to TSIG między master ↔ secondary.

G

Tagi: , , ,

Aktualizacja Nextcloud w Dockerze: Nie zapomnij o tym kluczowym kroku!

31 stycznia, 2026 | Brak Komentarzy | Kategoria: Linux, Porady

Nextcloud Docker indeksyPodczas aktualizacji Nextcloud działającego w kontenerach Docker często pomija się jeden istotny element: indeksy bazy danych. Zaniedbanie przebudowy indeksów może powodować spowolnienie działania Nextcloud po aktualizacji. W tym artykule wyjaśniam krok po kroku, jak prawidłowo zadbać o Nextcloud Docker indeksy przed podniesieniem wersji.

To jeden z tych problemów, które trudno uchwycić na pierwszy rzut oka, bo wszystko działa – tylko wolniej. Czasem dochodzą do tego nieoczywiste komunikaty w logach lub w panelu administracyjnym: sugestie dotyczące bazy danych, ostrzeżenia o brakujących indeksach, albo zalecenia „optymalizacji”. W praktyce bardzo często winny jest pominięty krok przed główną aktualizacją: sprawdzenie i dodanie brakujących indeksów w bazie danych (w tym przypadku SQLite) komendą occ.

W tym artykule pokażę:

  • dlaczego Nextcloud potrafi zwolnić po aktualizacji, mimo że „nic się nie zepsuło”,
  • czym są indeksy w bazie danych i czemu mają krytyczne znaczenie dla wydajności,
  • dlaczego aktualizacje Nextcloud mogą wymagać nowych indeksów,
  • jak bezpiecznie wykonać procedurę krok po kroku w Dockerze (linuxserver/nextcloud),
  • co zrobić, gdy komenda zwróci błąd.

Zanim zrobisz większą aktualizację Nextcloud w kontenerze Docker, uruchom occ db:add-missing-indices i dopiero potem przechodź do aktualizacji obrazu. To prosty nawyk, który potrafi oszczędzić godziny diagnozy „dlaczego po update jest wolniej”.

Skąd bierze się spowolnienie Nextcloud po aktualizacji?

Wydajność Nextcloud zależy od wielu elementów: zasobów serwera, konfiguracji PHP, pamięci podręcznej (Redis), silnika bazy danych i sposobu przechowywania danych. Jeśli jednak mówimy o scenariuszu „po aktualizacji było dobrze, a teraz jest gorzej”, to warto zacząć od tego, co aktualizacja zmienia najczęściej: strukturę danych i sposób, w jaki aplikacja odpyta bazę.

Nextcloud rozwija się dynamicznie. Z każdą wersją pojawiają się nowe funkcje, nowe mechanizmy indeksowania plików, dodatkowe metadane, czasem nowe tabele lub kolumny. Nawet jeśli sama migracja bazy przejdzie poprawnie, to po aktualizacji aplikacja może wykonywać zapytania, które wcześniej były rzadkie albo w ogóle nie występowały. Jeśli do tych zapytań brakuje indeksów, baza danych zaczyna wykonywać kosztowne skany, co w SQLite potrafi szybko stać się wąskim gardłem.

Efekt? Użytkownik widzi „czkawkę” w interfejsie, administrator widzi wzrost obciążenia, a w logach — pozornie nic spektakularnego.

Czym są indeksy w bazie danych i dlaczego są kluczowe?

Indeks w bazie danych możesz porównać do spisu treści albo indeksu haseł w książce. Jeśli chcesz znaleźć konkretne nazwisko w 800-stronicowej publikacji, nie czytasz wszystkiego od początku — korzystasz z indeksu, który wskazuje stronę. Podobnie działa baza danych: kiedy aplikacja pyta „znajdź wszystkie rekordy spełniające warunek X”, indeks pozwala szybko dojść do wyniku bez przeglądania całej tabeli.

Bez indeksu baza często musi wykonać tzw. full table scan, czyli przeszukanie całej tabeli. Przy małych danych to jeszcze „jakoś działa”. Ale Nextcloud bardzo szybko generuje duże ilości rekordów: pliki, udziały, wersje, podglądy, informacje o użytkownikach, aplikacjach, logach, aktywnościach, cronach, zadaniach tła… Lista rośnie.

Najważniejsze korzyści z indeksów:

  • Szybsze zapytania SELECT – szczególnie po kolumnach używanych w filtrach i joinach.
  • Mniejsze obciążenie CPU i I/O – mniej pracy dla bazy i mniej odczytów.
  • Stabilniejsza wydajność przy rosnącej liczbie rekordów.
  • Mniej „dziwnych” problemów, gdzie interfejs działa, ale reaguje opóźnieniem.

Oczywiście indeksy mają też koszt: spowalniają część operacji zapisu (INSERT/UPDATE), bo indeks również trzeba aktualizować. Ale w kontekście Nextcloud, gdzie kluczowe są szybkie odczyty i filtrowanie, poprawnie dobrane indeksy są absolutnie fundamentalne.

Dlaczego aktualizacja Nextcloud może wymagać nowych indeksów?

Aktualizacja Nextcloud to nie tylko „nowszy kod w kontenerze”. To także:

  • nowe lub zmodyfikowane tabele,
  • nowe kolumny w istniejących tabelach,
  • zmiany w sposobie, w jaki aplikacja wyszukuje dane,
  • nowe funkcje, które generują dodatkowe zapytania (np. aktywności, udostępnienia, pełnotekstowe wyszukiwanie, integracje).

W idealnym świecie każda migracja bazy danych dodaje wszystko, co potrzebne. W praktyce — zwłaszcza w dużych projektach — zdarza się, że po aktualizacji pojawiają się zalecenia: „Dodaj brakujące indeksy, aby poprawić wydajność”. Nextcloud dostarcza do tego gotowe narzędzie: komendę OCC, która potrafi wykryć brakujące indeksy i je utworzyć.

Jeśli ten krok pominiesz, Nextcloud będzie działał, ale baza może wykonywać znacznie więcej pracy. A przy SQLite — która świetnie sprawdza się w mniejszych instalacjach, ale ma swoje ograniczenia w obciążonych środowiskach — brak indeksów potrafi być szczególnie bolesny.

Wskazówka administracyjna: Jeśli Twoja instancja ma wielu użytkowników, duże biblioteki plików lub intensywne udostępnienia, rozważ migrację z SQLite do PostgreSQL/MariaDB. Ale nawet wtedy komenda dodająca brakujące indeksy pozostaje dobrym nawykiem.

Instrukcja krok po kroku: indeksy SQLite przed aktualizacją Nextcloud w Dockerze

Poniższa procedura zakłada, że używasz obrazu linuxserver/nextcloud i zarządzasz kontenerem standardowo (Docker / docker-compose). Kluczowa zasada: najpierw backup, potem indeksy, dopiero później aktualizacja obrazu.

[GRAFIKA: Schemat blokowy przedstawiający poprawny proces aktualizacji Nextcloud z krokiem „db:add-missing-indices”]
Grafika powinna pokazywać prosty proces w formie flowchartu: (1) Backup → (2) Uruchomienie komendy occ db:add-missing-indices → (3) Aktualizacja obrazu/wersji Nextcloud → (4) Weryfikacja działania i logów. Alternatywnie: zrzut ekranu terminala z wykonaniem komendy i komunikatem o dodanych indeksach.

Krok 1: Zrób pełną kopię zapasową (kontener + wolumeny z danymi)

To jest moment, w którym wielu administratorów „idzie na skróty”, bo „to tylko mały update”. A potem pojawia się problem i nie ma do czego wrócić. Backup przed operacją na bazie danych to absolutna podstawa — nawet jeśli narzędzie jest bezpieczne, zawsze może dojść do:

  • braku miejsca na dysku podczas tworzenia indeksów,
  • przerwania procesu (restart hosta, restart Dockera, awaria zasilania),
  • problemów z uprawnieniami, które kończą się częściową modyfikacją plików bazy,
  • niezgodności w środowisku pośrodku zmian.

Co backupować?

  • Wolumen / katalog z danymi Nextcloud (to, co mapujesz jako /data i zwykle także /config w linuxserver/nextcloud).
  • Plik bazy SQLite – najczęściej znajduje się w obrębie danych/configu Nextcloud (zależnie od Twojego mapowania).
  • Konfigurację kontenera – np. plik docker-compose.yml, zmienne środowiskowe, reverse proxy, cron.

Najprościej: wykonaj kopię katalogów mapowanych jako wolumeny (np. snapshot na poziomie systemu plików, kopia na NAS, tar na zewnętrzny dysk). Jeżeli masz możliwość snapshotów (ZFS/Btrfs/LVM) – to jest świetny moment, by z nich skorzystać.

Krok 2: Uruchom komendę dodającą brakujące indeksy

Gdy backup jest gotowy i kontener Nextcloud działa, przechodzimy do sedna. Oto komenda, którą warto wykonać przed większą aktualizacją:

docker exec -it -u abc nextcloud php /config/www/nextcloud/occ \
db:add-missing-indices

Ta komenda uruchamia narzędzie occ wewnątrz kontenera i zleca Nextcloud sprawdzenie brakujących indeksów w bazie oraz ich utworzenie (jeśli to możliwe). W wielu przypadkach dostaniesz informację o tym, jakie indeksy zostały dodane, albo że nic nie trzeba robić.

Co oznaczają flagi i elementy komendy?

  • docker exec – uruchamia polecenie w działającym kontenerze.
  • -it – to dwie flagi naraz:
    • -i (interactive) utrzymuje wejście standardowe otwarte,
    • -t (tty) przydziela pseudo-terminal, dzięki czemu komenda zachowuje się „jak w normalnej konsoli”.

    W praktyce: bez -it często też zadziała, ale w administracji Nextcloud i pracy z occ to po prostu dobry standard.

  • -u abc – uruchamia polecenie jako użytkownik abc wewnątrz kontenera. W obrazach linuxserver.io aplikacje zwykle działają pod użytkownikiem o takiej nazwie, a uruchamianie occ jako root potrafi skończyć się problemami z uprawnieniami do plików (zwłaszcza w /config i danych Nextcloud).
  • nextcloud – nazwa Twojego kontenera. Jeśli masz inną (np. nc albo nextcloud-app), podmień ją na właściwą.
  • php – uruchamiamy interpreter PHP, bo occ jest skryptem PHP.
  • /config/www/nextcloud/occ – ścieżka do pliku occ w kontenerze linuxserver/nextcloud. To ważne: w zależności od obrazu ścieżka bywa inna, ale dla linuxserver/nextcloud ta lokalizacja jest typowa.
  • db:add-missing-indices – właściwa komenda OCC, która sprawdza i tworzy brakujące indeksy.

Krok 3: Zinterpretuj wynik i upewnij się, że wszystko przebiegło poprawnie

Jeśli wszystko pójdzie dobrze, zobaczysz komunikaty o dodanych indeksach lub informację, że brakujących indeksów nie znaleziono. Warto po tym kroku:

  • rzucić okiem na logi Nextcloud,
  • sprawdzić panel administracyjny (sekcja ostrzeżeń/konfiguracji),
  • odczekać chwilę, jeśli baza jest duża (tworzenie indeksów może trwać).

Dopiero po tej operacji przechodź do standardowej procedury aktualizacji kontenera (pull nowego obrazu, restart, ewentualne migracje).

Co zrobić, jeśli komenda zwróci błąd?

Błędy zdarzają się rzadko, ale warto mieć plan działania. Oto najczęstsze scenariusze i szybkie kroki naprawcze:

  1. Kontener nie działaJeśli docker exec zwraca błąd typu „Container … is not running”, najpierw upewnij się, że Nextcloud jest uruchomiony:
    • sprawdź docker ps,
    • zobacz logi kontenera: docker logs nextcloud,
    • uruchom kontener ponownie i dopiero wtedy wykonaj komendę OCC.
  2. Zła nazwa konteneraGdy komenda wskazuje, że nie ma takiego kontenera, sprawdź nazwę w docker ps i podmień w poleceniu.
  3. Problemy z uprawnieniamiJeśli w logach pojawiają się błędy zapisu lub dostępu do plików, najpierw upewnij się, że uruchamiasz polecenie jako właściwy użytkownik (-u abc). W obrazach linuxserver to zazwyczaj właściwy wybór. Jeśli masz nietypową konfigurację PUID/PGID, sprawdź, czy mapowania wolumenów mają poprawne prawa dostępu.
  4. Błąd ścieżki do OCCJeżeli dostaniesz komunikat, że plik /config/www/nextcloud/occ nie istnieje, możliwe że:
    • używasz innego obrazu niż linuxserver/nextcloud,
    • Twoja struktura w kontenerze jest inna.

    Wtedy wejdź do kontenera i sprawdź, gdzie leży occ:

    docker exec -it nextcloud sh

    a następnie zlokalizuj plik (np. find / -name occ 2>/dev/null) i dostosuj ścieżkę w komendzie.

  5. Sprawdź logi Nextcloud i logi konteneraJeśli błąd jest „aplikacyjny” (np. problem z bazą, lockami, trybem maintenance), zajrzyj do:
    • logów kontenera: docker logs nextcloud,
    • logu Nextcloud (w zależności od konfiguracji zwykle w /config/www/nextcloud/data/nextcloud.log lub analogicznym miejscu w wolumenie).

Uwaga: Jeśli Twoja instancja jest intensywnie używana (wielu aktywnych użytkowników), rozważ wykonanie tego kroku w oknie serwisowym. Dodawanie indeksów potrafi chwilowo zwiększyć obciążenie bazy.

Dlaczego warto robić to regularnie (i czemu „przed aktualizacją” ma znaczenie)?

Możesz zapytać: „Skoro to tylko indeksy, to czemu mam robić to przed aktualizacją, a nie po?”. Dwa powody:

  • Minimalizujesz ryzyko kumulacji zmian. Jeśli po aktualizacji coś zacznie działać gorzej, nie wiesz, czy to wina migracji wersji, nowych funkcji, czy brakujących indeksów. Robiąc indeksy wcześniej, izolujesz zmienną.
  • Zwiększasz szansę na płynny start po update. Po aktualizacji Nextcloud może uruchomić procesy, które natychmiast zaczną intensywnie odpytwać bazę. Jeśli indeksy już są, unikasz „zimnego prysznica” wydajnościowego.

W praktyce to mały rytuał administracyjny, który warto dodać do checklisty. Zwłaszcza jeśli prowadzisz blog techniczny i chcesz promować dobre nawyki: backup, sanity-check bazy, dopiero potem aktualizacja.

Podsumowanie

Wydajność Nextcloud po aktualizacji nie zawsze psuje się spektakularnie. Częściej „siada po cichu”: trochę wolniej tu, trochę wolniej tam — aż w końcu zaczyna przeszkadzać. Brakujące indeksy w bazie danych (także w SQLite) to jeden z najbardziej niedocenianych powodów takiego zachowania.

Dobry nawyk administracyjny wygląda tak:

  1. Backup (zawsze).
  2. occ db:add-missing-indices w działającym kontenerze.
  3. Dopiero potem aktualizacja Nextcloud (pull + restart + weryfikacja).

To prosta procedura, a potrafi realnie poprawić stabilność i wydajność po kolejnych wydaniach.

Twoja kolej

Masz za sobą aktualizację Nextcloud, po której instalacja zaczęła działać wolniej? A może komenda db:add-missing-indices uratowała Cię przed długim wieczorem z logami?

Napisz w komentarzu, jak wygląda Twoja checklist aktualizacji Nextcloud w Dockerze, jakie problemy spotkałeś i jak je rozwiązałeś. Jeśli artykuł okazał się pomocny, udostępnij go komuś, kto też administruje Nextcloud. I jeśli chcesz dostawać podobne praktyczne poradniki – zasubskrybuj bloga, bo regularnie publikuję sprawdzone procedury i rozwiązania „z pola walki”.

G

Tagi: , ,

Portainer nie działa po aktualizacji Dockera – najszybsze rozwiązanie

27 grudnia, 2025 | Brak Komentarzy | Kategoria: Linux, Porady

Błąd Portainer local unreachable po aktualizacji DockeraPortainer nie działa po aktualizacji Dockera – najszybsze rozwiązanie:

Po aktualizacji systemu lub Dockera (szczególnie do wersji Docker Engine 29) wielu administratorów zauważa, że Portainer uruchamia się poprawnie, można się do niego zalogować, ale nie da się zarządzać lokalnym środowiskiem Docker.

W interfejsie Portainera pojawia się wtedy komunikat:

Failed loading environment
The environment named local is unreachable

W tym artykule pokazuję najszybsze i najprostsze rozwiązanie, które pozwala przywrócić działanie Portainera bez cofania Dockera ani systemu operacyjnego.


Dlaczego Portainer przestaje działać po aktualizacji Dockera?

Od wersji Docker Engine 29 demon Dockera wymusza minimalną wersję API na poziomie 1.44. Problem polega na tym, że aktualna wersja Portainer CE wciąż korzysta ze starszej wersji Docker API.

Efekt jest następujący:

  • Docker działa poprawnie
  • Kontener Portainera uruchamia się bez błędów
  • Portainer nie może połączyć się z lokalnym Dockerem

To powoduje, że środowisko local jest oznaczone jako niedostępne.


Najprostsze i najszybsze rozwiązanie problemu

Rozwiązaniem jest obniżenie minimalnej wersji Docker API, którą demon Dockera akceptuje od klientów takich jak Portainer.

Wykonuje się to poprzez edycję pliku konfiguracyjnego Dockera:

Krok 1: Edycja pliku /etc/docker/daemon.json

Na hoście (Debian, Ubuntu, Raspberry Pi OS) otwórz plik:

sudo nano /etc/docker/daemon.json

Jeżeli plik nie istnieje, utwórz go i wklej:

{
  "min-api-version": "1.24"
}

Jeżeli plik już istnieje (np. zawiera data-root), dopisz nową linię, zachowując poprawną składnię JSON:

{
  "data-root": "/var/lib/docker",
  "min-api-version": "1.24"
}

Uwaga: brak przecinka między wpisami spowoduje, że Docker nie uruchomi się.


Krok 2: Restart Dockera

sudo systemctl daemon-reload
sudo systemctl restart docker

Sprawdź, czy Docker działa poprawnie:

docker ps

Krok 3: Restart Portainera

docker restart portainer

Po kilku sekundach odśwież interfejs Portainera w przeglądarce.


Efekt końcowy

Po wykonaniu powyższych kroków:

  • środowisko local w Portainerze staje się dostępne
  • można normalnie zarządzać kontenerami i stackami
  • nie ma potrzeby downgrade’u Dockera

Podsumowanie

Problem z Portainerem po aktualizacji Dockera wynika z niezgodności wersji Docker API, a nie z błędnej konfiguracji kontenera.

Dodanie wpisu:

"min-api-version": "1.24"

w pliku /etc/docker/daemon.json jest obecnie najszybszym i najbezpieczniejszym rozwiązaniem, dopóki Portainer nie wprowadzi pełnej kompatybilności z Docker Engine 29.

G

Tagi: , , ,

OpenVAS w kontenerze Docker

2 grudnia, 2025 | Brak Komentarzy | Kategoria: Linux, Porady
OpenVAS, Docker

Przewodnik po obrazie immauss/openvas

 

OpenVAS (Open Vulnerability Assessment Scanner) to jedno z najbardziej rozpoznawalnych narzędzi open-source do skanowania luk w zabezpieczeniach.
Dzięki konteneryzacji z wykorzystaniem Dockera wdrożenie oraz utrzymanie tego skanera stało się prostsze, bardziej powtarzalne i odporne na problemy
z zależnościami systemowymi. Jednym z najpopularniejszych kontenerowych wydań jest obraz immauss/openvas, który umożliwia szybkie uruchomienie w pełni funkcjonalnego środowiska skanowania na dowolnym serwerze obsługującym Docker.

Czym jest immauss/openvas?

Obraz immauss/openvas to nieoficjalny, lecz aktywnie rozwijany kontener Dockera zawierający kompletną instalację narzędzia OpenVAS/GVM.
Projekt jest regularnie aktualizowany, co zapewnia świeże bazy NVT (Network Vulnerability Tests), środowisko GVM oraz kompatybilność z nowszymi wersjami Dockera.

Najważniejsze cechy obrazu:

  • oparty na aktualnych pakietach GVM,
  • zautomatyzowane pobieranie i aktualizacje baz NVT,
  • gotowy do użycia interfejs webowy,
  • uproszczona konfiguracja oraz start kontenera.

Instalacja i pierwsze uruchomienie

Wymagania wstępne

  • System Linux, macOS lub Windows (z włączonym Docker Desktop).
  • Zainstalowany i działający Docker Engine.

Pobranie obrazu

docker pull immauss/openvas

Uruchomienie kontenera

Przykładowa komenda docker run:

docker run -d \
  --name openvas \
  -p 8080:9392 \
  -v openvas-data:/data \
  immauss/openvas

Opis parametrów:

  • --name openvas — nazwa kontenera,
  • -p 8080:9392 — mapowanie portu interfejsu webowego GVM na port 8080 hosta,
  • -v openvas-data:/data — wolumen zapewniający trwałość danych (konfiguracje, wyniki skanów, raporty).

Ważna informacja — pierwsze uruchomienie trwa długo

Przy pierwszym starcie kontener pobiera pełną bazę testów NVT oraz kompiluje je – operacja ta może potrwać
nawet kilkadziesiąt minut, w zależności od wydajności dysku i łącza internetowego. Jest to zachowanie oczekiwane i
nie należy przerywać tego procesu, jeśli kontener wygląda na zajęty lub logi intensywnie się przewijają.

Dostęp do interfejsu webowego i pierwsze kroki

Po poprawnym uruchomieniu kontenera otwórz przeglądarkę i wpisz adres:

http://[IP_SERWERA]:8080

Domyślny login: admin
Hasło: generowane automatycznie przy starcie kontenera.

Aby wyświetlić wygenerowane hasło, użyj polecenia:

docker logs openvas | grep "Admin Password"

Po zalogowaniu zaleca się natychmiastową zmianę hasła oraz konfigurację podstawowych parametrów systemu,
w szczególności ustawień związanych z kontami użytkowników, polityką haseł oraz dostępem sieciowym do panelu GVM.

Kluczowe funkcje i możliwości OpenVAS/GVM

OpenVAS w wersji kontenerowej oferuje pełny zestaw funkcjonalności środowiska GVM, co pozwala na realizację
kompleksowych procesów zarządzania podatnościami w infrastrukturze IT.

Skanowanie hostów i sieci

  • skan pojedynczego adresu IP,
  • skan całych zakresów adresowych (np. w notacji CIDR),
  • zaawansowane skanowanie z parametryzacją portów, intensywności testów oraz wykluczeń.

Zarządzanie zadaniami skanowania

  • definiowanie zadań skanowania przypisanych do konkretnych celów (Targets),
  • tworzenie harmonogramów skanów cyklicznych,
  • wykorzystanie profili skanowań dostosowanych do różnych scenariuszy (np. szybki skan, pełny audyt).

Zaawansowana analiza raportów

  • eksport raportów do formatów takich jak PDF, XML czy TXT,
  • grupowanie wyników według poziomu ryzyka i rodzaju podatności,
  • śledzenie zmian podatności w czasie, co ułatwia weryfikację efektywności wdrażanych poprawek.

Integracje i automatyzacja

  • dostępne API GVM (GMP), pozwalające na integrację z systemami SIEM, SOAR lub autorskimi narzędziami,
  • możliwość uruchamiania skanów zautomatyzowanych w ramach pipeline’ów CI/CD,
  • współpraca z systemami zarządzania ryzykiem i ticketingiem (np. poprzez integracje pośrednie).

Zalety użycia wersji kontenerowej

Uruchomienie OpenVAS jako kontenera Dockera niesie ze sobą szereg korzyści z punktu widzenia administratorów systemów
oraz zespołów odpowiedzialnych za cyberbezpieczeństwo.

Izolacja środowiska

Kontener zapewnia izolację procesów i zależności od systemu hosta. Dzięki temu instalacja OpenVAS nie wpływa na inne
usługi oraz pakiety zainstalowane w systemie operacyjnym, a ewentualne konflikty bibliotek są znacząco ograniczone.

Łatwość aktualizacji

Aktualizacja środowiska sprowadza się do pobrania nowszej wersji obrazu i ponownego uruchomienia kontenera:

docker pull immauss/openvas
docker stop openvas
docker rm openvas
docker run -d \
  --name openvas \
  -p 8080:9392 \
  -v openvas-data:/data \
  immauss/openvas

Dane (konfiguracje, wyniki skanów, raporty) pozostają zachowane w wolumenie openvas-data.

Przenośność i skalowalność

Kontener można uruchomić na dowolnym serwerze, który obsługuje Dockera — zarówno w infrastrukturze on-premise,
jak i w chmurze. Umożliwia to szybkie tworzenie środowisk testowych, a także skalowanie rozwiązania poprzez uruchomienie
wielu instancji w zależności od potrzeb organizacji.

Brak konfliktów zależności

Tradycyjna instalacja OpenVAS bezpośrednio w systemie bywa wymagająca i podatna na problemy z zależnościami.
Wersja kontenerowa eliminuje konieczność ręcznej kompilacji czy dostosowywania środowiska, ponieważ wszystkie
potrzebne komponenty znajdują się wewnątrz obrazu Docker.

Szybkie i powtarzalne wdrożenie

Wdrożenie OpenVAS za pomocą kontenera Docker może zostać w pełni zautomatyzowane (np. z użyciem Ansible, Terraform
czy pipeline’ów CI/CD), co pozwala na szybkie odtwarzanie środowiska w różnych lokalizacjach lub w razie awarii.

Podsumowanie

Kontener immauss/openvas stanowi wydajne, stabilne i praktyczne rozwiązanie dla specjalistów
cyberbezpieczeństwa, administratorów systemów, zespołów SOC oraz pentesterów. Umożliwia szybkie wdrożenie narzędzia
OpenVAS na dowolnym środowisku, zapewnia efektywną automatyzację skanowania oraz pełną powtarzalność konfiguracji.

Włączenie tego rozwiązania do arsenału narzędzi bezpieczeństwa znacząco ułatwia prowadzenie regularnych, niezależnych audytów podatności, wspiera proces zarządzania ryzykiem oraz pozwala na bieżąco weryfikować stan bezpieczeństwa infrastruktury IT w organizacji.

G

Tagi: , ,

Kontener WordPress i strefa czasowa

31 maja, 2023 | Brak Komentarzy | Kategoria: Linux, Porady
Kontener WordPress

Wirtualizacja i kontneryzacja są zdecydowanie technikami zmieniającymi sposób w jaki budujemy swoje usługi. O ile kiedyś przygotowanie np. własnej (nawet) statycznej strony www wymagało przygotowania serwera, później zainstalowania i skonfigurowania oprogramowania (nie wspominając, że najpierw w pocie czoła składało się coś na kształt peceta hmm… serwerowego) o tyle obecnie cały proces znacznie się skrócił bo dostajemy gotowe moduły do uruchomienia czy to w środowiskach wirtualizacyjnych, czy to na platformie dla kontenerów.

Oczywiście nie ma rozwiązań doskonałych i nawet coś tak łatwego w utrzymaniu jak kontenery ma swoje ułomności. Jedną z nich, dosyć często występującą, jest brak obsługi strefy czasowej w przypadku bardzo popularnego systemu CMS jakim jest WordPress. Jest to zadziwiające, że w przypadku oficjalnego obrazu dostępnego w serwisie Docker Hub nie pomyślano o tym. Być może nie jest to wada, która będzie uciążliwa od pierwszych minut funkcjonowania naszej strony ale szybko ujawni się jeśli włączymy np. dwustopniową autoryzację podczas logowania do panelu administracyjnego. Poniżej opisuję krótko jak naprawić tą niedogodność.

W internecie można znaleźć dużo porad na ten temat jednak tak naprawdę tylko jedna z nich sprawdziła się w moim przypadku. Dotyczy ona konfiguracji w oparciu o plik YAML dla konfiguracji Docker Compose. Przy korzystaniu z Portainera, czyli narzędzia, które zdecydowanie mogę polecić nie tylko początkującym, jest to w zasadzie najprostsza droga dla budowania całkiem skomplikowanych konfiguracji.

Rozwiązanie w całości opiera się na dopisaniu kliku linijek tekstu we wspomnianym pliku konfiguracyjnym:

services:
  service_name:
    volumes:
      - "/etc/timezone:/etc/timezone:ro"
      - "/etc/localtime:/etc/localtime:ro"

Jeśli zapewnimy prawidłową konfigurację systemu hosta kontenerów – mam na myśli strefę czasową – to praktycznie kontener WordPress skopiuje te ustawienia do swojego obrazu. Tylko tyle i aż tyle. Zatem do roboty!

MG

Tagi: , ,

Reset hasła administratora – Portainer

29 marca, 2023 | Brak Komentarzy | Kategoria: Linux, Porady
Portainer

Konteneryzacja przy użyciu Dockera jest obecnie jednym z absolutnie topowych tematów. Świat zmierza w kierunku upraszczania i przyspieszania wszelkich operacji więc nikogo nie zdziwi, że do zarządzania Dockerem najłatwiej i najszybciej jest użyć nakładki o nazwie Portainer. Niestety zawodna pamięć ludzka (oraz brak dobrych nawyków) często prowadzą nas na manowce. W konsekwencji może zdarzyć się, że hasło administracyjne do tego ostatniego po prostu nam umknie. Co wtedy zrobić?

Po pierwsze musimy zmierzyć się z konsolą serwera i zatrzymać kontener Portainer:

docker stop "id-kontenera-portainera"

W drugim kroku przystępujemy do właściwej operacji pobierając odpowiednie narzędzie z repozytorium:

docker pull portainer/helper-reset-password

Ostatecznie możemy zeresetować hasło dla konta admin:

docker run --rm -v portainer_data:/data portainer/helper-reset-password

W wyniku działania powyższej komendy powinniśmy otrzymać zestaw niezbędnych informacji:

... Password succesfully updated for user: admin
... Use the following password to login: ****

Zwróćmy uwagę na wyświetlane hasło, które trzeba zapamiętać. Najprawdopodobniej zmienimy je przy pierwszej okazji ale na razie będzie nam potrzebne.

Na koniec używamy poniższego polecenia, aby ponownie uruchomić kontener z Portainerem, a następnie zalogować się przy użyciu nowego hasła.

docker start "id-kontenera-portainera"

Jak wspomniałem podejrzewam, że pierwszą czynnością będzie zmiana hasła i cały cykl znowu może się powtórzyć. 😉

Tagi: , ,