Co się stało?

4 maja 2026 r. Zakład Ubezpieczeń Społecznych wdrożył metrykę 325 dla programu Płatnik w wersji 10.02.002. Miała być pobierana automatycznie przy starcie programu. W teorii — elegancko. W praktyce — od 5 maja użytkownicy masowo zgłaszali problemy z pobraniem pakietu aktualizacji. Program albo zawieszał się przy starcie, albo rzucał błędem połączenia, albo po prostu odmawiał dalszej pracy.

ZUS szybko opublikował komunikat o „ograniczeniach w pobieraniu aktualizacji” i zaproponował rozwiązanie: plik P2StartFix2.exe, który miał naprawić sytuację.

P2StartFix2 — oficjalny fix od ZUS

ZUS udostępnił narzędzie naprawcze P2StartFix2.exe. Instrukcja jest prosta:

1. Pobierz plik P2StartFix2.exe ze strony ZUS (link poniżej).
2. Zamknij program Płatnik.
3. Uruchom P2StartFix2.exe jako administrator.
4. Potwierdź zgodę na wykonanie aktualizacji — kliknij OK.
5. Potwierdź zakończenie — ponownie OK.
6. Uruchom Płatnika i sprawdź, czy aktualizacja przechodzi.

Link do pobrania P2StartFix2 i pełnego instalatora Płatnika:  Pobierz program Płatnik 10.02.002 — oficjalna strona ZUS

U wielu osób to wystarczy. Ale nie u wszystkich.

Gdy P2StartFix2 nie pomaga — ręczna aktualizacja metryki

Na forach i w grupach na Facebooku poświęconych Płatnikowi pojawiło się mnóstwo zgłoszeń, że P2StartFix2 nie rozwiązuje problemu. Na części komputerów fix przechodzi bez błędu, a Płatnik i tak nie rusza. Na innych wyskakuje komunikat o błędzie ładowania certyfikatu. Znam to z autopsji — obsługuję kilka firm i na dwóch stanowiskach fix po prostu nie zadziałał.

Rozwiązanie: ręczne pobranie metryki i wgranie jej z dysku.

Krok po kroku:

1. Pobierz paczkę z metryką ze strony ZUS

Wejdź na stronę serwera dystrybucyjnego ZUS:  https://pobierz.zus.pl/dystrybucja/slowniki/

2. Rozpakuj archiwum

Wypakuj pobrany plik ZIP do wybranego folderu — np. C:\Temp\metryka. Wewnątrz znajdziesz plik metryka.xml.

3. Wgraj metrykę ręcznie w Płatniku

• Uruchom Płatnik i zaloguj się.
• Z górnego menu wybierz: Administracja → Aktualizuj komponenty programu — z dysku…
• Otworzy się okno „Aktualizacja programu i danych płatnika”.
• Kliknij „Pobierz aktualizacje” (tak, ta nazwa jest myląca — chodzi o import z dysku).
• Wskaż plik metryka.xml z folderu, do którego rozpakowałeś archiwum.
• Poczekaj na zakończenie procesu.

Jeśli wszystko pójdzie dobrze, zobaczysz status „Zaktualizowano”. Gdyby dane były już aktualne, pojawi się status „Aktualne”.

4. Konwersja bazy danych

Po wgraniu nowej metryki program może poprosić o konwersję bazy danych. To normalne — szczególnie po metryce z 24 kwietnia, która wprowadzała zmiany w formularzach ZUS DRA i ZUS RCA. Zaloguj się jako Administrator Płatnika (nie zwykły Użytkownik) i postępuj zgodnie z komunikatami.

 Zanim cokolwiek zrobisz — wykonaj kopię zapasową bazy danych! Zapisz też, gdzie ta baza leży na dysku i jakie jest hasło dostępu. Bez tego w razie problemów nie odtworzysz danych.

Dlaczego autoaktualizacja nie działa?

To pytanie wraca przy każdej nowej metryce. Problem polega na tym, że mechanizm autoaktualizacji Płatnika opiera się na komunikacji z serwerami ZUS, które przy masowym pobieraniu po prostu nie wytrzymują obciążenia. Dodatkowo metryka 325 była podpisana certyfikatem, który u części użytkowników powodował problemy weryfikacji — szczególnie w środowiskach korzystających z podpisu osobistego (e-dowód).

ZUS sam przyznał, że metryka 325 miała rozwiązać problem użytkowników e-dowodu z pobieraniem danych. Paradoksalnie, jej wdrożenie wygenerowało nowe problemy.

Uwaga na false-positive antywirusów

W paczce z metryką 325 plik KOD_About.exe.zip jest fałszywie wykrywany przez niektóre silniki antywirusowe. To znany problem — plik pochodzi z oficjalnego serwera ZUS i nie jest zagrożeniem. Jeśli Twój antywirus blokuje pobranie, tymczasowo dodaj wyjątek dla folderu, do którego pobierasz paczkę.

PS. Niektórzy twierdzą ze cały ZUS to Malware

Podsumowanie

Program Płatnik to narzędzie, z którego korzystają setki tysięcy firm w Polsce. Niestety, prawie każde wdrożenie nowej metryki kończy się falą problemów. Kluczowa lekcja jest taka: nie polegaj wyłącznie na autoaktualizacji. Trzymaj pod ręką link do strony ZUS z plikiem metryki i wiedz, jak wgrać ją ręcznie. To umiejętność, która będzie Ci służyć przy każdej kolejnej aktualizacji.

Przydatne linki:

• Pobierz program Płatnik 10.02.002 — ZUS
• Komunikaty techniczne ZUS
• Instrukcja aktualizacji komponentów — ZUS
• Forum użytkowników Płatnika

Artykuł Płatnik nie startuje po aktualizacji metryki? Fix z ZUS nie pomaga? pochodzi z serwisu Z IT Wzięte.

TL;DR — szybki fix w 2 minuty

1. W Adobe Readerze: Edycja → Preferencje → Menedżer zaufania
2. Sekcja Adobe AATL → kliknij „Uaktualnij teraz”
3. Sekcja EUTL (European Union Trusted Lists) → też „Uaktualnij teraz”
4. Zamknij Reader, otwórz PDF ponownie

Jeśli to nie pomogło — czytaj dalej, bo masz jedną z mniej oczywistych przyczyn.

Dlaczego Adobe pokazuje „Validity unknown” przy Certumie

Adobe Reader nie ufa certyfikatowi „bo jest podpisany przez Certum” — Adobe ufa liście, na której Certum (i inne kwalifikowane CA) się znajduje. Te listy są dwie:

• AATL (Adobe Approved Trust List) — własna lista Adobe, aktualizowana automatycznie mniej więcej co 14 dni. Certum jest na niej od kilku lat.
• EUTL (European Union Trusted Lists) — lista UE z dostawcami kwalifikowanymi z każdego państwa członkowskiego. Od 2016 roku to właściwa lista dla podpisów kwalifikowanych w UE — siedzą tam NCCert, KIR Szafir, EuroCert i Certum.

Jeśli któraś z list nigdy się u Ciebie nie zaktualizowała (świeża instalacja, długo wyłączony komputer, polityka firmowa blokująca aktualizacje) — Reader nie ma jak zweryfikować ścieżki zaufania i pokazuje „nieznana poprawność”. To nie znaczy, że podpis jest zły. To znaczy, że Twoja kopia Adobe nie wie, kim jest Certum.

Fix #1 — aktualizacja AATL i EUTL

Klasyk i pierwsza rzecz do sprawdzenia. Krok po kroku:

1. Otwórz Adobe Reader (DC lub Acrobat)
2. Edycja → Preferencje (Mac: Acrobat → Preferencje)
3. Wybierz kategorię Menedżer zaufania
4. Sekcja Aktualizacje automatyczne dla certyfikatów zaufania zatwierdzonych przez Adobe (AATL) → przycisk „Uaktualnij teraz”
5. Tuż obok jest druga sekcja European Union Trusted Lists (EUTL) → też „Uaktualnij teraz”
6. Upewnij się, że obie opcje „Załaduj zaufane certyfikaty…” są zaznaczone
7. OK, zamknij Reader, otwórz dokument ponownie

U 9 na 10 osób temat zamyka się w tym miejscu.

Fix #2 — uszkodzony trust store (addressbook.acrodata)

Znany bug Adobe: przy aktualizacji AATL/EUTL niektóre certyfikaty zawierające w danych binarnych sekwencję FE FF potrafią „spuchnąć” w lokalnym truststore i wszystkie podpisy oparte o nie nagle są invalid. Objawy: podpis jeszcze wczoraj się weryfikował, dziś już nie, a aktualizacja list nic nie daje.

Lekarstwo — wykasowanie skorumpowanego pliku książki adresowej:

1. Najpierw: Pomoc → Sprawdź aktualizacje i zaktualizuj Reader do najnowszej wersji
2. Zamknij Adobe Reader (sprawdź, czy nie wisi w tle — Task Manager / Activity Monitor)
3. Skasuj plik addressbook.acrodata:
   • Windows: %APPDATA%\Adobe\Acrobat\DC\Security\addressbook.acrodata
     (czyli C:\Users\<TwojUser>\AppData\Roaming\Adobe\Acrobat\DC\Security\)
   • macOS: ~/Library/Application Support/Adobe/Acrobat/DC/Security/addressbook.acrodata
4. Uruchom Reader ponownie
5. Wróć do Menedżer zaufania i zrób świeży update AATL i EUTL

Plik addressbook.acrodata Adobe odbuduje sam przy starcie. Jeśli masz tam ręcznie zaimportowane certyfikaty (rzadkie, ale się zdarza w środowiskach korporacyjnych) — najpierw zrób kopię.

Fix #3 — brak znacznika czasu (TSA)

Kolejny scenariusz: dokument był podpisany rok temu, certyfikat już dawno wygasł, a Reader pokazuje, że „podpis był ważny w momencie weryfikacji” — co jest oczywistym fałszem, bo podpis był ważny w momencie złożenia, nie weryfikacji. Tu wchodzi znacznik czasu z kwalifikowanej TSA (Time Stamping Authority).

Jeśli dokument ma osadzony qualified timestamp, ale Reader go nie używa — przełącz tryb weryfikacji:

1. Preferencje → Podpisy → Weryfikacja → Więcej
2. W sekcji Czas weryfikacji wybierz: „Bezpieczny czas (znacznik czasowy)” zamiast „Bieżący czas”
3. OK, otwórz dokument ponownie

Jeśli dokument nie ma timestampu — to wina podpisującego, nie Twoja. Przy podpisach kwalifikowanych powinno się ZAWSZE używać TSA (Certum udostępnia time.certum.pl, KIR Szafir ma własną, EuroCert też). proCertum SmartSign domyślnie podpisuje z timestampem, ale w starszych wersjach trzeba to było zaznaczyć ręcznie w opcjach.

Fix #4 — to nie jest PAdES, to CAdES

Tu zaczyna się ciekawie. W Polsce wciąż się zdarza, że ktoś podpisuje PDF narzędziem, które generuje osobny plik podpisu (typowo .xades lub .cades) zamiast osadzić podpis w samym PDF. Adobe Reader takiego podpisu nie zweryfikuje, bo nawet go nie widzi — w PDF-ie nie ma żadnego pola podpisu.

Skróty:

• PAdES (PDF Advanced Electronic Signatures) — podpis osadzony bezpośrednio w PDF. Tylko ten Adobe weryfikuje natywnie.
• CAdES (CMS Advanced Electronic Signatures) — podpis w osobnym pliku .p7s / .cades obok dokumentu, albo wbudowany w zewnętrzną kopertę.
• XAdES — wariant XML, też nie dla Adobe.

Jeśli dostałeś PDF + osobny .xades/.cades — weryfikujesz to podpisywarką (np. proCertum SmartSign, Szafir, mObywatel — w zależności od formatu), nie Adobe Readerem. proCertum SmartSign domyślnie podpisuje PDF-y w PAdES, ale przy starszych konfiguracjach trzeba to wymusić w ustawieniach formatu podpisu.

Fix #5 — dokument zmodyfikowany po podpisie

Komunikat: „Podpis jest ważny, ale dokument został zmieniony po podpisaniu”. Czasem to świadoma zmiana, ale częściej — zwykła nieuwaga:

• Ktoś otworzył podpisany formularz, wypełnił kolejne pole i zapisał — podpis nie zezwalał na takie zmiany przyrostowe
• Ktoś przerzucił PDF przez konwerter online lub edytor i ten przepisał plik, niszcząc strukturę podpisu
• PDF został „zoptymalizowany” jakimś narzędziem typu Smallpdf — i tyle

Lekarstwo: poproś nadawcę o oryginalną, niemodyfikowaną kopię. Tej zepsutej już nie naprawisz — to fundamentalna własność podpisu cyfrowego, a nie błąd.

Fix #6 — Protected Mode blokuje OCSP/CRL

Adobe Reader w trybie chronionym (Protected Mode, domyślnie włączony na Windowsie) czasami nie może uderzyć na zewnętrzne serwery sprawdzające status certyfikatu (OCSP/CRL). Najczęściej widać to przy podpisywaniu, rzadziej przy weryfikacji — ale jeśli żaden poprzedni fix nie zadziałał, warto sprawdzić.

Preferencje → Zabezpieczenia (rozszerzone) → odznacz „Włącz tryb chroniony przy uruchamianiu”, restart Readera. Jeśli temat zniknie — wrzuć potem do białej listy serwery Certum (*.certum.pl, *.certum.eu) zamiast trzymać Protected Mode wyłączony na stałe.

Diagnostyka — jak ustalić, co konkretnie boli Readera

Zamiast strzelać, otwórz panel diagnostyczny:

1. Lewy panel Reader → ikona panelu podpisów (pióro)
2. Rozwiń wpis podpisu
3. Pokaż szczegóły zatwierdzenia (Show Signature Properties)

Reader pokaże dokładnie, gdzie ma problem — najczęściej zobaczysz jedno z:

• „The signer’s identity is unknown because it has not been included in your list of trusted certificates” → fix #1 (AATL/EUTL)
• „The certificate chain could not be built” → fix #1 lub #2 (addressbook)
• „Signature is valid, but the document has been altered or corrupted” → fix #5 (modyfikacja)
• „Revocation status could not be determined” → fix #6 (Protected Mode / sieć)
• „The signature includes an embedded timestamp but it could not be verified” → fix #3 (timestamp)

Podsumowanie — w jakiej kolejności sprawdzać

Standardowy flow troubleshootingowy:

1. Update AATL + EUTL (90% przypadków zamyka się tutaj)
2. Update samego Readera + skasowanie addressbook.acrodata + ponowny update list
3. Sprawdzenie panelu szczegółów podpisu — co konkretnie zgłasza Reader
4. W zależności od komunikatu — timestamp, format podpisu, tryb chroniony, modyfikacja dokumentu

Większość zgłoszeń serwisowych w stylu „Adobe nie chce mi sprawdzić podpisu” rozwiązuje się na pierwszym kroku. Te bardziej upierdliwe — na drugim. Reszta to już konkretne, identyfikowalne problemy, a nie ogólne „nie działa”.

Artykuł Adobe Reader ma problem z podpisem Certum pochodzi z serwisu Z IT Wzięte.

Scenariusz 1: Zabbix na LAN — wszystko w jednej sieci

To najprostszy i najczęstszy model. Serwer Zabbix stoi w tej samej sieci co monitorowane hosty. Agenty na serwerach raportują bezpośrednio do serwera Zabbix, który zbiera dane, przetwarza triggery, wysyła alerty i wyświetla dashboardy.

Jak to wygląda w praktyce

[Host 1] ──┐
[Host 2] ──┤── LAN ──── [Zabbix Server + Frontend + DB]
[Host 3] ──┘

Serwer Zabbix odpytuje agentów (passive checks) lub agenty same wysyłają dane (active checks). Wszystko dzieje się w jednym segmencie sieci. Nie ma firewalli po drodze, nie ma NAT-u, nie ma opóźnień WAN.

Konfiguracja

Minimalna. Instalujesz serwer Zabbix, stawiasz bazę (PostgreSQL lub MySQL), wdrażasz agentów na hostach. W zabbix_agentd.conf ustawiasz:

ini

Server=192.168.1.10          # IP serwera Zabbix (passive checks)
ServerActive=192.168.1.10    # IP serwera Zabbix (active checks)
Hostname=web-server-01       # unikalna nazwa hosta

I gotowe. Agent raportuje, serwer zbiera. Żadnego proxy, żadnych tuneli, żadnych komplikacji.

Zalety

• Prostota — jeden serwer, jedna baza, jedna instancja do zarządzania.
• Niskie opóźnienia — dane z agentów trafiają do serwera natychmiast, bo wszystko jest na LAN-ie.
• Passive i active checks bez ograniczeń — serwer ma bezpośredni dostęp do agentów, więc działają oba tryby. Możesz korzystać z remote commands do automatycznego restartowania usług.
• SNMP, IPMI, HTTP bez problemów — serwer odpytuje urządzenia sieciowe bezpośrednio, bez pośredników.
• Łatwy troubleshooting — jedna maszyna, jeden log, jedno miejsce do sprawdzenia.

Wady

• Skala ograniczona do jednej lokalizacji — jeśli masz drugi oddział albo sieć klienta, ten model nie wystarczy.
• Brak redundancji — padnie serwer Zabbix, padnie monitoring. W małych środowiskach to akceptowalne, w większych — nie.
• Brak separacji — serwer Zabbix widzi wszystko i ma dostęp do wszystkiego. W kontekście bezpieczeństwa i segmentacji sieci to niekoniecznie pożądane.

Kiedy stosować

Jedna firma, jedna serwerownia, jeden LAN. Monitorujesz swoje serwery, switche, NAS-y, UPS-y. Masz pełną kontrolę nad siecią. Nie musisz monitorować niczego zdalnie. To scenariusz dla 80% małych i średnich wdrożeń.

Scenariusz 2: Zabbix z active proxy u klienta

Tu zaczyna się ciekawiej. Masz centralny serwer Zabbix — np. w swoim DC albo na VPS-ie. Klient ma swoją sieć, za NAT-em, za firewallem, do której nie masz (i nie chcesz mieć) bezpośredniego dostępu. U klienta stawiasz Zabbix proxy w trybie active. To proxy inicjuje wszystkie połączenia do serwera — serwer nigdy nie łączy się do proxy. Serwer nawet nie musi znać IP proxy.

W tym modelu Serwer zabixa sam nigdy nie komunikuje się z Proxy u klienta. To Proxy wysyła dane na ip serwera w świat (czśto na wysokim porcie), a jeśli np firewall na serwerze przyjmuje dane tylko z podanych ip to to jest najbezpieczeniejsze co można wymyślić poza VPN .

Jak to wygląda w praktyce

Sieć klienta (za NAT/firewall):                    Twój DC:
┌──────────────────────────┐                ┌──────────────────┐
│ [Host 1] ──┐             │                │                  │
│ [Host 2] ──┤── LAN ── [Zabbix Proxy] ──────────► [Zabbix Server]  │
│ [Host 3] ──┘   (active)  │   port 10051   │  + Frontend + DB │
│ [Switch] ──┘             │                │                  │
└──────────────────────────┘                └──────────────────┘
         ← proxy inicjuje połączenie →
         ← serwer NIE łączy się do proxy →

Kluczowa sprawa: active proxy sam puka do serwera. Pobiera konfigurację (jakie hosty monitorować, jakie itemy zbierać) i odsyła zebrane dane. Serwer nie musi mieć routingu do sieci klienta. Firewall u klienta musi przepuścić tylko jeden port wychodzący (domyślnie 10051 TCP) do serwera Zabbix.

Konfiguracja proxy

Na maszynie u klienta instalujesz Zabbix proxy. W zabbix_proxy.conf:

ini

ProxyMode=0                          # 0 = active (domyślne)
Hostname=klient-abc-proxy            # musi się zgadzać z nazwą w frontendzie
Server=zabbix.twojafirma.pl:10051   # adres Twojego serwera Zabbix
DBName=/tmp/zabbix_proxy.db          # SQLite wystarczy dla małych wdrożeń
ConfigFrequency=120                  # co ile sekund pobierać konfigurację
DataSenderFrequency=5                # co ile sekund wysyłać dane
ProxyOfflineBuffer=72                # ile godzin trzymać dane przy braku łączności

Na frontendzie serwera Zabbix: Administration → Proxies → Create proxy — wpisujesz nazwę klient-abc-proxy, tryb Active. Nie musisz podawać żadnego IP proxy.

Konfiguracja agentów u klienta

Agenty wskazują na lokalne IP proxy, nie na serwer Zabbix:

ini

Server=192.168.10.50           # IP proxy w sieci klienta
ServerActive=192.168.10.50     # IP proxy w sieci klienta
Hostname=klient-abc-dc01       # unikalna nazwa hosta

Agent nie wie, że rozmawia z proxy a nie z serwerem — protokół jest identyczny.

Przepływ danych

1. Proxy → Serwer: Proxy łączy się z serwerem co ConfigFrequency sekund i pobiera konfigurację (lista hostów, itemów, triggerów do monitorowania).
2. Agenty → Proxy: Agenty w sieci klienta raportują dane do proxy (LAN, bez wychodzenia na zewnątrz).
3. Proxy → Serwer: Proxy buforuje dane lokalnie i wysyła je do serwera co DataSenderFrequency sekund.
4. Serwer przetwarza: Triggery, eventy, alerty — to wszystko dzieje się na serwerze. Proxy jest tylko kolektorem danych.

Serwer nigdy nie inicjuje połączenia do proxy. Proxy puka do serwera. To fundamentalna różnica, która rozwiązuje problem NAT-u, firewalli i braku bezpośredniego dostępu do sieci klienta.

Co się dzieje, gdy padnie łącze?

Proxy buforuje dane lokalnie. Parametr ProxyOfflineBuffer (domyślnie 1 godzina) określa, jak długo proxy trzyma dane, gdy nie może połączyć się z serwerem. Ustawiasz np. 72 godziny — i proxy przeżyje weekend bez łączności. Gdy połączenie wróci, proxy wyśle zaległe dane i serwer je przetworzy.

W trybie ProxyBufferMode=hybrid (od Zabbix 7.0) proxy trzyma dane w pamięci dla szybkości, a gdy pamięć się zapełni — zrzuca na dysk. Najlepsze z obu światów.

Zalety

• Firewall-friendly — jedyne wymaganie: port wychodzący z proxy do serwera. Żadnych portów przychodzących u klienta, żadnego VPN-a, żadnego otwierania dziur.
• Serwer nie ma dostępu do sieci klienta — i to jest feature, nie bug. Separacja jest pełna. Serwer nie może skanować sieci klienta, nie może łączyć się z hostami. Dane płyną tylko w jedną stronę: od proxy do serwera.
• Buforowanie offline — awaria łącza nie oznacza utraty danych. Proxy trzyma metryki lokalnie i dosyła je po przywróceniu połączenia.
• Skalowalność — jeden serwer Zabbix, dziesiątki proxy u różnych klientów. Każde proxy zbiera dane ze swojego segmentu, serwer centralizuje wszystko.
• Odciążenie serwera — proxy wykonuje preprocessing danych i skanowanie sieci (discovery) lokalnie. Serwer dostaje gotowe dane.
• Prosta konfiguracja sieciowa — nie musisz znać publicznego IP proxy, nie musisz konfigurować port forwarding u klienta. Proxy samo się łączy.

Wady

• Brak remote commands — serwer nie może wysłać komendy do hosta przez active proxy, bo nie ma do niego bezpośredniego połączenia. Od Zabbix 7.0 active agent potrafi odbierać remote commands, ale wymaga to dodatkowej konfiguracji.
• Opóźnienie w danych — dane nie trafiają na serwer natychmiastowo. Jest bufor, jest DataSenderFrequency. W praktyce opóźnienie to kilka sekund, ale nie jest zerowe.
• Opóźnienie w konfiguracji — po zmianie itemów na serwerze proxy musi pobrać nową konfigurację. Domyślnie ConfigFrequency=3600 (1 godzina!). Warto zmniejszyć do 120-300 sekund. Można też wymusić ręcznie: zabbix_proxy -R config_cache_reload.
• Dodatkowy komponent — proxy to kolejna maszyna do utrzymania, kolejna baza danych, kolejny serwis do monitorowania (tak — monitoruj swoje proxy).
• Brak passive checks z serwera — serwer nie może odpytać agenta przez proxy w trybie active. Agenty muszą pracować w trybie active checks.

Kiedy stosować

Monitorujesz infrastrukturę klientów jako usługę (MSP/MSSP). Masz wiele oddziałów za NAT-em. Klient nie chce (słusznie) otwierać VPN-a do Twojego serwera. Potrzebujesz centralnego dashboardu dla wielu lokalizacji. Chcesz separacji — serwer nie powinien mieć dostępu do sieci klienta.

Porównanie: LAN vs Active Proxy

Cecha	Zabbix na LAN	Zabbix + Active Proxy
Złożoność wdrożenia	Niska	Średnia
Firewall/NAT	Nie przeszkadza	Rozwiązany — proxy łączy się na zewnątrz
Serwer ma dostęp do sieci klienta	Tak (pełny)	Nie (zero)
Kierunek połączenia	Serwer Agent	Proxy → Serwer (jednokierunkowy)
Passive checks	Tak	Nie (tylko active)
Remote commands	Tak	Ograniczone
Buforowanie offline	Nie	Tak (do 72h+)
Skalowalność lokalizacji	Jedna	Wiele
Opóźnienie danych	Brak	Kilka sekund
Koszt	1 serwer	1 serwer + N proxy
Monitoring SNMP/IPMI	Bezpośredni z serwera	Przez proxy (lokalnie)

Który model wybrać?

To nie jest kwestia „lepszy/gorszy”. To kwestia kontekstu.

Jeśli monitorujesz swoją infrastrukturę, w jednej lokalizacji, na jednym LAN-ie — stawiasz serwer Zabbix i nie komplikujesz sobie życia. Proxy jest zbędne.

Jeśli monitorujesz infrastrukturę klientów, zarządzasz wieloma lokalizacjami, albo potrzebujesz monitoringu bez VPN-a i bez otwierania portów u klienta — active proxy to jedyna sensowna droga. Proxy puka do Twojego serwera, wysyła dane, a serwer nigdy nie widzi sieci klienta. Bezpiecznie, skalowalne, firewall-friendly.

W praktyce oba modele mogą współistnieć. Serwer Zabbix monitoruje lokalny LAN bezpośrednio, a jednocześnie odbiera dane z proxy rozsianych po lokalizacjach klientów. To nie jest albo-albo — to kwestia dopasowania architektury do potrzeb.

Artykuł Zabbix na LAN vs Zabbix Proxy – dwa modele, które warto znać pochodzi z serwisu Z IT Wzięte.

Ustawiasz uprawnienia na folderach QNAP, wszystko działa, a na drugi dzień znowu masz problem z dostępem? Użytkownicy nie mogą zapisywać plików do folderów, w których wczoraj jeszcze mogli? Klasyczny scenariusz – ustawiasz RW na Folder, wychodzisz, wracasz rano i uprawnienia wróciły do stanu wyjściowego.

Zanim zaczniesz resetować NAS-a, przeinstalowywać firmware albo grzebać w ACL-ach – sprawdź crontab. Bardzo prawdopodobne, że winowajcą jest systemowe zadanie ImR_all, które co noc nadpisuje Twoje uprawnienia.

Co to jest ImR_all i dlaczego psuje uprawnienia

W domyślnej konfiguracji QNAP w crontabie znajdziesz wpis:

0 3 * * * /usr/local/sbin/ImR_all -soft /Qmultimedia

To zadanie uruchamia się codziennie o 3:00 w nocy i wykonuje „miękki” reset indeksowania oraz uprawnień na folderze /Qmultimedia (alias do /share/MD0_DATA/Multimedia). Jest to element systemu Multimedia Console, który odpowiada za indeksowanie plików multimedialnych – zdjęć, filmów, muzyki.

Problem polega na tym, że ImR_all potrafi nadpisać uprawnienia, które ręcznie ustawiłeś na folderach i podfolderach w obrębie Multimedia. Efekt – Twoje niestandardowe ACL-e i ustawienia dostępu wracają do stanu „domyślnego” każdej nocy.

Objawy problemu

Jeśli widzisz którykolwiek z tych objawów, prawdopodobnie ImR_all jest winowajcą:

• Uprawnienia na folderze Multimedia resetują się po nocy
• Użytkownicy tracą dostęp do podfolderów, który dzień wcześniej działał
• Zmiana uprawnień w panelu QTS nie „trzyma się” dłużej niż kilka godzin
• W File Station lub przez SMB nagle pojawia się „Access Denied” na folderach, które wcześniej były dostępne
• Po ręcznym ustawieniu uprawnień przez SSH (chmod, setfacl) zmiany znikają następnego dnia

Rozwiązanie – wyłączenie ImR_all w crontabie

Rozwiązanie jest proste – trzeba zakomentować lub usunąć wpis ImR_all z crontaba. Wymaga to dostępu SSH do NAS-a.

Krok 1: Włącz SSH na QNAP

1. Zaloguj się do panelu QTS jako administrator
2. Przejdź do Panel sterowania → Usługi sieciowe i plików → Telnet/SSH
3. Zaznacz Zezwalaj na połączenie SSH
4. Ustaw port (domyślnie 22, ale rozważ zmianę na niestandardowy, np. 2222, jeśli NAS jest dostępny z internetu)
5. Kliknij Zastosuj

Krok 2: Połącz się z NAS przez SSH

Z komputera z Windows użyj PuTTY lub wbudowanego terminala:

bash

ssh admin@ADRES_IP_QNAP

Na macOS / Linux po prostu otwórz terminal i wpisz powyższe polecenie. Zaloguj się danymi administratora QNAP.

Krok 3: Zrób backup crontaba

Zanim cokolwiek zmienisz – kopia zapasowa:

bash

cp /etc/config/crontab /etc/config/crontab.backup

Krok 4: Edytuj crontab

Otwórz plik crontaba w edytorze:

bash

vi /etc/config/crontab

Znajdź linię:

0 3 * * * /usr/local/sbin/ImR_all -soft /Qmultimedia

Zakomentuj ją, dodając # na początku linii:

#0 3 * * * /usr/local/sbin/ImR_all -soft /Qmultimedia

Szybka ściągawka vi:

• Naciśnij i żeby wejść w tryb edycji
• Dodaj # na początku linii
• Naciśnij Esc
• Wpisz :wq i naciśnij Enter żeby zapisać i wyjść

Krok 5: Załaduj nowy crontab i zrestartuj cron

To kluczowy krok – samo zapisanie pliku nie wystarczy. QNAP wymaga jawnego załadowania crontaba:

bash

crontab /etc/config/crontab && /etc/init.d/crond.sh restart

Krok 6: Zweryfikuj zmianę

Sprawdź, czy Twoja zmiana została zastosowana:

bash

crontab -l | grep ImR_all

Jeśli wszystko poszło dobrze, powinieneś zobaczyć zakomentowaną linię z # na początku lub brak wyniku (jeśli usunąłeś linię zamiast komentować).

Dlaczego zmiana w crontabie wymaga dodatkowego kroku

Na standardowym Linuxie edytujesz crontab poleceniem crontab -e i zmiany od razu działają. Na QNAP jest inaczej – system trzyma „źródło prawdy” w pliku /etc/config/crontab i trzeba je jawnie załadować poleceniem crontab /etc/config/crontab.

Co więcej – nie używaj crontab -e na QNAP. Zmiany wprowadzone tą komendą są tymczasowe i znikną przy następnym restarcie lub aktualizacji systemu, bo QTS nadpisze je zawartością z /etc/config/crontab.

Poprawna procedura to zawsze:

1. Edytuj /etc/config/crontab
2. Załaduj: crontab /etc/config/crontab
3. Restart crona: /etc/init.d/crond.sh restart

Czy wyłączenie ImR_all jest bezpieczne?

Tak, z jednym zastrzeżeniem. ImR_all odpowiada za odświeżanie indeksu multimediów. Jeśli korzystasz z wbudowanych aplikacji QNAP do przeglądania multimediów (Multimedia Station, Photo Station, Video Station), wyłączenie tego zadania sprawi, że nowo dodane pliki nie będą automatycznie indeksowane w nocy.

Praktycznie nie ma to żadnego znaczenia, jeśli:

• Używasz Multimedia Console z włączonym automatycznym indeksowaniem (to osobny mechanizm)
• Korzystasz z Plex, Jellyfin lub innego zewnętrznego serwera mediów (mają własne indeksowanie)
• Nie korzystasz z wbudowanych aplikacji multimedialnych QNAP
• Multimedia Console jest wyłączona

Nawet jeśli korzystasz z natywnych aplikacji QNAP – ręczne indeksowanie jest dostępne z poziomu Multimedia Console (przycisk „Reindex”).

Dodatkowe porady – naprawianie uprawnień po szkodach

Jeśli ImR_all zdążył już namieszać w Twoich uprawnieniach, oto jak je naprawić.

Sprawdzenie aktualnych uprawnień z SSH

bash

getfacl /share/MD0_DATA/Multimedia
ls -la /share/MD0_DATA/Multimedia/

Reset uprawnień na folderze Multimedia

Jeśli uprawnienia są kompletnie rozwalone, możesz je zresetować:

bash

# Usuń wszystkie ACL
setfacl -R --remove-all /share/MD0_DATA/Multimedia/*

# Ustaw właściciela i grupę
chown -R admin:administrators /share/MD0_DATA/Multimedia

# Ustaw uprawnienia
chmod -R 770 /share/MD0_DATA/Multimedia

Następnie w panelu QTS przejdź do Prawa dostępu → Foldery współdzielone → Multimedia → Edytuj uprawnienia i ponownie ustaw dostęp dla użytkowników/grup. Zaznacz opcję „Zastosuj i zastąp wszystkie istniejące uprawnienia”.

Użycie set_volume_mode

QNAP ma też wbudowane narzędzie do resetowania trybu uprawnień na wolumenie:

bash

/sbin/set_volume_mode

Uruchom je bez parametrów, żeby zobaczyć dostępne opcje. Pozwala to przełączyć wolumin między trybem uprawnień Linuxowych a Windows ACL.

Co jeszcze warto sprawdzić w crontabie

Skoro już jesteś w crontabie, rzuć okiem na inne wpisy, które mogą wpływać na działanie NAS-a. Domyślny crontab QNAP zawiera kilka ciekawych pozycji:

Nie wyłączaj tych zadań bez dobrego powodu – są potrzebne do prawidłowego działania systemu.

Podsumowanie

Problem z samoczynnie zmieniającymi się uprawnieniami na QNAP to klasyczny przypadek „nic nie ruszałem, a samo się zepsuło”. W rzeczywistości QNAP co noc uruchamia zadanie ImR_all, które resetuje uprawnienia na folderze Multimedia.

Rozwiązanie:

1. Włącz SSH
2. Edytuj /etc/config/crontab
3. Zakomentuj linię z ImR_all
4. Załaduj crontab: crontab /etc/config/crontab && /etc/init.d/crond.sh restart
5. Gotowe – uprawnienia zostaną takie, jakie ustawisz

Artykuł QNAP – uprawnienia folderów zmieniają się same? pochodzi z serwisu Z IT Wzięte.

Ransomware nie szyfruje tego, czego nie widzi

Zacznijmy od podstaw. Ransomware to program, który szyfruje pliki na dyskach, do których ma dostęp. Klucz do zrozumienia tego zdania: do których ma dostęp.

Jeśli Twój backup leży na udziale sieciowym, na NAS-ie zamontowanym przez SMB, na dysku podpiętym 24/7 do serwera — ransomware zaszyfruje go razem z resztą. Nie dlatego, że jest „sprytny”. Dlatego, że ma do niego ścieżkę sieciową. Dokładnie tak samo, jak Ty otwierasz ten udział w Eksploratorze plików.

I to jest dokładnie to, co dzieje się w większości ataków. Według danych branżowych, 94% ataków ransomware obejmuje próbę zniszczenia kopii zapasowych. Atakujący wiedzą, że backup to jedyna rzecz, która stoi między nimi a okupem. Więc celują w niego jako pierwszy krok.

W przypadku ataków w 2026 — najprawdopodobniej przywracanie systemów trwało tygodniami. Tysiące komputerów do postawienia od zera. Gdyby istniała kopia odłączona od sieci, czas odtworzenia liczyłby się w godzinach, nie tygodniach.

Czym jest backup air-gapped i dlaczego działa

Air-gapped backup to kopia zapasowa, która jest fizycznie odłączona od infrastruktury — nie ma do niej ścieżki sieciowej, nie jest zamontowana jako dysk, nie jest widoczna dla żadnego systemu w sieci. Ransomware nie może zaszyfrować czegoś, do czego nie ma połączenia. Proste.

Jak to wygląda w praktyce? Kilka wariantów od najprostszego do najbardziej zaawansowanego:

Dysk zewnętrzny USB z rotacją

Najprostsza forma air-gap. Dwa lub trzy dyski zewnętrzne USB, podłączane na czas backupu i fizycznie odłączane po zakończeniu. Rotacja codzienna lub tygodniowa — jeden dysk podłączony, reszta w szafie (najlepiej w innym pomieszczeniu lub budynku).

Koszt: 200–500 zł za dysk. Skuteczność: 100% ochrony przed ransomware sieciowym.

Taśmy LTO

Klasyka w większych środowiskach. Taśma po zapisaniu trafia na półkę — fizycznie nie ma połączenia z niczym. LTO-9 to 18 TB na taśmę (45 TB po kompresji). Droższa inwestycja początkowa (napęd LTO-9 to kilkanaście tysięcy złotych), ale koszt nośnika niski i niezawodność ogromna.

Dedykowany serwer backupowy z izolacją sieciową

Serwer backupowy, który łączy się z infrastrukturą produkcyjną tylko w oknie backupowym — przez ściśle kontrolowane reguły firewalla. Poza oknem backupowym: zero połączeń. Bardziej zaawansowane rozwiązanie, wymaga kompetencji sieciowych, ale daje wygodę automatyzacji przy zachowaniu izolacji.

Backup w chmurze z immutability

Usługi takie jak Backblaze B2, Wasabi czy AWS S3 z Object Lock pozwalają ustawić niezmienność (immutability) — zapisane dane nie mogą być nadpisane ani usunięte przez określony czas, nawet jeśli atakujący przejmie klucze dostępowe. To nie jest klasyczny air-gap, ale daje podobny efekt: ransomware nie jest w stanie zniszczyć tych kopii.

Reguła 3-2-1-1-0 — minimum, nie ideał

Branżowy standard to reguła 3-2-1-1-0:

• 3 kopie danych (produkcja + dwie kopie zapasowe)
• 2 różne typy nośników (np. dysk + taśma, dysk + chmura)
• 1 kopia off-site (poza lokalizacją główną)
• 1 kopia air-gapped lub immutable
• 0 błędów przy weryfikacji odtwarzalności

Ten ostatni punkt jest krytyczny i najczęściej pomijany. Backup, którego nigdy nie testowałeś, nie jest backupem. Jest obietnicą, która może się nie spełnić. Testuj odtwarzanie regularnie — minimum raz na kwartał.

Kopia na NAS-ie podłączonym do tej samej sieci co reszta infrastruktury nie spełnia żadnego z tych punktów, poza byciem „drugą kopią”. To nie jest backup — to złudzenie bezpieczeństwa.

Antywirus: dlaczego „jakiś darmowy” nie wystarczy

Druga warstwa, która regularnie zawodzi w atakowanych organizacjach, to ochrona endpointów. Statystyki za 2025 rok mówią jasno:

• 41% udanych ataków na placówki medyczne wynikało ze znanych, ale niezałatanych luk bezpieczeństwa
• 33% ataków wykorzystywało exploity na znane podatności
• 42% placówek nie miało odpowiedniej liczby specjalistów monitorujących systemy

To nie jest historia o superzaawansowanych hakerach. To historia o Windows Server bez aktualizacji od pół roku, o koncie admina z hasłem „admin123″, o antywirusie, którego nikt nie otworzył od dnia instalacji.

Co powinien robić porządny system ochrony endpointów

Profesjonalny antywirus klasy endpoint protection (np. ESET PROTECT, Bitdefender GravityZone, Microsoft Defender for Endpoint) to nie jest „skanowanie plików jak w 2005 roku”. To wielowarstwowy system, który:

• Analiza behawioralna — wykrywa ransomware po zachowaniu (masowe szyfrowanie plików, zmiana rozszerzeń), nawet jeśli sam plik jest zupełnie nowy i nieznany
• Ochrona przed exploitami — blokuje techniki wykorzystywane do przejmowania kontroli nad systemem przez luki w oprogramowaniu
• Sandboxing — podejrzane pliki uruchamiane są w izolowanym środowisku zanim dotrą do użytkownika
• Centralna konsola zarządzania — widoczność na całą infrastrukturę z jednego miejsca, alertowanie, wymuszanie polityk
• EDR (Endpoint Detection & Response) — ciągłe monitorowanie aktywności na endpointach, możliwość retrospektywnego przeszukiwania zdarzeń, izolowanie zainfekowanych maszyn

Ale nawet najlepszy antywirus nie pomoże, jeśli…

• …nikt nie patrzy na alerty. Średni czas wykrycia incydentu w ochronie zdrowia to ponad 200 dni. Dwieście dni, w trakcie których atakujący swobodnie eksplorują sieć.
• …nie ma segmentacji sieci. Jeśli jeden zainfekowany komputer w rejestracji ma dostęp do serwera z bazą pacjentów, to atak na stację roboczą = atak na krytyczne dane.
• …systemy nie są aktualizowane. Exploit na podatność sprzed 6 miesięcy to nie jest „zaawansowany atak”. To odpalenie gotowego narzędzia.

Segmentacja sieci — trzecia warstwa, o której nikt nie mówi

Segmentacja to podział sieci na odizolowane strefy, tak żeby kompromitacja jednego segmentu nie oznaczała kompromitacji całej infrastruktury.

W praktyce: komputer w rejestracji nie powinien mieć dostępu do serwera z backupami. Drukarka sieciowa nie powinna widzieć kontrolera domeny. Sieć Wi-Fi dla gości nie powinna mieć żadnej ścieżki do sieci wewnętrznej.

Jak to zrobić tanio? VLAN-y na zarządzalnym switchu i reguły firewalla. Zarządzalny switch to koszt od kilkuset złotych. Konfiguracja VLAN-ów to kwestia kilku godzin dla kompetentnego informatyka.

Segmentacja sprawia, że nawet jeśli ransomware dostanie się do jednej stacji roboczej, jego rozprzestrzenienie się na resztę sieci jest zablokowane lub znacząco utrudnione.

Plan odtwarzania — bo kiedy, nie czy

Disaster Recovery Plan (DRP) to dokument, który odpowiada na jedno pytanie: co robimy, kiedy wszystko padnie?

Nie musi to być 50-stronicowy elaborat. Minimum, które ma sens:

1. Lista systemów krytycznych z kolejnością przywracania (co najpierw? Serwer DHCP/DNS? Kontroler domeny? System ERP? Poczta?)
2. Lokalizacja backupów — gdzie fizycznie leżą nośniki, kto ma do nich dostęp, jakie są dane logowania
3. Procedura odtwarzania krok po kroku dla każdego krytycznego systemu
4. Lista kontaktowa — kto dzwoni do kogo, kto ma uprawnienia do podjęcia decyzji
5. Regularne testy — minimum raz na kwartał odtwórz coś z backupu. Najlepiej cały system na maszynie testowej

Szpital z DRP przywraca krytyczne usługi w godzinach. Szpital bez DRP wzywa Wojska Obrony Terytorialnej i spędza tygodnie na stawianiu tysiąca komputerów od zera. To nie hipoteza — to dokładnie to, co się wydarzyło w Szczecinie w marcu 2026.

Double extortion — dlaczego prewencja ma znaczenie

Od 2024 roku standardem w atakach ransomware jest podwójne wymuszenie (double extortion): atakujący najpierw kradną dane, potem je szyfrują. Nawet jeśli masz backup i odtworzysz systemy w godzinach, grożą wyciekiem wykradzionych danych.

To jest argument za inwestowaniem w ochronę, nie przeciw. Air-gapped backup chroni przed utratą danych i długim przestojem. Ale przed kradzieżą danych chroni tylko prewencja: porządny antywirus z EDR, segmentacja sieci, szybka detekcja anomalii, monitoring.

Wielowarstwowe podejście (defense in depth):

• Warstwa 1: Prewencja — antywirus, aktualizacje, segmentacja, szkolenia użytkowników
• Warstwa 2: Detekcja — EDR, monitoring, alerty, SIEM
• Warstwa 3: Odtwarzanie — backup air-gapped, DRP, testowane procedury

Żadna warstwa nie jest niezawodna sama w sobie. Ale ich kombinacja sprawia, że atak ransomware staje się incydentem do obsłużenia, a nie katastrofą na tygodnie.

Checklist: co sprawdzić u siebie

Trzy pytania, na które Twój informatyk (lub Ty sam) powinien umieć odpowiedzieć natychmiast:

1. Gdzie jest kopia zapasowa odłączona od sieci? Jeśli odpowiedź brzmi „na NAS-ie” albo „na dysku podłączonym do serwera” — nie masz backupu air-gapped. Masz drugą kopię danych, która padnie razem z resztą.
2. Jaki system ochrony endpointów jest wdrożony i kto monitoruje alerty? Jeśli odpowiedź brzmi „Windows Defender z domyślnymi ustawieniami” albo „nie wiem” — masz problem. Nie chodzi o markę, chodzi o to, czy ktoś aktywnie zarządza ochroną i reaguje na incydenty.
3. Kiedy ostatnio testowaliśmy odtwarzanie z backupu? Jeśli odpowiedź brzmi „nigdy” albo „nie pamiętam” — Twój backup to Schrödingerowska kopia: jednocześnie działa i nie działa, dopóki nie sprawdzisz.

Podsumowanie

Ransomware nie musi oznaczać tygodni przestoju. Trzy rzeczy decydują o tym, czy atak będzie incydentem czy katastrofą:

1. Backup odłączony od sieci — bo ransomware nie zaszyfruje tego, czego nie widzi
2. Porządny antywirus z aktywnym zarządzaniem — bo większość ataków wykorzystuje znane podatności i banalne wektory
3. Przetestowany plan odtwarzania — bo w trakcie kryzysu nie ma czasu na improwizację

Dobrą wiadomością jest to, że zabezpieczenie się nie wymaga milionowego budżetu. Dysk USB z rotacją, profesjonalny antywirus, segmentacja na VLAN-ach, przetestowany plan odtwarzania. To są rzeczy, które kompetentny informatyk wdroży w każdej firmie — od gabinetu lekarskiego po średnie przedsiębiorstwo.

Zrób to zanim będzie za późno.

Artykuł Dlaczego Twój backup jest bezwartościowy, jeśli jest podłączony do sieci pochodzi z serwisu Z IT Wzięte.

Problem: amnezja w połowie zadania

Jeśli używałeś Claude Code na większym projekcie, znasz ten scenariusz. Ładujesz codebase, odpalasz łańcuch tool calli – czytanie plików, analiza, edycja, testy. Claude radzi sobie świetnie. Aż nagle w terminalu pojawia się komunikat:

Claude is compacting the conversation...

I od tego momentu zaczyna się jazda. Claude „zapomina” decyzje architektoniczne podjęte 20 minut temu. Czyta te same pliki ponownie. Czasami wręcz sprzecza się sam ze sobą – implementacja z kroku 5 nie pasuje do tego, co zrobił w kroku 2, bo krok 2 wyleciał z kontekstu.

To był prawdziwy ból dupy przy dłuższych sesjach. Przy oknie 200K tokenów użyteczna przestrzeń to jakieś 150K po odjęciu bufora na kompakcję. Dla małego projektu – ok. Dla repo z backendem, frontendem i testami? Za mało.

Rozwiązanie: 1M tokenów kontekstu – bez dopłat

13 marca 2026 Anthropic ogłosił, że okno kontekstowe o wielkości 1 miliona tokenów jest teraz ogólnie dostępne dla modeli Opus 4.6 i Sonnet 4.6. Bez beta headerów, bez specjalnych flag, bez dopłat za długi kontekst.

Najważniejsze fakty:

• Standardowa cena – za 900K tokenów płacisz dokładnie tyle samo za token co za 9K. Opus 4.6: $5/$25 za milion tokenów (input/output). Sonnet 4.6: $3/$15.
• Pełne rate limity – długie requesty mają taki sam throughput jak krótkie. W becie było inaczej.
• 600 plików multimedialnych per request – wcześniej limit wynosił 100 obrazów lub stron PDF. Teraz 6x więcej.
• Bez beta headera – jeśli wcześniej go używałeś, API go po prostu ignoruje. Nie musisz nic zmieniać w kodzie.
• Dostępne na Claude Platform, Azure Foundry i Google Cloud Vertex AI.
• Claude Code na planach Max, Team i Enterprise – Opus 4.6 automatycznie dostaje 1M kontekstu. Bez konfiguracji.

Co to oznacza w praktyce?

Przy 200K tokenów użyteczna przestrzeń to ~150K. Przy 1M masz ~830K tokenów na faktyczną pracę. To wystarczy na tysiące plików źródłowych, pełne trace’y tool calli i długie sesje debugowania – bez kompakcji.

Anthropic podaje konkretną liczbę: od wdrożenia 1M kontekstu zanotowano 15% spadek zdarzeń kompakcji wśród użytkowników Claude Code. To nie benchmark – to pomiar z realnego użycia.

Co się zmienia w codziennej pracy:

• Cały codebase w jednej sesji – nie musisz już wybierać, które pliki załadować. Ładujesz wszystko.
• Łańcuchy tool calli bez utraty kontekstu – Claude przeszukuje logi, bazy danych, kod źródłowy, proponuje fix – i nie zapomina, co znalazł na początku.
• Dłuższe sesje bez restartu – wielogodzinne sesje agentowe, które wcześniej wymagały ręcznego /compact, teraz trzymają się kupy.

Ciekawy jest też benchmark. Na teście MRCR v2 (Multi-Round Coreference Resolution) w wariancie 1M tokenów Opus 4.6 osiąga 76%, podczas gdy Sonnet 4.5 – tylko 18,5%. To jakościowa różnica w tym, ile kontekstu model faktycznie potrafi wykorzystać bez „context rot” – degradacji jakości przy dużych ilościach danych.

Context awareness – Claude wie, ile mu zostało

Modele Opus 4.6 i Sonnet 4.6 mają wbudowaną świadomość kontekstu (context awareness). Po każdym tool callu Claude dostaje informację w stylu:

Token usage: 35000/1000000; 965000 remaining

Dzięki temu model sam wie, ile miejsca mu zostało i może planować pracę odpowiednio. Nie zgaduje – wie. To jak zegarek na egzaminie zamiast strzelania, ile czasu minęło.

Jak włączyć 1M w Claude Code?

Jeśli jesteś na planie Max, Team lub Enterprise – nie musisz nic robić. Opus 4.6 automatycznie używa 1M kontekstu.

Sprawdzenie aktualnego modelu:

/model

Jeśli chcesz wymusić 1M na konkretnym modelu (np. przez alias):

opus[1m]
sonnet[1m]

Jeśli z jakiegoś powodu nie chcesz 1M kontekstu:

bash

export CLAUDE_CODE_DISABLE_1M_CONTEXT=1

To usuwa warianty 1M z model pickera.

Voice mode – koduj głosem (ale po angielsku)

3 marca 2026 Anthropic zaczął roll-out natywnego trybu głosowego w Claude Code. Na razie dostępny dla ~5% użytkowników, ale roll-out rozszerza się z każdym tygodniem.

Jak to działa?

/voice

Wpisujesz tę komendę w terminalu. Od teraz:

1. Przytrzymaj spację – mów
2. Puść spację – transkrypcja leci do promptu
3. Claude wykonuje polecenie jak zwykle

Tryb push-to-talk. Proste. Możesz też miksować – napisać pół prompta na klawiaturze, a resztę powiedzieć głosem. Transkrypcja wchodzi w miejsce kursora.

Kiedy to ma sens?

• Opisywanie bugów – mówienie „sprawdź dlaczego ten API call zwraca 500 w produkcji, podejrzewam że middleware autentykacji łapie wyjątek i zwraca pusty obiekt” jest 3x szybsze niż pisanie tego samego.
• Sesje refaktoringu – mówisz co chcesz, Claude pisze kod. Dwie z czterech faz pracy (myślenie → wyrażenie intencji → pisanie kodu → review) nie wymagają klawiatury.
• Przerwy od klawiatury – po 6 godzinach kodowania ręce potrzebują odpoczynku. Głos pozwala kontynuować bez przerwy w pracy.

Ograniczenie: tylko angielski

I tu jest haczyk. Voice mode działa na razie tylko po angielsku. Silnik STT (speech-to-text) domyślnie transkrybuje na angielski. Jeśli mówisz po polsku, transkrypcja albo się sypie, albo produkuje bezsensowny tekst angielski.

Na GitHubie Claude Code jest już otwarty issue (#33170) z prośbą o dodanie konfiguracji języka – ustawienie voiceLanguage w settings.json. Na razie nie istnieje. Społeczność wnioskuje o coś w stylu:

json

{
  "voiceEnabled": true,
  "voiceLanguage": ["en", "pl"]
}

Ale oficjalnie – silnik pod spodem (prawdopodobnie Whisper) wspiera wiele języków. Problem w tym, że Claude Code po prostu nie daje opcji wyboru języka. Na razie jedyne obejście to zewnętrzne narzędzia do dyktowania (Wispr Flow, Superwhisper, AquaVoice), które transkrybują w dowolnym języku i wklejają tekst do terminala.

Protip: Nawet po angielsku – precyzyjne nazwy plików, ścieżki i zmienne lepiej wpisywać ręcznie. Voice sprawdza się świetnie do wyrażania intencji („refactor the auth middleware to use RBAC”), kiepsko do precyzyjnych identyfikatorów.

Dla kogo to jest?

Podsumowanie

Dwie zmiany, które realnie wpływają na codzienną pracę z Claude Code:

1M tokenów kontekstu – koniec z kompakcją w połowie zadania, koniec z „Claude zapomniał co robiliśmy”. Cały codebase, pełne trace’y, wielogodzinne sesje – w jednym oknie.

Voice mode – szybsze wyrażanie intencji, mniej pisania, ale na razie tylko po angielsku. Jeśli pracujesz w angielskim środowisku – game changer. Jeśli chcesz mówić po polsku – poczekaj lub użyj zewnętrznego narzędzia do dyktowania.

Czy Claude Code przestanie się gubić? Z 5x większym oknem kontekstowym – znacząco rzadziej. Nie jest to gwarancja (context rot istnieje nawet przy 1M tokenów), ale różnica między 200K a 1M jest jak różnica między kartką A4 a flipchartem. Więcej miejsca = mniej zgubionego kontekstu = lepsza praca.

Źródła

• Ogłoszenie 1M GA: claude.com/blog/1m-context-ga
• Dokumentacja context windows: platform.claude.com/docs/en/build-with-claude/context-windows
• Claude Code docs – model config: code.claude.com/docs/en/model-config
• Issue: voice language config: github.com/anthropics/claude-code/issues/33170

Artykuł Claude Code – 1 milion tokenów kontekstu i tryb głosowy pochodzi z serwisu Z IT Wzięte.

Prowadzisz stronę internetową, mały sklep online albo firmowy serwis? Zastanawiałeś się kiedyś, czy ktoś właśnie nie testuje Twoich zabezpieczeń? CERT Polska uruchomił serwis moje.cert.pl – bezpłatną platformę, która pozwala każdemu przeskanować swoje domeny pod kątem podatności, wycieków danych i zagrożeń sieciowych. Oto co powinieneś o niej wiedzieć.

Czym jest moje.cert.pl?

Serwis moje.cert.pl to projekt zespołu CERT Polska działającego w ramach NASK (Państwowy Instytut Badawczy). Platforma wystartowała testowo pod koniec 2024 roku, a w lutym 2025 została oficjalnie udostępniona publicznie. Od tamtej pory zyskała już prawie 16 tysięcy zarejestrowanych użytkowników i przeskanowała ponad 3,3 miliona domen, subdomen i adresów IP, wykrywając ponad pół miliona podatności i błędnych konfiguracji.

Jak ujął to Marcin Dudek, kierownik CERT Polska – jest to rozwiązanie unikalne na skalę światową, ponieważ tak kompleksowe narzędzie diagnostyczne nie było dotychczas udostępniane bezpłatnie i publicznie w żadnym innym kraju.

Co dokładnie oferuje serwis?

Skanowanie bezpieczeństwa domen

Sercem platformy jest narzędzie Artemis – autorski skaner bezpieczeństwa rozwijany przez CERT Polska. Artemis wykorzystuje znane narzędzia open source (m.in. nuclei, sqlmap) i zawiera kilkadziesiąt modułów sprawdzających różne aspekty bezpieczeństwa strony. System wykrywa między innymi:

• podatności SQL Injection umożliwiające kradzież całej bazy danych,
• błędne konfiguracje serwerów,
• brak mechanizmów SPF i DMARC (ochrona przed fałszywymi e-mailami),
• podatności na zdalne wykonanie kodu,
• inne luki wiążące się z wysokim ryzykiem.

Skanowanie jest cykliczne — domyślnie co dwa miesiące, ale interwał można zmienić w ustawieniach. Wyniki trafiają wyłącznie do administratora danej domeny i nie są nigdzie upubliczniane.

Monitoring wycieków haseł

Serwis monitoruje wycieki danych z wielu źródeł — komercyjnych (m.in. Recorded Future), publicznych baz wycieków oraz materiałów pozyskanych przez CERT Polska w ramach pracy operacyjnej (np. hasła wykradzione przez złośliwe oprogramowanie). Jeśli w Twojej domenie pojawi się wyciek, otrzymasz natychmiastowy alert.

Powiadomienia o zagrożeniach sieciowych

System n6, zintegrowany z platformą, codziennie przetwarza miliony zdarzeń, identyfikując infekcje złośliwym oprogramowaniem, hostowanie szkodliwych treści oraz podatności aplikacji dostępnych publicznie z internetu. Administratorzy sieci otrzymują powiadomienia o problemach w swoich zasobach.

Komunikaty o zagrożeniach

Od maja 2025 w serwisie dostępna jest zakładka z ostrzeżeniami dotyczącymi polskiej cyberprzestrzeni i alertami o podatnościach. Komunikaty są widoczne bezpośrednio w panelu, przez kanał RSS, a po wyrażeniu zgody — także wysyłane e-mailem.

Infrastruktura organizacji (nowość 2026)

Najnowsza funkcja pozwala spojrzeć na swoją infrastrukturę oczami potencjalnego atakującego. System identyfikuje publicznie widoczne zasoby organizacji: subdomeny, użyte technologie, panele administracyjne, otwarte porty — w tym te zapomniane lub niezgłoszone. Dzięki temu administrator może ograniczyć powierzchnię ataku, ukrywając lub dodatkowo zabezpieczając niepotrzebnie eksponowane elementy.

Dla kogo jest moje.cert.pl?

Platforma jest zaprojektowana z myślą o szerokim gronie odbiorców:

• Osoby prywatne posiadające własne strony internetowe mogą szybko sprawdzić, czy ich witryna jest bezpieczna.
• Małe i średnie firmy zyskują dostęp do narzędzi diagnostycznych, które do niedawna były zarezerwowane dla dużych organizacji z własnymi działami IT security.
• Instytucje publiczne mogą monitorować bezpieczeństwo nawet bardzo złożonych środowisk — bez ponoszenia dodatkowych kosztów.
• Organizacje sektorowe (np. z sektora finansowego) mogą dodatkowo skorzystać z szybszej identyfikacji i reagowania na zagrożenia specyficzne dla ich branży.

Jak zacząć?

1. Wejdź na moje.cert.pl i zarejestruj konto.
2. Dodaj swoje domeny — system wymaga weryfikacji, że jesteś ich właścicielem lub administratorem (np. przez rekord DNS lub plik na serwerze).
3. Zamów skanowanie i poczekaj na wyniki.
4. Jeśli korzystasz z zapory sieciowej, warto dodać do białej listy adresy IP skanerów CERT Polska (lista jest dostępna w FAQ serwisu), aby wyniki były kompletne.

Dlaczego warto?

Statystyki mówią same za siebie — wśród pierwszych 1800 przeskanowanych domen system wykrył ponad 30 tysięcy podatności, z czego ponad tysiąc stanowiło wysokie ryzyko. Do tego ponad 34 tysiące przypadków wycieków haseł. Wiele z tych problemów było nieznanych administratorom do momentu otrzymania raportu.

Każda wykryta i usunięta podatność to potencjalny incydent bezpieczeństwa, którego udało się uniknąć. A biorąc pod uwagę, że narzędzie jest całkowicie bezpłatne — naprawdę nie ma powodu, żeby z niego nie skorzystać.

Podsumowanie

Serwis moje.cert.pl to jedno z najciekawszych polskich narzędzi cyberbezpieczeństwa ostatnich lat. Łączy w sobie zaawansowane skanowanie podatności, monitoring wycieków danych, alerty o zagrożeniach sieciowych i mapowanie infrastruktury — wszystko w jednym miejscu i za darmo. Jeśli masz jakąkolwiek stronę internetową lub administrujesz siecią firmową, zarejestruj się i sprawdź, jak Twoja infrastruktura wygląda z perspektywy atakującego. Może się okazać, że nie jest tak bezpieczna, jak myślisz.

Źródła: CERT Polska, NASK, Ministerstwo Cyfryzacji

Artykuł Skaner Bezpieczeństwa dla Firm pochodzi z serwisu Z IT Wzięte.

Powiadomienia push z serwera na telefon – zarówno przez integrację z Zabbix, jak i w własnych skryptach bash.

Czym jest ntfy i jak działa?

ntfy (czytaj: „notify”) to darmowy serwis powiadomień push oparty o prosty protokół HTTP. Zamiast konfigurować serwer SMTP czy płacić za bramkę SMS, wysyłasz jedno żądanie curl:

curl -d "Backup zakończony" ntfy.sh/moj-serwer-xyz123

Jedna komenda = powiadomienie push na telefonie. Bez konta, bez tokena, bez konfiguracji serwera.

Bajecznie proste do zastosowania praktycznie we wszytkim.

Dlaczego ntfy zamiast powiadomień email czy SMS?

Dla administratora serwera Linux czy VPS to game changer – alerty ze serwera na smartfon bez żadnych kosztów i konfiguracji.

Konfiguracja aplikacji mobilnej

1. Pobierz aplikację ntfy:

• Android: Google Play lub F-Droid
• iOS: App Store

1. Kliknij + i wpisz nazwę tematu (np. serwer-prod-x7k9m2)
2. Gotowe – każdy POST na ntfy.sh/serwer-prod-x7k9m2 ląduje na telefonie

Ważne: Używaj losowych nazw tematów! Tematy są publiczne – kto zna nazwę, może subskrybować.

Integracja ntfy z Zabbix – powiadomienia push zamiast email

Standardowe powiadomienia Zabbix przez email są wolne i często ignorowane. SMS-y kosztują. ntfy daje natychmiastowe alerty na telefon za darmo.

Krok 1: Skrypt alertów dla Zabbix

Sprawdź katalog alertscripts:

grep AlertScriptsPath /etc/zabbix/zabbix_server.conf
# Domyślnie: /usr/lib/zabbix/alertscripts

Utwórz plik /usr/lib/zabbix/alertscripts/ntfy.sh:

#!/bin/bash

# ========== KONFIGURACJA ==========
# Wpisz własną, unikalną nazwę tematu!
NTFY_TOPIC="zabbix-TWOJ-UNIKALNY-STRING"
# ==================================

TO="$1"
SUBJECT="$2"
MESSAGE="$3"

# Mapowanie severity Zabbix na priorytety ntfy
case "$SUBJECT" in
    *Disaster*|*DISASTER*)
        PRIORITY="urgent"
        TAGS="rotating_light,disaster"
        ;;
    *High*|*HIGH*)
        PRIORITY="high"
        TAGS="warning,high"
        ;;
    *Average*|*AVERAGE*)
        PRIORITY="default"
        TAGS="orange_circle,average"
        ;;
    *Warning*|*WARNING*)
        PRIORITY="low"
        TAGS="yellow_circle,warning"
        ;;
    *OK*|*Resolved*)
        PRIORITY="low"
        TAGS="white_check_mark,resolved"
        ;;
    *)
        PRIORITY="default"
        TAGS="bell"
        ;;
esac

# Wysłanie powiadomienia push
curl -s \
    -H "Title: ${SUBJECT}" \
    -H "Priority: ${PRIORITY}" \
    -H "Tags: ${TAGS}" \
    -d "${MESSAGE}" \
    "https://ntfy.sh/${NTFY_TOPIC}"

exit 0

Nadaj uprawnienia:

chmod +x /usr/lib/zabbix/alertscripts/ntfy.sh
chown zabbix:zabbix /usr/lib/zabbix/alertscripts/ntfy.sh

Test (jako user zabbix):

sudo -u zabbix /usr/lib/zabbix/alertscripts/ntfy.sh "" "[HIGH] Test alert" "Testowe powiadomienie z Zabbix"

Krok 2: Media Type w Zabbix

Alerts → Media types → Create media type

Krok 3: Trigger Action

Alerts → Actions → Trigger actions → Create action

Zakładka Action:

• Name: Powiadomienia push ntfy
• Conditions: Trigger severity >= Warning

Zakładka Operations:

Default subject:

[{TRIGGER.SEVERITY}] {HOST.NAME}: {TRIGGER.NAME}

Default message:

Host: {HOST.NAME}
Problem: {TRIGGER.NAME}
Severity: {TRIGGER.SEVERITY}
Czas: {EVENT.DATE} {EVENT.TIME}

W sekcji Operations → Add:

• Send to users: wybierz użytkowników
• Send only to: ntfy

Zakładka Recovery operations – analogicznie dla powiadomień o rozwiązaniu problemu.

Krok 4: Media dla użytkownika

Users → [Twój user] → Media → Add

Gotowe! Zabbix wykrywa problem → push notification leci na telefon.

Powiadomienia push w skryptach Bash

ntfy idealnie nadaje się do alertów ze skryptów – backup, monitoring dysku, cronjob, deployment.

Alert po zakończeniu backupu

#!/bin/bash

NTFY_TOPIC="backup-serwer-abc123"

notify() {
    curl -s \
        -H "Title: $1" \
        -H "Priority: $2" \
        -H "Tags: $3" \
        -d "$4" \
        "https://ntfy.sh/${NTFY_TOPIC}"
}

notify "Backup started" "low" "arrow_forward" "Rozpoczynam backup na $(hostname)"

if tar -czf /backup/data-$(date +%Y%m%d).tar.gz /data 2>/tmp/backup.err; then
    SIZE=$(ls -lh /backup/data-$(date +%Y%m%d).tar.gz | awk '{print $5}')
    notify "✅ Backup OK" "default" "white_check_mark" "Rozmiar: ${SIZE}"
else
    notify "❌ Backup FAILED" "urgent" "x" "Błąd: $(cat /tmp/backup.err)"
    exit 1
fi

Monitoring miejsca na dysku

Alert gdy dysk się zapełnia – klasyczny przypadek użycia dla administratora VPS:

#!/bin/bash
# Cron: */30 * * * * /usr/local/bin/disk-check.sh

NTFY_TOPIC="monitoring-xyz789"
THRESHOLD=85

df -h | grep -vE '^Filesystem|tmpfs|cdrom' | awk '{print $5 " " $6}' | while read output; do
    usage=$(echo $output | awk '{print $1}' | sed 's/%//')
    partition=$(echo $output | awk '{print $2}')

    if [ $usage -ge $THRESHOLD ]; then
        curl -s \
            -H "Title: ⚠ Brak miejsca na dysku" \
            -H "Priority: high" \
            -H "Tags: warning,disk" \
            -d "Partycja $partition zapełniona w ${usage}% na $(hostname)" \
            "https://ntfy.sh/${NTFY_TOPIC}"
    fi
done

Alert o logowaniu SSH

Powiadomienie push gdy ktoś loguje się na serwer – przydatne do monitorowania bezpieczeństwa:

Utwórz /usr/local/bin/ssh-notify.sh:

#!/bin/bash

[ "$PAM_TYPE" != "open_session" ] && exit 0

curl -s \
    -H "Title: 🔐 SSH: ${PAM_USER}@$(hostname)" \
    -H "Priority: high" \
    -H "Tags: lock,ssh" \
    -d "User: ${PAM_USER}
Z adresu: ${PAM_RHOST}
Czas: $(date '+%Y-%m-%d %H:%M:%S')" \
    "https://ntfy.sh/ssh-TWOJ-TOPIC"

exit 0

chmod +x /usr/local/bin/ssh-notify.sh

Dodaj na końcu /etc/pam.d/sshd:

session optional pam_exec.so /usr/local/bin/ssh-notify.sh

Uniwersalna funkcja do skryptów

Dodaj do ~/.bashrc lub /etc/profile.d/ntfy.sh:

export NTFY_TOPIC="moj-serwer-default"

ntfy() {
    local msg="$1"
    local title="${2:-Alert}"
    local priority="${3:-default}"

    curl -s \
        -H "Title: ${title}" \
        -H "Priority: ${priority}" \
        -d "${msg}" \
        "https://ntfy.sh/${NTFY_TOPIC}"
}

ntfy-ok()    { ntfy "$1" "✅ ${2:-OK}" "default"; }
ntfy-warn()  { ntfy "$1" "⚠ ${2:-Warning}" "high"; }
ntfy-error() { ntfy "$1" "❌ ${2:-Error}" "urgent"; }

Użycie:

ntfy "Zadanie zakończone" "Mój skrypt"
ntfy-ok "Deployment finished"
ntfy-error "Baza danych nie odpowiada" "DB Alert"

Priorytety powiadomień

Dla alertów Zabbix z severity Disaster używaj urgent – telefon zadzwoni nawet w nocy.

Tagi i emoji

Tagi zamieniają się na emoji w powiadomieniu:

curl -H "Tags: warning,server,fire" -d "CPU 98%!" ntfy.sh/moj-topic

Przydatne tagi: warning , white_check_mark , x , rotating_light , fire , computer , lock

Akcja po kliknięciu

Link otwierany po tapnięciu w powiadomienie:

curl \
    -H "Click: https://zabbix.firma.pl/tr_events.php?eventid=${EVENT_ID}" \
    -H "Title: Problem na serwerze" \
    -d "Kliknij aby otworzyć w Zabbix" \
    ntfy.sh/zabbix-alerts

Limity publicznego serwera ntfy.sh

Dla typowego monitoringu serwera VPS to więcej niż wystarczy.

Podsumowanie

ntfy.sh to najprostszy sposób na powiadomienia push z serwera Linux na telefon:

• Zero konfiguracji – tylko curl
• Natychmiastowe alerty – push w sekundę
• Integracja z Zabbix – 10 minut i działa
• Działa w skryptach bash – jedna linijka kodu
• Darmowy – bez rejestracji, bez limitu który boli
• W dokumentacji znajdziecie wszysto. jak tego użyć od Basha aż do Powershell

Koniec sprawdzania maili. Ustaw ntfy, telefon Cię powiadomi.

Linki:

• Strona: ntfy.sh
• Dokumentacja: docs.ntfy.sh
• GitHub: github.com/binwiederhier/ntfy

Artykuł ntfy – Darmowe powiadomienia push z serwera na telefon pochodzi z serwisu Z IT Wzięte.

Dziś wytłumaczę Ci, dlaczego graficzne edytory zabijają wydajność przy pracy z AI i dlaczego tmux w czystym terminalu to absolutny „must-have”. Poznasz też najważniejsze skróty tmux, które zmienią Twoją pracę.

Dlaczego Twój VS Code „zamula”? (Proste wyjaśnienie techniczne)

Zacznijmy od fundamentów. Dlaczego Twój komputer dławi się przy VS Code, a w terminalu „lata”?

Sekret tkwi w budowie programu. VS Code jest zbudowany na technologii Electron. Mówiąc najprościej: każde okno edytora to w praktyce… osobna, ukryta przeglądarka internetowa (Chrome).

Gdy uruchamiasz w nim agenty AI:

1. Marnujesz zasoby: Komputer musi „rysować” każdą literkę logów jako element graficzny strony www. To pożera gigantyczne ilości RAM-u.
2. Ryzykujesz awarię: Procesy są zależne od interfejsu graficznego. Jeśli okno się „zlaguje”, Twoje połączenie z API OpenAI czy Anthropic może zostać zerwane.

Czysty terminal + tmux działa inaczej. Tu nie ma renderowania grafiki. Jest czysty tekst wysyłany bezpośrednio do jądra systemu.

• Efekt? Zużycie pamięci spada drastycznie.
• Procesor? Odpoczywa, zajmując się tylko logiką AI, a nie rysowaniem ładnych ramek.

Tmux – Co to jest i dlaczego ratuje życie?

Tmux (Terminal Multiplexer) to narzędzie, które zmienia jedno okno konsoli w wielozadaniowe centrum dowodzenia. Pozwala podzielić ekran na wiele paneli, zupełnie jakbyś miał kilka monitorów w jednym oknie.

Ale tmux ma jedną supermoc, której nie ma żaden VS Code: Nieśmiertelność Sesji.

Magia „Detach” i „Attach” – Efekt Terminatora

To najważniejszy powód, dla którego warto porzucić terminal w edytorze. W VS Code, gdy zamkniesz okno – zabijasz wszystkie procesy.

W tmuxie wygląda to tak:

1. Uruchamiasz 3 agenty AI, które „mielą” dane.
2. Wciskasz skrót Detach (odłączenie).
3. Zamykasz całkowicie okno terminala. Możesz nawet wylogować się z systemu.
4. Idziesz na kawę, wracasz za 4 godziny.
5. Otwierasz terminal, wpisujesz jedno z tmux polecenia i… wszystko tam jest.

Procesy nigdy nie przestały działać. Kursor mruga dokładnie w tym miejscu, gdzie go zostawiłeś. To idealne rozwiązanie, by zostawić agenty pracujące w tle, nie obciążając pulpitu otwartymi oknami.

Niezbędnik: Skróty tmux dla Vibe Codingu

Nie musisz być hakerem z filmu, żeby tego używać. Wystarczy Ci dosłownie kilka kombinacji. W tmuxie kluczem jest tzw. Prefix. Domyślnie to Ctrl + b. Najpierw wciskasz to, puszczasz, a potem odpowiednią literę.

Oto najważniejsze skróty tmux, które musisz znać:

Dla osoby nietechnicznej kluczowe jest zrozumienie hierarchii w tmuxie, bo to ona miesza w głowie na początku. Musimy to wytłumaczyć obrazowo:

1. Sesja (Session): To Twój cały wirtualny komputer.
2. Okno (Window): To jak karta w przeglądarce. Masz jedną na ekranie, reszta jest ukryta.
3. Panel (Pane): To podział ekranu. W jednym oknie (karcie) możesz mieć np. 4 panele.

Oto rozszerzona sekcja do artykułu, nasycona słowami kluczowymi pod SEO (skróty tmux, okna tmux, panele tmux).

Panele, Okna i Zarządzanie Chaosem

ZIT radzi: Nie ucz się tego na pamięć. Wydrukuj to sobie albo wrzuć do zakładek. W tmux wszystko zaczyna się od Prefixu (domyślnie Ctrl + b). Najpierw wciskasz Prefix, puszczasz go, a potem wciskasz skrót.

1. Panele (Panes) – Twoja przestrzeń robocza

To tutaj dzieje się magia Vibe Codingu. Dzielisz ekran, żeby widzieć kod i logi agenta AI jednocześnie.

2. Okna (Windows) – Jak karty w przeglądarce

Gdy na jednym ekranie masz już za dużo paneli (np. backend, frontend, baza danych), czas otworzyć nowe „czyste” okno.

3. Sesje i Tryb „Boga” (Zarządzanie)

To są polecenia, które decydują o życiu i śmierci Twoich procesów.

Podstawowe tmux polecenia

Skróty działają wewnątrz, ale czasem musisz zarządzać sesjami „z zewnątrz”. Oto lista komend, które wpisujesz w zwykłym terminalu:

• tmux – Uruchamia nową sesję. Twój start.
• tmux ls – Wyświetla listę wszystkich sesji działających w tle. Sprawdzasz, czy Twoje agenty nadal żyją.
• tmux attach – Absolutnie najważniejsze polecenie. Pozwala wrócić do ostatniej sesji (np. po tym, jak zamknąłeś terminal). To Twój powrót do pracy.
• tmux kill-server – Ostateczne rozwiązanie. Zamyka wszystko i czyści pamięć.

Podsumowanie

Jeśli poważnie myślisz o pracy z AI i chcesz utrzymać wysokie tempo (Vibe Coding), przestań polegać na ciężkich edytorach do uruchamiania procesów.

VS Code służy do pisania kodu. Tmux służy do jego życia.

To rozdzielenie sprawi, że Twój sprzęt odetchnie, a Ty zyskasz kontrolę nad chaosem, jaki generują autonomiczne agenty. Mniej lagów, więcej „vibe’u”.

Artykuł Dlaczego tmux i skróty tmux to Game Changer dla Agentów AI pochodzi z serwisu Z IT Wzięte.

Dostajemy komunikat iż „Magazyn wiadomości osiągnął maksymalny rozmiar Outlook 365”. i nie można nic zrobić, nic nie da sie usunąć ani nic, czyli kolejny odcinek serialu pod nazwą outlook problem .

Teraz tak :

Plik PST (Personal Storage Table) to lokalny plik przechowujacy kopie wiadomosci e-mail, kalendarza, kontaktow i innych elementow Outlooka. Uzywany jest glownie w konfiguracjach POP3 oraz do archiwizacji.

Plik OST (Offline Storage Table) to lokalny plik cache dla kont Exchange i Microsoft 365. Pozwala na prace offline z pelnym dostepem do poczty, ktora synchronizuje sie z serwerem po polaczeniu z siecia.

No i w nowym outlooku mają one ograniczenie do 50 GB . Tak …50GB nie 500 tylko 50 . Co nie jest mega limitem dla aktywnie działającego użytkownika…

Mozna różne rzeczy tutaj robić ( usuną plik pobrać, pobrać na nowo rzeczy z imap, można zkompaktować folder) ale problem wróci…

Najlepszym rozwiązaniem na szybko jest zmiana w rejestrze która zmienia ten limit .

Uruchamiamy regedit

Wchodzimy na HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\PST

I dodajemy 2 wartości DWORD :

• MaxLargeFileSize o wartosci 4294967295
• WarnLargeFileSize o wartosci 4090445042

…i w teorii mamy brz ograniczen (coś pod 4 PB) .

Należy pamiętać o tym że im większy plik tym większa szansa na przypadkową awarie pliku .

Zatem koniecznie po uruchomieniu, wyczyśmy śmieci , spamy i skonfigurujmy konecznie archiwizacje.

Artykuł Magazyn wiadomości osiągnął maksymalny rozmiar Outlook 365 pochodzi z serwisu Z IT Wzięte.