Fórum Root.cz
Hlavní témata => Server => Téma založeno: xsouku04 24. 06. 2024, 12:16:09
-
Zvažuji přechod z Linuxu na FreeBSD. Potřebuji probrat, jestli jsou moje očekávání reální.
Provozuji již 20 let cca 8 fyzických serverů a na nich běží virtualizace.
Na Linuxu mi vadí především "časté" změny a nestabilita:
- Co se týče virtualizace zažil jsem vserver, opevnz, lxc. Nejlepší a nejstabilnější bylo openvz, vserver zase jednoduchý a taky dobrý. Lxc je takový nedodělek a ještě horší další nádstavba lxd. Módní docker nepotřebuji.
- Co se týče firewallu tak jsem také zažil tři změny. Chains, iptables a nyní nftable. Nftable jsou celkem OK, ale jen některé moduly z iptables stále nemají náhradu.
- V Linuxu mi přijde, že je dost věcí zbytečně složitých a špatně dokumentovaných.
- Ač je často obtížné vyloučit problém hardware, přijde mi spíše, že stabilita systému se zhoršuje. Např. proč je možné, že se systém přestane odpovídat kvůli jedinému programu, které vyžere nějaké zdroje? Proč jádro nezabije/neomezí přednostně tento proces, ale klidně zabije nějaký náhodný, který za to vůbec nemůže? Tedy pokud s tím jádro vůbec něco udělá. Pravděpodobně lze vše vychytat nějakým vhodný nastavením, ale proč je defaultní nastavení tak špatné? Subjektivně od doby OpenVZ se spolehlivost jádra snižuje.
Co se mi líbí na FreeBSD
- Věci se zbytečně nemění a když tak jednoznačně k lepšímu se zpětnou kompatibilitou.
- FreeBSD mi přijde jednodušší a možná i lépe dokumentovaný. Např. komplikovanost balíčkovacího systému Debianu v porovnání s balíčky a možnostmi na freeBSD - nesrovnatelné. Ani instalace freeBSD na server není komplikovanější, spíše naopak, zvláště když chci použít ZFS. Možnost vytvořit si vlastní porty - zkompilovat nejnovější verzi oficiálně doporučovaným způsobem a udělat si z toho balíček.
- Nativní podpora ZFS a i prastaré UFS má nativní podporu snapshotů.
- Virtualizace jails již 20 let.
- To že se něco nesmyslně nemění pod rukama umožňuje lepší stabilitu. Předpokládám.
- Umí spouštět i Linuxové virtuály i když bez systemd. - to zatím není problém
Co se mi nelíbí na FreeBSD
- Má podstatně méně uživatelů, ale že by se úplně přestali vydávat aktualizace se mi nezdá pravděpodobné.
- Údajně méně podporovaného hardware - nejspíš problém hlavně u desktopů, ale tam to používat nechci.
Napadá mne, že je hrozná škoda, že jsem nepřešel už na začátku. Před těmi 20 lety bylo nejspíše platných důvodů, proč používat freeBSD nejspíše více než dnes. Máto nyní ještě smysl? Možná je u mě specifické to, že potřebuji hlavně stabilitu 24/7 a naopak nepotřebuji nejnovější featury linuxové jádra.
-
to bude jako prechod z cestiny na slovenstinu, trocha zvyku.
-
Co se týče virtualizace zažil jsem vserver, opevnz, lxc. Nejlepší a nejstabilnější bylo openvz, vserver zase jednoduchý a taky dobrý. Lxc je takový nedodělek a ještě horší další nádstavba lxd. Módní docker nepotřebuji.
Proč tolik? Na linuxu používám (za celý život) pouze dvě formy virtualizace a to KVM a nspawn pro kontejnery. Vše, co jsi vyjmenoval, jsou kontejnery.
Co se týče firewallu tak jsem také zažil tři změny. Chains, iptables a nyní nftable. Nftable jsou celkem OK, ale jen některé moduly z iptables stále nemají náhradu.
Velmi rychle jsem si zvykl na FW před servery. Tedy nekomplikovat si život stylem vše na jedné hromadě. Navíc opět, co je na tom tvém fw tak složitého, že některé věci v nftables nejsou?
Věci se zbytečně nemění a když tak jednoznačně k lepšímu se zpětnou kompatibilitou.
Jo, tohle je asi největší výhoda.
Nativní podpora ZFS a i prastaré UFS má nativní podporu snapshotů.
K tomu bych doplnil pro mě chybějící lvm. FreeBSD má ZFS, protože nemá nic jiného. ZFS není dokonalé. Ano, v ZFS lze mít ZVOL, ale na spoustu věcí se hodí co nejobyčejnější oddíl typu LV v LVM.
Virtualizace jails již 20 let.
Kontejner. Naopak skutečná virtualizace na FreeBSD dost dlouho chyběla, dneska je tam bhyve. Pokud tento způsob někoho baví. Moje instalace FreeBSD používá jaily tak nějak na všechno. Co kontejner, to jedna funkce. Základní systém je v podstatě minimální instalace.
To že se něco nesmyslně nemění pod rukama umožňuje lepší stabilitu. Předpokládám.
Asi jo.
Umí spouštět i Linuxové virtuály i když bez systemd. - to zatím není problém
To nevím a rozhodně bych vůbec nedoporučoval používat FreeBSD pro spouštění čehokoliv z linuxu. Raději mít Linux server a vedle toho FreeBSD server. Takto to provozuju já. Kombinatorika typu "tohle tam pojede" do budoucna pouze přináší problémy.
Má podstatně méně uživatelů, ale že by se úplně přestali vydávat aktualizace se mi nezdá pravděpodobné.
Nevím a je to jedno.
Údajně méně podporovaného hardware - nejspíš problém hlavně u desktopů, ale tam to používat nechci.
Nevím a tohle o linuxu slyším už nějakých 20 let. Nikdy jsem neměl problém s HW na linuxu a nemám jej ani na FreeBSD. Kupuju nejobyčejnější a nejprůměrnější x86 HW. Nikdy žádný problém u žádného OS.
Napadá mne, že je hrozná škoda, že jsem nepřešel už na začátku. Před těmi 20 lety bylo nejspíše platných důvodů, proč používat freeBSD nejspíše více než dnes. Máto nyní ještě smysl? Možná je u mě specifické to, že potřebuji hlavně stabilitu 24/7 a naopak nepotřebuji nejnovější featury linuxové jádra.
Co se týče stability, tak mezi Linuxem a FreeBSD nevidím rozdíl. Na tvém místě bych spíš vyřešit ten nepořádek (tak se mi to jeví) v tisíci různých kontejnerech, podivné nutnosti používat něco v iptables apod.
Já vždy jedu co nejnativnější prostředí, proto taky mimochodem na linuxu používám nspawn. Protože je to system native, systemd v linuxu mám, automaticky je tam integrovaný nspawn, vůbec nic dalšího nepotřebuju instalovat. Celý ten stroj je jednoduchý jak facka.
Tím netvrdím, že jiné kontejnery jsou horší nebo něco podobného. To ne. Jen tím chci vysvětlit můj přístup k administraci serverů. Vše co možná nejjednodušší, nejnativnější, bez zbytečných komponent. Vše co jde vyřešit na jiné a jednodušší úrovni, tak to patří tam. Strojů od namachrovaných linuxáků, kde se řeší vše od otevírání dveří, splachování záchodů až po centrální firewall jsem už viděl dost.
-
Hromada z toho utíká k Linuxu.
-
FreeBSD má přece UFS. Mám zkušenost že na databáze, které často updatují a zapisují menší bloky dat nemusí být ZFS nejlepší, nejen pomalejší, ale dovedou zničit SSD disk i za rok. Změna recordsize pomůže jen částečně. Změny ostatních voleb nepomáhali vůbec. Na linuxu jsem to úplně vzdal a pro hodně busy databáze používal ext4 s lvm. Uvidíme jestli se to freeBSD podaří vyřešit.
V době kdy bylo jasné žen OpenVZ končí byl ještě systemd nestabilní, proto jsme vybrali lxc. Není tedy opět čas měnit kontejnerovou technologii? Tedy už počtvrté?
Za poslední rok se mi kousnul server s Linuxem cca 8 krát. Sice část těch kousnutí může mít na svědomí hardware, ale když to porovnám s dobou OpenVZ, kdy se něco takového nestalo ani jednou za pět let, je to jednoznačné zhoršení stability.
Několikrát systém spadl, nebo přestal dočasně reagovat protože tam něco vyžralo část zdrojů.
Jednou linux spadul a log měl plný Faile to start systemd-journald.service pořád dokola na své konzoli. Zjevně se nějak pomátl journald a vyžral paměť. Nebo samotný systemd? Jinkdy vyžral paměť nejspíše samotný zfs souborový s přispěním deduplikace, i když paměti měl dost 128 GB. A mnohokrát přišlo kernel panic, nebo chyba ovladače síťové karty, takže síťová karta přestala fungovat ....
Je jasné, že freeBSD není univerzálním řešením, ale zlepšit by se to mohlo.
-
FreeBSD má přece UFS.
To já vím. Ale FreeBSD nemá žádný nástroj pro vytváření blokových zařízení, na která by se mohlo dát UFS. FreeBSD počítá s tím, že tam bude HW diskový řadič, na kterém se vše vyřídí. V tomto je linux opravdu mnohem dál. Na straně FreeBSD na to dali náplast v podobě ZFS. (Já jsem vůbec zmlsanej z BTRFS a stále se neumím smířit s tím, že nic lepšího není. Stále mi chybí distribuovaný FS, který by navíc neřešil redundanci na úrovni diskových zařízení, ale naopak co nejvýš - tedy možnost definovat si redundanci až na úrovni subvolume/datasetu a ono to samo rozhodí data na disky a klidně i po síti.)
Na linuxu jsem to úplně vzdal a pro hodně busy databáze používal ext4 s lvm.
Už si nepamatuju, jestli jsem do té diskusi nějak zasahoval nebo ne, já na DB používám XFS. Roky. Pochopitelně na FreeBSD ZFS, ale tak tady je to jasné.
V době kdy bylo jasné žen OpenVZ končí byl ještě systemd nestabilní, proto jsme vybrali lxc. Není tedy opět čas měnit kontejnerovou technologii? Tedy už počtvrté?
To musíte vědět vy. Vůbec nevím, co provozujete apod. Já jsem adminoval ještě v době, kdy kontejnery nebyly tak populární a pro nás bylo naprosto normální mít stovky VM na plné virtualizaci (vmware, doma kvm). Doma jsem si nspawn vyzkoušel někdy před 10 lety, zjistil jsem, že je to ok, smazal jsem 30 VM (KVM) a převedl na nspawn. A nijak jsem to neprožíval, KVM má své výhody, nspawn taky.
Za poslední rok se mi kousnul server s Linuxem cca 8 krát. Sice část těch kousnutí může mít na svědomí hardware, ale když to porovnám s dobou OpenVZ, kdy se něco takového nestalo ani jednou za pět let, je to jednoznačné zhoršení stability. Několikrát systém spadl, nebo přestal dočasně reagovat protože tam něco vyžralo část zdrojů.
Jednou linux spadul a log měl plný Faile to start systemd-journald.service pořád dokola na své konzoli. Zjevně se nějak pomátl journald a vyžral paměť. Nebo samotný systemd? Jinkdy vyžral paměť nejspíše samotný zfs souborový s přispěním deduplikace, i když paměti měl dost 128 GB. A mnohokrát přišlo kernel panic, nebo chyba ovladače síťové karty, takže síťová karta přestala fungovat ....
Je jasné, že freeBSD není univerzálním řešením, ale zlepšit by se to mohlo.
Takhle se věci nespravují. Pokud něco padá, je potřeba zjistit co. Pokud je podezření na HW, tak vyměnit HW. Věci se nespravují náhodným zkoušením různých OS apod. Takže nastavit monitoring, monitorovat všechno, co tam má běžet, co tam nemá běžet tak odinstalovat, mít čisté prostředí apod.
Vzpomněl jsem si na jeden server, na kterém bylo napsáno "don't touch". Chodilo se kolem něj po špičkách. Časem se kolem toho vyrojil příběh, fámy apod. Víš, čím to bylo? Mezi základní deskou a zadním plechem byl šroubek, který při dotyku na skříň zkratoval základní desku. Řešením není na to lepit nálepky, ale koupit nový server a v případě zájmu prozkoumat ten původní.
Kdybych měl podezření na vadný hw a po přechodu na freebsd by se "vyřešilo" tak bych stejně nebyl spokojený.
-
Já lvm nepotřebuji, maximálně na ty snapshoty, protože to linux jinak neumí. Takže že jej freeBSD nemá vůbec nevadí, když snapshoty umí řešit lépe.
Problém je v tom, že ten důvod proč Linux padá není jeden a zpravidla se nedá zopakovat či nic rozumného najít. Důvody jsou různé a všemožné zkoumání nepomáhá.
Už nyní používám ZFS. Právě kvůli těm zfs send a zfs recieve každých pět minut,aby bylo odkud pouštět zálohy, když se jeden ze serverů kousne.
A mám tady další věc. Pokud udělám zfs send přes ssh musím hodně výrazně uměle omezit rychlost na méně jak 100 Mbit i když je k dispozici 1 GBbit. , aby to výrazně nedegradovalo výkon ostatních aplikací. A přitom běžný síťový provoz je cca jen 30 Mbit.
-
Souhlasím s Tomášem, že to vypadá na problém HW. U stable debianu s distribučním (tj. otestovaným)
jádrem se s pády z důvodu SW nesetkávám. Samozřejmě načatý HW je špatně, stačí i odcházející síťovka, paměťový modul, apod.
Pokud udělám zfs send přes ssh musím hodně výrazně uměle omezit rychlost na méně jak 100 Mbit i když je k dispozici 1 GBbit. , aby to výrazně nedegradovalo výkon ostatních aplikací. A přitom běžný síťový provoz je cca jen 30 Mbit.
A co to způsobuje? Zahlcené disky čtením, slabé CPU s málo jádry, které už nestíhá komprimaci+šifrování SSH?
-
Pokud udělám zfs send přes ssh musím hodně výrazně uměle omezit rychlost na méně jak 100 Mbit i když je k dispozici 1 GBbit. , aby to výrazně nedegradovalo výkon ostatních aplikací. A přitom běžný síťový provoz je cca jen 30 Mbit.
A co to způsobuje? Zahlcené disky čtením, slabé CPU s málo jádry, které už nestíhá komprimaci+šifrování SSH?
Disky jsou SSD a i kdyby nestíhaly, jádro by si mělo pohlídat, že tím přehnaně netrpí ostatní aplikace. Jader procesoru bylo hodně. Opět by to mělo hlídat jádro. Zkoušeli jsme snížit priority tomu procesu, omezit io operace a nic nepomáhala až umělé snížení přenášení rychlosti na zhruba desetinu toho co by mělo jít přenést.
Část problémů je určitě hardware. Měnil jsem jednu desku a budu muset nepoužívat jednu integrovanou síťovku a místo ní přidám další. (i tohle ale může být problém ovladače) V ostatních případech to bylo mohlo být Linuxem. Paměti ECC mám. Ono když se to stane u jednoho serveru třeba jednou za rok a příště něco jiného. Nečekaně. Tak je obtížné získat nějaké důkazy. Mám ipmi, takže občas vidím divné hlášky, jako že jádro občas zabije nějaký náhodný proces protože něco v jiném containeru zjevně vyžralo paměť, nebo nějaké nesmysly vypisuje systemd. Nebo selhal ovladač síťovky. (možná je to Intel bug, protože ten dodal ovladač) Nebo kernel panic, což by mohlo a zjevně i bylo hardwarem.
Já jsem asi moc rozmlsanej a i problém v průměru jednou za rok (nucený restart) na jeden server je u mne moc. Protože jak píši 5 let jsem se s tím vůbec nesetkával.
-
Hromada z toho utíká k Linuxu.
https://w3techs.com/technologies/details/os-bsd
BSD má naprosto marginální podíl = je to UFO. Znám pár lidí, co už BSD opustila. Důvod? Debian má dobrou uživatelskou základnu. A sehnat BSDčkaře je pořád těžší.
Plus - zadej si na jobs.cz BSD a uvidíš ;-)
-
A mám tady další věc. Pokud udělám zfs send přes ssh musím hodně výrazně uměle omezit rychlost na méně jak 100 Mbit i když je k dispozici 1 GBbit. , aby to výrazně nedegradovalo výkon ostatních aplikací. A přitom běžný síťový provoz je cca jen 30 Mbit.
Tak to tam bude něco hodně špatně. Já mám zfs send cca 600MB/s na rotačních discích. Pokud to posílám přes síť, tak tam dávám lzop, ať to stíhá komprimovat rychlostí sítě i tak to bezproblémů saturuje síť. (Bavím se o desktopovém HW.) Degradovat gigabit na 100mbit je divné. Buď se ty tvoje appky hádají o cpu (což dle popisu nepředpokládám), nebo o disky.
-
A sehnat BSDčkaře je pořád těžší.
Plus - zadej si na jobs.cz BSD a uvidíš ;-)
Sehnat dobrého Linuxáře také není jednoduché. Navíc se tam plete ten zbytek... jobs.cz? Co je to za metriku?
-
jobs.cz? Co je to za metriku?
Tak se koukni po jiných serverech, třeba na ÚP :-D Ale Jobs.cz je dobrý indikátor toho, co je žádané.
Ad "dobrý linuxář", často to je o tom, jestli ten člověk je ochoten se učit. Často se to prostě naučí.
-
kdyz uz, tak bych si vybral openbsd
-
Zkoušeli jsme snížit priority tomu procesu, omezit io operace a nic nepomáhala až umělé snížení přenášení rychlosti na zhruba desetinu toho co by mělo jít přenést.
Nevím, velice bych se divil, kdyby to byl problém obecně linuxu. Gigabit není žádný tok. Není třeba limit na tom portu 100Mbps, ať už chybou driveru, síťovky, nebo omezení před serverem, a při spuštění velkého toku to omezí dostupné pásmo pro ostatní spojení?
-
jobs.cz? Co je to za metriku?
Tak se koukni po jiných serverech, třeba na ÚP :-D Ale Jobs.cz je dobrý indikátor toho, co je žádané.
ok ok ok. Tak třeba "debian" – 8 nabídek na celé Česko. Fakt si nemyslím, že to o něčem vypovídá.
Ad "dobrý linuxář", často to je o tom, jestli ten člověk je ochoten se učit. Často se to prostě naučí.
Pokud ta ochota se učit je silnější než vykazovat práci, tak je to problém. A není to nijak neobvyklé. No a pak je to často ego ve stylu „jak to dělám já je to nejlepší a ostatní jste tupci a je mi jedno, co potřebujete“. Ale to samozřejmě není nic specifického pro Linux prostředí.
-
Porovnávej BSD vs Linux, když dáš na jobs.cz BSD, kolik ti to hodí pozic? A kolik stránek ti to vrátí na Linux?
Né, máš pravdu, všichni jedou BSD! :-D
-
Mně to přijde jako typickej PEBKAC...
Linuxu nerozumí, tak přejde na BSD, kterému taky nebude rozumět..
Ale tak, když si myslí, že to pomůže...
Já si myslím, že ne a lepší variantou je, zjistit, kde je skutečně problém. V Linuxu jako takovém, zcela určitě nebude.
-
Nevím, co nabídka práce vypovídá o stabilitě a kvalitě OS, a pokud už něco na jobs hledat, tak by to měl být spíše UNIX vs. LINUX než BSD.
-
Porovnávej BSD vs Linux
Ale no tak. Linux je jádro, nikoli systém. Debian je systém. Ovládat Debian fakt není stejné jako ovládat RHEL.
-
kdyz uz, tak bych si vybral openbsd
A proč OpenBSD? OpenBSD má opět o řád méně uživatelů než freeBSD.
-
Zkoušeli jsme snížit priority tomu procesu, omezit io operace a nic nepomáhala až umělé snížení přenášení rychlosti na zhruba desetinu toho co by mělo jít přenést.
Nevím, velice bych se divil, kdyby to byl problém obecně linuxu. Gigabit není žádný tok. Není třeba limit na tom portu 100Mbps, ať už chybou driveru, síťovky, nebo omezení před serverem, a při spuštění velkého toku to omezí dostupné pásmo pro ostatní spojení?
Netuším. Ovladačem síťovky by to být mohlo. Také by to mohl být problém switche v servrovně, který je pod zprávou serverhousing. Sice je to gigabit ale zvládá jen 1/4 ? Také divné.
Tyhle dvě věci by mohla vyloučit zvláštní síť jen pro backupy, pokud by to přestalo muselo by to být jednou z těchto dvou věcí. Ostatní datový tok je max 30 Mbit, takže rochlost 950 Mbit by to mělo dávat s 50 Mbit rezervnou pro ten pro ten 30 Mbit tok. Ale bohužel je to problémové.
-
Tak si dále hraji z freeBSD. Zjistil jsem že na stávajícím hardware běží freeBSD bez problému a to i na zánovních deskách.
Hlavní konfigurace, konfigurace služeb a konfigurace sítě je v /etc/rc.conf a je to fakt velmi jednoduché a přehledné. To si dost líbí. Stejně jako možnost startovat a vypínat služby pomocí jednoduchých skriptů. Nedá se to moc srovnávat s sysvinit v dřívějším linuxem, který používal před systemd. FreeBSD je na tom výrazně lépe. Vše je zatím jednodušší. Systemd je sice složitější, ale také toho umí více, takže to je jiná kategorie, s kterou to nelze srovnávat.
Zklamalo mě ale nastavování firewallu a to především makra, které jdou zanořovat jen obskurdním způsobem v souboru
/etc/pf.conf
Jednoduchý firewall by mohl vypadat takhle. Ve skutečnosti je těch sítí a ip adres je mnohem více a tak je důležité to rozepsat pomocí maker, aby bylo jasné co která ip nebo síť je a dalo se v tom vyznat a ip adresy případně měnit.
net1='"192.168.144.0/24"'
net2='"192.168.145.0/24"'
net3='"10.0.0.0/24"'
ssh_allow= "{" $net1 $net2 $net3 "}"
block in all
table <ssh_access> $ssh_allow
pass in quick on $ext_if proto tcp from <ssh_access> to any port 22
pass out all
pass in inet proto icmp all icmp-type echoreq
Tedy nepřijde mi to lepší než nftables, které také nejsou nic moc na to že je to už třetí předělávka.
Nyní si stačí pohrát s jaily a může se to začít používat. Zítra stroj nesu do serverovny. Jsem zvědav, jestli se některých linoxových záhad zbavím, nebo mi to pomůže vypátrat skutečné jádro problému. Obecně mi přijde, že co je jiné jak v Linuxu, tak je to hezčí a jednodušší a zjevně také lépe odzkoušené, protože se to měnilo jen minimálně.
-
Zvláštní. Mám řadu různých strojů s Debianem. A - pokud nevypadne něco jinde, typicky konektivita nebo napájení - tak o nich ani nevím.
Jeden HW, 24 CPU, kontejnery v lxc, uptime 2 roky. Jiný 16 CPU v QEMU, kontejnery v dockeru. Několik dalších HW nebo VPS bez kontejnerů. VPS od vpsfree, kontejnery v lxc - ten padá asi nejvíc, ale protože se jim něco sype ve vpsAdminOS. U všech se o HW stará někdo jiný - nejspíš ví, jak na to a čemu se vyhnout? A nejspíš taky mají nějaký HW firewall před serverem pro prevenci DOS - ani nevím :) Když dojde RAM, OS sestřelí největší proces. Pokud je to service, v systemd jde nastavit, jestli má znovu nastartovat (výchozí stav je, že ne)..
-
Zvláštní. Mám řadu různých strojů s Debianem. A - pokud nevypadne něco jinde, typicky konektivita nebo napájení - tak o nich ani nevím.
Jeden HW, 24 CPU, kontejnery v lxc, uptime 2 roky. Jiný 16 CPU v QEMU, kontejnery v dockeru. Několik dalších HW nebo VPS bez kontejnerů. VPS od vpsfree, kontejnery v lxc - ten padá asi nejvíc, ale protože se jim něco sype ve vpsAdminOS. U všech se o HW stará někdo jiný - nejspíš ví, jak na to a čemu se vyhnout? A nejspíš taky mají nějaký HW firewall před serverem pro prevenci DOS - ani nevím :) Když dojde RAM, OS sestřelí největší proces. Pokud je to service, v systemd jde nastavit, jestli má znovu nastartovat (výchozí stav je, že ne)..
když neaktualizuješ, tak se není co divit, že ti vše funguje :), s uptime 2 roky a debianem bych se mohl nechlubil.
-
když neaktualizuješ, tak se není co divit, že ti vše funguje :), s uptime 2 roky a debianem bych se mohl nechlubil.
Všude jsou unattended-upgrades, dokonce ani to nedělá problémy. Jen ten restart se musí udělat ručně, nový kernel je 1-2x do roka :)
-
když neaktualizuješ, tak se není co divit, že ti vše funguje :), s uptime 2 roky a debianem bych se mohl nechlubil.
Všude jsou unattended-upgrades, dokonce ani to nedělá problémy. Jen ten restart se musí udělat ručně, nový kernel je 1-2x do roka :)
takže ve výsledku ani nevíš, která služba se ti po její aktualizaci restartovala a která ne, pořád se mohou používat už dávno aktualizované a opravené kódy jen proto, že si je drží proces.
Je to rozhodně lepší než nic, ale prakticky ti to stejně nedává žádné záruky, restart tady není jen o tom, aby se aktualizoval kernel, ale aby se znovunačetly všechny programy. Už dávno mě přestalo bavit vyplňovat bug reporty na balíčky, které nerestartovaly daemony při jejich změnách.
-
[...] restart tady není jen o tom, aby se aktualizoval kernel, ale aby se znovunačetly všechny programy [...]
https://manpages.debian.org/bookworm/needrestart/needrestart.1.en.html
-
[...] restart tady není jen o tom, aby se aktualizoval kernel, ale aby se znovunačetly všechny programy [...]
https://manpages.debian.org/bookworm/needrestart/needrestart.1.en.html
ano, ano, ale je to zase takové částečné řešení, pokud aplikace nedrží už soubor otevřený, ale pouze si ho načetla, nebude to needrestart detekovat. Jak jsem psal, už jsem u spoustu balíčků právě kvůli tomu vyplňoval kdysi reporty, teď debian používám hodně sporadicky, takže nevím, kam se to posouvá.
-
Tak jsme na FreeBSD přešli zatím s jedním serverem. Na zkoušku.
Používám jaily s vnet. Konfigorování přímo pomocí /etc/jails.conf a jejich includů.
Umí to vše co používáme na Linuxu.
Postřehy.
- Konfigurace je mnohem kratší a přehlednější. Vše důležité je v rc.conf pf.conf a jails.conf, každý kontainer má konfigurák jen na jediný řádek, kde nastavuji ip, jinak si bere defaultní hodnoty z jals.conf. Konfigurák každého jailsu se automaticky includuje do jails.conf . Vše co se v jailech opakuje (jako různé sety sety ip adres pro firewall) se includuje z fyzického stroje z namountovaného podadresáře. Tím je konfigurace hrozně krátká a přehledná a změna se bude dělat na jednom místě pro všechny jaily.
- Příkazy jsou pro mne jednodušší a intuitivnější (tedy pokud se liší), tedy alespoň subjektivně.
- Lepší dokumentace a jsou dostupné knížky, které to dobře popisují
- Např. nastavování firewallu zvládli v Linuxu za dobu co pamatuji již třikrát (chains, iptables, nftables). Ve freebsd funguje pořád stejně a stále za dnešním Linuxem v ničem nezaostává. Přijde mi, že na Linuxu se věci občas zbytečně komplikují, protože si někdo jen honí ego, musí něco předělat a zkomplikovat.
Linux ale opouštět nebudeme, ale nejspíše na dvou strojích bude freebsd. Jako první chci převést na freebsd databázi. Na novějších Linuxech nejsem schopen dosáhnout stejné spolehlivosti jaké jsem dosahovali v době openvz. ZFS na Linuxu má pro databázi mizerný výkon a ničí disky pomocí write ampplifation. Obvyklé rady jak nastavit ZFS a databázi zabírají jen málo. A ani ext4 není žádný zázrak. Clonování hlavní databáze se občas záhadně a bezdůvodně zpožďuje. Možná za to Linux nemůže, ale myslím že je slušná šance, že tyto potíže prostě na freebsd nebudou. Jako souborový systém pro databázi volím na freebsd ufs. Možná mne použití freebsd objasní co je na Linuxu špatně nakonfigurované. Možné to prostě vyřeší vhodnější defaults a já je pak budu třeba schopen uplatnit zpětně i na Linuxu.
-
Jako souborový systém pro databázi volím na freebsd ufs.
Tak hlavně často zálohuj a modli se, aby neklekla UPS. :-X ::)
-
Jako souborový systém pro databázi volím na freebsd ufs.
Tak hlavně často zálohuj a modli se, aby neklekla UPS. :-X ::)
Alze databáze se zálohuje přes clonování. Clon lze snadno změnit na hlavní node.
Clon také mohu pravidelně zastavovat a dělat z něj zálohy jak je libo. Překvapivě rsync záloha není ani pomalejší než kopírování zfs snapshotu na jiný disk a počítač.
Ač se o tom skoro nepíše, pro databáze kde se hodně zapisuje nebo updatuje, zfs a obecně copy on write není úplně nejlepší. Je ale pravda, že ten overhead by teoreticky měl být mnohem menší než co jsem zaznamenal já. Žádná rada výrazně nepomůže. Jsem zvědavý jaký bude na freebsd.
Pro nastartování klonování, nebo noční zálohy, UFS umí nativně snapshot. Copy on write je ale jen dočasné, než se snapshot zazálohuje třeba přes rsync a zruší. Pokud to dělám mimo zátěžovou špičku v podstatě vůbec to nevadí. Také bych si mohl postavit něco jako raid přes síť. Ve freeBSD se to jmenuje HAST. Linux to umí také, ale je to jako obvykle přesložitělé a špatně dokumentované a jmenuje se to DRDB.
ZFS budu používat jen na jiné než databázové jaily, ale vyzkouším to i na clon hlavní databáze, abych porovnal výkon a opotřebení disku s tím co dosáhnu na Linuxu. Kdyby to bylo výrazně lepší než pod Linuxem, tak by některý clon mohl běžet na ZFS a tím by zálohování zjednodušilo. Pokud to bude podobně, musí to zůstat jak to je a zálohy dělat z dočasně zastaveného clonu. Hlavní uhlavního databázového jailu bych chtěl vysokou dostupnost zajistit právě pomocí toho HAST. Dobré je, že vyzkoušet si to mohu naprosto bez rizika na clonech.
-
Ač se o tom skoro nepíše, pro databáze kde se hodně zapisuje nebo updatuje, zfs a obecně copy on write není úplně nejlepší. Je ale pravda, že ten overhead by teoreticky měl být mnohem menší než co jsem zaznamenal já.
...
ZFS budu používat jen na jiné než databázové jaily, ale vyzkouším to i na clon hlavní databáze, abych porovnal výkon a opotřebení disku s tím co dosáhnu na Linuxu.
Asi jsem to varování měl napsat explicitněji - já nějaký overhead, výkon a opotřebení vůbec neřeším. UFS jsem viděl tolikrát neopravitelně zhavarovaný (včetně jeho nefunkční parodie na fsck), že se tomu žádný jiný filesystem nevyrovná.
Příšerný bazmek, už nikdy to nechci ani vidět. Není to použitelné ani na router.
-
Vida, jak to lítá tam a zpátky. My zase cca 50 serverů (ostré, ale i testovky) s BSD budeme rušit. Dozrálo to, když i člověk, co se o to staral řekl, ze komunita vadne.
Místo toho se jde na placený RedHat.
Osobně proti BSD vůbec nic nemám. Blivno mi je z W11, programů "všechnovcludu", předplatného místo trvalých licencí a všudypřítomného šmírování. Ne z BSD, to mi přijde poněkud chcíplé, ale ne ošklivé.
BTW...proč jezdit na jednorožci, když tu je Debian nebo ten RedHat? Pro levicově smýšlející i RedFlag :-D
-
Vida, jak to lítá tam a zpátky. My zase cca 50 serverů (ostré, ale i testovky) s BSD budeme rušit. Dozrálo to, když i člověk, co se o to staral řekl, ze komunita vadne.
Místo toho se jde na placený RedHat.
Osobně proti BSD vůbec nic nemám. Blivno mi je z W11, programů "všechnovcludu", předplatného místo trvalých licencí a všudypřítomného šmírování. Ne z BSD, to mi přijde poněkud chcíplé, ale ne ošklivé.
BTW...proč jezdit na jednorožci, když tu je Debian nebo ten RedHat? Pro levicově smýšlející i RedFlag :-D
Můžete trochu lépe rozvést ty důvody? Jedna z věcí, které jsou mi na freeBSD sympatické je právě to, že se to již moc nevyvíjí. Linux se vyvíjí, ale z mého pohledu vůbec ne k lepšímu. Nejraději bych používal Linux na úrovní z roku cca 2011 + patche openvz. Ale kvůli bezpečnosti a kompilaci novějších programů to moc nejde. Začínal jsem na virtualizaci s vserver, pak přišlo vylepšení s openvz a od té doby se to z mého pohledu spíše zhoršuje.
Samozřejmě ten kdo potřebuje módní nástroje jako docker, musí jít s Linuxem, ale to není můj případ.
-
UFS umí nativně snapshot
Tady bych jen upozornil, že UFS snapshoty fungují pouze pokud NEJSOU zapnuté journaled soft-updates. A standardně je newfs zapne.
Na to jsem náhodou narazil, když jsem se snažil zálohovat dumpem.
-
Můžete trochu lépe rozvést ty důvody? Jedna z věcí, které jsou mi na freeBSD sympatické je právě to, že se to již moc nevyvíjí.
No, k tomu vyvíjení/nevyvíjení bych poznamenal toto:
Trochu se hrabu v programovaní jaderných modulů a device driverů. Protože fušuji do telekomunikací, mám Asterisk a DAHDI. Když jsem se snažil vytvořit vývojové a testovací prostředí, kde bych tytéž věci dělal na BSD i Linuxu (mj. studium jak a proč ty věci fungují), potřeboval jsem zvolit správnou verzi DAHDI, která bude stejná v obou systémech. To abych prostudoval v čem spočívá portace DAHDI z Linuxu na FreeBSD.
V Linuxu jsem zkoušel spoustu verzí DAHDI a spoustu verzí kernelu, resp. různých dister s nějakou specifickou verzí kernelu.
No, jak to říct, prostě v kernel API Linuxu je neskutečný bo*del. Občas se změní jméno nějaké funkce, nějaká funkce je nahrazená jinou, u funkce se změní počet a pořadí parametrů...
Snažil jsem se použít kernel řady 4, ale to se prostě nedalo. Takže teď mám obstarožní Centos 6 s kernelem 2.6 a tam jsem schopen dělat, co potřebuji.
Ve FreeBSD jsou věci, cca od verze 9, pořád stejně. A předtím to tak bylo do verze 8.
-
Můžete trochu lépe rozvést ty důvody? Jedna z věcí, které jsou mi na freeBSD sympatické je právě to, že se to již moc nevyvíjí.
A taky to znamená, že tikety zůstávají dlouho otevřené, dlouho čekáš na radu, komunita se zmenšuje a nevznikají na tom nové projekty.
-
Trochu OT, ja pouzivam pfSense a tom to tiez nejak drhne (https://redmine.pfsense.org/versions/74).
-
Ač se o tom skoro nepíše, pro databáze kde se hodně zapisuje nebo updatuje, zfs a obecně copy on write není úplně nejlepší. Je ale pravda, že ten overhead by teoreticky měl být mnohem menší než co jsem zaznamenal já.
...
ZFS budu používat jen na jiné než databázové jaily, ale vyzkouším to i na clon hlavní databáze, abych porovnal výkon a opotřebení disku s tím co dosáhnu na Linuxu.
Asi jsem to varování měl napsat explicitněji - já nějaký overhead, výkon a opotřebení vůbec neřeším. UFS jsem viděl tolikrát neopravitelně zhavarovaný (včetně jeho nefunkční parodie na fsck), že se tomu žádný jiný filesystem nevyrovná.
Příšerný bazmek, už nikdy to nechci ani vidět. Není to použitelné ani na router.
Dík. Vypadá že je to fakt podstatná slabina. Ne každý je až tak kritický, ale vypadá, že to fakt nemají moc dořešené.
Je fakt, že výpadek napájení se v minulosti přihodil tak jednou za 10 let, nebo spíše méně, ale tak je třeba být připraven.
Je zajímavé pozorovat, jak se o zásadních problémech málo píše. O tom jak je něco dobré je spousta článků a "dokumentace" a tom jak je něco špatné se jakoby všichni stydí psát dokumentovat to. A z toho pak vznikají různé pasti a hypes, kdy je něco populárnější než si zaslouží.
-
Dík. Vypadá že je to fakt podstatná slabina. Ne každý je až tak kritický, ale vypadá, že to fakt nemají moc dořešené.
...
Je zajímavé pozorovat, jak se o zásadních problémech málo píše. O tom jak je něco dobré je spousta článků a "dokumentace" a tom jak je něco špatné se jakoby všichni stydí psát dokumentovat to.
Naprosto smrtící byla kombinace SU+J, tam to zhavarovalo se spolehlivostí snad 99%, pokud neproběhlo korektní vypnutí, přičemž pokud si dobře pamatuju, tak to byl default u newfs při instalaci. ::)
Mimochodem v OpenBSD ty soft updates zlikvidovali jako významnou překážku při dalším vývoji vfs vrstvy (https://marc.info/?l=openbsd-cvs&m=168856997929968) s tím, že to je neudržovatelná věc.
-
Trochu OT, ja pouzivam pfSense a tom to tiez nejak drhne (https://redmine.pfsense.org/versions/74).
nojo, hackeři vymírají a pojídači koláčů neznají nic než Linux
-
Trochu OT, ja pouzivam pfSense a tom to tiez nejak drhne
Proč OT? Nemí pfSense postavené na BSD?
-
Trochu OT, ja pouzivam pfSense a tom to tiez nejak drhne (https://redmine.pfsense.org/versions/74).
nojo, hackeři vymírají a pojídači koláčů neznají nic než Linux
Nj, ale tam to drhne především proto, že zájem o vývoj (relativně) open-source "komunitní" varianty je již drahně let pod bodem mrazu.
-
Ja by som oponoval, ze ak na freebsd v open source robi menej ludi, tak je to naopak lepsie, lebo viacej veci sa da spravit bez toho okoliteho ruchu. Navyse, co som sledoval, tak netflix, sony a dalsie firmy dotuju vyvoj dost slusne, i ked casto nie verejne(firmy nechcu aby ludia vedeli, ze im bezi v nejakej konzole bsd), co je priamo z ust hlavneho vyvojara.
-
Ja by som oponoval, ze ak na freebsd v open source robi menej ludi, tak je to naopak lepsie,
Takže každá část má být ideálně One-man-Show? Dej do kopie Torvaldse, že to všechno dělá blbě a měl to celé dělat sám :-)
Lenoch jeden líná ...komunita mu musí pomáhat. Zajeď za ním, že bys mu radil :-)
-
Takže každá část má být ideálně One-man-Show? Dej do kopie Torvaldse, že to všechno dělá blbě a měl to celé dělat sám :-)
Lenoch jeden líná ...komunita mu musí pomáhat. Zajeď za ním, že bys mu radil :-)
Sledujem vyvoj programovacieho jazyka jai alebo aj odin a sledoval som rozne podcasty o nich a okolo nich a ineho sw a otazka open source prisla na debatu dost casto a generalny konsenzus je taky ze open source(tym nemam na mysli verejny kod ale skor verejne pull / merge requesty) su praveze na skodu a je to zly system. Osobne to vidim totozne. Cim viac ludi sa do niecoho babre, tym viac to stoji, tym viac sa debatuje, tym menej roboty sa urobi. Kazdu cast kodu by mal mat na starosti jeden clovek ktory to cele vedie a komunia by sa do kodu vobec nemala starat, len davat namietky, rady, a podobne. Diskusia je fajn ale kod by mal mat gatekeepera. Ono aj ani do linuxoveho kernelu si nemoze hocikto len tak commitnut zmeny.
-
Jenže tady motáte více věcí dohromady.
Nechat vše na jednom člověku je cesta do pekel a vyhoření, zabřednutí do stereotypů a opakování chyb. To, co vlastně chcete je hierarchické vedení. Chcete jednoho člověka zodpovědného za určitý subsystém, který rozhoduje o tom, co a jak se bude dělat a má na to lidi, kteří to zrealizují.
-
Takže každá část má být ideálně One-man-Show? Dej do kopie Torvaldse, že to všechno dělá blbě a měl to celé dělat sám :-)
Lenoch jeden líná ...komunita mu musí pomáhat. Zajeď za ním, že bys mu radil :-)
Sledujem vyvoj programovacieho jazyka jai alebo aj odin a sledoval som rozne podcasty o nich a okolo nich a ineho sw a otazka open source prisla na debatu dost casto a generalny konsenzus je taky ze open source(tym nemam na mysli verejny kod ale skor verejne pull / merge requesty) su praveze na skodu a je to zly system. Osobne to vidim totozne. Cim viac ludi sa do niecoho babre, tym viac to stoji, tym viac sa debatuje, tym menej roboty sa urobi. Kazdu cast kodu by mal mat na starosti jeden clovek ktory to cele vedie a komunia by sa do kodu vobec nemala starat, len davat namietky, rady, a podobne. Diskusia je fajn ale kod by mal mat gatekeepera. Ono aj ani do linuxoveho kernelu si nemoze hocikto len tak commitnut zmeny.
Pochybuji, že se to dá generalizovat - znám vývoj databází - a když bych se podíval na MySQL, SQLite, Firebird a Postgres, tak každá z těch databází má úplně jiný typ vývoje, jinou komunitu, a v podstatě platí, že to, co je někdy výhoda, je v jiné chvíli nevýhodou. V 90 měl MySQL nebo Firebird výrazně větší progres než Postgres, právě díky relativně malému týmu. Dneska do Firebirdu skoro nikdo nejde, právě kvůli jeho malému týmu. SQLite je skoro one man show, ale zas jak je to výrazně menší projekt, tak to zase tolik nevadí, a nikdo ani nečeká větší progres. Postgres je tou komunitou, kde každý kecá do všeho, a vývoj jde pomalu - ale "každý si jede za své" a není až tak velký problém s financováním projektu - což třeba u MySQL nebo MariaDB problém je. Navíc s vývojem Postgresu se setkalo mnohem víc lidí, takže je větší šance najít talenty. Vývoj programovacího jazyka (navíc, který jede nad llwm) je relativně "jednoduchá" omezená záležitost. A souhlasím, že je pro konzistenci programovacího jazyka lepší menší vývojový tým než větší. Ale je to možné, že velkou část těžké a špinavé práce se udělá v týmu llwm.
-
Vývojáři jsou vždy základem komunity. Bez vývojářů se základ komunity zužuje a uživatelska zkušenost vadne. Vedlejším dopadem je málo odvozených projektů. Ostatně FreeBSD pomalu mizí, třeba naposled FreeNAS / TrueNAS už BSD nahradili.
-
Vývojáři jsou vždy základem komunity. Bez vývojářů se základ komunity zužuje a uživatelska zkušenost vadne. Vedlejším dopadem je málo odvozených projektů. Ostatně FreeBSD pomalu mizí, třeba naposled FreeNAS / TrueNAS už BSD nahradili.
Pro mne osobně jsou důležité jen tři věci.
- Jestli existuje balíček, nebo jde kompilovat software, který používám
- Vydávají se bezpečnostní záplaty na core funkce a jádro - je jasné, že jich nebude potřeba mnoho, neb se věci moc nemění
- Je možné pořídit hardware na server - veškerý stávající hardware funguje bez potíží
To že se to moc nemění a nevyvíjí je pro mne podstatná výhoda. Protože vše pro mne podstatné to umí a vývoj nových věcí představuje zvýšený počet problémů, bezpečnostních děr a nestability.
To je právě to proč se mi Linux nelíbí. Než se pořádně odladí jedna věc, už je zastaralá. V androidu je to ještě výrazně horší tam má všechno kvůli tomu jepičí život.
Já potřebuji, aby to co udělám bez větších změn fungovalo 10 a více let a bylo neměnné a stabilní.
Samozřejmě ty jednotlivé aplikace upgradovat budu, ale zásahů chci co nejméně.
A v tomto ohledu je pro mne Linux horší volba. V Linuxu je moc lidí, moc možností a moc lidí si honí ego tím, že věci pro mne nesmyslně komplikují a to jen s minimální přidanou hodnotou.
Za dobu co pamatuji se třikrát předělávalo jak funguje firewall a kontejnerová virtualizace. Celková spolehlivost je horší, nebo alespoň není lepší než před 15 lety. Pro mne Linux jen bobtná bez reálného užitku.
Linux nehodlám úplně opouštět, takže se případně budu moci třeba za 15 let vrátit, pokud by freebsd úplně umíralo.
Nepotřebuji, aby se uživatelská zkušenost zlepšovala. Mě bohatě stačí, když se nebude zhoršovat, jak je to bohužel z mého pohledu u Linuxu. Uživatelská zkušenost na dekstopu se samozřejmě zlepšuje. Ale pro mé použití na serveru je to nyní horší než to bylo a moc se to na můj vkus mění.
-
UFS umí nativně snapshot
Tady bych jen upozornil, že UFS snapshoty fungují pouze pokud NEJSOU zapnuté journaled soft-updates. A standardně je newfs zapne.
Na to jsem náhodou narazil, když jsem se snažil zálohovat dumpem.
Prosím jak mohu zjistit nastavení UFS ? Např. u odolnosti proti výpadkům elektřiny se to hodně liší, podle toho jaké žurnálování je zapnuté. Ale nevím jak to zjistit. Často se píše že UFS SU+J, bylo fuj, ale dost možná je to hlavně v bug v jedné verzi freebsd, což už bylo dávno opraveno. Někdo jiný si zase pochvaluje jiný typ journalování, ale nikdo jsem se o tom nenačetl nějaké shrnutí.
A pokud nepoužijí journálování vůbec, mělo by to znamenat, že oprava po výpadku bude trvat déle - musí projít vše, ale nekonzistence by nastat neměla a mělo by to být spolehlivější než oprava na pozadí s journalováním. Také je trochu lepší výkon.
Pokud jednou za deset let vypnout proud. Počítám s tím, že budu opravovat ručně a déle, ale nechtěl bych aby z dat byla fašírka. Pokud se několik posledních záznamů neuloží vůbec nevadí, ale nemělo by se poškodit nic předešlého.
-
Prosím jak mohu zjistit nastavení UFS ?
Zkus manuál (https://man.freebsd.org/cgi/man.cgi?query=tunefs&sektion=&manpath=freebsd-release-ports). ;D
-p Show a summary of what the current tunable settings are on the
selected file system. More detailed information can be obtained from the dumpfs(8) utility.
Počítám s tím, že budu opravovat ručně a déle, ale nechtěl bych aby z dat byla fašírka.
No, já bych počítal s tím, že neopravíš nic. Zálohovat, zálohovat, zálohovat.
-
Prosím jak mohu zjistit nastavení UFS ? Např. u odolnosti proti výpadkům elektřiny se to hodně liší, podle toho jaké žurnálování je zapnuté. Ale nevím jak to zjistit. Často se píše že UFS SU+J, bylo fuj, ale dost možná je to hlavně v bug v jedné verzi freebsd, což už bylo dávno opraveno. Někdo jiný si zase pochvaluje jiný typ journalování, ale nikdo jsem se o tom nenačetl nějaké shrnutí.
A pokud nepoužijí journálování vůbec, mělo by to znamenat, že oprava po výpadku bude trvat déle - musí projít vše, ale nekonzistence by nastat neměla a mělo by to být spolehlivější než oprava na pozadí s journalováním. Také je trochu lepší výkon.
Pokud jednou za deset let vypnout proud. Počítám s tím, že budu opravovat ručně a déle, ale nechtěl bych aby z dat byla fašírka. Pokud se několik posledních záznamů neuloží vůbec nevadí, ale nemělo by se poškodit nic předešlého.
tunefs -p /dev/device nebo tunefs -p /mountpoint
LolPhirae má pravdu v tom, že téměř žádný z těch režimů UFS (bez ničeho), UFS SU, UFS SU+J není tak odolný proti náhlým výpadkům hw nebo napájení jako třeba ext4 nebo ZFS.
Nejbezpečnější varianta z tohohle hlediska je UFS bez dalších povolených fíčur.
SU vzniklo kdysi primárně kvůli dvěma věcem - zrychlení metadatových operací s inody a rychlejší fsck, kdy to nekontroluje všechno. Ty metadatové operace se zrychlí proto, že se při zápisu dělá fs reordering a sdružuje je a řeší jejich závislosti. Hlavně na točivých discích s dlouhou příst. dobou to přineslo razantní zrychlení při operacích s mnoha soubory v rozsáhlejších adr. strukturách a zvýšení propustnosti při přístupu z více procesů.
Nevýhodou je pak to, že se to proti normálnímu orderingu v UFS ty operace zpožďují (klidně i desítky vteřin) a při náhlém výpadku to může ovlivnit hodně souborů, do kterých se zapisovalo.
SU+J je přidání fixního 16MB žurnálu pro metadatové operace (tváří se jako soubor .sujournal v rootu), který hlavně dál zrychluje kontrolu a opravu na větších úložištích.
Bohužel se může stát, když se správně trefíte (aspoň když jsem to před pár lety testoval), že zatímco s UFS máte zasažených pár posledních souborů, co se nedopsaly. S UFS SU je jich razantně víc a u SU+J jich značná část skončí úplně prázdných, což pravděpodobně souvisí s tím, že to fsck rychle vymete a ihned uvolní data.
Takže, jestli si pro váš workload řeknete, že nevadí delší fsck, a případný pokles výkonu nebude zásadní, tak vypněte SU (tunefs -n disable /dev/neco).
Ještě je tam další režim, geom journal. A to je ještě něco jiného, to udělá v podstatě virtuální zařízení (jako dm v Linuxu), kde se pak prování žurnálování na úrovni bloků. Filesystém je nad tím, všechny zápisy jdou přes žurnál.
Vždycky mi to přišlo jako hack, co ten primární problém moc neřeší.
Nicméně, jestli si to pamatuju dobře, tak s LolPhirae jsme o tomhle přesně mluvili. A já jsem trochu oponoval tím, že se sice je to dost blbé (a bylo by fajn, aby i FreeBSD mělo robustní ne-COW systém), ale prakticky vzato jsem žádné tragédie i po výpadcích s SU, kdy bych se z toho nedostal, něměl. Část toho je pravděpodobně klika, část je daná tím, že také hodně závisí na konkrétní aplikaci, jak přesně zapisuje. Jestli používá standardně page cache, nebo O_DIRECT příp O_SYNC. Jestli třeba sama nepoužívá fsync() nebo "jen" fdatasync() atp.
Když tam byla nějaká data, co jsem chtěl mít celá (třeba logy nebo malou db), tak jsem měl mountpoint s vynuceným syncem, což je samozřejmě trochu extrém, protože daň za to pak je, že je to líné jak vandrácká hůl.
Upřímně, za posledních pár let jsem na FreeBSD téměř vždy používal jen ZFS. To, že je součástí systému a plně integrované, mi přišlo jedna z mála výhod, které to má oproti Linuxu, a byl to také hlavní důvod nasazení FreeBSD jako takového.
A také si odhaduji, že to tak má většina uživatelů, což je možná důvod, proč UFS a řešení těch problémů nevypadá jak nějaká extra priorita.
Jinak vcelku extenzivní test ohledně odolnosti je třeba tady:
https://unixdigest.com/articles/battle-testing-php-fopen-sqlite-postgresql-and-mariadb-on-ffs-ufs-ext-xfs-and-zfs.html
Já si pár let zpět dělal něco podobného, byť jen se simulovanými pády QEMU virtuálu s FreeBSD, OpenBSD a Linuxem. Používal jsem dd, případně něco, co jsem si narychlo spácal na testy. Ve smyčce to zapisovalo a modifikovalo soubory, věděl jsem kontrolní součty, takže jsem po opravě fs byl schopen rychle kontrolovat, jak to dopadlo. Zkoušel jsem různé variace přístupů, syncování. Dopadlo to víceméně stejně, jako v linkovaném článku.
Můj závěr byl, že v Linuxu to není třeba extra řešit, na FreeBSD pak ZFS. UFS bez SU jako bezpečnější volba, pokud nějakého důvodu nemůžu, nechci COW. OpenBSD strašně líné, neškláluje se, ale je konzistentní.
-
Jinak vcelku extenzivní test ohledně odolnosti je třeba tady:
https://unixdigest.com/articles/battle-testing-php-fopen-sqlite-postgresql-and-mariadb-on-ffs-ufs-ext-xfs-and-zfs.html
Můj závěr byl, že v Linuxu to není třeba extra řešit, na FreeBSD pak ZFS. UFS bez SU jako bezpečnější volba, pokud nějakého důvodu nemůžu, nechci COW. OpenBSD strašně líné, neškláluje se, ale je konzistentní.
To je hodně zajímavé. Provozoval jsem jeden čas mongo na ext4 na dvou nezávislých strojích a bylo to v jedné konkrétní aplikaci naprosto nepoužitelné. Neustále se to rozsypávalo. Každý měsíc se musela DB restorovat (na druhém stroji to bylo tak jednou za 2 měsíce). Přechod na XFS to zcela vyřešil. Pozdější migrace na FreeBSD/UFS+SU neměla nikdy (je to tak 1,5 roku) problém.
Pravda, je to trochu jiný případ. Nešlo o HW fail, ale o rozsypání dat na běžících strojích. Tím hůř pro ext4. Trochu jsem naivně doufal v nějaký posun od dob ext2, ale tímhle u mne na Linux strojích s DB workloadem definitivně skončil.
-
Prosím jak mohu zjistit nastavení UFS ? Např. u odolnosti proti výpadkům elektřiny se to hodně liší, podle toho jaké žurnálování je zapnuté. Ale nevím jak to zjistit. Často se píše že UFS SU+J, bylo fuj, ale dost možná je to hlavně v bug v jedné verzi freebsd, což už bylo dávno opraveno. Někdo jiný si zase pochvaluje jiný typ journalování, ale nikdo jsem se o tom nenačetl nějaké shrnutí.
A pokud nepoužijí journálování vůbec, mělo by to znamenat, že oprava po výpadku bude trvat déle - musí projít vše, ale nekonzistence by nastat neměla a mělo by to být spolehlivější než oprava na pozadí s journalováním. Také je trochu lepší výkon.
Pokud jednou za deset let vypnout proud. Počítám s tím, že budu opravovat ručně a déle, ale nechtěl bych aby z dat byla fašírka. Pokud se několik posledních záznamů neuloží vůbec nevadí, ale nemělo by se poškodit nic předešlého.
tunefs -p /dev/device nebo tunefs -p /mountpoint
LolPhirae má pravdu v tom, že téměř žádný z těch režimů UFS (bez ničeho), UFS SU, UFS SU+J není tak odolný proti náhlým výpadkům hw nebo napájení jako třeba ext4 nebo ZFS.
Nejbezpečnější varianta z tohohle hlediska je UFS bez dalších povolených fíčur.
SU vzniklo kdysi primárně kvůli dvěma věcem - zrychlení metadatových operací s inody a rychlejší fsck, kdy to nekontroluje všechno. Ty metadatové operace se zrychlí proto, že se při zápisu dělá fs reordering a sdružuje je a řeší jejich závislosti. Hlavně na točivých discích s dlouhou příst. dobou to přineslo razantní zrychlení při operacích s mnoha soubory v rozsáhlejších adr. strukturách a zvýšení propustnosti při přístupu z více procesů.
Nevýhodou je pak to, že se to proti normálnímu orderingu v UFS ty operace zpožďují (klidně i desítky vteřin) a při náhlém výpadku to může ovlivnit hodně souborů, do kterých se zapisovalo.
SU+J je přidání fixního 16MB žurnálu pro metadatové operace (tváří se jako soubor .sujournal v rootu), který hlavně dál zrychluje kontrolu a opravu na větších úložištích.
Bohužel se může stát, když se správně trefíte (aspoň když jsem to před pár lety testoval), že zatímco s UFS máte zasažených pár posledních souborů, co se nedopsaly. S UFS SU je jich razantně víc a u SU+J jich značná část skončí úplně prázdných, což pravděpodobně souvisí s tím, že to fsck rychle vymete a ihned uvolní data.
Takže, jestli si pro váš workload řeknete, že nevadí delší fsck, a případný pokles výkonu nebude zásadní, tak vypněte SU (tunefs -n disable /dev/neco).
Ještě je tam další režim, geom journal. A to je ještě něco jiného, to udělá v podstatě virtuální zařízení (jako dm v Linuxu), kde se pak prování žurnálování na úrovni bloků. Filesystém je nad tím, všechny zápisy jdou přes žurnál.
Vždycky mi to přišlo jako hack, co ten primární problém moc neřeší.
Nicméně, jestli si to pamatuju dobře, tak s LolPhirae jsme o tomhle přesně mluvili. A já jsem trochu oponoval tím, že se sice je to dost blbé (a bylo by fajn, aby i FreeBSD mělo robustní ne-COW systém), ale prakticky vzato jsem žádné tragédie i po výpadcích s SU, kdy bych se z toho nedostal, něměl. Část toho je pravděpodobně klika, část je daná tím, že také hodně závisí na konkrétní aplikaci, jak přesně zapisuje. Jestli používá standardně page cache, nebo O_DIRECT příp O_SYNC. Jestli třeba sama nepoužívá fsync() nebo "jen" fdatasync() atp.
Když tam byla nějaká data, co jsem chtěl mít celá (třeba logy nebo malou db), tak jsem měl mountpoint s vynuceným syncem, což je samozřejmě trochu extrém, protože daň za to pak je, že je to líné jak vandrácká hůl.
Upřímně, za posledních pár let jsem na FreeBSD téměř vždy používal jen ZFS. To, že je součástí systému a plně integrované, mi přišlo jedna z mála výhod, které to má oproti Linuxu, a byl to také hlavní důvod nasazení FreeBSD jako takového.
A také si odhaduji, že to tak má většina uživatelů, což je možná důvod, proč UFS a řešení těch problémů nevypadá jak nějaká extra priorita.
Jinak vcelku extenzivní test ohledně odolnosti je třeba tady:
https://unixdigest.com/articles/battle-testing-php-fopen-sqlite-postgresql-and-mariadb-on-ffs-ufs-ext-xfs-and-zfs.html
Já si pár let zpět dělal něco podobného, byť jen se simulovanými pády QEMU virtuálu s FreeBSD, OpenBSD a Linuxem. Používal jsem dd, případně něco, co jsem si narychlo spácal na testy. Ve smyčce to zapisovalo a modifikovalo soubory, věděl jsem kontrolní součty, takže jsem po opravě fs byl schopen rychle kontrolovat, jak to dopadlo. Zkoušel jsem různé variace přístupů, syncování. Dopadlo to víceméně stejně, jako v linkovaném článku.
Můj závěr byl, že v Linuxu to není třeba extra řešit, na FreeBSD pak ZFS. UFS bez SU jako bezpečnější volba, pokud nějakého důvodu nemůžu, nechci COW. OpenBSD strašně líné, neškláluje se, ale je konzistentní.
Moc děkuji za perfektní rozsáhlé vysvětlení.
tunefs -p /dev/ada0p1
tunefs: POSIX.1e ACLs: (-a) disabled
tunefs: NFSv4 ACLs: (-N) disabled
tunefs: MAC multilabel: (-l) disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j) disabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e) 4096
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: space to hold for metadata blocks: (-k) 6400
tunefs: optimization preference: (-o) time
Takže zbývá případně vypnut SU - soft updates. A možná mohu povolit trim.
Nevím proč, ale mariadb na freebsd a UFS dovede klonovat hlavní databázi cca tak 100 krát rychleji, než na Linuxu.
Když klonování zastavím na 10 minut a pak opět pustím , za jednu vteřinu na freeBSD dožene 100- 150 vteřin. Na Linuxu (ext4 na LVM) tak 1-2 vteřiny a je to dost proměnlivé a občas to klonovat prostě vůbec nestíhá. Nějak se zasekává zpracovávání logu s sql příkazy co se mají provést. Databáze se fláká, ale přitom nestíhá klonovat.
Vyzkouším ještě jak to stejné funguje na FreeBSD pokud použiji pro databázi ZFS. Tam byl na Linuxu se ZFS kromě mizerného výkonu hlavně neskutečné velké zápisy na disky, že by životnost lepšího SSD disku měla být vypotřebována cca za rok. Prostě obrovská write amplifikation, které se nešlo zbavit, experimentování s nastavováním sshift a blocksize pomáhalo jen pramálo. Prostě to pro databázi z hodně zápisy a updaty nedělalo dobrotu. Možná je problém se zarovnáním ZFS na fyzické bloky na disku nebo něco takového.
Vyzkouším to FreeBSD a dám vědět.
-
Odporúčam knižku FreeBSD Mastery: Advanced ZFS od Michael W Lucasa (kúpiť sa dá napríklad na https://www.tiltedwindmillpress.com/product/fmaz/ (https://www.tiltedwindmillpress.com/product/fmaz/)).
Okrem iného tam na pár stranách rozoberá aj optimalizáciu ZFS pre MySQL/PostgreSQL.
-
Odporúčam knižku FreeBSD Mastery: Advanced ZFS od Michael W Lucasa (kúpiť sa dá napríklad na https://www.tiltedwindmillpress.com/product/fmaz/ (https://www.tiltedwindmillpress.com/product/fmaz/)).
Okrem iného tam na pár stranách rozoberá aj optimalizáciu ZFS pre MySQL/PostgreSQL.
Díky. Knížku mám, ale k řešení jak se pod Linuxem se ZFS zbavit write applification mne to nenavedlo.
Nicméně dobrá zpráva pro mne je, že to vypadá, že pod freebsd se výrazná write aplification prostě nekoná.
Tedy mohu provozovat bez obav ZFS.
Měřím to pomocí iostat. Měřím množství přenesených dat vždy za 10 minut = 600 vteřin.
iostat -w 600 -I
tty nda0 nda1 ada0 cpu
tin tout KB/t xfrs MB KB/t xfrs MB KB/t xfrs MB us ni sy in id
0 40 39.5 5906776 227821 42.8 5454707 228138 122 9270042 1104661 0 0 0 0 100
0 15 51.4 28209 1416 51.2 28298 1416 40.2 25716 1009 0 0 0 0 100
0 32 51.9 28138 1427 49.5 29527 1427 40.6 26021 1031 0 0 0 0 99
0 22 51.1 29321 1465 54.9 27304 1465 41.0 23886 956.1 0 0 0 0 100
nda0 a nda1 jsou disky se ZFS v režimu mirror, proto se zapisuje na oba to stejné.
Na nich běží jail, který klonuje hlavní databázi.
ada0 je SATA SSD disk na kterém běží jiný jail, který klonuje to stejnou databázi, používá ale souborový systém UFS +SU .
Obě databáze klonují ty stejná data v reálném čase a já mohu pozorovat o kolik zapisuje ZFS více, když zapisuje ta stejná data.
Write applification tam jen cca 1,4 násobná (mění se v čase) s čímž se dá žít. Tedy disk by měl v pohodě dožít důchodu. Na Linuxu to byly desetinásobky.
Pokud ale provedu příkaz:
sysctl vfs.zfs.txg.timeout=60
vfs.zfs.txg.timeout: 5 -> 60
Tedy změním maximální dobu držení zápisů na disk v paměti z 5 vteřin na 60. Pak naměřím:
iostat -w 600 -I
tty nda0 nda1 ada0 cpu
tin tout KB/t xfrs MB KB/t xfrs MB KB/t xfrs MB us ni sy in id
0 40 39.5 5906776 227821 42.8 5454707 228138 122 9270042 1104661 0 0 0 0 100
0 15 35.0 11371 388.6 33.8 11718 386.2 41.0 12676 508.0 0 0 0 0 100
0 15 52.6 7913 406.1 52.3 7961 406.7 40.6 18653 739.6 0 0 0 0 100
0 15 57.5 7988 448.9 59.0 7803 449.2 40.6 19213 760.9 0 0 0 0 100
0 15 62.4 6880 419.3 52.0 8251 419.3 40.8 19882 792.1 0 0 0 0 100
0 15 64.3 7143 448.3 59.0 7797 449.6 40.9 19778 790.5 0 0 0 0 100
1 106 69.3 6869 464.6 64.1 7422 464.4 40.9 21398 853.7 0 0 0 0 100
0 31 69.3 6654 450.5 68.7 6719 450.8 40.9 20786 830.1 0 0 0 0 100
0 17 67.7 7100 469.7 68.6 7008 469.7 41.1 23351 937.8 0 0 0 0 100
Vypadá to, že ZFS provede méně zápísů než UFS+SU. Tedy write applification je něco jako 0.6 .
Pokud by se za 10 minut zapsalo 1 GB, za hodinu je to 6 GB, za den 12*6=72 GB (v noci zápisy zanedbávám) za rok *365 = cca 26 TB. Tedy disk 2000TB má v podstatě neomezenou životnost.
Odpovídá to i tomu co ukáže
smartctl -a /dev/nvme1
Za dopoledne to ukázalo 12 GB dat.
Recordsize mám na 8K, nastavení mysql jsem zatím nechal defaultní.
V Linuxu byly disky zralé na výměnu po roce, ty nejlepší po několika letech, takže to nebylo moc reálné používat.
Také jsem se dnes dočetl, že writing overhead může zvyšovat to, když se dělá hodně snapshotů.
Doporučuji tak více snapshotů dělat pomocí jediného příkazu, což je efektivnější na zápisy i rychlost.
https://www.reddit.com/r/zfs/comments/u70q9o/deleted_by_user/
Tedy to vypadá, že minimálně v mém případě se přechodem na freebsd vyřeší dva zásadní problémy s kterými jsem se trápil roky. Zpožďování klonovaných databází a špatně fungující ZFS, kterou kvůli tomu nejde použít na hodně zapisující databázi.
Nastavováním freebsd jsem strávil mnohonásobně méně času než Linuxu a výsledná konfigurace je mnohem kratší, přehlednější, tedy lépe udržovatelná. Ale je to částečně tím, že jsem zkušenější. Dobrou knížku o lxc jsem nenašel, o jailech existuje a stojí 10 dolarů....
-
Vypadá to, že jsem objevil ještě další podstatnou výhodu freeBSD. Balíčkoví systém a porty.
Jde o to, že balíčky se aktualizují standardně čtvrtletně. Tedy jsou často jen jednu verzi pozadu oprati nejnovější vydané verzi daného projektu. Tedy běžně mohou být třeba jen 4 měsíce staré. Tedy ideální na nasazení.
Dá se také přejít live větev (podobně jako debian testing), kde jsou i novější balíčky. Tam mohou být staré třeba jen měsíc. Tohle bych asi využil, když dělám nový jail a následně jak se to nasadí a vyzkouší, bych přešel pak už na čtvrtletní aktualizace. Mohu se ale vyhnout tomu, abych začínal na zastaralé větvi.
U debianu jsou balíčky často i 3 roky staré, což je mnohdy fakt nepoužitelné a nezbývá, než si důležité programy kompilovat sám a nebo používat repozitář projektu, ale ten ne vždy existuje. V debian backports téměř nic důležitého není.
Co jsem se koukal tam má balíčky např. s mariadb k dispozici ve třech různých verzích. Když se ukázalo, že s nejnovější jsou nějaké záhadné potíže (to se stalo), prostě nainstaluji balíček se starší verzí a problém dočasně vyřešen.
Také jsou k dispozici např. 3 různé verze Ruby. Nabalíčkované jsou i gemy - obrovské množství.
Debian někdy také nabízí dvě verze, např pythonu a mariadb, ale ve stable jsou vždy mnohem starší a verzí je méně.
No a kdyby bylo potřeba něco ještě novějšího, tak je možné si balíčky sám zkompilovat a vytvořit vlastní repozitář. Na rozdíl od debianu to není přesložitělé. Posun o několik verzí dopředu obvykle nemění závislosti ani patche a drobné změny se dají zvládnout. Ale nemělo by to být hlavně potřeba, protože držet se několik měsíců pozadu je vesměs rozumné.
Někdy děláme i sami drobné úpravy ve zdrojáku, tedy mít jednoduchý způsob jak si to sám kompilovat a vytvářet balíčky se hodí, jen přidám vlastní patche - i kdyby to měla být stejná verze jen s drobnými vlastními úpravami. Ano tohle by šlo realativně jednoduše i v debianu, ale dělat patche na něco 3 roky starého nedává smysl.
-
To už je na tom BSD tak bídně, že se musí snažit dělat skrytou reklamu a nahánět užíváky po rootu?
Že máš balíček maximálně Q starý vůbec nemusí znamenat, že ho někdo korektně udržuje.
-
To už je na tom BSD tak bídně, že se musí snažit dělat skrytou reklamu a nahánět užíváky po rootu?
Že máš balíček maximálně Q starý vůbec nemusí znamenat, že ho někdo korektně udržuje.
Zajímalo by mne, jakým způsobem může někdo špatně udržovat balíček s tři měsíce starými zdrojovými kódy?
Zdrojové kódy byly prohlášeny za stabilní před třemi měsíci.
To může být naopak více problémové, provozovat něco 3 roky starého i když zabalené v balíčku "stabilní", protože málo která chyba je opravdu prohlášena za bezpečnostní hrozbu, aby se vynutil upgrade. A spousta chyb se odstraní jen z vyšší verzí.
-
Jj, odchází jim vývojáři, ale všechno mají ťip-ťop super aktuálni a opravené :-D Používají samoléčitelný kód, tak se i chyby samy opravují :-D
Takže fakt BSDčkáři přišli doplnit stavy :-D
Kdybych se neznal s několika lidmi, kteří BSD dělali na fulltime deset let a sami řekli, že to skomírá, tak bych ti i věřil :-D
-
Jj, odchází jim vývojáři, ale všechno mají ťip-ťop super aktuálni a opravené :-D Používají samoléčitelný kód, tak se i chyby samy opravují :-D
Takže fakt BSDčkáři přišli doplnit stavy :-D
Kdybych se neznal s několika lidmi, kteří BSD dělali na fulltime deset let a sami řekli, že to skomírá, tak bych ti i věřil :-D
Balíčky které potřebuji a všechny které jsem zkoumal jsou aktuální (nebo aktuální za 3 dny s novým čtvrtletím budou) a i kdyby nebyly, umím si je sám připravit, protože to není přesložitělé a 3 roky staré jak v debianu. No zrovna zde mi přijde argument o skomírání docela irelevantní.
Také jde o to, že ti co free BSD používají z vlastního rozhodnutí (a ne rozhodnutí jejich zaměstnavatele), tak nemají potřebu se na to téma hádat někde na fóru a free BSD používají dále. Navenek to vypadá, že freeBSD skomírá, ale věřím že má spousty spokojených tichých uživatelů, kteří komunikují spíše výjimečně.
A spousty problémů a nedokonalostí zvládnout odstranit nebo obejít sami, nebo je to jednodušší než v Debianu nebo Redhatu. Je kuriózní, že freebsd je mnohem konzervativnější (věci zbytečně nemění a nekomplikuje), přesto má ale balíčky novější. No nevýhoda možná je, že je to spíše jako debian testing než stable, ale s výhodou, že se upgraduje (kromě bezpečnosti) jen jednou za čtvrt roku, což je zjevně nutné si ručně pohlídat. Jaké s tím budou dlouhodobě potíže nevím. Debian testing je nutné upgradovat pod dohledem hodně často, což není moc dlouhodobě udržitelné, možná přechodně a pak až vyjde další stable, tak zaparkovat do stable.
Já to vidím tak, že dnes je doba plná hype. Všichni chtějí dělat co je zrovna IN. A freeBSD in není. To já jsem na věci co jsou hrozně IN naopak opatrný, protože to bývá často nafouknutá bublina. Navíc je v té oblasti přetlak a zvýšená konkurence a slepota.
-
Je kuriózní, že freebsd je mnohem konzervativnější (věci zbytečně nemění a nekomplikuje)
Aha. No, mohl bych povyprávět třeba o loňském bezva nápadu pod záminkou opravu "zranitelnosti" "vylepšit" pf firewall posbíráním náhodných commitů z OpenBSD za posledních asi 15 let, přičemž umělci motající se kolem (dnes už prakticky closed source) pfSense jich pár desítek "nedopatřením" vynechali a u dalších si nevšimli, že už to bylo mezitím dávno revertnuto (protože to bylo rozbité), takže rozjebali IPv6 takovým způsobem, že se z toho dodneška ještě úplně nevzpamatovali.
-
Je kuriózní, že freebsd je mnohem konzervativnější (věci zbytečně nemění a nekomplikuje)
Aha. No, mohl bych povyprávět třeba o loňském bezva nápadu pod záminkou opravu "zranitelnosti" "vylepšit" pf firewall posbíráním náhodných commitů z OpenBSD za posledních asi 15 let, přičemž umělci motající se kolem (dnes už prakticky closed source) pfSense jich pár desítek "nedopatřením" vynechali a u dalších si nevšimli, že už to bylo mezitím dávno revertnuto (protože to bylo rozbité), takže rozjebali IPv6 takovým způsobem, že se z toho dodneška ještě úplně nevzpamatovali.
Nic k tomu nemohu najít. Nějaký zdroj informací?
Bych mohl říct, že když se tlačil systemd jako novinka, tak to vedlo i k tomu, že počítač kolikrát ani nenastartoval. Pořád to měnili. Nyní se to dá, ale několik let to bylo rozdrbané.
-
Nic k tomu nemohu najít. Nějaký zdroj informací?
Story začíná zhruba tady úplně zcestnou "zranitelností" (https://www.freebsd.org/security/advisories/FreeBSD-SA-24:05.pf.asc)
a crafted Echo Request packet after a Neighbor Solicitation (NS) can trigger an Echo Reply.
Výsledky po "opravě" viz Bug 280701 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701) a sequel, dodnes je stav nadmíru výtečný, viz např. commenty ke shora nalinkovanému bugu, nebo třeba jako když máte pár mašin za firewallem s NATem, tak pingnout ven na stejný cíl jde jen z jedné Bug 283795 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283795)
Vše v režii matlalů z Netgate, kteří už stihli víceméně zlikvidovat komunitní pfSense.
-
Nic k tomu nemohu najít. Nějaký zdroj informací?
Story začíná zhruba tady úplně zcestnou "zranitelností" (https://www.freebsd.org/security/advisories/FreeBSD-SA-24:05.pf.asc)
a crafted Echo Request packet after a Neighbor Solicitation (NS) can trigger an Echo Reply.
Výsledky po "opravě" viz Bug 280701 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701) a sequel, dodnes je stav nadmíru výtečný, viz např. commenty ke shora nalinkovanému bugu, nebo třeba jako když máte pár mašin za firewallem s NATem, tak pingnout ven na stejný cíl jde jen z jedné Bug 283795 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283795)
Vše v režii matlalů z Netgate, kteří už stihli víceméně zlikvidovat komunitní pfSense.
To si jako ti lidi s netgate rozbili ten svůj proprietární router co prodávají a který je založený na freebsd a nejsou schopni to dát půl roku do pořádku? A jediné řešení je ty jejich příspěvky ručně odstranit?
-
To si jako ti lidi s netgate rozbili ten svůj proprietární router co prodávají a který je založený na freebsd a nejsou schopni to dát půl roku do pořádku? A jediné řešení je ty jejich příspěvky ručně odstranit?
Mě už to ani moc nepřekvapuje, vzpomeňme si, co tahle firma zatáhla za hrůzu do FreeBSD při implementaci Wireguardu (https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/).
Jinak zjevně to podle mých pokusů pořád není ve stavu, v jakém to bylo před nápadem udělat z ICMP(v6) stateful protokol a ty zanesené bugy jsou natolik fatální a způsobující tak bizarní chování v nejrůznějších situacích, že na debugování fakt nemám čas. Přestal jsem to aktualizovat (tedy v případě komunitní verze pfSense není co, již rok a čtvrt nic nevypustili (https://docs.netgate.com/pfsense/en/latest/releases/versions.html)) a tak nějak vůbec nasazovat, protože těmito upstream zoufalostmi domrvili i OPNsense (backport tzv. "oprav" do FreeBSD 14.x) a "vanilla" FreeBSD.
Přitom zrovna na ty routery to bylo výborné. Ach jo. :-X :-\
-
No ten příklad s tím wireguard je také docela hrozný. Co provedou příště? A přitom pro wireguard existují i user space implementace, které je možné použít bez zásahu do jádra.
Mám ale obavy, že do Linuxu mohou přispívat také podobní, komerčně pohánění "experti". Protože se kolim Linuxu toho hodně děje, snadněji se to tam ztratí a asi také neprojde něco až tak hrozné, ale zase případů může být více.
A bohužel psát o takových věcech není moc populární, neb napsat článek na téma "Jak nám zase sprasili kernel" není ničí sen.
Zkusím tedy mé problémy s replikací databází, výrazné, náhodné spomalení SQL dotazů a write aplification na ZFS zopakovat s nějakým jiným Linuxem. Jiné jádro, jiný Linux (ne Debian), bez lxc containru, aby prostě všechno bylo pokud možno jinak. Jestli to bude dělat také.
-
Tak se ukázalo, že na FreeBSD kromě nečinnosti. Když se dlouho neopravuje zjevná chyba nebo se neaktualizuje balíček s bezpečnostním problémem může stát také opak, kdy někdo je nesmyslně horlivý a zanáší nesmyslné chyby a nedodělky a to i pod záminkou bezpečnostních oprav, které ale v podstatě nepředstavují žádnou bezpečnostní hrozbu.
Ta horlivost mi přijde potencionálně nebezpečnější, neb vytvořit si vlastní ports a balíčky je relativně jednoduché včetně vlastních bezpečnostních aktualizací, pokud by vznikla nebezpečná nečinnost.
Tak jako tak, přejít s dvěma servery na FreeBSD je pro mne nyní nejmenší cesta odporu. Řeší to několik záhodným problémů, které máme na Linuxu roky. Ač věřím že ty problémy by šly vyřešit nebo obejít jinak, už se mi do patlání se s Linuxem moc nechce.
Problémy, který mi řeší přechod po FreeBSD
- Na Linuxu mi vzniká se ZFS řádově osminásobná Write amplification. Címš trpí výkon a nelze použít pro hodně zapisující databáze, zničí to disky. Pod FreeBSD zdánlivě stejná konfigurace tento problém nemá. ZFS je možné v mém případě vyladit tak, že má menší opotřebení SSD disků, než jiné souborové systémy a to při zachování výhod jako snapshoty odolnost ZFS. Vypadá to, že ostatní tento problém nemají, ale málo kdo má tak vytížené databáze aby ten problém mohl vůbec zaznamenat.
- U mne je replikace databází po Linuxem nesmyslně pomalá, že replika kolikrát nestíhá. Databáze se fláká, přesto nestíhá. Na FreeBSD, když je potřeba, běží cca 100krát rychleji. Pokud tu stejnou databází rsyncnu freeBSD, okamžitě je po problému.
- I pokud běží databáze v mém případě na ext4 na Debianu stable uvnitř lxc, stabilita není úplně dobrá jako v minulosti. Nemám moc odvahu dát na novější systém hlavní databázi. Databáze občas náhodně přeruší tcp spojení s tím že šla pryč. A podobné nechutnosti. Věřím též, že za některé nedávné pády serveru nemůže hardware ale OS.
Špatně se to ladí, když se to stane možná jednou za rok.
Opět věřím, že by bylo možné to nějak vyladit, ale vypadá, že to prostě na freeBSD nedělá, aniž bych musel cokoli ladit.
A to freeBSD mi fakt přijde hrozně jednoduché a tím i dobře udržovatelné a krásné v porovnání s Linuxem, kde kdejaká firma tlačí své řešení bez řádné dokumentace.
Např. pokud chci nastavit routování uvnitř containeru v Linunxu debianu. Debianní /etc/network/interfaces je totální humus. Další pseudojazyk, který nemá hlavu a patu a je hodně omezující. Nepřišel jsem např. na to jak includnout routovací pravidla z externího souboru, který mi generuje nějaký skript. Tedy na jeden hodně obskurdní způsob jsem přišel, ale je to překomplikovaná nechutnost. Možná by lepší nastavovat síťování kontaineru pomocí systemd, ale to je celé také špatně dokumentovaná nechutnost, navíc není standardem pro debian.
Ve freeBSD si mohu nastavit co mne napadne přímo z jails.conf a mohu inlcudovat co mne napadne. Prostě první co jsem zkusil funguje na jedničku.
V Linuxu je podobně přesložitělé téměř vše. Někdo se zaměří jen na malou část a tu nesmyslně přesložití jen s minimálním benefitem. Připadá mi, jako by si na tom dělal doktorát nebo co.
Nový jail mám nachystaný za 5 minut. Balíčky mají novější verze, takže nemusím ručně kompilovat jako pod debianem. A pokud už budu nucen kompilovat, mohu to dělat pomocí ports, systematicky a vytvořit si vlastní balíčky a repozitář. Kompilovat pak budu jen jednou pro všechny servery a jaily dohromady. Celkový počet závislostí není nic hrozného.
No já jsem už kdysi FreeBSD používal, i když jen jako uživatel. (neinstaloval jsem to) V letech 1999-2004. Vše fungovalo tehdy dobře. Nyní se k tomu zase částečně vrátím.
-
A pokud už budu nucen kompilovat, mohu to dělat pomocí ports, systematicky a vytvořit si vlastní balíčky a repozitář. Kompilovat pak budu jen jednou pro všechny servery a jaily dohromady.
V souvislosti s výrobou vlastních balíčků bych doporučil podívat se na ports-mgmt/poudriere.
Já ho používám pro build balíčků pro postarší embedded hardware. Mám udělaný jail, který je zkonfigurovaný, aby dělal 586 binárky a v něm pak poudrierem buildím balíčky např. pro VIA C3, AMD Geode apod. Ty pak slouží pro aplikace jako GSM brána, ISDN/VoIP gateway, komunikační a terminálový server a tak podobně.
-
A pokud už budu nucen kompilovat, mohu to dělat pomocí ports, systematicky a vytvořit si vlastní balíčky a repozitář. Kompilovat pak budu jen jednou pro všechny servery a jaily dohromady.
V souvislosti s výrobou vlastních balíčků bych doporučil podívat se na ports-mgmt/poudriere.
Já ho používám pro build balíčků pro postarší embedded hardware. Mám udělaný jail, který je zkonfigurovaný, aby dělal 586 binárky a v něm pak poudrierem buildím balíčky např. pro VIA C3, AMD Geode apod. Ty pak slouží pro aplikace jako GSM brána, ISDN/VoIP gateway, komunikační a terminálový server a tak podobně.
Dík. Vím. Porty už jsem zkoušel a podařilo si zkompilovat něco výrazně novějšího než na co byl balíček.
Ale nyní to nemám zapotřebí, neb vše je ve verzi, která vyhovuje. A pokud se jednou rozchozený jail osvědčí, zpravidla pak stačí hlídat jen bezpečnost a pravidelný upgrade není vyloženě nutný. Tedy člověk má na výběr, jestli bude upgradovat čtvrtetně, okamžitě, nebo si udělá vlastní větev portu, kterou si pak pohlídá a upgradovat obvykle nemusí téměř vůbec.
Vrátit si verzi ke kompilování v čase je možné údajně pomocí portdowngrade.
Ta možnost kompilovat a držet si vlastní verze balíčků s automatickým řešením závislostí mi přijde obrovská výhoda a jistota, že případný problém si člověk bude moci opravit sám. Ať už problém vznikne tím, že potřebuje něco nestandardního či novějšího, nebo proto, že oficiální správce balíčků nereaguje dostatečně dobře. Je to tudíž trochu protiargument na to, že FreeBSD je mrtvý, protože vývojáři utíkají. Člověk je totiž mnohem více samostatný v tom co si může udělat sám.
A že by byly rozbité či zastaralé nějaké základní balíčky co se točí kolem základního použití nebo webhostingu je dost nepravděpodobné a těch ostatních moc nebude.
Vlastní balíčky je možné si tvořit i v Debianu, ale vše je tak přesložitělé, že to není běžné.
Ve FreeBSD je to jedna z běžných možností jak to řešit a je to automatizované.
-
Pokud udělám zfs send přes ssh musím hodně výrazně uměle omezit rychlost na méně jak 100 Mbit i když je k dispozici 1 GBbit. , aby to výrazně nedegradovalo výkon ostatních aplikací. A přitom běžný síťový provoz je cca jen 30 Mbit.
A co to způsobuje? Zahlcené disky čtením, slabé CPU s málo jádry, které už nestíhá komprimaci+šifrování SSH?
Disky jsou SSD a i kdyby nestíhaly, jádro by si mělo pohlídat, že tím přehnaně netrpí ostatní aplikace. Jader procesoru bylo hodně. Opět by to mělo hlídat jádro. Zkoušeli jsme snížit priority tomu procesu, omezit io operace a nic nepomáhala až umělé snížení přenášení rychlosti na zhruba desetinu toho co by mělo jít přenést.
Část problémů je určitě hardware. Měnil jsem jednu desku a budu muset nepoužívat jednu integrovanou síťovku a místo ní přidám další. (i tohle ale může být problém ovladače) V ostatních případech to bylo mohlo být Linuxem. Paměti ECC mám. Ono když se to stane u jednoho serveru třeba jednou za rok a příště něco jiného. Nečekaně. Tak je obtížné získat nějaké důkazy. Mám ipmi, takže občas vidím divné hlášky, jako že jádro občas zabije nějaký náhodný proces protože něco v jiném containeru zjevně vyžralo paměť, nebo nějaké nesmysly vypisuje systemd. Nebo selhal ovladač síťovky. (možná je to Intel bug, protože ten dodal ovladač) Nebo kernel panic, což by mohlo a zjevně i bylo hardwarem.
Já jsem asi moc rozmlsanej a i problém v průměru jednou za rok (nucený restart) na jeden server je u mne moc. Protože jak píši 5 let jsem se s tím vůbec nesetkával.
U tech bugu inte lsitovek - je treba obcas nahrat novy firmware. A vubec jednou za cas poupdatovat firmwary vsude mozne po serveru. Neni taky ke skode nechat sjet integrovane diagnostiky a podivat se na jejich logy.
-
Tak teď jsem narazil na roky starý bug v instalaci FreeBSD, který myslím stále není opraven.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258987
I když nějaký patch už tam je.
https://forums.freebsd.org/threads/dev-gpt-efibootx-on-mirrored-zfs-root.85192/
Jde o to, že pokud instaluji na raid1 (klidně na ZFS), tak se mi UEFI boot loader nainstaluje jen na jeden disk ze dvou.
Pokud by tak odešel disk, na kterém je nainstalovalný bootloader, já kvůli tomu nenabootuji.
Další hloupost je, že nainstalovaný systém UEFI mountuje. Když to selže, tak se start předčasně přeruší. A systém zůstane v nepoužitelném stavu i když budu bootovat pomocí např. USB flashky.
Rozbil to někdo moc agilní ve freeBSD verzi 13.0, dříve to bylo dobře a od té doby je to špatně. Je třeba to opravovat ručně. Navíc také netuším jak často se ve FreeBSD updatuje bootloader, potom je to nutné opět opravit.
Nicméně je nutno podotknout, že Debian to má také špatně. Vůbec se neobtěžovali to řešit. Sice podporují instalaci na raid, ale takový raid, který je spolehlivý jako by žádný raid nebyl. V Ubuntu tahle možnost je, ale marně si vzpomínám že měla taky nějakou podstatnou vadu. Ten bug s chybným mountování boot/uefi je v Debianu také trvale.
Tedy možná by se dalo napsat, že co se týče tohoto bugu, freeBSD nám Linuxovatí a padá dolů na jeho úroveň.
Ale výhoda je, že jak je ve FreeBSD všechno jednodušší, problémy se snadněji opravují. V Linuxu je také pravděpodobnější že vám pod rukama změní bootloader a tím vaši nedokonalou opravu rozbijí, protože pak musíte ručně nový bootloader nahrát do druhého oddílu.
-
Jinak zjevně to podle mých pokusů pořád není ve stavu, v jakém to bylo před nápadem udělat z ICMP(v6) stateful protokol a ty zanesené bugy jsou natolik fatální a způsobující tak bizarní chování v nejrůznějších situacích, že na debugování fakt nemám čas. Přestal jsem to aktualizovat (tedy v případě komunitní verze pfSense není co, již rok a čtvrt nic nevypustili (https://docs.netgate.com/pfsense/en/latest/releases/versions.html)) a tak nějak vůbec nasazovat, protože těmito upstream zoufalostmi domrvili i OPNsense (backport tzv. "oprav" do FreeBSD 14.x) a "vanilla" FreeBSD.
Přitom zrovna na ty routery to bylo výborné. Ach jo. :-X :-\
pfSense 2.8.0 CE založený na FreeBSD 15-CURRENT vydaný pred 6 dňami. :D
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html
-
pfSense 2.8.0 CE založený na FreeBSD 15-CURRENT vydaný pred 6 dňami. :D
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html
No, leda kulový... https://www.pfsense.org/download/
-
pfSense 2.8.0 CE založený na FreeBSD 15-CURRENT vydaný pred 6 dňami. :D
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html
No, leda kulový... https://www.pfsense.org/download/
No je to v systémovém update na beta kanálu, jsou tam buildy možná obden. Dělal jsem si jen rychlý test, asi bych to jen tak nedoporučil vzhledem k aktuálnímu stavu. Třeba se teď stává, že na konci toho in-place upgrade (nad kterým je úplně minimální kontrola) naběhne nový kernel a nevidí žádné virtio ani e1000 emulované síťovky ani virtio disky :)
Dá se z toho dostat jen tak, že se nabootujete starý, zálohovaný kernel.old s novým userlandem. Takže to sice emituje spoustu hezkých hlášek, ale aspoň se dostanete ze smyčky rebootů a můžete se tam třeba přihlásit. Někteří jiní odvážlivci mají podle všeho zas vcelku pravidelné kernel panicy i když jim to naběhne se všemi drivery (např. na Netgate krabičkách).
Dál jsem to nezkoumal, ale přide mi to spíš jako alfa než beta. Stejně jako nechápu, proč nepoužívají na updaty bootenv, když je to na ZFS rootu.
-
Dělal jsem si jen rychlý test, asi bych to jen tak nedoporučil vzhledem k aktuálnímu stavu.
Já si nemůžu pomoct, ale provozovat něco na -CURRENT verzi FreeBSD nesvědčí o přílišné příčetnosti vývojářů. Jinak samozřejmě ten obrovský odliv testerů po tom, co předvedli s Plus variantou kdysi dostupnou pro "lab" nasazení zdarma je logicky vidět. Fakt to jde hodně z kopce.
proč nepoužívají na updaty bootenv, když je to na ZFS rootu.
Protože ty jsou pouze v placené verzi. ::)
-
Vůbec ten vývojový model je úplně postavený na hlavu - polomrtvá komunitní verze a testujeme na platících zákaznících. ::)
-
Já si nemůžu pomoct, ale provozovat něco na -CURRENT verzi FreeBSD nesvědčí o přílišné příčetnosti vývojářů. Jinak samozřejmě ten obrovský odliv testerů po tom, co předvedli s Plus variantou kdysi dostupnou pro "lab" nasazení zdarma je logicky vidět. Fakt to jde hodně z kopce.
Taky to na mě trochu působí, i přesně po tom už zmíněném cirkusu s kernelovým Wireguard driverem, který upstreamovali.
Na -STABLE byla, myslím, založená poslední větev CE 2.6.x tři roky zpátky, komerční verze podobně. A taky by mi asi přišlo logičtější udržet se toho a případně backportovat z -CURRENT jen nějaké zásadní fíčury. Ale samozřejmě neznám jejich přesnou motivaci k tomuhle kroku, ani jestli mají nějaké své vývojáře, co by se tím případně mohli zabývat.
proč nepoužívají na updaty bootenv, když je to na ZFS rootu.
Protože ty jsou pouze v placené verzi. ::)
Aha díky, toho jsem si nevšiml.. ;) Jako chápu, že chtějí prodávat předplatné a škatule, na druhou stranu mi to přijde trochu zvrácené, zvlášť při testování v téhle formě.
Jinak, už jsem teď dohledal, co tam v té nové větvi 2.8.x je vlastně za potíž. Ty virtio věci i e1000 z QEMU chodí, ale z nějakého důvodu vše jen v legacy PCI (ne express) variantách.
Tzn. musel jsem v libvirt předělat testovací virtuál na model s čipsetem i440FX místo Q35, model síťovky z e1000e přehodit na e1000, nastavit pci bus na 0x00 atd. Pak už se to chytlo.
Já to mám naštěstí víceméně na své blbnutí.
-
Já to mám naštěstí víceméně na své blbnutí.
Nojo, na blbnutí asi dobrý, ale např. ta komerční varianta je v testovacích virtuálech naprosto nepoužitelná, protože přidání/odebrání síťového rozhraní (nebo třeba výměna síťové karty) zlikviduje registraci (licenci) - viz např. 1 (https://forum.netgate.com/post/1080603), 2 (https://forum.netgate.com/post/1197853).
Už to "řeší" léta zcela bezvýsledně, a mám dojem, že o žádné řešení ve skutečnosti nestojí. Takovouhle pitomost u routeru, to vymyslela opravdu velká mozkovna. ::)
-
jejich přesnou motivaci k tomuhle kroku, ani jestli mají nějaké své vývojáře, co by se tím případně mohli zabývat.
Nějaké oficiální bláboly k motivaci jsou zde (https://www.netgate.com/blog/pfsense-software-is-moving-ahead). Ono to leccos vypovídá (i) o (již zde diskutovaném) vývoji FreeBSD jako takovém. Na jednu stranu backporty opravy zatažených chyb se nějak moc nekonají, na druhou pak někomu lupne v kouli a pod záminkou "zranitelnosti" rozdrbe funkční věc několik verzí FreeBSD zpět.
avoid more complex and larger volumes of work any time pfSense software should change to a newer FreeBSD base.
No, co k tomu říct - ve výsledku to je rozbité tak nějak průběžně a permanentně, protože jinak by s tím bylo moc práce, hmmm... tohle asi fakt není nic pro mě a produkční nasazení kdekoliv. Ale jinak "přínosem" (a celkem si troufnu říct, že hlavním motivem) je to, že jiné projekty založené na FreeBSD (především OPNsense) s tím mají práci navíc, protože si ty backporty do -RELEASE verzí musejí dělat sami.
-
Nějaké oficiální bláboly k motivaci jsou zde (https://www.netgate.com/blog/pfsense-software-is-moving-ahead). Ono to leccos vypovídá (i) o (již zde diskutovaném) vývoji FreeBSD jako takovém. Na jednu stranu backporty opravy zatažených chyb se nějak moc nekonají, na druhou pak někomu lupne v kouli a pod záminkou "zranitelnosti" rozdrbe funkční věc několik verzí FreeBSD zpět.
avoid more complex and larger volumes of work any time pfSense software should change to a newer FreeBSD base.
No, co k tomu říct - ve výsledku to je rozbité tak nějak průběžně a permanentně, protože jinak by s tím bylo moc práce, hmmm... tohle asi fakt není nic pro mě a produkční nasazení kdekoliv. Ale jinak "přínosem" (a celkem si troufnu říct, že hlavním motivem) je to, že jiné projekty založené na FreeBSD (především OPNsense) s tím mají práci navíc, protože si ty backporty do -RELEASE verzí musejí dělat sami.
Jo, super, díky za další info a odkaz na bláboly :)
OPNsense jsem konkrétně nezkoušel, možná se na to také někdy podívám.
Upřímně, mnoho let zpátky jsem tyhle brány dělal víceméně na standardních počítačích s FreeBSD nebo OpenBSD jen se svými skripty, i když možná na některých místech byl PCEngines a léta páně i m0n0wall 8)
Šlo víceméně o to, co jsem tu někde zmiňoval i třeba s TrueNASem vs standardním systémem. Po tom, co jsem řešil třeba pro kamarády x NASů, kde se jim něco podělalo při upgradech TrueNASu a různých migracích, nebo nutnost viset někde na fórech a řešit, co tam nakonec v těch releasech od speciálních distribucí změní nebo ne. Tak jsem si řekl, že to pro mě nemá moc řešit. Pro relativně jednoduché setupy (pár služeb a uživatelů) klidně obětuji web UI s grafíky, práva budu klidně dál nastavovat přes setfacl, nastavím si ručně mailové notifikace atp., ale budu mít relativní klid a predikovatelné upgrady.
A tam, kde chtěli klikat v nějakém SOHO setupu a používat kontejnery, už je Synology.
Stran těch bran/firewallů jsou to v poslední době pak spíš hotová komerční řešení založená na Linuxu nebo OpenWRT.
-
Tak teď jsem narazil na roky starý bug v instalaci FreeBSD, který myslím stále není opraven.
...
Jde o to, že pokud instaluji na raid1 (klidně na ZFS), tak se mi UEFI boot loader nainstaluje jen na jeden disk ze dvou.
Pokud by tak odešel disk, na kterém je nainstalovalný bootloader, já kvůli tomu nenabootuji.
...
Boot z RAIDu a řešení chcíplého disku je obecně bohužel nedořešená potíž i na drtivé většině systémů. Proto jsem už tu už párkrát také zmiňoval, že na kritické systémy mám pořád rád na systém nějaký základní HW RAID řadič nebo VROC od Intelu (bohužel na to je potřeba minimálně server s Xeon Silver a vyššími). Není to jen o správné synchronizaci oddílů, ale i o tom, jak se systém a EFI firmware chová s vadným nebo částečně uhnilým zařízením, než se zavede systém. Pokud to má být blbuvzdorné a třeba ve vzdálené lokaci, tak je řadič pořád výhoda. Při výskytu kritické chyby na disku ho řadič vykopne, používá jen ten párový a špatný kousek už nemá šanci zastavit následný reboot.
Nicméně k tomu vašemu poznatku, ano ty synchronizace je to potřeba řešit manuálně a to i na většině Linuxových systémů.
Já to na FreeBSD NASech a serverech dělal tak, že jsem si udělal skript, co se pouští po updatu sytému.
Jestliže je to standardně nainstalovaný systém přes bsdinstall, kde zvolíte mirror, tak se udělají EFI oddíly s GPT labelem efiboot0 a efiboot1 (dá se případně měnit přes příkaz glabel). U systému s legacy BIOSem je to pak gptboot0 a gptboot1 a samozřejmě pokud máte těch disků v mirrou víc tak i další sekvenčně číslované labely.
Ty jsou pak standardně dostupné v /dev/gpt/efiboot0 atp.
Žádný s těch EFI oddílů nemusí být připojený pro normální fungování systému. Je to nutné připojit pouze pro freebsd-update.
Tzn. pokud chcete, aby se to nezastavilo, když je oddíl nedostupný (odejde první disk), přidejte do fstabu volbu "failok" (to je podobné jako nofail na Linuxu). Teoreticky by se dalo dát i noauto a připojovat ručně před upgradem (ale muselo by se ověřit, jestli nějaký upgrade skript neočekává po prvním bootu nového kernelu, já myslím, že ne a je to potřeba jen před rebootem pro instalaci nového bootloaderu).
A k té synchronizaci.. v podstatě stačí zkontrolovat, že je pro sichr odpojený /boot/efi, kdyžtak ho odpojit. Následně pak porovnat oddíly a případně překopírovat celý EFI oddíl přes dd.. např.
if [ ! cmp -s /dev/gpt/efiboot0 /dev/gpt/efiboot1 ]; then
dd if=/dev/gpt/efiboot0 of=/dev/gpt/efiboot1 bs=1M conv=fsync
fi
Je určitě víc způsobů, jak to udělat - porovnávat md5 hashe, mit následnou kontrolu atp.
Jak si to zapracujete do systému nějakých updatů je pak samozřejmě individuální.
Já mám v periodic (man periodic) obvykle nastavené, že systém denně kontrolují dostupné aktualizace systému a posílá e-mail, když jsou k dispozici. Následně je to stejně manuální spuštění freebsd-update.. v nějakém vhodném čase. Takže skript (který tedy u mě typicky řeší i další věci) není problém. Samozřejmě kdybych těch serverů měl třeba 65, tak to nějak automatizuji.
Další věc pro ty EFI systémy, je otestování, že to opravdu bude nabíhat i s chybějícím prvním diskem.
Záleží pak na konkrétní desce, serveru. Buď má explicitně vytvořené záznamy s odkazem na disk a EFI zavaděč v EFI bootovací tabulce s nějakou prioritou (instalátor bsd vytvoří takový záznam pro první disk), nebo jsou tam typicky také implicitně všechny přístupné disky s ESP oddílem, kde to sáhne po souboru /efi/boot/bootx64.efi (v tomhle případě kopie /efi/freebsd/loader.efi).
Ale na ty implicitní položky a jejich prioritu se nedá někdy úplně spoléhat (některé EFI firmwary to dokonce můžou mít zakázané volbou).
Doporučuji prohlédnout to přes: efibootmgr -v včetně bootovacího pořadí.
To se pak dá případně změnit (volba -o) a případně vytvořit nový explicitní záznam pod tím primárním.
-
Omyl, pardon.
-
Nejdřív jsem chtěl navrhnout Gentoo, protože to vypadalo, že OP se líbí BSD přístup k distribuci. Po přečtení dvou stránek je zřejmé, že problém je jinde.
„Ono je to rozbité a nejde zjistit proč, ono to nefunguje a já nevím proč, ono je to saturované, a nemám páru proč…“ ¯\_(ツ)_/¯
-
Nejdřív jsem chtěl navrhnout Gentoo, protože to vypadalo, že OP se líbí BSD přístup k distribuci. Po přečtení dvou stránek je zřejmé, že problém je jinde.
„Ono je to rozbité a nejde zjistit proč, ono to nefunguje a já nevím proč, ono je to saturované, a nemám páru proč…“ ¯\_(ツ)_/¯
Ono je to ale trochu jinak. To co na starém OpenVZ Linuxovém jádře s ext4 běží 10 let bez problémů má ve stejné konfiguraci na debian stable s lxc a ZFS náhlé záhadné potíže.
A opět střih, to stejné na FreeBSD, potíže opět zmizí.
Většina důvodů proč do FreeBSD nechodit jsou jen pomluvy. A ano i do FreeBSD přispívají dnes novodobí patláci co mohou něco celkem bezdůvodně pokazit a ještě to nasadit jako bezpečnostní opravu nebo do stable větve.
FreeBSD není na všechno, ale já nepotřebuji všechno a to co potřebuji to umí dobře. Žádné nové featury jádra nepotřebuji, jen stabilitu a možnost přeložit i novější aplikace.
Vše co potřebuji FreeBSD umí a vše co se liší je podstatně jednodušší než v Linuxu. Instalace, vytváření a konfigurace kontaineru, automatizace práce z kontainerem, balíčkování, rozdělování disku a používání ZFS. Ladění problémů.
Ono není divu, že v menším rybníce se dá lépe orientovat a pro případ, že nepotřebuji větší, to může být prostě lepší.
Jo jinak gentoo působí sympaticky, ale nevím jestli má smysl do něj investovat čas. Moc serverů na tom neběží a pro domácí stroj je kompilace zbytečné sado maso.
-
if [ ! cmp -s /dev/gpt/efiboot0 /dev/gpt/efiboot1 ]; then
dd if=/dev/gpt/efiboot0 of=/dev/gpt/efiboot1 bs=1M conv=fsync
fi
Další věc pro ty EFI systémy, je otestování, že to opravdu bude nabíhat i s chybějícím prvním diskem.
Záleží pak na konkrétní desce, serveru. Buď má explicitně vytvořené záznamy s odkazem na disk a EFI zavaděč v EFI bootovací tabulce s nějakou prioritou (instalátor bsd vytvoří takový záznam pro první disk), nebo jsou tam typicky také implicitně všechny přístupné disky s ESP oddílem, kde to sáhne po souboru /efi/boot/bootx64.efi (v tomhle případě kopie /efi/freebsd/loader.efi).
Ale na ty implicitní položky a jejich prioritu se nedá někdy úplně spoléhat (některé EFI firmwary to dokonce můžou mít zakázané volbou).
Doporučuji prohlédnout to přes: efibootmgr -v včetně bootovacího pořadí.
To se pak dá případně změnit (volba -o) a případně vytvořit nový explicitní záznam pod tím primárním.
Díky za rady. Možnost porovnávat a kopírovat celou particion takto jednoduše by mne nenapdla. Přidat si to do postupu při updatování/upgradování systému zní rozumně.
-
Díky za rady. Možnost porovnávat a kopírovat celou particion takto jednoduše by mne nenapdla. Přidat si to do postupu při updatování/upgradování systému zní rozumně.
Ano, kopírovat obsah oddílu jde takhle úplně v pohodě a přišlo mi to v dané situaci nejrychlejší.
Taky se ten samotný bootloader reálně neaktualizuje úplně tak často.
Jinak krom samotného efi bootloaderu (/efi/freebsd/loader.efi) tam může být také ještě vedle něj text. soubor loader.env, kde je možné případně změnit nějaké proměnné jako např. rootdev, pokud je pak na jiném disku (nebo ZFS poolu) než ten prvotní zavaděč. Takže když byste tohle chtěl upravovat, je to pak třeba synchronizovat také.
Taky teď koukám na tu podmínku, co jsem v rychlosti napsal, tak by samozřejmě nefungovala, pardon :). Odstraňte si kdyžtak ty hranaté závorky ;)
-
Dík funguje. Příkaz proběhl, partition se zkopíovala za cca 2 vteřiny a vyhnul jsem se i formátování.
do /etc/fstab jsem přidal
/dev/gpt/efiboot0 /boot/efi msdosfs rw,failok 2 2
/dev/gpt/efiboot1 /boot/efi2 msdosfs rw,noauto 2 2
Novou položku v biosu pak vytvořím pomocí
efibootmgr -a -c -l /boot/efi2/EFI/freebsd/loader.efi -L FreeBSD_druhy_disk
V Linuxu, který má úplně stejný problém přidání UEFi záznamu řeším pomocí
efibootmgr --create --disk /dev/nvme1n1p1 --part 1 --label "debian 172e" --loader "\EFI\debian\shimx64.efi"
Ve freeBSD je v manuálová stránka kratší a obsahuje přímo použitelný srozumitelný příklad.
V Linuxu použitelný příklad není a pochopit se to z manuálové stránky moc nedá, člověk musí hledat po internetu a skončí s něčím co je špatně zapamatovatelné a nutí člověka uvádět v cestě zpětná lomítka jako za času MSDosu a navíc ještě zařízení disku. Je taková typická ukázka toho jak mohou být stejné věci ve FreeBSD jednodušší.
Samozřejmě to není zásadní problém, ale v Linuxu je prostě složitější a méně šikovné vše co se od FreeBSD liší a na co jsem kdy narazil. Možností je sice přehršle, ale jedno z vícero řešení je často obskurně zbytečně složité.
-
Abych demonstroval jednoduchost konfigurace FreeBSD a také to může pomoci někomu dalšímu, rozhodl jsem se podělit se svojí konfiguraci.
Konfiguruj síť, firewall, NAT , co se má pustit po startu a také fungování jailů (kontainery).
Vše dělám tak, aby to bylo co nejkratší, přehledné a jedna věc byla jen na jednom místě.
Důležité nastavení je pak obsaženo v těchto několika malých souborech.
/etc/rc.conf - nastavení sítě a toho co se má při startu pustit
hostname="Bdxxx"
keymap="cz.kbd"
# přejmenuji síťovku s jménem igb0, aby bylo jasné, kam připojit kabel
ifconfig_igb0_name="prostredni"
# vytvořím bridge - virtuální switch do kterého se budou zapojovat jednotlivé jaily.
cloned_interfaces="bridge0"
# přidám externí fyzickou síťovku do bridge
# pevná adresa by se dělala takto
#ifconfig_bridge0="inet 89.xxx.xxx.xx/27 addm prostredni up"
# pro získání ip adresy se použije DPHCP
ifconfig_bridge0="addm prostredni SYNCDHCP"
ifconfig_prostredni="up"
# pokud nepoužiji DHCP, musím definovat výchozí bránu
#defaultrouter="89.xxx.xxx.xx"
# sám může být router kvůli NATu
gateway_enable="YES" # sysctl -w net.inet.ip.forwarding=1
Routování mohu přidat takto
#static_routes="net1 net2"
#route_net1="-net 81.XXX.XXX.XXX/29 -interface bridge0"
#route_net2="-net 81.XXX.XXX.XXX/28 -interface bridge0"
sshd_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
jail_enable="YES"
jail_parallel_start="NO"
# seznam kontainerů, které se mají spustit po startu systému
jail_list=""
powerd_enable="YES"
moused_nondefault_enable="NO"
dumpdev="AUTO"
zfs_enable="YES" # zfs mount -a
pf_enable="YES"
pflog_enable="YES
Syntaxe rc.conf spočívá v definování proměnných v shelu. Defaultní skripty pak testují existenci těchto proměnných a podle toho se zachovají.
Hodnoty proměnných bývají shodné s tím, jak by se stejná věc prováděla přímo z příkazové řádky. Tedy např. ipfconfig_bridge0="inet 89.xxx.xxx.xx/27 addm prostredni up" ve skutečnosti provede "ifconfig bridge0 inet 89.xxx.xxx.xx/27 addm prostredni up" . Přidá do bridge0 síťovku se jménem "prostredni" a nastaví ip adresu na virtuální síťovce bridge0.
Takže syntaxe je dobře popsána v manuálových stránkách, mohu si ji nejdříve vyzkoušet z příkazového řádku a stejnou syntaxi použít ve rc.conf. To je velké ulehčení oproti Linuxu, kdy např. konfigurační soubor sítě má úplně jinou syntaxi, než když chceme to síť nastavit ručně z příkazové řádky.
/etc/pf.conf - nastavení firewallu a NATu
# kontrola a reload firewallu: pfctl -vf /etc/pf.conf
ext_if = "bridge0"
# Tady jsou definice společné pro všechny fyzické servery
include "/etc/ovps_shared/pf.conf"
# ukázka v dokumentaci https://docs.freebsd.org/en/books/handbook/firewalls/
nat on $ext_if from 192.168.164.0/24 to any -> $ext_if
block all
pass from { self, 192.168.164.0/24 } to any keep state
# to list table content from terminal: pfctl -t ssh_access -Ts
table <ssh_access> const $ssh_access_set
pass in quick on $ext_if proto tcp from { <ssh_access> } to any port 24
pass out all
pass in inet proto icmp all icmp-type echoreq
Pokud budou mít jaily neveřejný ip adresy, budou z rozsahu 192.168.164.0/24 a fyzický stroj jim bude dělat NAT.
/etc/jail.conf - nastavení kontainerů
$bridge = "bridge0";
$epair = "epair${id}";
# jailům s neveřejnou ip adresou budu dělat NAT
$gateway = "89.XXX.XXX.XXX";
# PATH/HOSTNAME
path = "/jails/${name}/rootfs";
host.hostname = "${name}";
# VNET/VIMAGE
vnet;
# jeden ze dvou nových síťovek vložím do kontaineru
vnet.interface = "${epair}b";
# vytovří se pár síťových zařízení. Jeden se vloží do jailu jeden do bridge
exec.prestart = "ifconfig ${epair} create up";
exec.prestart += "ifconfig ${epair}a up descr jail:${name}";
exec.prestart += "ifconfig ${bridge} addm ${epair}a up";
exec.prestart += "mkdir -p ${path}/etc/ovps_shared";
# firewall pak už bude v containeru. Aby věděl, jakou má ip adresu a název síťového zařízení, vytvořím mu soubor
# pf_local_definitions, který includne
exec.prestart += "echo 'ext_if = \"${epair}b\"\next_ip = \"${ip}\"'> ${path}/etc/pf_local_definitions.conf";
# pro přehled jakou má jaký kontainer ip adresu, uložím ip do souboru v jeho adresáři se jmpénem ip
exec.prestart += "echo '${ip}'> /jails/${name}/ip";
# container má přístup k adresáři /etc/ovps_shared, kde jsou společné konfigurace a definice pro
# všechny kontainery. Nebudu se tak zbytečně opakovat a v případě změn to změním jen na jednom místě.
exec.prestart += "mount_nullfs -o ro /etc/ovps_shared ${path}/etc/ovps_shared";
# níže nastavuji síťování pro jail
exec.start = "ifconfig ${epair}b ${ip} up";
exec.start += "route add -net 81.xxx.xxx.xxx/29 -interface ${epair}b";
exec.start += "route add default ${gateway}";
exec.poststop = "ifconfig ${bridge} deletem ${epair}a";
exec.poststop += "ifconfig ${epair}a destroy";
exec.release = "umount -t nullfs ${path}/etc/ovps_shared";
# STARTUP/LOGGING
exec.start += "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.consolelog = "/var/log/jail_console_${name}.log";
# PERMISSIONS
allow.raw_sockets;
exec.clean;
mount.devfs;
devfs_ruleset = 5;
# každý jail má také konfigurák ve svém adresáři, kde mohu nastavit jméno a ip adresu, nebo jiné
# nastavení která se liší od defaultu výše.
.include "/jails/*/config.conf";
Zde je geniální to, že nastavení, které je pro všechny jaily stejné dám do souboru /etc/jails.conf a to čím se liší dám do
/jails/nazevJailu/config.conf . Konfig jednotlivých jailů tak může být velmi krátký. Natavuji jen jméno a ip adresu.
/jails/nazevJailu/config.conf - konfigurace jednotlivých kontainerů
nazevJailu{
# NETWORKS/INTERFACES
$id = "154";
$ip = "192.168.164.${id}/24";
}
Samotný jail je pak umístěn v adresáři /jails/nazevJailu/rootfs
Pokud někdo vidí nějaké nedostatky, nebo že lze něco udělat ještě lépe, prosím napište.
-
Pokud někdo vidí nějaké nedostatky, nebo že lze něco udělat ještě lépe, prosím napište.
nikde nevidím IPv6... :-)
Trochu bojuji s dualstack (1xIPv4+IPv6/64) + VNET + ISP, který omezuje 1 MAC na 1 NIC. S VNET jsem to bez NAT6 nebo routingu nedokázal rozchodit :-(
-
Pokud někdo vidí nějaké nedostatky, nebo že lze něco udělat ještě lépe, prosím napište.
nikde nevidím IPv6... :-)
Trochu bojuji s dualstack (1xIPv4+IPv6/64) + VNET + ISP, který omezuje 1 MAC na 1 NIC. S VNET jsem to bez NAT6 nebo routingu nedokázal rozchodit :-(
IPv6 neřeším neb nepoužívám. Nicméně v mém případě záměrně není vnitřní síť oddělena od té venkovní. A NAT používám jen proto, aby měly kontainery s neveřejnou ip adresou přístup na internet.
Pokud má kontainer veřejnou ip adresu, nebo pokud by měl ipv6 ip adresu, může komunikovat s vnějším světem napřímo. Tedy kontainer se nastavuje úplně stejně jako by se jednalo o další fyzický stroj připojené do téže sítě jako fyzický stroj. Má i svůj firewall.
Co se týče routování ipv6 a pf mluvilo se v tomto vlákně o tom že je to zabagované. Nevím jestli se vás to týká nebo ne.
-
Pokud někdo vidí nějaké nedostatky, nebo že lze něco udělat ještě lépe, prosím napište.
nikde nevidím IPv6... :-)
Trochu bojuji s dualstack (1xIPv4+IPv6/64) + VNET + ISP, který omezuje 1 MAC na 1 NIC. S VNET jsem to bez NAT6 nebo routingu nedokázal rozchodit :-(
IPv6 neřeším neb nepoužívám. Nicméně v mém případě záměrně není vnitřní síť oddělena od té venkovní. A NAT používám jen proto, aby měly kontainery s neveřejnou ip adresou přístup na internet.
Pokud má kontainer veřejnou ip adresu, nebo pokud by měl ipv6 ip adresu, může komunikovat s vnějším světem napřímo. Tedy kontainer se nastavuje úplně stejně jako by se jednalo o další fyzický stroj připojené do téže sítě jako fyzický stroj. Má i svůj firewall.
Chápu. Tak to máte jiný use-case. Ten můj je spíš takový ten běžný VPSkový - jedna veřejná IPv4 a blok IPv6 a hromada dualstack kontejnerů (u každého jedna veřejná IPv6+priviátní IPv4 s rdr z veřejné). V tuhle chvíli mi to funguje na aliasech (tj. bez VNET), protože NAT6 se mi nechce dělat a routing zase nepodporuje ISP.
Co se týče routování ipv6 a pf mluvilo se v tomto vlákně o tom že je to zabagované. Nevím jestli se vás to týká nebo ne.
Pokud myslíte ten pfsense s CURRENT verzí, tak já používám klasický 14.2-RELEASE, takže problém nemám, alespoň ne s FreeBSD :-)
-
Chápu. Tak to máte jiný use-case. Ten můj je spíš takový ten běžný VPSkový - jedna veřejná IPv4 a blok IPv6 a hromada dualstack kontejnerů (u každého jedna veřejná IPv6+priviátní IPv4 s rdr z veřejné). V tuhle chvíli mi to funguje na aliasech (tj. bez VNET), protože NAT6 se mi nechce dělat a routing zase nepodporuje ISP.
Já mám sice k dispozici více veřejných ipv4. Takže kromě fyzického stroje mohou mít veřejnou i některé jaily, ale běžně to nepoužívám a jaily mají jen neveřejnou ipv4. Protože ipv6 nepotřebuji tak to neřešeím, ale jaily by kromě neveřejné ipv4 rozhodně mohli mít i ipv6. Tedy nevidím v čem je to jiný use case. Podle mne je to typický use case. Netipické možná je, že vše se připojuje jen k jedné počítačové síti jedním kabelem. A tatáž síť je i u uvnitř vytvořeného brigde. Tedy všichni mohou komunikovat se všemi jako by se vůbec nejednalo o jaily. A firewally jsou jen na úrovni samotných jailů. Je to takto jednodušší a nejsem ničím omezován.
Obvykle většinou ostatní vytváří novou síť pro jaily, který je oddělena od venkovní síťe. Jiný use case to ale moc není. On vám totiž stejně nikdo z internetu nemůže jen tak útočit na neveřejnou ip adresu a i kdyby, ip adresy z kterých jsou služby přístupné určuje firewall každého jailu.
-
Protože ipv6 nepotřebuji tak to neřešeím, ale jaily by kromě neveřejné ipv4 rozhodně mohli mít i ipv6. Tedy nevidím v čem je to jiný use case.
Právě protože IPv6 nepouživáte, tak máte jiný případ užití tj. use case a zároveň patrně můžete použít víc MAC adres pro vaše veřejné IP adresy, což někteří ISP neumožňují (Hetzner např.).
On vám totiž stejně nikdo z internetu nemůže jen tak útočit na neveřejnou ip adresu a i kdyby, ip adresy z kterých jsou služby přístupné určuje firewall každého jailu.
Jako že důvěřujete L2 vrstvě?
P.S.: Ale asi už jsem to vyřešil a vše mi běží s VNET vč. public IPv6 a vše na jedné MAC adrese.
-
Právě protože IPv6 nepouživáte, tak máte jiný případ užití tj. use case a zároveň patrně můžete použít víc MAC adres pro vaše veřejné IP adresy, což někteří ISP neumožňují (Hetzner např.).
Kdybych IPv6 chtěl používat, prostě si ji na některém JAILu nastavím a předpokládám, že nemusím nic dalšího měnit.
Ale je fakt, že možné omezení poskytovatele internetu na jedinou MAC mne nenapadlo. Nechápu moc smysl toho omezení v případě, že dává více adres, zjevně si tím něco ulehčuje na úkor zákazníka.
Jak se to dělá? To se vaše síťovka směrem do internetu musí tvářit, že obsluhuje všechny veřejné ip adresy, ale ve skutečnosti je neobsluhuje, ale jen přeroutuje do VNET? To jde?
Jako že důvěřujete L2 vrstvě?
Tomuhle takto nerozumím. Vím jen, že pakety směrem z internetu chodí výhradně z výchozí brány poskytovatele. A ten provoz na jiné než naše veřejné IP adresy nedovolí, leda že by tam měl něco hodně špatně. A to nejen on, ale i další po cestě. (ano obecně se na to spoléhat nelze) Kromě rozumně se chovajícího poskytovatele nás pro jistotu chrání i firewall, který běží i na všech neveřejných ip adresách. Tedy v dalším oddělení sítí nevidím žádný smysl, kromě toho si vše zkomplikovat.
-
Tomuhle takto nerozumím. Vím jen, že ...
Jinak receno, pana Boha si nevidel, ale veris, ze existuje ...
Najdi si neco na tema sourcerouting, napriklad ... to je jeden z milionu zpusobu jak ti dostat na router pakety s destinaci na privatni IP.
-
Tomuhle takto nerozumím. Vím jen, že ...
Jinak receno, pana Boha si nevidel, ale veris, ze existuje ...
Najdi si neco na tema sourcerouting, napriklad ... to je jeden z milionu zpusobu jak ti dostat na router pakety s destinaci na privatni IP.
Jako je fajn si to ověřit a vědět o tom, ale zas třeba stran toho source routingu se to jak na Linuxu, tak na FreeBSD (nevím možná dekády už) ve výchozím stavu ignoruje a musíš to explicitně povolit přes sysctl.
V pf, které máš pak většinou zapnuté v těch jailech, je to tak, že jakmile má paket v headeru IP options (včetně toho SR), tak ho blokuje, pokud neuděláš pravidlo, co to zas explicitně povolí (např. pass in quick on epair4b all allow-opts).
Stejně tak je tam jednoduše použitelný antispoof, co můžeš aplikovat v každém jailu (antispoof for epair4b inet).
-
Tomuhle takto nerozumím. Vím jen, že ...
Jinak receno, pana Boha si nevidel, ale veris, ze existuje ...
Najdi si neco na tema sourcerouting, napriklad ... to je jeden z milionu zpusobu jak ti dostat na router pakety s destinaci na privatni IP.
Tak by mne zajímalo, jak tedy přesně mohu ten útok zopakovat, abych si zkusil útočit sám na sebe.
Když zadám do googlu "example of source route attack", tak to najde jen teoretické tlachání. Nikde žádný příklad, jak se mohu zkusit připojit na neveřejnou ip adresu přes internet, pokud znám veřejnou ip adresu routeru nebo prostě počítače ve stejné lokální síti? Brání něco takový příklad někde uvést?
A nějaký seznam nejpoužívanějších z těch miliónů způsobů by nebyl? Rád bych si zkusil útočit sám na sebe.
Podotýkám, že hlavní obrana je firewall na každém containeru a to i s neveřejnou ip adresou. A oddělení sítě by to zlepšilo jen o to, že nemůže být teoreticky použit router mého poskytovatele.
-
Tomuhle takto nerozumím. Vím jen, že ...
Jinak receno, pana Boha si nevidel, ale veris, ze existuje ...
Najdi si neco na tema sourcerouting, napriklad ... to je jeden z milionu zpusobu jak ti dostat na router pakety s destinaci na privatni IP.
Tak by mne zajímalo, jak tedy přesně mohu ten útok zopakovat, abych si zkusil útočit sám na sebe.
Když zadám do googlu "example of source route attack", tak to najde jen teoretické tlachání. Nikde žádný příklad, jak se mohu zkusit připojit na neveřejnou ip adresu přes internet, pokud znám veřejnou ip adresu routeru nebo prostě počítače ve stejné lokální síti? Brání něco takový příklad někde uvést?
A nějaký seznam nejpoužívanějších z těch miliónů způsobů by nebyl? Rád bych si zkusil útočit sám na sebe.
Podotýkám, že hlavní obrana je firewall na každém containeru a to i s neveřejnou ip adresou. A oddělení sítě by to zlepšilo jen o to, že nemůže být teoreticky použit router mého poskytovatele.
Nemohu se zbavit dojmu, že to jsou takové urban legendy, které se předávají mezi generacemi adminů.
Nicméně, když už se diskuze stočila k tomuto - považuji za naprostou samozřejmost, že je toto ošetřené firewallem na hranici sítě.
V sítích, do kterých tak či onak fušuji, je to zpravidla udělané tak, že je síť připojená přes router s RouterOSem. Ve firewallu se pak zahazují pakety, přícházející WAN interfacem, které při tom mají dst adresu z rozsahu private networks nebo localhostu.
Od toho se odvíjí, že nepoužívám na IPv4 IPsec v tunelovém režimu, protože tam se, alespoň v RouterOSu, resp. asi i v Linuxu, na WAN interface objevují pakety, rozbalené IPsecem, které ale mají adresy z privátního rozsahu. Aby takové, legitimní, firewall dokázal rozeznat od paketů podvržených, je potřeba značkovat a to je vopruz. A zvyšuje to riziko nějaké chyby.
Pokud už potřebuji, aby procházely nějaké pakety od ISP, který nepoužívá sdílené adresy 100.64.0.0/10 (RFC6598), tak tam je pravidlo s explicitní výjimkou.
-
Ono je také rozdíl, pokud zabezpečujete počítačovou síť kanceláře, kde může být třeba jeden server.
Nebo pokud zabezpečujete farmu serverů.
V kanceláři je navíc třeba řešit to, že je možné nějakou chybou připojit i ne úplně dobře zabezpečené počítače. Nebo třeba notebook, tablet či telefon přes wifi, který správce nemusí mít pod kontrolou. Do sítě se také připojují webkamery, tiskárny a další zařízení, které se nemusí vůbec chovat ideálně. Tedy je potřeba to hlídat na tom routeru.
Ale pokud zabezpečuji farmu serverů, tak je snadnější si ohlídat firewall na jednotlivých serverech. A na druhou stranu nechci jeden router, který by se mohl polámat a celou farmu odstavit. Také být úzkým hrdlem přístupu.
-
A na druhou stranu nechci jeden router, který by se mohl polámat a celou farmu odstavit. Také být úzkým hrdlem přístupu.
Hm, takže ty servery se připojují bez routeru?
-
A na druhou stranu nechci jeden router, který by se mohl polámat a celou farmu odstavit. Také být úzkým hrdlem přístupu.
Hm, takže ty servery se připojují bez routeru?
Ano bez routeru v naší správě. Myslím že serverhousing má nějakou redundanci a i kdyby ne, jistě má náhradní zařízení, které je schopen nasadit v řádu desítek minut. Na celou serverovnu jistě má nějaká náhradní. A i konfigurace je pro něj triviální, nebo to dělá denně. Naproti tomu já se routerOS učit nehodlám (když už tak openWRT) a kdyby router dělal jeden z Linuxových strojů, tak jsou to zbytečné náklady, starosti a ten stroj se může polámat a pak nejde nic.
Vím že spousta lidí by téměř vše řešila routerem navíc a zjevně má představu, že všechno ostatní je špatně, ale já mezi ně nepatřím.
-
Ale je fakt, že možné omezení poskytovatele internetu na jedinou MAC mne nenapadlo. Nechápu moc smysl toho omezení v případě, že dává více adres, zjevně si tím něco ulehčuje na úkor zákazníka.
Tak pod pojmem bezpečnost se schová řada nastavení a omezení :-). Mám pocit(?), že Proxmox defaultně také filtruje MAC u VM... Fakt je, že je to jeden ze způsobů jak omezit právě útoky na L2.
To se vaše síťovka směrem do internetu musí tvářit, že obsluhuje všechny veřejné ip adresy, ale ve skutečnosti je neobsluhuje, ale jen přeroutuje do VNET? To jde?
Jde. Ale není to zadarmo. Je to triviální IP redirect :-) Prakticky stačí v jailech mít bránu na IPv6 adresu bridge. Bridge interface zajistí forward na správnou bránu se svojí odchozí MAC :-)
Bylo by asi lepší to napsat v netgraphu a přepisovat MAC, ale nemám to na nějaké extra zátěže, takže zatím mi to takhle stačí. Uvidím, jak se to bude vyvíjet. Možná na to dojde.
Jako že důvěřujete L2 vrstvě?
Tomuhle takto nerozumím. Vím jen, že pakety směrem z internetu chodí výhradně z výchozí brány poskytovatele.
Je to samozřejmě závislé na daném řešení konkrétního ISP. Takže zatímco u Hetznera cizí provoz (snad) není, tak u Akamaie nedávno býval docela čilý ruch (dnes už ne) a na ten interface bych nic nevystrčil, byť to asi nějak ošetřené měli. Ale nevím jak a jak velká je šance, že jim při změnách něco nedopadne. Takže tomu a priory nevěřím. A vytvářet ty jaily s IPv4 na čistě virtuálním bridgi není pro mne žádná komplikace.
-
Jde. Ale není to zadarmo. Je to triviální IP redirect :-) Prakticky stačí v jailech mít bránu na IPv6 adresu bridge. Bridge interface zajistí forward na správnou bránu se svojí odchozí MAC :-)
Aha to bude tohle. Přesměrování adresy na jinou adresu. Výhoda je, že může mít každý jail třeba i svoji virtuální síť. Ten kdo virtuál spravuje může znefunkčnit konektivitu maximálně sobě samému, protože může být od všeho oddělen další virtuální sítí. Vlastní firewall sice mít může, ale to s kterou neveřejnou ip může komunikovat určuje i správce.
Address Redirection
Address redirection is useful if several IP addresses are available, yet they must be on one machine. With this, natd(8) can assign each LAN client its own external IP address. natd(8) then rewrites outgoing packets from the LAN clients with the proper external IP address and redirects all traffic incoming on that particular IP address back to the specific LAN client. This is also known as static NAT. For example, the IP addresses 128.1.1.1, 128.1.1.2, and 128.1.1.3 belong to the natd gateway machine. 128.1.1.1 can be used as the natd gateway machine's external IP address, while 128.1.1.2 and 128.1.1.3 are forwarded back to LAN clients A and B.
Z mého pohledu to ale i věci komplikuje.
Totiž v mém případě mohu kontejnery libovolně stěhovat z jednoho fyzického stroje na druhý kvůli rozložení zátěže a např. odstávce a aktualizaci hardwarového stroje. Stačí když kontainer zastavím, vytvořím a přenesu snapshot a pak jej mohu spustit se stejnou ip adresou jinde. Tedy přesun trvá řádově jen jednotky až desítky vteřin.
Spolu se snapshotem se mi přenese i nastavení jako ip adresa. Firewall je přímo uvnitř kontaineru, tedy přesun nemá na funkčnost vliv. Přesun je tak velmi jednoduchý a blbuvzdorný. Pokud mám ale velkou část bezpečnosti na firewallu fyzického stroje, přesun není tak jednoduchý a musí se to dobře promýšlet. No normálně to asi není tak důležité, ale já potřebuji dostupnost 24/7, poroto jednoduchost a blbuvzdornost přesunu virtuálů je podstatná vlastnost.
U vás je zase podstatné, že poskytovatele konektivity vyžaduje jen komunikaci jen jednu MAC, takže nemáte na výběr.
Je to samozřejmě závislé na daném řešení konkrétního ISP. Takže zatímco u Hetznera cizí provoz (snad) není, tak u Akamaie nedávno býval docela čilý ruch (dnes už ne) a na ten interface bych nic nevystrčil, byť to asi nějak ošetřené měli. Ale nevím jak a jak velká je šance, že jim při změnách něco nedopadne. Takže tomu a priory nevěřím. A vytvářet ty jaily s IPv4 na čistě virtuálním bridgi není pro mne žádná komplikace.
Aby server housing zbytečně ohrožoval své zákazníky nevhodným nastavením, věřím že musí být hloupý a arogantní zároveň. A nebo též nějakým nedopatřením. Není ale v jeho zájmu se takto chovat, protože až většina vzniklých problémů bude stejně řešit on. Ať už jde o možné zneužití IP adres zákazníka, nebo DOS útoky libovolným směrem. Je tedy rozhodně v jeho zájmu pochybný trafik, co není nutný k funkci, odstřihnout co nejdříve. Na rozdíl např. od různé detekce to nic nestojí a přispívá ke zdraví a přehlednosti.
-
Chtěl jsem si vyrobit vlastní jls, který bude uvádět ip adresu i pro vnet a také bude zobrazovat příznat autostart pro různé jaily. Ale objevil jsem již hotový skript, který se jmenuje jmore.
https://vermaden.wordpress.com/2024/11/22/new-jless-freebsd-jails-list-manage-tool/
https://github.com/vermaden/jmore
Aby ti fungovalo i pro mne, tak jsem udělal dvě drobné úpravy.
Na řádku 157 a podobných dalších jsem přidal "/jails/*/config.conf \" aby to prohledávalo mé konfiguráky k jednotlivým jailům, co nemají standardní umístění.
A úplně nakonec jsem vložil:
echo -n "autostart:"
sysrc -n jail_list
Což vypíše jaily, které mají nastavený automatický start při nastartování systému.
jmore nyní vypíše např.:
JAIL JID TYPE VER DIR IFACE IP(s)
---- --- ---- --- --- ----- -----
jail1 3 vnet 14.2-R /jails/jail1/rootfs epair154b 192.168.164.154/24
jail2 11 vnet 14.2-R /jails/jail2/rootfs epair156b 192.168.164.156/24
jail3 5 vnet 14.2-R-p3 /jails/jail3/rootfs epair155b 192.168.164.155/24
autostart:jail1 jail2 jail3
Tedy přesně jak bych si to představoval. Ukazuje to navíc verzi a patchlevel FreeBSD. Líbí se mi, že je to jednoduché a kdybych chtěl vypisovat i něco dalšího, dá se to snadno upravit.
FreeBSD je top právě v té jednoduchosti ! Když si chce člověk něco upravit, tak se v tom nezahrabe.
-
Používám FreeBSD na řadě serverů od roku 2003/2004, včetně (později) Asteriskových ústředen, tedy také přes dvacet let a neměnil bych. Dostal jsem se k tomu tehdy nějak náhodou díky jednomu projektu a nebyl už pak důvod měnit. Veškeré výhody, které byly zmíněny mohu potvrdit. I povahově jsem celkem konzervativní, tak mi přístup FreeBSD k inovacím vyhovuje :)
Za sebe ale vidím jednu zásadní nevýhodu, která možná nebyla ve vláknu zmíněna - protože mi FreeBSD stačí na 90 % serverových potřeb, tak o co více znám FreeBSD, o to méně znám Linux. Jednoduchost a zvyk z FreeBSD mě pak u Linuxu vždy hned na začátku trochu rozhodí... ;D