Bądź na bieżąco - RSS

WP Staging – bezpieczne testy WordPressa przed aktualizacją

30 maja, 2026 | Brak Komentarzy | Kategoria: Linux, Porady

WP Staging – kopia testowa WordPress przed aktualizacjąWP Staging to wtyczka, która pozwala utworzyć testową kopię strony WordPress bez ręcznego kopiowania plików, eksportowania bazy danych i poprawiania adresów URL. W praktyce jest to jedno z tych narzędzi, które warto mieć pod ręką przed większą aktualizacją WordPressa, motywu, wtyczek albo przed zmianą wyglądu strony.

Najważniejszy sens stagingu jest prosty: najpierw testujemy zmiany na kopii strony, a dopiero później wykonujemy je na stronie produkcyjnej. Dzięki temu ryzyko awarii publicznej witryny jest znacznie mniejsze.

W tym artykule pokażę:

  • do czego służy wtyczka WP Staging,
  • kiedy warto jej używać,
  • jak przygotować środowisko przed klonowaniem strony,
  • jak utworzyć kopię testową WordPressa krok po kroku,
  • na co uważać przy SEO, bezpieczeństwie i kopiach zapasowych,
  • jakie są typowe problemy i ograniczenia wersji darmowej.

Zanim zaktualizujesz WordPressa, motyw lub ważną wtyczkę, utwórz kopię testową. Kilka minut pracy ze stagingiem może oszczędzić kilka godzin przywracania strony po nieudanej aktualizacji.

Dlaczego WP Staging ma sens w administracji WordPressem?

WordPress jest wygodnym systemem, ale każda aktualizacja może zmienić zachowanie strony. Najczęściej wszystko przebiega poprawnie, jednak w praktyce administratorzy spotykają się z problemami typu:

  • biały ekran po aktualizacji wtyczki,
  • konflikt nowej wersji PHP z motywem,
  • niedziałający formularz kontaktowy,
  • rozsypany układ strony po aktualizacji buildera,
  • problemy z WooCommerce lub płatnościami,
  • niewidoczne błędy JavaScript w panelu lub na froncie strony.

Staging rozwiązuje ten problem w prosty sposób. Tworzymy kopię strony, wykonujemy aktualizacje na kopii, sprawdzamy najważniejsze funkcje i dopiero wtedy podejmujemy decyzję, czy można działać na stronie produkcyjnej.

[GRAFIKA: schemat „Strona produkcyjna → WP Staging → kopia testowa → test aktualizacji → decyzja o wdrożeniu”]

Co robi wtyczka WP Staging?

WP Staging potrafi utworzyć kopię działającej strony WordPress w osobnym katalogu, np.:

https://twojadomena.pl/staging/

Wtyczka kopiuje pliki oraz bazę danych, a następnie przygotowuje środowisko testowe tak, aby można było zalogować się do niego oddzielnie i sprawdzić zmiany bez wpływu na stronę główną.

Według opisu w repozytorium WordPress.org WP Staging łączy funkcje stagingu, klonowania, backupu, odtwarzania i migracji. Wersja darmowa pozwala m.in. utworzyć kopię strony w podkatalogu, wykonywać backupy oraz korzystać z procesu działającego na własnym serwerze, bez zewnętrznej usługi SaaS.

Kiedy warto używać WP Staging?

Najczęstsze scenariusze użycia są bardzo praktyczne:

  • Aktualizacja WordPressa – szczególnie przy większych zmianach wersji.
  • Aktualizacja motywu – zwłaszcza gdy motyw ma własne szablony, builder albo zmiany w plikach potomnych.
  • Test nowych wtyczek – zanim dodamy je do produkcji.
  • Zmiana wersji PHP – dobry test przed przełączeniem hostingu na nowsze PHP.
  • Przebudowa strony – kiedy chcemy spokojnie przygotować nowy układ bez pokazywania go użytkownikom.
  • Diagnostyka błędów – można bezpiecznie wyłączać wtyczki i testować konflikty.

Przygotowanie przed utworzeniem kopii testowej

Zanim klikniemy przycisk tworzenia stagingu, warto wykonać kilka prostych czynności kontrolnych.

1. Wykonaj pełną kopię zapasową

Staging nie powinien zastępować backupu. Przed większymi zmianami wykonaj osobną kopię:

  • plików strony,
  • bazy danych,
  • katalogu wp-content,
  • konfiguracji, np. wp-config.php.

Jeżeli strona działa na hostingu współdzielonym, sprawdź też, czy hosting umożliwia szybkie przywrócenie kopii z panelu administracyjnego.

2. Sprawdź wolne miejsce na serwerze

Kopia testowa zajmuje dodatkowe miejsce. Jeżeli strona ma dużo zdjęć, dokumentów PDF, kopii archiwalnych lub katalogów cache, staging może być znacznie większy, niż się spodziewamy.

Warto wcześniej sprawdzić rozmiar katalogów:

du -sh public_html
du -sh public_html/wp-content
du -sh public_html/wp-content/uploads

Na hostingu bez SSH można to zwykle sprawdzić w menedżerze plików lub panelu administracyjnym hostingu.

3. Wyłącz zbędne cache na czas testów

Wtyczki cache, optymalizacji JavaScript i CDN potrafią utrudniać diagnozę. Na kopii testowej dobrze jest sprawdzić, czy problem pochodzi z kodu strony, czy tylko ze starego cache.

Po utworzeniu stagingu warto więc wyczyścić:

  • cache WordPressa,
  • cache wtyczki optymalizacyjnej,
  • cache po stronie hostingu,
  • cache CDN, jeżeli jest używany.

Instalacja WP Staging

Najprostsza instalacja odbywa się z panelu WordPressa:

  1. Zaloguj się do panelu administracyjnego WordPressa.
  2. Przejdź do Wtyczki → Dodaj nową.
  3. Wyszukaj WP STAGING.
  4. Zainstaluj wtyczkę „WP STAGING – WordPress Backup, Restore & Migration”.
  5. Aktywuj wtyczkę.

Po aktywacji w menu WordPressa pojawi się sekcja WP Staging. To z niej uruchamiamy klonowanie, backup lub inne operacje dostępne w danej wersji wtyczki.

Tworzenie kopii testowej krok po kroku

Krok 1: Utworzenie nowej strony staging

W panelu WordPressa przejdź do:

WP Staging → Staging Sites → Create New Staging Site

Następnie nadaj nazwę kopii testowej. Najlepiej użyć prostej nazwy technicznej, np.:

staging
test
dev

Jeżeli wybierzesz nazwę staging, kopia może być dostępna pod adresem podobnym do:

https://twojadomena.pl/staging/

Krok 2: Wybór plików i tabel bazy danych

W większości prostych stron można zostawić ustawienia domyślne. Jeżeli jednak strona jest duża, warto rozważyć pominięcie katalogów, które nie są potrzebne do testów, np. starych backupów, dużych archiwów ZIP albo katalogów cache.

Nie należy natomiast pochopnie wyłączać tabel bazy danych. Jeżeli nie mamy pewności, do czego służy dana tabela, lepiej ją skopiować. Dotyczy to szczególnie stron z WooCommerce, formularzami, rezerwacjami lub niestandardowymi wtyczkami.

Krok 3: Start klonowania

Po sprawdzeniu ustawień klikamy przycisk uruchamiający klonowanie. Czas wykonania zależy od:

  • rozmiaru strony,
  • liczby plików w uploads,
  • wydajności hostingu,
  • rozmiaru bazy danych,
  • limitów PHP i operacji I/O.

Na małej stronie proces może potrwać kilka minut. Na dużych stronach z wieloma zdjęciami lub sklepem internetowym trzeba liczyć się z dłuższym czasem.

Krok 4: Logowanie do kopii testowej

Po zakończeniu procesu WP Staging pokaże link do strony testowej. Do panelu stagingu logujemy się zwykle tym samym kontem administratora, którego używamy na stronie produkcyjnej.

Warto od razu sprawdzić, czy jesteśmy faktycznie na kopii testowej. WP Staging oznacza środowisko stagingowe w panelu administracyjnym, aby ograniczyć ryzyko pomylenia go ze stroną produkcyjną.

Co testować na kopii staging?

Po utworzeniu kopii nie chodzi tylko o to, żeby sprawdzić, czy strona się otwiera. Dobra procedura testowa powinna obejmować najważniejsze elementy witryny.

  • Strona główna i kilka podstron.
  • Menu, stopka i widżety.
  • Formularz kontaktowy.
  • Wyszukiwarka na stronie.
  • Logowanie do panelu.
  • Dodawanie i edycja wpisu.
  • Wyświetlanie grafik i dokumentów.
  • Responsywność na telefonie.
  • Podstawowe błędy w konsoli przeglądarki.

Jeżeli strona działa jako sklep, należy dodatkowo sprawdzić koszyk, proces zamówienia, metody płatności i wiadomości e-mail. Na stagingu trzeba jednak uważać, aby nie wysyłać testowych wiadomości do prawdziwych klientów.

WP Staging a SEO

Staging nie powinien być indeksowany przez Google. Kopia testowa może zawierać te same treści co strona produkcyjna, a to mogłoby powodować problemy z duplikacją treści.

WP Staging zabezpiecza kopie testowe przed indeksowaniem i ogranicza dostęp do nich. Mimo tego warto ręcznie sprawdzić ustawienia:

  • czy staging wymaga logowania,
  • czy w ustawieniach WordPressa zaznaczona jest opcja zniechęcania wyszukiwarek do indeksowania,
  • czy wtyczka SEO nie generuje mapy strony dla środowiska testowego,
  • czy przypadkowo nie dodaliśmy linku do stagingu w publicznym menu.

W środowisku produkcyjnym, gdzie używany jest Yoast SEO, po zakończeniu testów warto sprawdzić również tytuły SEO, opisy meta i mapę strony. Nie chodzi o to, żeby optymalizować staging, ale aby upewnić się, że po aktualizacji nic nie popsuło konfiguracji SEO na stronie głównej.

Wersja darmowa czy Pro?

Wersja darmowa WP Staging jest wystarczająca do podstawowego scenariusza: utworzenia kopii testowej i ręcznego sprawdzenia aktualizacji. To bardzo dobry start dla administratorów, którzy chcą bezpieczniej testować zmiany.

Wersja Pro dodaje funkcje przydatne w bardziej profesjonalnych procesach, m.in. przesyłanie zmian ze stagingu na produkcję, bardziej rozbudowane scenariusze backupu, migracje, obsługę multisite i integracje z zewnętrznymi miejscami przechowywania kopii.

W praktyce wybór zależy od sposobu pracy:

  • jeżeli potrzebujesz tylko sprawdzić aktualizację przed wykonaniem jej na produkcji – zwykle wystarczy wersja darmowa,
  • jeżeli chcesz przenosić zmiany ze stagingu na stronę produkcyjną jednym procesem – sprawdź wersję Pro,
  • jeżeli obsługujesz strony klientów, sklepy lub większe serwisy – warto rozważyć płatną wersję i regularny backup poza serwerem.

Typowe problemy

Brak miejsca na serwerze

To jeden z najczęstszych problemów. Jeżeli klonowanie zatrzymuje się lub kończy błędem, sprawdź wolną przestrzeń dyskową. Szczególnie duże potrafią być katalogi:

wp-content/uploads
wp-content/cache
wp-content/backup
wp-content/updraft
wp-content/ai1wm-backups

Starych kopii zapasowych nie warto kopiować do stagingu, jeżeli nie są potrzebne do testów.

Limity hostingu

Na hostingu współdzielonym mogą przeszkadzać limity czasu wykonania PHP, pamięci RAM albo operacji na plikach. W takim przypadku warto:

  • wykluczyć niepotrzebne katalogi z klonowania,
  • wykonać proces poza godzinami dużego ruchu,
  • zwiększyć limity PHP w panelu hostingu,
  • sprawdzić logi błędów.

Problem z logowaniem do stagingu

Jeżeli po utworzeniu kopii testowej nie można się zalogować, przyczyną może być wtyczka bezpieczeństwa, zmieniony adres logowania albo dodatkowe uwierzytelnianie. Warto sprawdzić ustawienia WP Staging oraz tymczasowo uprościć konfigurację zabezpieczeń na kopii testowej.

Mylenie strony produkcyjnej z testową

To błąd organizacyjny, ale bardzo realny. Przed wykonaniem zmian zawsze sprawdź pasek adresu w przeglądarce. Dobrym nawykiem jest używanie innego koloru panelu administracyjnego na stagingu lub dodanie wyraźnego opisu w kokpicie.

Dobre praktyki

  • Twórz staging przed większymi aktualizacjami, nie dopiero po awarii.
  • Nie traktuj stagingu jako jedynego backupu.
  • Nie trzymaj starych kopii testowych bez potrzeby.
  • Nie udostępniaj publicznie adresu stagingu.
  • Po testach usuń niepotrzebną kopię, aby odzyskać miejsce.
  • Przy stronach firmowych prowadź krótką listę testów do wykonania po aktualizacji.

Efekt końcowy

Po poprawnym wdrożeniu WP Staging zyskujemy prosty i powtarzalny sposób testowania zmian. Administrator może sprawdzić aktualizacje, nowe wtyczki i modyfikacje motywu bez ryzyka natychmiastowego uszkodzenia strony produkcyjnej.

Nie jest to zamiennik dobrego backupu, ale bardzo dobre uzupełnienie codziennej administracji WordPressem. W małych firmach, stronach usługowych i blogach technologicznych staging często wystarcza, aby uniknąć najbardziej typowych problemów po aktualizacjach.

Podsumowanie

WP Staging to praktyczna wtyczka dla każdego, kto administruje stroną WordPress i chce ograniczyć ryzyko zmian wykonywanych „na żywym organizmie”. Największą wartością jest możliwość szybkiego utworzenia kopii testowej, sprawdzenia aktualizacji i spokojnego podjęcia decyzji, czy można przejść do strony produkcyjnej.

Jeżeli WordPress jest ważnym elementem komunikacji firmy, sprzedaży albo obsługi klientów, staging powinien być standardowym etapem przed większymi zmianami. Zasada jest prosta: najpierw test, potem produkcja.

Źródła

G

Tagi: , ,

ZeroTier na PiKVM – zdalny dostęp do konsoli bez publicznego adresu IP

25 kwietnia, 2026 | Brak Komentarzy | Kategoria: Linux, Porady

ZeroTier na PiKVMZeroTier na PiKVM – zdalny dostęp do konsoli bez publicznego adresu IP

PiKVM jest jednym z tych narzędzi, które najbardziej docenia się dopiero w sytuacji awaryjnej: serwer nie startuje, trzeba wejść do BIOS/UEFI, zmienić kolejność bootowania albo sprawdzić komunikat na ekranie, kiedy zwykły pulpit zdalny już nie działa. Problem zaczyna się wtedy, gdy urządzenie znajduje się za NAT-em, w sieci klienta albo w miejscu, gdzie nie chcemy wystawiać żadnych portów do Internetu.

Jednym z praktycznych rozwiązań jest podłączenie PiKVM do prywatnej sieci ZeroTier. W efekcie administrator łączy się z panelem PiKVM po adresie z wirtualnej sieci, bez przekierowania portów na routerze i bez udostępniania interfejsu WWW publicznie.

Kiedy takie rozwiązanie ma sens?

  • gdy PiKVM pracuje w lokalizacji bez stałego publicznego adresu IP,
  • gdy nie chcemy konfigurować przekierowania portów na routerze,
  • gdy urządzenie ma służyć jako awaryjny dostęp do serwera lub komputera,
  • gdy potrzebujemy prostego dostępu administracyjnego do kilku lokalizacji.

W praktyce jest to podobne do małego, prywatnego VPN-a dla urządzeń administracyjnych. ZeroTier tworzy osobną sieć, a dostęp do PiKVM otrzymują tylko zatwierdzone urządzenia.

Założenia

  • PiKVM z systemem w wersji 2022.06.20 lub nowszej,
  • dostęp do konta w ZeroTier Central,
  • utworzona sieć ZeroTier i znany jej Network ID,
  • dostęp root do PiKVM przez SSH lub web terminal,
  • świadomość, że modyfikujemy usługi systemowe i plik /etc/fstab.

Uwaga: PiKVM zwykle pracuje w trybie tylko do odczytu. To celowe zabezpieczenie przed uszkodzeniem systemu plików przy nagłej utracie zasilania. Dlatego zmiany zaczynamy od komendy rw, a po zakończeniu wracamy do trybu ro.

1. Instalacja pakietu ZeroTier

Logujemy się na PiKVM jako root i przełączamy system plików w tryb zapisu:

rw
pacman -S zerotier-one
systemctl enable --now zerotier-one.service
systemctl stop zerotier-one.service

Usługę uruchamiamy tylko po to, aby wygenerowała swoją tożsamość. Następnie ją zatrzymujemy, ponieważ pliki tożsamości przeniesiemy do trwałej przestrzeni PiKVM.

2. Odczytanie identyfikatora urządzenia

Adres węzła ZeroTier odczytujemy z pliku identity.public:

cat /var/lib/zerotier-one/identity.public | cut -d: -f 1

Otrzymany identyfikator dodajemy w panelu ZeroTier Central do swojej sieci. W nowym panelu można to zrobić przez listę urządzeń sieci, a w starszym panelu przez ręczne dodanie członka lub zatwierdzenie nowego urządzenia.

3. Przeniesienie konfiguracji do trwałej pamięci PiKVM

PiKVM ma specjalną przestrzeń persistent storage, przeznaczoną właśnie na pliki, które mają przetrwać restart. Wykorzystamy ją do przechowania tożsamości ZeroTier.

pst=/var/lib/kvmd/pst/data/zerotier-one

kvmd-pstrun -- mkdir -p "$pst"
kvmd-pstrun -- cp -a /var/lib/zerotier-one/{*.public,*.secret} "$pst"

Następnie tworzymy katalog z konfiguracją sieci i pusty plik <network_id>.conf. Taki plik powoduje dołączenie usługi ZeroTier do wybranej sieci przy starcie.

read -r -p "Podaj Network ID ZeroTier: " NETWORK_ID

kvmd-pstrun -- mkdir -p "$pst/networks.d"
kvmd-pstrun -- touch "$pst/networks.d/$NETWORK_ID.conf"

Opcjonalnie, jeśli chcemy dopuścić konfigurację DNS z ZeroTier, można dodać plik lokalnej konfiguracji dla tej sieci:

kvmd-pstrun -- /bin/sh -c "echo allowDNS=1 > $pst/networks.d/ \
$NETWORK_ID.local.conf"

W środowiskach firmowych warto tę decyzję przemyśleć. DNS z sieci overlay może być przydatny, ale nie zawsze powinien nadpisywać lokalną konfigurację rozwiązywania nazw.

4. Przygotowanie katalogu roboczego ZeroTier jako tmpfs

Usługa ZeroTier standardowo korzysta z katalogu /var/lib/zerotier-one. Chcemy, aby po starcie był to katalog roboczy w pamięci, a właściwe pliki były kopiowane z persistent storage.

rm -rf /var/lib/zerotier-one
mkdir -p /var/lib/zerotier-one

grep -q '^tmpfs /var/lib/zerotier-one ' /etc/fstab || \
echo "tmpfs /var/lib/zerotier-one tmpfs mode=0755 0 0" >> /etc/fstab

mount -a

Komenda mount -a jest ważna, ponieważ od razu montuje nowy wpis z /etc/fstab. Bez tego usługa może wystartować na nieprzygotowanym katalogu.

5. Nadpisanie konfiguracji usługi systemd

Teraz tworzymy drop-in dla usługi ZeroTier:

systemctl edit zerotier-one.service

W edytorze wklejamy:

[Unit]
Requires=var-lib-zerotier\x2done.mount
After=var-lib-zerotier\x2done.mount
ConditionPathIsReadWrite=/var/lib/zerotier-one

[Service]
ExecStartPre=-/usr/bin/find /var/lib/zerotier-one -mindepth 1 -delete
ExecStartPre=/usr/bin/cp -a /var/lib/kvmd/pst/data/zerotier-one/. \
/var/lib/zerotier-one/

Najczęstsza literówka w tym miejscu to wpisanie zerotier-one.zervice zamiast zerotier-one.service. Warto też zwrócić uwagę na kropkę na końcu ścieżki źródłowej w poleceniu cp. Dzięki niej kopiujemy zawartość katalogu, a nie sam katalog jako podkatalog.

Po zapisaniu pliku przeładowujemy systemd:

systemctl daemon-reload

6. Powrót do trybu tylko do odczytu i uruchomienie usługi

ro
systemctl start zerotier-one.service

Stan usługi sprawdzamy poleceniem:

systemctl status zerotier-one.service

Po poprawnym starcie powinniśmy zobaczyć, że przed uruchomieniem usługi wykonują się kroki ExecStartPre, czyli czyszczenie katalogu roboczego i kopiowanie konfiguracji z persistent storage.

7. Sprawdzenie połączenia

Listę sieci ZeroTier sprawdzamy poleceniem:

zerotier-cli listnetworks

Adres IP z interfejsu ZeroTier można odszukać na przykład tak:

ip a | grep zt

Po zatwierdzeniu urządzenia w ZeroTier Central i przydzieleniu adresu IP, panel PiKVM powinien być dostępny z komputera administratora pod adresem z sieci ZeroTier, np.:

https://ADRES_ZEROTIER_PIKVM/

Typowe problemy

  • PiKVM nie pojawia się w ZeroTier Central – sprawdź, czy usługa działa i czy urządzenie ma dostęp do Internetu.
  • Brak adresu IP w ZeroTier – upewnij się, że urządzenie zostało autoryzowane w panelu ZeroTier.
  • Usługa nie startuje po zmianie fstab – sprawdź, czy istnieje katalog /var/lib/zerotier-one i wykonaj mount -a.
  • Po restarcie znika konfiguracja – sprawdź, czy pliki *.public, *.secret i networks.d znajdują się w /var/lib/kvmd/pst/data/zerotier-one.
  • Nie działa DNS z ZeroTier – sprawdź zawartość pliku <network_id>.local.conf i ustawienie allowDNS.

Efekt końcowy

Po wykonaniu konfiguracji PiKVM dołącza do prywatnej sieci ZeroTier automatycznie po starcie. Administrator łączy się z urządzeniem po adresie z sieci overlay, bez publikowania panelu PiKVM w Internecie i bez konfigurowania przekierowań portów.

To dobre rozwiązanie dla serwisowego dostępu awaryjnego, małych serwerowni, komputerów przemysłowych oraz lokalizacji, w których klasyczny VPN jest zbyt ciężki albo nie obejmuje wszystkich urządzeń.

Podsumowanie

ZeroTier na PiKVM nie zastępuje zdrowych zasad bezpieczeństwa, ale może znacząco uprościć dostęp administracyjny. Najważniejsze jest to, aby nie traktować PiKVM jako publicznej strony WWW. Dostęp powinien być ograniczony, konta zabezpieczone mocnym hasłem, a lista członków sieci ZeroTier regularnie kontrolowana.

Warto również zapisać sobie procedurę cofnięcia zmian i testować konfigurację wtedy, gdy mamy jeszcze fizyczny dostęp do urządzenia. PiKVM najczęściej przydaje się wtedy, gdy wszystko inne zawodzi, więc jego konfiguracja powinna być możliwie prosta i powtarzalna.

Źródła

G

Tagi: , ,

Jak zbudować ścianę wideo monitoringu w OBS Studio i wyświetlać wiele kamer na jednym ekranie

28 marca, 2026 | Brak Komentarzy | Kategoria: Linux, MacOS, Porady, Windows

Ściana wideo monitoringu w OBS Studio na ekranie z wieloma kamerami IP

Ściana wideo monitoringu w OBS Studio to prosty sposób na wyświetlanie wielu kamer IP na jednym ekranie bez wdrażania drogiego systemu VMS. Takie rozwiązanie sprawdza się w firmach, magazynach, halach produkcyjnych, punktach usługowych i niewielkich centrach nadzoru, gdzie liczy się czytelny podgląd obrazu, elastyczny układ i niski koszt uruchomienia.

OBS Studio kojarzy się głównie ze streamingiem, ale w praktyce bardzo dobrze nadaje się również do budowy stanowiska podglądu. Program pozwala tworzyć sceny z wielu źródeł, skalować obraz, układać kamery w siatki i wysyłać gotowy widok na osobny monitor lub telewizor. Oficjalna dokumentacja OBS potwierdza, że sceny i źródła są podstawą pracy programu, a Projector Output pozwala wyświetlać sceny, preview, program i multiview na dodatkowych ekranach.

Dlaczego warto zbudować ścianę wideo monitoringu w OBS Studio

Największą zaletą takiego rozwiązania jest elastyczność. W klasycznych systemach monitoringu użytkownik często jest ograniczony do układów narzuconych przez producenta rejestratora lub aplikacji. W OBS możesz samodzielnie przygotować układ 2×2, 3×3, 4×4 albo widok mieszany, w którym jedna kamera zajmuje większą część ekranu, a pozostałe pełnią rolę podglądu pomocniczego.

To ważne zwłaszcza wtedy, gdy jedna strefa wymaga stałej obserwacji, a pozostałe kamery mają jedynie uzupełniać obraz sytuacji. Dzięki temu operator szybciej zauważa zdarzenia i nie traci czasu na przełączanie wielu osobnych okien.

Co przygotować przed konfiguracją

Zanim dodasz kamery do OBS, ustal kilka podstawowych rzeczy:

  • ile kamer ma być widocznych jednocześnie,
  • jaka jest ich rozdzielczość,
  • czy obraz ma być tylko wyświetlany, czy także nagrywany,
  • czy stanowisko będzie pracowało na jednym, czy na kilku ekranach,
  • czy sieć jest stabilna i oparta na LAN, a nie na Wi-Fi.

To etap, którego nie warto pomijać. Im więcej strumieni Full HD lub 4K, tym większe znaczenie mają procesor, karta graficzna i pamięć RAM. W praktyce stabilność jest ważniejsza niż maksymalna rozdzielczość, dlatego lepiej zbudować płynny podgląd niż przeciążone stanowisko z opóźnieniami.

Jak dodać kamery IP do OBS

W OBS podstawą są sceny i źródła. Scena to gotowy układ, a źródła to elementy, które w nim umieszczasz. Mogą to być strumienie z kamer, tekst, grafiki albo inne okna. Oficjalny przewodnik OBS właśnie tak opisuje logikę programu.

Kamery IP najczęściej dodaje się jako źródła strumieni sieciowych lub jako przechwycenie obrazu z innej aplikacji. Najlepiej jednak korzystać z bezpośrednich źródeł tam, gdzie to możliwe, ponieważ taki układ jest bardziej przewidywalny i łatwiejszy w utrzymaniu.

Na tym etapie warto też zadbać o nazewnictwo. Zamiast nazw typu Kamera 1, Kamera 2 i Kamera 3 lepiej użyć nazw opisowych, takich jak:

  • Wejście główne,
  • Brama wschodnia,
  • Magazyn,
  • Linia pakowania,
  • Parking.

Dzięki temu późniejsza obsługa scen będzie dużo wygodniejsza.

Jak ułożyć wiele kamer na jednym ekranie

Najprostszy układ to siatka 2×2 dla czterech kamer. Przy ośmiu lub dziewięciu źródłach zwykle lepiej wygląda siatka 3×3. Z kolei przy większej liczbie kamer bardzo dobrze sprawdza się układ mieszany: jedna duża kamera główna i kilka mniejszych kafli pomocniczych.

Tutaj liczy się czytelność. Ściana wideo monitoringu w OBS Studio ma pomagać w obserwacji, a nie zmuszać operatora do wpatrywania się w zbyt małe okna. Dlatego nie zawsze warto upychać maksymalną liczbę kamer na jednym ekranie. Często lepiej przygotować kilka scen tematycznych, na przykład:

  • wejścia i recepcja,
  • parking i bramy,
  • hala produkcyjna,
  • magazyn i strefa dostaw,
  • widok alarmowy.

Dobrą praktyką jest też dodanie krótkich etykiet tekstowych nad każdą kamerą. To poprawia ergonomię i przyspiesza reakcję operatora.

Jak wyświetlić ścianę wideo monitoringu w OBS Studio na osobnym ekranie

Jedną z najmocniejszych funkcji OBS w takim zastosowaniu jest Projector Output. Oficjalna dokumentacja OBS opisuje, że na drugi ekran można wysłać pojedyncze źródło, scenę, preview, program albo wbudowany multiview, zarówno w trybie pełnoekranowym, jak i okienkowym.

W praktyce oznacza to, że możesz pracować na jednym monitorze z interfejsem OBS, a gotową ścianę wideo pokazywać na drugim ekranie. To bardzo wygodne rozwiązanie dla recepcji, ochrony, dyspozytorni albo stanowiska technicznego.

Wydajność i opóźnienia

Jeżeli planujesz jednocześnie wyświetlać wiele kamer i nagrywać obraz, musisz zwrócić uwagę na wydajność. OBS oferuje pracę na wielu źródłach i scenach, ale przy większej liczbie strumieni każdy dodatkowy element zwiększa obciążenie komputera. Właśnie dlatego warto testować konfigurację na realnych kamerach i sprawdzić, czy nie pojawiają się spadki płynności. Oficjalne materiały OBS podkreślają znaczenie testów i poprawnego ustawienia źródeł jeszcze przed produkcyjnym użyciem.

Dodatkowo pamiętaj, że w monitoringu IP pewne opóźnienie jest normalne. Wynika ono z transmisji, buforowania i dekodowania obrazu. Dlatego najlepiej ograniczać zbędnie skomplikowany tor sygnału i korzystać ze stabilnej sieci przewodowej.

Kiedy OBS wystarczy, a kiedy lepiej wybrać VMS

OBS Studio dobrze sprawdza się wtedy, gdy potrzebujesz elastycznego i niedrogiego podglądu z wielu kamer na jednym ekranie. Jeżeli jednak oczekujesz zaawansowanych alarmów, analityki obrazu, zarządzania użytkownikami, integracji z kontrolą dostępu albo rozbudowanego archiwum nagrań, lepszym wyborem będzie dedykowany system VMS.

W praktyce wiele firm łączy oba podejścia. Rejestrator lub VMS odpowiada za zapis i administrację, a OBS służy do budowy czytelnej ściany wideo dla operatora.

Najczęstsze błędy przy budowie ściany wideo

Najczęstszy błąd to zbyt duża liczba kamer na jednym ekranie. Drugim problemem bywa źle dobrana rozdzielczość projektu. Trzecim – brak logicznego podziału na sceny. Warto też unikać przypadkowych nazw źródeł i pracy na niestabilnym Wi-Fi.

Jeśli chcesz, aby stanowisko działało niezawodnie, ustaw prosty układ, krótkie nazwy, osobne sceny dla kluczowych obszarów i przewodową sieć. Dopiero później rozbudowuj konfigurację.

Podsumowanie

Ściana wideo monitoringu w OBS Studio to rozwiązanie praktyczne, elastyczne i stosunkowo tanie. Pozwala wyświetlać wiele kamer IP na jednym ekranie, przygotować różne sceny dla różnych obszarów i dopasować układ do realnych potrzeb operatora.

Najważniejsze jest jednak nie samo uruchomienie OBS, ale przemyślenie liczby kamer, wydajności komputera, sposobu wyświetlania obrazu i ergonomii pracy. Jeżeli zadbasz o te elementy, OBS może stać się bardzo użytecznym narzędziem do codziennego podglądu monitoringu.

G

Tagi: , , ,

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

Jak zwiększyć rozmiar dysku maszyny wirtualnej w Proxmox – krok po kroku

25 października, 2025 | Brak Komentarzy | Kategoria: Linux, Porady

Interfejs Proxmox z podświetloną opcją zwiększania rozmiaru dysku w maszynie wirtualnej - minimalistyczna grafika wektorowa

Wprowadzenie

Z biegiem czasu nawet najlepiej zaplanowana maszyna wirtualna może zacząć odczuwać brak przestrzeni dyskowej. Rosnące bazy danych, nowe aplikacje, aktualizacje systemowe czy gromadzone logi – wszystko to powoduje, że konieczne staje się zwiększenie rozmiaru dysku w Proxmox. Na szczęście, dzięki elastyczności Proxmox VE, operacja ta jest prosta i bezpieczna – pod warunkiem, że wykonamy ją poprawnie.

W tym poradniku pokazuję jak zwiększyć rozmiar dysku w Proxmox oraz jak rozszerzyć partycję w systemie Linux, aby w pełni wykorzystać nową przestrzeń.

Zwiększanie rozmiaru dysku w Proxmox przez interfejs webowy

Krok 1: Zaloguj się do panelu Proxmox

  1. Otwórz przeglądarkę i wejdź na adres panelu, np. https://twoj-serwer:8006.
  2. W drzewie po lewej wybierz węzeł (node), a następnie właściwą maszynę wirtualną.

Krok 2: Przejdź do zakładki „Hardware”

W ustawieniach VM wybierz zakładkę Hardware. Zobaczysz listę urządzeń przypisanych do maszyny: karty sieciowe, dyski, itp.

Krok 3: Wybierz dysk do powiększenia

  1. Z listy wybierz odpowiedni dysk wirtualny (np. scsi0, virtio0, sata0).
  2. Kliknij Disk Actions (Działania na dysku) → Resize (Zmień rozmiar).

Krok 4: Zwiększ rozmiar dysku

  1. W oknie dialogowym podaj, o ile GB chcesz zwiększyć dysk (np. 20).
  2. Potwierdź zmianę — Proxmox powiększy plik dysku.

Uwaga: Operacja zwiększania jest jednokierunkowa. Zmniejszanie dysków nie jest wspierane – upewnij się co do docelowego rozmiaru.

Krok 5: Uruchom maszynę wirtualną

Jeśli VM była wyłączona, uruchom ją. Hypervisor widzi już nowy rozmiar, ale system gościa musi rozszerzyć partycję, by wykorzystać dodatkowe miejsce.

Rozszerzanie partycji w systemie Linux

Po zwiększeniu dysku w Proxmox wykonujemy trzy kroki w gościu:

  1. Aktualizacja tablicy partycji,
  2. Rozszerzenie partycji,
  3. Powiększenie systemu plików.

Sprawdź aktualny stan dysku

Zaloguj się do VM (SSH lub konsola Proxmox) i sprawdź dyski:

lsblk

Przykładowy wynik:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda      252:0    0   80G  0 disk
└─vda1   252:1    0   40G  0 part /

Widać, że dysk vda ma 80 GB, ale partycja vda1 wciąż 40 GB.

Aktualizacja tablicy partycji i rozszerzenie partycji

Wygodne narzędzie to growpart (pakiet cloud-guest-utils):

sudo apt update && sudo apt install -y cloud-guest-utils
sudo growpart /dev/vda 1

Powyższe rozszerza partycję 1 na dysku /dev/vda do maksymalnego dostępnego rozmiaru.

Alternatywy: fdisk, parted (patrz niżej).

Powiększenie systemu plików

Dla ext4:

sudo resize2fs /dev/vda1

Dla XFS (zakładając, że / jest na XFS):

sudo xfs_growfs /

Sprawdź efekt:

df -h

Zwiększanie rozmiaru dysku w systemach z LVM

Jeśli system korzysta z LVM (Logical Volume Manager), po rozciągnięciu partycji fizycznej wykonaj:

  1. Aktualizacja PV: 
    sudo pvresize /dev/vda3
  2. Rozszerzenie LV (na cały wolny obszar): 
    sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
  3. Powiększenie systemu plików (ext4): 
    sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

Narzędzia do zarządzania partycjami w Linux

  • fdisk – klasyczny, interaktywny edytor tablicy partycji (MBR/GPT).
  • parted – nowocześniejszy, dobrze radzi sobie z GPT i dużymi dyskami.
  • growpart – szybkie rozszerzanie istniejących partycji (często na VM).
  • lvextend – powiększanie logicznych wolumenów w LVM.

Najczęstsze problemy i rozwiązania

1) Proxmox nie pozwala zwiększyć dysku

  • Sprawdź typ kontrolera (VirtIO/SCSI) oraz wersję Proxmox.
  • W starszych wersjach wymagane było wyłączenie VM przed powiększeniem.

2) Linux nie widzi nowego rozmiaru

  • Wymuś ponowne odczytanie tablicy partycji: 
    sudo partprobe
  • Jeśli to nie pomaga – uruchom VM ponownie.

3) Brak growpart

  • Użyj fdisk:
    1. Usuń i utwórz tę samą partycję z tym samym początkiem, ale większym końcem.
    2. Zapisz zmiany i wykonaj resize2fs lub xfs_growfs.

    Bezpieczeństwo: dane pozostają nienaruszone, o ile początek partycji się nie zmieni.

4) Błąd przy resize2fs

  • Upewnij się, że system plików nie jest zamontowany jako tylko do odczytu.
  • W razie potrzeby skorzystaj z trybu awaryjnego (single-user) lub z partycji ratunkowej.

Najlepsze praktyki

  • Backup przed operacją – szczególnie w środowiskach produkcyjnych.
  • Stopniowe powiększanie – dodawaj przestrzeń w rozsądnych krokach.
  • Dokumentacja zmian – przyda się do audytu i odtwarzania konfiguracji.

Podsumowanie

  1. Zaloguj się do Proxmox → Hardware → Disk Actions → Resize.
  2. Uruchom VM i zaloguj się do systemu gościa.
  3. Rozszerz partycję (growpart, fdisk, parted).
  4. Powiększ system plików (resize2fs lub xfs_growfs).

Po tych krokach Twoja maszyna wirtualna w pełni wykorzysta większy dysk.

G

Tagi: , , , ,

Bezpieczny serwer SFTP w 5 minut? To możliwe z Dockerem i atmoz/sftp!

27 września, 2025 | Brak Komentarzy | Kategoria: Linux, Porady
Serwer SFTP atmoz/sftp

Potrzebujesz szybko uruchomić bezpieczny serwer SFTP w odizolowanym środowisku, bez instalacji dodatkowego oprogramowania na serwerze? Dzięki obrazowi Docker atmoz/sftp jest to możliwe w kilka minut. W tym artykule pokażemy, jak skonfigurować taki serwer krok po kroku oraz jak dostosować go do różnych scenariuszy w praktyce.

Dlaczego warto wybrać atmoz/sftp?

Obraz atmoz/sftp to lekka, gotowa do użycia implementacja serwera SFTP, która działa w kontenerze Dockera. Rozwiązuje typowe problemy administratorów:

  • Izolacja: serwer SFTP działa w kontenerze, minimalizując ryzyko wpływu na system hosta.
  • Łatwa konfiguracja: wystarczy kilka zmiennych środowiskowych, by uruchomić gotowy serwer.
  • Bezpieczeństwo: dostęp oparty na SSH i możliwość ograniczenia użytkowników do wybranych katalogów.
  • Szybkość wdrożenia: w kilka minut można uruchomić działający serwer, bez kompilacji czy skomplikowanej konfiguracji.

Instalacja Dockera

Jeśli nie masz jeszcze zainstalowanego Dockera, możesz to zrobić w systemach Linux za pomocą poleceń:

sudo apt update 
sudo apt install docker.io -y 
sudo systemctl enable --now docker

Sprawdź, czy Docker działa poprawnie:

docker --version

Uruchomienie podstawowego serwera SFTP

Poniższe polecenie tworzy prosty serwer SFTP z jednym użytkownikiem:

docker run -p 22:22 -d \ 
-v /host/data:/home/user/upload \ 
-e SFTP_USERS="user:password:::upload" \ 
atmoz/sftp

Wyjaśnienie parametrów:

  • -p 22:22 – mapowanie portu kontenera na port hosta.
  • -v /host/data:/home/user/upload – montowanie katalogu z hosta jako przestrzeni dostępnej dla użytkownika.
  • -e SFTP_USERS – definiuje użytkowników w formacie login:hasło:uid:gid:katalog.

Praktyczne scenariusze konfiguracji

1. Jeden użytkownik z dostępem do katalogu

docker run -p 22:22 -d \ 
-v /srv/sftp/data:/home/alice/data \ 
-e SFTP_USERS="alice:SuperHaslo:::data" \ 
atmoz/sftp

Użytkownik alice może logować się i przesyłać pliki wyłącznie do katalogu /home/alice/data.

2. Wielu użytkowników z różnymi katalogami

docker run -p 22:22 -d \ 
-v /srv/sftp/alice:/home/alice/data \ 
-v /srv/sftp/bob:/home/bob/docs \ 
-e SFTP_USERS="alice:HasloAlice:::data bob:HasloBob:::docs" \ 
atmoz/sftp

Każdy użytkownik ma własny katalog i jest w nim ograniczony (tzw. chroot).

3. Integracja z aplikacją – katalog współdzielony

docker run -p 2222:22 -d \ 
-v /srv/app/uploads:/home/client/shared \ 
-e SFTP_USERS="client:TrudneHaslo:::shared" \ 
--name sftp-server \ 
atmoz/sftp

Taki scenariusz jest często używany do automatycznej wymiany danych między aplikacjami a partnerami biznesowymi.

Bezpieczeństwo i dobre praktyki

  • Używaj silnych haseł lub – lepiej – kluczy SSH.
  • Uruchamiaj kontener z ograniczonymi uprawnieniami i wyłącz dostęp roota.
  • Regularnie aktualizuj obraz atmoz/sftp do najnowszej wersji.
  • Monitoruj logi kontenera za pomocą docker logs.

Zalety wykorzystania Dockera i atmoz/sftp

Uruchomienie serwera SFTP w kontenerze Dockera pozwala na:

  • Szybkie wdrożenie: pełna konfiguracja w kilka minut.
  • Łatwą migrację: kontener można przenieść na inny host bez zmian w konfiguracji.
  • Bezpieczeństwo: odizolowane środowisko minimalizuje ryzyko podatności w systemie hosta.
  • Skalowalność: łatwo uruchomić wiele instancji dla różnych klientów.

Podsumowanie

Obraz atmoz/sftp to idealne rozwiązanie, jeśli potrzebujesz szybko uruchomić bezpieczny serwer SFTP w odizolowanym i łatwym do zarządzania środowisku. Dzięki Dockerowi wdrożenie jest proste, a konfiguracja elastyczna – od prostych jednoużytkownikowych scenariuszy po integrację z aplikacjami biznesowymi.

G

Tagi: , , , ,

Jak odblokować funkcje enterprise w Proxmox VE? Poznaj pve-fake-subscription

30 sierpnia, 2025 | Brak Komentarzy | Kategoria: Linux, Porady
pve-fake-subscription

Proxmox VE to jedno z najpopularniejszych, darmowych rozwiązań do wirtualizacji serwerów i zarządzania klastrami. Platforma oferuje bogaty zestaw funkcji, które w komercyjnych produktach często są dodatkowo płatne. Jednak bez aktywnej enterprise subscription, użytkownicy nie mają dostępu do oficjalnych repozytoriów enterprise oraz pełnych funkcji wspieranych przez producenta. Zamiast tego widzą uciążliwe komunikaty o braku subskrypcji.

Czym jest pve-fake-subscription?

pve-fake-subscription to popularny skrypt dostępny na GitHub, który „oszukuje” system Proxmox VE, podając mu fałszywą licencję subskrypcyjną. Dzięki temu panel administracyjny przestaje wyświetlać komunikaty o braku licencji, a użytkownik może odblokować dostęp do pewnych funkcji enterprise.

Jak to działa w uproszczeniu?

  • Skrypt podmienia lokalne pliki konfiguracyjne odpowiedzialne za weryfikację klucza subskrypcji.
  • System uznaje, że posiada ważną subskrypcję enterprise.
  • Dzięki temu znika komunikat o braku licencji, a część funkcji interfejsu zostaje odblokowana.

Rozwiązanie to jest dobrze znane w społeczności homelab i entuzjastów IT, jednak nie jest oficjalnie wspierane przez twórców Proxmox.

Ważne ostrzeżenie

Uwaga: poniższe informacje są przeznaczone wyłącznie do celów edukacyjnych i testowych w środowiskach homelab lub nieprodukcyjnych. Używanie narzędzia pve-fake-subscription w środowisku produkcyjnym może:

  • naruszać warunki licencyjne Proxmox,
  • pozbawić system ważnych aktualizacji bezpieczeństwa,
  • prowadzić do niestabilności i utraty wsparcia technicznego.

Autor niniejszego wpisu ani blog nie ponoszą odpowiedzialności za ewentualne szkody wynikające z użycia tego rozwiązania. Jeśli pracujesz w środowisku produkcyjnym – zawsze korzystaj z legalnej subskrypcji Proxmox Enterprise.

Instalacja i użycie pve-fake-subscription

Poniżej znajduje się przykładowa instrukcja instalacji na serwerze z Proxmox VE. Wymagane są uprawnienia root.

Krok 1: Pobranie repozytorium

apt update && apt install -y git
git clone https://github.com/Jamesits/pve-fake-subscription.git
cd pve-fake-subscription

Krok 2: Uruchomienie skryptu

./install.sh

Po uruchomieniu, skrypt wprowadzi odpowiednie zmiany w systemie, aby Proxmox uznał, że posiada aktywną subskrypcję.

Krok 3: Weryfikacja

Po zalogowaniu się do interfejsu webowego Proxmox VE, komunikat o braku subskrypcji powinien zniknąć. Niektóre funkcje enterprise mogą stać się dostępne bez konieczności wykupienia licencji.

Zalety i wady korzystania z pve-fake-subscription

Zalety:

  • Brak komunikatu o braku subskrypcji w GUI.
  • Możliwość testowania funkcji enterprise w homelabie.
  • Szybka i prosta instalacja.

Wady:

  • Potencjalne naruszenie licencji Proxmox VE.
  • Brak gwarancji bezpieczeństwa i stabilności.
  • Ryzyko problemów podczas aktualizacji systemu.

Podsumowanie

pve-fake-subscription to sprytne narzędzie pozwalające na odblokowanie funkcji enterprise w Proxmox VE w środowisku domowym. Świetnie sprawdza się w testach i nauce obsługi tej platformy, ale nie powinno być stosowane w środowiskach produkcyjnych.

Pamiętaj: jeśli Twoja firma korzysta z Proxmox VE w krytycznych systemach, zawsze inwestuj w legalną enterprise subscription. To zapewni Ci bezpieczeństwo, stabilność i profesjonalne wsparcie techniczne.

G

Tagi: , ,
« Starsze Wpisy