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é.