 | Strona
domowa Ireny i Zbigniewa Kuleszów
Serdecznie witamy na domowych, prywatnych serwerach Dzisiaj jest: 2026-06-23 Aktualizacja strony dnia: [an error occurred while processing this directive] |  |
| Powitanie | Irena | Zbigniew | Elektronika | Studenci | Serwer | Prawo_jazdy | Kolejka | Pobierz | Linki | Info | O Tobie |
Po restarcie maszyny system nie potrafił przejść do normalnego trybu wielozadaniowego (Multi-User) i wpadał w pętlę krytycznych błędów konsoli tekstowej:
init: cant exec getty /usr/libexec/getty for port /dev/ttyv0: no such file or directorya następnie:
getty repeating too quickly on port ttyv0, sleeping 30 secs.Objaw ten dotyczył wszystkich konsol wirtualnych od ttyv0 do ttyv7.
cannot read termcap database.Uniemożliwiało to poprawne działanie standardowych powłok tekstowych i zaawansowanych edytorów (np. vi), wymuszając pracę w trybie terminala dump.
Próba 1: Podejrzenie uszkodzenia plików binarnego systemu i bazy termcap
cap_mkdb.
Próba 2: Podejrzenie awarii bibliotek dynamicznych (Błąd linkera)
objdump -p.
Próba 3: Próba wymuszenia aktualizacji i naprawy przez freebsd-update
freebsd-update fetch installlub
freebsd-update IDS.
Próba 4: Analiza tabeli montowania i uprawnień katalogów root
mount -u /i
mount -a. Próba przeniesienia getty i bazy termcap na partycję główną / w celu ominięcia struktury /usr.
Kluczem do rozwiązania zagadki okazało się prześledzenie rozruchu skryptu startowego linia po linii za pomocą wbudowanego mechanizmu debugowania powłoki sh w trybie awaryjnym (Single-User Mode):
/bin/sh -x /etc/rc
Wynik testu: Skrypt /etc/rc rozpoczynał działanie, ładował podstawowe zmienne, po czym nagle i po cichu kończył pracę (exit 0), całkowicie przerywając dalszą procedurę bootowania. Dalsza weryfikacja za pomocą:
/rescue/cat -n /etc/rc.conf
ujawniła anomalie. Na samym końcu pliku konfiguracyjnego /etc/rc.conf znajdowało się pojedyncze, ukryte polecenie:
exit
Jak do tego doszło? Słowo to zostało najprawdopodobniej przypadkowo zapisane do pliku podczas jednej z sesji SSH (np. poprzez błędne przekierowanie strumienia
echo "coś" > /etc/rc.confzamiast dopisania >>, bądź wklejenie komendy wyjścia z terminala bezpośrednio do otwartego edytora).
W systemie FreeBSD plik /etc/rc.conf nie jest pasywnym plikiem tekstowym (jak np. pliki .ini czy .json). Jest on wykonywany metodą tzw. sourcingu (kropki lub polecenia . / source) wewnątrz głównego skryptu startowego /etc/rc. Wstrzyknięcie słowa exit do rc.conf spowodowało, że:
Naprawa systemu wymagała całkowitego odcięcia się od uszkodzonej konfiguracji i przywrócenia spójności z poziomu czystej, statycznej powłoki ratunkowej:
Enter full pathname of shell: /rescue/sh
/rescue/mount -u /
/rescue/ee /etc/rc.conflub automatycznie przez sed).
/rescue/reboot.
Po usunięciu słowa exit, skrypt /etc/rc wykonał się w całości, automatycznie montując wszystkie partycje UFS2, podnosząc sieć i przywracając sprawność procesu getty na wszystkich konsolach.
Lekcja dla administratorów (Takeaway)W trakcie pracy nad rozbudowaną witryną składającą się z kilkuset statycznych stron HTML wykonano standardową kontrolę techniczną serwisu po wygenerowaniu mapy witryny (sitemap.xml).
Celem było sprawdzenie poprawności indeksacji oraz weryfikacja, czy wszystkie adresy zwracają kod HTTP 200.
Wyniki pozornie były proste — mapa witryny działała, a strona była dostępna. Jednak analiza crawlerem wykazała kilka błędów 404, których lokalizacja w kodzie nie była oczywista.
Po uruchomieniu skanowania narzędziem typu crawler pojawiło się kilka adresów zwracających błąd 404.
Co istotne:
Problem polegał nie tyle na samej liczbie błędów, co na braku jednoznacznej informacji, skąd one pochodzą.
Naturalnym krokiem jest przeszukanie kodu HTML pod kątem błędnego adresu. W praktyce jednak nie zawsze prowadzi to do rozwiązania problemu.
Odwołania do nieistniejących zasobów mogą znajdować się w różnych miejscach:
<img>,
<a>,
<script>,
<link>),
url(...)),
srcset,
W efekcie ręczne przeszukiwanie pojedynczych plików często nie daje natychmiastowego wyniku.
Jednym z pierwszych kroków powinna być analiza samej mapy witryny.
W wielu przypadkach błędy 404 wynikają z:
Każdy adres w sitemap.xml powinien zwracać kod HTTP 200. Jeśli tak nie jest, mapa witryny wprowadza w błąd mechanizmy indeksujące oraz narzędzia analityczne.
W trakcie analizy okazało się, że duża część trudności nie wynikała z samej witryny, ale z narzędzi używanych do jej analizy.
Różne wyniki w różnych crawlerachRóżne narzędzia dawały różne rezultaty:
Brak spójności utrudniał jednoznaczną ocenę sytuacji.
Część narzędzi wskazywała jedynie adres 404, bez informacji:
Powodowało to konieczność ręcznego przeszukiwania całej struktury serwisu.
Nie wszystkie wykryte adresy pochodziły bezpośrednio z treści strony.
Część była generowana przez:
W efekcie część błędów nie miała „widocznego” miejsca w HTML.
Dodatkowym źródłem niejednoznaczności był sam generator sitemap.xml, który:
W rezultacie mapa witryny mogła zawierać adresy, które nie były już częścią aktualnej struktury serwisu.
Analiza przypadku prowadzi do kilku wniosków:
W praktyce nawet niewielka liczba błędów może wskazywać na pozostałości po wcześniejszych zmianach w strukturze strony.
W środowisku rozbudowanych serwisów statycznych najtrudniejszym elementem nie jest samo wykrycie błędu, ale jego poprawna interpretacja.
Crawler i sitemap są narzędziami pomocniczymi — przydatnymi, ale nieomylne dane trzeba zawsze potwierdzić w kodzie źródłowym oraz strukturze serwera.
Dopiero połączenie analizy narzędziowej i ręcznej weryfikacji pozwala uzyskać pełny obraz stanu technicznego witryny.
W praktyce administracji stron WWW bardzo często pojawia się uproszczenie: „mam sitemapę, więc Google wie wszystko o mojej stronie”. To jedno z tych zdań, które brzmią sensownie, ale w realnym świecie technicznym są tylko częściowo prawdziwe.
Sitemap XML nie jest mapą w sensie diagnostycznym. To jest raczej lista adresów URL przekazana robotowi wyszukiwarki. Google dostaje informację: „te strony istnieją”. Ale to nie oznacza, że te strony są poprawne, dostępne, dobrze połączone albo wartościowe w strukturze serwisu.
Sitemap – lista, nie analizaPlik sitemap.xml pełni jedną funkcję: pokazuje robotowi wyszukiwarki, jakie adresy URL powinny zostać uwzględnione w indeksowaniu. I to wszystko.
Nie sprawdza on:
Sitemap jest więc bardziej deklaracją niż analizą. Można powiedzieć, że to „spis treści”, ale bez sprawdzania, czy wszystkie rozdziały nadal istnieją.
Crawlery – czyli jak Google „czyta” stronęZupełnie inną klasą narzędzi są crawlery. To one działają podobnie do Googlebota: przechodzą po stronie link po linku i sprawdzają jej rzeczywisty stan.
Crawler:
Dopiero na podstawie takiego skanu można powiedzieć coś o „zdrowiu” strony, a nie tylko o jej liście adresów.
Broken links – sygnał, nie katastrofaW trakcie crawlowania często pojawiają się tzw. broken links (np. 404). Wbrew popularnemu podejściu nie są one automatycznie problemem krytycznym dla SEO. Google nie „karze” za pojedyncze błędy tego typu.
Problem zaczyna się dopiero wtedy, gdy:
Wtedy nie chodzi już o pojedyncze błędy, ale o degradację spójności całego serwisu.
Sitemap vs crawler – różnica, która robi różnicęW praktyce te dwa podejścia często są mylone, bo wiele narzędzi łączy je w jednym interfejsie. Ale funkcjonalnie to są dwa różne światy:
I dopiero zestawienie tych dwóch perspektyw daje realny obraz strony.
Wnioski praktyczneW przypadku stron średniej wielkości (kilkaset do kilku tysięcy podstron) często zaczyna się moment, w którym sama sitemap przestaje być wystarczająca jako narzędzie kontroli.
Pojawia się wtedy potrzeba spojrzenia na stronę jak Googlebot:
I to jest moment, w którym SEO techniczne zaczyna mieć większe znaczenie niż sama obecność sitemapy.
DNSSEC w teorii jest prostym mechanizmem: podpisujemy strefę DNS, publikujemy rekordy kryptograficzne i zyskujemy ochronę przed podszywaniem się pod odpowiedzi DNS. W praktyce jednak wdrożenie w środowisku hostingowym pokazuje, że największym problemem nie jest sama technologia, ale model zarządzania domeną.
ZałożenieCelem było sprawdzenie, czy DNSSEC można włączyć w typowej konfiguracji: domena krajowa (.pl), DNS zarządzany przez dostawcę hostingu, bez własnej infrastruktury DNS.
Weryfikacja stanuPierwszym krokiem była kontrola delegacji zabezpieczeń:
dig domena.pl DS
Brak rekordu DS w odpowiedzi oznacza brak aktywnego DNSSEC po stronie rejestru.
Następnie sprawdzono strefę DNS:
Wniosek był jednoznaczny: strefa DNS nie jest podpisana, a DNSSEC nie jest aktywny.
Problem praktycznyW środowiskach hostingowych często nie ma bezpośredniego przełącznika DNSSEC w panelu użytkownika, mimo że:
Brakuje jednak elementu kluczowego: publikacji rekordu DS w rejestrze domeny.
Kluczowy wniosekDNSSEC nie jest usługą „po stronie hostingu DNS”, tylko elementem łańcucha zależności:
rejestr domeny → delegacja DS → serwery DNS → podpisana strefa
Oznacza to, że:
DNSSEC w praktyce ujawnia typowy problem infrastruktury DNS: rozdzielenie odpowiedzialności.
Z punktu widzenia administratora:
W efekcie technologia, która ma zwiększać bezpieczeństwo, często okazuje się trudna nie dlatego, że jest skomplikowana, ale dlatego, że jest rozproszona między różne systemy.
Dobór sprzętu do nowoczesnego firewalla opartego o OPNsense przestał być prosty. W praktyce nie wybiera się już „routera”, tylko mały serwer brzegowy (edge firewall).
W analizowanym przypadku celem było zbudowanie urządzenia:
W urządzeniach klasy AliExpress (CWWK / Topton / OEM):
Największe obciążenia nie wynikają z NAT, ale z:
👉 wniosek: nie nadają się do 2.5G
👉 wniosek:
świetne do routera, ale ograniczone pod IDS i VPN przy dużym ruchu
👉 wniosek:
najlepsza klasa dla firewalla 2.5G+ z zapasem
| CPU | Rdzenie | PassMark | NAT 2.5G | VPN | IDS/IPS | Klasa |
|---|---|---|---|---|---|---|
| i3-5010U | 2C/4T | ~2k | ❌ | ❌ | ❌ | legacy |
| i3-8140U | 2C/4T | ~4k | 🟡 | ❌ | ❌ | basic |
| N300 | 8C/8T | ~6k | 🟡 | 🟡 | ❌ | low-power |
| N305 | 8C/8T | ~9–10k | 🟢 | 🟡 | 🟡 | edge router |
| N355 | 8C/8T | ~11k | 🟢 | 🟢 | 🟡🟢 | strong low-power |
| i5-8259U | 4C/8T | ~8k | 🟢 | 🟢 | 🟡 | mid firewall |
| i5-1235U | 10C/12T | ~13–14k | 🟢🟢 | 🟢🟢 | 🟢🟢 | optimal firewall |
W toku analizy wybrano docelową konfigurację:
Intel i5-1235U + 6× Intel i226-V + 2× 10GbE uplink
i5-1235U oferuje:
👉 klucz:
firewall musi mieć headroom, nie tylko „peak performance”
👉 efekt:
igc
Mimo dobrych parametrów energetycznych:
👉 wniosek:
N-series = edge router
i5-1235U = edge firewall
W firewallach 2.5G–10G nie wygrywa najniższy pobór energii, tylko stabilny zapas CPU przy szczytowym obciążeniu (VPN + IDS + routing).
Dobór sprzętu firewall w tej klasie nie polega na wyborze „najmocniejszego CPU”, tylko na znalezieniu punktu, w którym:
* Operating system: FreeBSD (amd64 architecture)
* File system: UFS2 (classic partition layout, including separate mount points / and /usr)
* Additional services: Active container/jail environments managed from the host systeminit: cant exec getty /usr/libexec/getty for port /dev/ttyv0: no such file or directorygetty repeating too quickly on port ttyv0, sleeping 30 secs.cannot read termcap database.cap_mkdbobjdump -pfreebsd-update fetch installfreebsd-update IDSmount -u /mount -a/bin/sh -x /etc/rc/rescue/cat -n /etc/rc.confexitecho "something" > /etc/rc.confEnter full pathname of shell: /rescue/sh/rescue/mount -u //rescue/ee /etc/rc.conf/rescue/reboot* the public zone domena.pl is managed by an external DNS provider,
* the local BIND server maintains its own version of the same zone exclusively for the LAN,
* in the local network domena.pl resolves to a private address (e.g. 192.168.1.100),
* on the Internet domena.pl resolves to a public address (e.g. 88.x.x.x),
* DNSSEC is handled automatically using:
dnssec-policy default;
and
inline-signing yes;
.dig @192.168.1.1 domena.pl Astatus: NOERROR
ANSWER: 0
AUTHORITY: 1
domena.pl. IN SOA ns1.example.pl. hostmaster.example.pl.@ IN A 192.168.1.100named-checkzone domena.pl domena.pl.zone.dbloaded serial XXXXX
OKrndc zonestatus domena.plfile: domena.pl.zone.db.signed
serial: 202407013
signed serial: 202407376named-checkzone domena.pl domena.pl.zone.db2026060105* the source file had been modified,
* BIND was aware of the new data,
* but the active zone was still using the old signed file.domena.pl.zone.db.signed
domena.pl.zone.db.signed.jbk
domena.pl.zone.db.signed.signed
domena.pl.zone.db.signed.signed.jnlfile "domena.pl.zone.db.signed";
inline-signing yes;.signed
.signed.signedzone "domena.pl" {
type primary;
file "/path/domena.pl.zone.db";
dnssec-policy default;
inline-signing yes;
allow-update { none; };
};file "domena.pl.zone.db.signed";service named stoprm domena.pl.zone.db.signed*service named startdomena.pl.zone.db.signed
domena.pl.zone.db.signed.jbkdig @192.168.1.1 domena.pl A +short192.168.1.100nslookup domena.pl 8.8.8.8Aliases: domena.pl.example.plcat /etc/resolv.confsearch example.pl*.example.pl CNAME example.pldomena.pl → domena.pl.example.pldomena.pl -> 88.x.x.xdomena.pl -> 192.168.1.100ssh serwer1
ping nas
ping backupsearch example.plhost → host.example.pldomena.pl → domena.pl.example.pl*.example.pl CNAME example.pl* jellyfin.example.pl
* grafana.example.pl
* nextcloud.example.pl* the number of errors was small,
* the pages themselves worked correctly,
* there was no obvious place in the HTML where these URLs were used.* in HTML tags (<img>, <a>, <script>, <link>),
* in CSS (url(...)),
* in JavaScript (dynamic assignments),
* in srcset,
* in shared templates used across multiple pages,
* in sitemap.xml.* leaving old URLs in sitemap.xml,
* outdated entries after changes in site structure,
* sitemap generation errors from automated tools.* one detected 404 errors,
* another did not report them at all,
* yet another found URLs that did not exist in the code.* which page contained the reference,
* in which element the link was found.* CSS (e.g. background images),
* JavaScript (dynamic assignments),
* conditionally loaded elements,
* outdated entries in static assets.* could retain outdated URLs,
* did not always refresh structure after changes,
* sometimes relied on historical data.* no single tool provides a complete picture of the site state,
* crawler results should be treated as a starting point, not final truth,
* each 404 error requires verification of its source, not just the URL,
* sitemap.xml must be treated as an active element, not a one-time generated file.* whether the page returns a 404 error,
* whether internal links lead to existing resources,
* whether the site structure is logical,
* whether a given subpage is an orphan page. * visits every page like a user or bot,
* analyzes server responses (200, 301, 404, 500),
* detects broken links,
* maps the structure of connections between subpages. * errors occur in internal links,
* the site structure relies on non-existing resources,
* the linking architecture gradually becomes disorganized. * sitemap says: “what should exist”
* crawler says: “what actually works” * through crawl,
* through link analysis,
* through verification of structure, not only the URL list. * no DNSKEY records
* no RRSIG signatures * DNS is fully managed from the hosting side,
* the DNS zone works correctly,
* records can be freely edited. * correct DNS configuration does not guarantee DNSSEC,
* the hosting panel does not always provide full control over domain security,
* activation often requires action on the registrar side or technical support. * DNSSEC is not a “setting”, but a process in a service chain,
* the absence of a single element (DS) invalidates the entire configuration,
* and visibility in hosting panels can be misleading. * with OPNsense system (FreeBSD)
* 2.5G support (LAN)
* 10G uplink (WAN/backbone)
* minimum 6× Intel i226-V (LAN interfaces)
* RAM 8–16 GB
* 24/7 stability
* budget ~1500–2000 PLN * network card (Intel i226-V) is fixed
* RAM and SSD are secondary
* CPU defines the real firewall class * VPN (WireGuard / OpenVPN)
* IDS/IPS (Suricata / Zenarmor)
* burst traffic (peak 2.5G–10G load) * low performance
* no CPU headroom
* only basic NAT/firewall * very low power consumption
* good efficiency per Watt
* limited peak performance great as a router, but limited for IDS and VPN under heavy load* higher single-core performance
* better VPN throughput
* larger CPU headroom
* more stable operation under IDS best class for 2.5G+ firewall with headroom| CPU | Cores | PassMark | NAT 2.5G | VPN | IDS/IPS | Class |
|---|---|---|---|---|---|---|
| i3-5010U | 2C/4T | ~2k | ❌ | ❌ | ❌ | legacy |
| i3-8140U | 2C/4T | ~4k | 🟡 | ❌ | ❌ | basic |
| N300 | 8C/8T | ~6k | 🟡 | 🟡 | ❌ | low-power |
| N305 | 8C/8T | ~9–10k | 🟢 | 🟡 | 🟡 | edge router |
| N355 | 8C/8T | ~11k | 🟢 | 🟢 | 🟡🟢 | strong low-power |
| i5-8259U | 4C/8T | ~8k | 🟢 | 🟢 | 🟡 | mid firewall |
| i5-1235U | 10C/12T | ~13–14k | 🟢🟢 | 🟢🟢 | 🟢🟢 | optimal firewall |
Intel i5-1235U + 6× Intel i226-V + 2× 10GbE uplink* WAN: 2×10G (uplink / ISP / backbone / aggregation)
* LAN: 6×2.5G Intel i226-V (VLAN segmentation / DMZ / LAN)
* CPU: Intel i5-1235U
* RAM: 16 GB DDR4
* Storage: NVMe SSD * high single-core performance (VPN, routing)
* 10 cores (P + E cores)
* stable throughput under IDS load
* large CPU headroom firewall must have headroom, not only “peak performance”* 2×10G → uplink / backbone
* 6×2.5G → LAN segmentation * no interface bottleneck
* no VLAN congestion * Intel i226-V → igc driver
* stable OPNsense 24+ support
* proven firewall platform * no swap under IDS
* stable logging
* buffer for Suricata / Zenarmor * N300 / N305 / N355 have limited single-core performance
* IDS and VPN are CPU-bound
* at 10G and heavy traffic there is no headroom N-series = edge router
i5-1235U = edge firewallIn 2.5G–10G firewalls the winner is not the lowest power consumption, but stable CPU headroom under peak load (VPN + IDS + routing).* i5-1235U + 6× i226-V + 2×10G * N355 * N305 * i3-5010U
* i3-8140U
* N300 * CPU is not a bottleneck under burst traffic
* IDS does not saturate the system
* VPN maintains stable throughput
* 2.5G/10G networking does not cause throttling| Powrót na stronę
główną - Informacje o
stronie, prawa autorskie, legalność itd. tutaj
Informacje o przetwarzaniu i ochronie danych osobowych, kontakt i zapytania itd. tutaj Prywatne serwery Zbigniewa Kuleszy zjk.pl. Aktualny dostawca Internetu - Vectra.pl, Wszelkie prawa zastrzeżone. Zespół redakcyjny zjk.pl: zjk7@wp.pl W sprawie treści i działania strony oraz w sprawie funkcjonowania i udostępniania treści na serwerach zjk.pl - kontakt z administratorem: webmaster@zjk.pl lub zjk7@wp.pl
|
