Byla vydána (𝕏) nová verze 24.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 24.7 je Thriving Tiger. Přehled novinek v příspěvku na fóru.
Binarly REsearch upozorňuje na bezpečnostní problém PKFail (YouTube) v ekosystému UEFI. Stovky modelů zařízení používají pro Secure Boot testovací Platform Key vygenerovaný American Megatrends International (AMI) a jeho privátní část byla při úniku dat prozrazena. Do milionů zařízení (seznam v pdf) po celém světě tak útočníci mohou do Secure Bootu vložit podepsaný malware. Otestovat firmware si lze na stránce pk.fail. Ukázka PoC na Linuxu na Windows na YouTube.
Mobilní operační systém /e/OS (Wikipedie) založený na Androidu / LineageOS, ale bez aplikací a služeb od Googlu, byl vydán ve verzi 2.2 (Mastodon, 𝕏). Přehled novinek na GitLabu. Vypíchnuta je rodičovská kontrola.
Společnost OpenAI představila vyhledávač SearchGPT propojující OpenAI modely umělé inteligence a informace z webů v reálném čase. Zatím jako prototyp pro vybrané uživatele. Zapsat se lze do pořadníku čekatelů.
Distribuce Linux Mint 22 „Wilma“ byla vydána. Je založená na Ubuntu 24.04 LTS, ale s desktopovým prostředím Cinnamon (aktuálně verze 6.2), příp. MATE nebo Xfce, balíkem aplikací XApp, integrací balíčků Flatpak a dalšími změnami. Více v přehledu novinek a poznámkách k vydání.
Příspěvek na blogu Truffle Security: Kdokoli může přistupovat ke smazaným a privátním repozitářům na GitHubu.
Byla vydána nová verze 14 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v cgitu. Vypíchnout lze podporu rozšíření v Lua.
Byla vydána verze 1.80.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Apple oznámil, že v beta verzi spustil své Apple Maps na webu. Podporován je také webový prohlížeč Chrome. Ne však na Linuxu.
Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 65 tisíc vývojářů. Z Česka jich bylo 710. Ze Slovenska 246.
Zřejmě ho tam už máš automaticky , dříve se používalo LILO jako default a dnes je to Grub (kterej já nahrazuju Burgem protože má hezčí vzhledy) :)
https://www.youtube.com/watch?v=V8btccc-Ecg
grub (lilo) je součást každé linuxové distribuce - i Ty musíš mít nějaký bootloader naistalovaný - v případě buntu to je tuším taktéž grub. Při instalaci druhého (x-tého) linuxu většinou při konfiguraci grubu dojde k automatickému nalezení ostatních OS v PC a k jejímu přidání do konfig.souboru. V opačném případě je nutná ruční úprava - více určitě najdeš na netu - GRUB 2
Konfigurace GRUBu s automatickou detekcí nainstalovaných OS:
# grub-install --target=i386-pc --recheck --debug /dev/sdx # grub-mkconfig -o /boot/grub/grub.cfg
1.1.2015 14:18
David Watzke | skóre: 74
| blog: Blog...
| Praha
Přesně tak, dle tvých otázek stejně soudím na ne příliš zkušeného uživatele a experimentování by mohlo vést k rozdrbání selého systému a dalším dotazům typu Pomooooc ..... :)
Když už, tak bych nejdříve nainstaloval Debian a pak ..buntu - ty mají celkem slušný instalátor, který umí naisnalovat systém vedle již existujícíhc systémů.
Pokud ale jen laboruješ, doporučuji i uvedený postup (takto to používám já při testování různých distribucí). Virtualbox zvládneš v pohodě a nehrozí žádný kolaps systému
Zrovna nedávno jsem si instaloval hybridní počítač (virtuál) s Fedorou a Ubuntu. Na disku jsem udělal jeden oddíl (začátek: na 1 MB, ne hned na začátku disku) a ten naformátoval jako LVM PV. Všechny oddíly (ubuntu, fedora, swap…) mám pak jako logické oddíly (LV) v tom LVM. Zavaděč (Grub) do MBR jsem nechal nainstalovat jen jednu distribuci (tu, co jsem instaloval jako první). Po instalaci druhé distribuce jsem v té první (čí Grub budeš používat je na tobě, ale vyber si jeden) dal update-grub a ten našel jádro i té druhé distribuce (na jiném LVM oddílu) a přidal ho do nabídky – takže si při startu počítače můžeš vybrat.
Dneska to funguje fakt pohodově, takže si takhle můžeš vyzkoušet, kolik distribucí chceš.
Taky si můžeš udělat LV a do něj pomocí dd nakopírovat ISO obraz nějakého instalačního/živého CD nebo DVD a spouštět si ho takhle z disku pomocí Grubu.
1.1.2015 22:54
xkucf03 | skóre: 49
| blog: xkucf03
BTW: LVM má výhodu i v tom, že nemusíš disk dělit „napolovic“ a pak řešit problém, že máš někde moc volného místa a jinde málo. Pro každou distribuci si uděláš LV třeba 20 GB (ono by stačilo i mnohem méně) a další LV pro svoje data… Jednotlivé oddíly můžeš pak podle potřeby zvětšovat.
Proč bys dělil harddisk napolovic jako v minulém desetiletí? Nechápu, proč tento nesmyslný postup přežívá dodnes. Dnes se taková situace řeší pomocí Btrfs subvolumes. Každá distribuce má svůj subvolume, případně má-li být disk šifrovaný, mohou být filesystémy třeba dva (nešifrovaný /boot a šifrovaný zbytek) a na každém z nich oddělený subvolume pro každou z distribucí. (V praxi obvykle volím několik dalších subvolumes, například pro /etc a /var, aby se daly mountovat s různými flagy a podobně.) V bootloaderu pak stačí dát kernelu parametr rootflags=subvol=subvolume_pro_tuhle_distribuci a je hotovo. Zásadních výhod je několik:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
31.12.2014 18:15
1.1.2015 10:56
1.1.2015 17:08
1.1.2015 10:59
1.1.2015 14:08
/home nebo kořen z jiné distribuce.Moje rada se tedy dá obecně shrnout takto: Neděl disk předem na poloviny. Dělení disku patří do minulého desetiletí. V dnešní době existují lepší způsoby, jak sdílet disk mezi distribucemi.
(Ubuntu a Debian jsou asi tak druhá nejhorší a úplně nejhorší možnost, pročež nechápavě kroutím hlavou nad volbou právě této dvojice distribucí. Ale ať tak nebo tak, má rada zcela jistě platí i v takovém případě.)
Btrfs používám a je super (hlavně kvůli snapshotům), ale dokud nebude umět pododdíly jako blokové zařízení, tak to úplně plnohodnotná náhrada za LVM není…
Btrfs nemá být náhrada za LVM. Je svým způsobem ortogonální k LVM. Subvolume není nic jiného než jakási datová struktura na existujícím filesystému, která nemá dopředu přidělené extenty (jako u LVM) ani nic podobného, a může tedy obsazovat prostor dynamicky podle potřeby, stejně jako kterýkoliv soubor, adresář nebo cokoliv jiného ve filesystému. Účel i způsob fungování LVM je zkrátka jiný.
Otázka je, kdy je lepší mít snapshot s rozhraním blokového zařízení, ve kterém se bude v momentě snapshotnutí nacházet nějaký nekonzistentní namountovaný fiesystém, nebo s rozhraním filesystému (o pár úrovní abstrakce výš), ze kterého se dají přímo zkopírovat konzistentní soubory. Já bych voliil tu druhou možnost, ale umím si představit, že kvůli efektivitě by třeba v některých případech (spousta malých souborů na skoro plném filesystému) mohla vyhrát ta první možnost.
Další rozdíl tkví v tom, že LVM snapshot má předem danou velikost a příliš mnoho změněných bloků může způsobit, že snapshotu prostě dojde místo a odpojí se (je-li menší než originál, což by ale člověk očekával, nechce-li udržovat polovinu disku vyhrazenou pro snapshoty). Když snapshotu začne docházet místo, jeho zvětšení zpravidla vyžaduje manuální zásah. To se v Btrfs nestane, protože snapshot je dynamický a místo si prostě alokuje z volných bloků filesystému, stejně jako každá copy-on-write operace. Tedy když začne Btrfs snapshotu docházet místo, začne být opravdu zle, protože tím pádem může dojít místo v celém filesystému. 
(Už nějakou dobu jsem se nedíval, v jakém stavu je hierarchický systém kvót, který (snad) tyto nedostatky vyřeší.) Otázkou zase zůstává, co z těch dvou možností je lepší pro jaký účel.
Mají-li snapshoty rovnou poskytovat konzistentní data (místo nekonzistentního obrazu namountovaného filesystému), pak mi ale bloková zařízení nedávají příliš smysl — vždyť i starší a v některých ohledech vyspělejší ZFS má buď ZVOL (blokové zařízení s checksumy a fault-tolerance, ale bez filesystému, tj. určené k použití jinými filesystémy) nebo filesystém (ano, podivně přetížený pojem), který je v podstatě přesnou obdobou Btrfs subvolume. Stejně jako Btrfs subvolume, ani ZFS filesystém není sám o sobě blokové zařízení; funguje na mnohem vyšší úrovni abstrakce a obsahuje přímo konzistentní data.
Odpovídám na oba předchozí komentáře.
Jsou dva základní přístupy, jak věci kolem disků řešit:
Nemám úplně vyhraněný názor, který z těchto přístupů je lepší. Poslední dobou používám spíš Btrfs a počet vrstev pod ním se snažím minimalizovat, ale nezavrhoval bych ani tu první možnost (vždy bude mít své uplatnění).
Btrfs je dneska bohužel někde na půl cesty – umí skoro všechno, skoro by ho šlo dát hned na blokové zařízení1 (resp. bloková zařízení), ale bohužel jen skoro.
Jenže pak si člověk vzpomene, že by potřeboval swap, takže vedle toho Btrfs dá ještě druhý oddíl. U swapu se ještě dá relativně dobře odhadnout, kolik bude potřeba místa. Ale pak přijde virtualizace – ne vždy stačí kontejnerová (LXC), která by běžela nad souborovým systémem, a je potřeba KVM a bloková zařízení pro jednotlivé virtuály2. Nebo zjistím, že Btrfs není úplně nejlepší pro všechny účely a na nějakou jednu věc by se mi víc hodil jiný souborový systém. Nebo si chci jen otestovat více FS nebo třeba udělat dočasný disk, na kterém budu něco divokého provádět a pak ho celý zahodím, místo abych to mazal soubor po souboru. Nebo třeba nasdílet část disku po iSCSI.
Takže nakonec dopadneš tak, že máš LVM a nad ním Btrfs. Tzn. máme dvě relativně tlusté/složité vrstvy, jejichž funkcionalita se z velké části překrývá. Nebylo by šťastnější jednu z nich vylepšit a překlopit to jedním a nebo druhým směrem a nebýt takhle na půli cesty?
Další věc je, kde dělat RAID. Můžeme mít pod tím vším MD RAID. Nebo použít RAID v LVM. Nebo použít (i) RAID v Btrfs. První dvě možnosti jsou suboptimální – když už tu to Btrfs máme, tak by bylo fajn používat jeho RAID3. Tak si uděláme dva LV nad různými PV, nad nimi jedno Btrfs a v něm uděláme RAID. Na jednom počítači to takhle mám. Ale přijde mi4, že je tam těch vrstev trochu moc. Nicméně flexibilní to je, což o to. Můžu si vedle toho udělat LV nad jedním PV bez RAIDu pro dočasná data a můžu si udělat LV zrcadlený nad dvěma PV s nějakým jiným FS nebo swapem.
A pak si do toho zkus zakomponovat ještě šifrování. Dát ho pod LVM je neefektivní, protože bys všechno šifroval dvakrát (pro obě poloviny RAIDu). Takže ho dáš asi spíš nad LVM a musíš spravovat několik klíčů/hesel pro jednotlivé oddíly…
Prostě si myslím, že by bylo fajn, kdyby Btrfs umělo část svého prostoru označit jako oddíl a zpřístupnit zbytku systému jako blokové zařízení. Už toho umí tolik – není to žádný jednoduchý jednoúčelový FS – že tohle by komplexitu už moc nezvýšilo. Naopak by to umožnilo vypustit LVM5 pod tím. Takové ZFS bloková zařízení umí a nemyslím si, že by to byla až tak zcestná nebo extrémistická myšlenka.
[1] Klidně bez nějaké prehistorické MBR tabulky oddílů – k čemu taky primární/rozšířené oddíly, když máme Btrfs a subvolume? Stejně bychom měli jen jeden oddíl přes celý disk.
[2] ano, dalo by se to řešit bootováním po síti a třeba NFS…
[3] ví, kde je který soubor, není to pro něj jen posloupnost bajtů, kterou je třeba synchronizovat celou
[4] a to už je co říct
[5] Nic proti LVM nemám, ale jen mi přijde trochu moc mít LVM a nad ním ještě Btrfs, když to skoro není potřeba resp. nemuselo by být.
[1] No, některé BIOSy odmítnou bootovat, když tam není MBR, ač k tomu obvykle nemají žádný objektivní technický důvod. Ale když nejde o bootovací disk, tam je situace jiná a na nějakých serverech opravdu mám Btrfs přímo na zařízení. Flexibility tam pak samozřejmě mnoho nezbývá.
[3] Bohužel RAID5 a RAID6 v Btrfs zatím není připravený na běžné použití, takže tam zbývá jedině RAID0 a RAID1, případně ZFS (který RAID5 a RAID6 umí už odpradávna) nebo klasický MD/DM a nad tím Btrfs (což může být suboptimální, protože Btrfs nemá volby stride a stripe width, narozdíl od Ext4).
Souhlasím, že by bylo super, kdyby Btrfs uměl něco jako ZVOL u ZFS. Třeba něco takového časem vznikne.
osobně bych to tazateli nedoporučoval, ne z nevýhod btrfs ale spíš z důvodu nutných znalostí, tedy z neznalostí tazatele.
Prozatím jedu na ext4, ale pokukuji po btrfs (subvolumes, snapshot, snadnější/přehlednější zálohování ... velký přínos). Prozatím chci vyzkoušet a laborovat na ntb, ale zatím nevím jak vyřešit následující věc:
- btrfs se nedoporučuje pro databázové soubory a virtuální obrazy disků. obojí potřebuji - nechci mít x systémů a přepínat se, ale využívám virtualizaci (stabilně je můj primární OS linux *archlinux*, ale z pracovních důvodů potřebuji widle, na práci v nich mi stačí virtualizace) - jak tedy vyřešit toto?
--- postačuje na soubor/adresář
chattr +C /dir/filenebo je i jiný způsob jak toto omezení obejít?
Btrfs se hodí pro virtuální obrazy disků, protože se pak dají obrazy klonovat okamžitě pomocí cp --reflink, tedy bez fyzického kopírování velkých objemů dat. V situacích, kde klonování obrazů není potřeba, samozřejmě tato výhoda ztrácí význam. Místo omezování CoW u jednotlivých souborů a adresářů se dá vytvořit subvolume a ten pak přimountovat s optionem nodatacow. Otázka ovšem je, proč to dělat. Na SSD to s největší pravděpodobností úplně postrádá smysl a je lepší vždy používat CoW. Na běžném disku rovněž není úplně jisté, že se Btrfs s CoW nehodí na virtuální obrazy disků. Nechal bych to koňovi, přesněji řečeno optionu autodefrag, a případný problém s fragmentací kvůli CoW bych řešil teprve tehdy, pokud by opravdu nějaký nastal.
Nevím, že by „se“ PostgreSQL nedoporučoval pro databázové soubory. Filesystém s copy-on-write by byl přímo ideální pro databáze, kdyby ho ovšem databáze explicitně podporovaly (tedy kdyby používaly aspoň obdobu cp --reflink, když už ne něco sofistikovanějšího na úrovni bloků). Některé sady benchmarků porovnávají (mimo jiné) výkon pgBench na Btrfs a jinde zase někdo zkoušel vyhodnotit vliv Btrfs (včetně komprese) na výkon PostgreSQL. WiKi od ArchLinuxu stále ještě tvrdí, že se má PostgreSQL spouštět jen s nodatacow, ale nepřikládal bych těmto „moudrům“ zásadní váhu. Měl jsem PostgreSQL na Btrfs s copy-on-write, kde zaprvé natrhlo prdel hračce zvané MySQL (až dvojnásobně rychlé zpracování některých joinů nad půlterabytovou databází). (Dlužno ovšem dodat, že byly všechny dotazy drtivě CPU-bound, protože PostgreSQL ani MySQL nemají (zatím) vícevláknové vyhodnocování dotazů.) Každopádně jsem nezaznamenal ani náznak nějaké „nevhodnosti“ Btrfs pro databáze.
díky za názor, krapet sme odbočili od tématu, ale snad nevadí.
Předně nevím, proč se rozepisuješ o PostgeSQL, já o tomto nemluvil ani slovo, jen obeně o databázi, v mém případě pak jde o MySql a Pervasive PSQL (v rámci firemního systému třetí strany) což ale nevadí a Tvého názoru si cením.
Co se týká virtuálaních obrazů disků - na klonování nepotřebuji btrfs, ale udělám si snapshot v rámci použité virtualizace (ať už VirtualBox, qemu-kvm, wmware .....). jinak o nevhodnosti BRTFS na tuto oblast vycházím přímo z oficiálních pramenů - tam je přímo doporučeno nepoužívat COW na databáze a virtualizaci. Malou zkušenost mám zhruba před rokem, když opravdu byl citelný pokles výkonu při použití BTRFS a virt. disku - ale uznávám, možná jen moji chybou. moc sem tenkrát nelaboroval.
Niceméně veškeré zdroje, které sem měl možnost prostudovat, toto potvrzují. Např:
Files with a lot of random writes can become heavily fragmented (10000+ extents) causing trashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM.
Ale i tato oblast mě láká a asi znovu vyzkouším využití Btrfs. Tazateli původního příspěvku spíše doporučuji nejdříve využít virtualizace, prostudovat literaturu o btrfs a pak se na toto pole vrhnout. Je třeba uznat, že práce s klaciským soub. systémem extX a btrfs je trochu odlišná.
Btrfs se hodí pro virtuální obrazy disků, protože se pak dají obrazy klonovat okamžitě pomocí cp --reflink, tedy bez fyzického kopírování velkých objemů dat. V situacích, kde klonování obrazů není potřeba, samozřejmě tato výhoda ztrácí význam. Místo omezování CoW u jednotlivých souborů a adresářů se dá vytvořit subvolume a ten pak přimountovat s optionem nodatacow.
Takže by se to dalo považovat za náhradu těch blokových zařízení? Jen s tím kosmetickým rozdílem, že ty oddíly nebudou v /dev/něco, ale třeba v /mnt/btrfs/dev/něco? Má takový soubor podle tebe srovnatelnou režii s oddílem v LVM?
Soubor má podle mého názoru vždy větší režii než oddíl LVM. Není-li fragmentovaný, může být rozdíl v režii zanedbatelný, ale filesystém je prostě na vyšší úrovni abstrakce a jeho čtení vždy znamená „začít tak nebo tak od LVM a k tomu ještě udělat něco navíc“. Na Btrfs se kontrolují checksumy, což může být další režie navíc, nerozhodne-li se uživatel pro option nodatasum. Použití nodatasum by mohlo být v pořádku, pokud by virtuální stroj používal Btrfs a checksumování by prováděl uvnitř. Pak by asi dávalo smysl nedělat checksumy dvakrát na dvou úrovních zvlášť.
Kdybych měl řešit tohle konkrétní dilema a kdyby I/O výkon byl pro virtuální stroje podstatný, asi bych zkusil nějaký jednoduchý benchmark a posoudil, jestli vypínání CoW a checksumů dává nějaký smysl. Rozhodně se to bude lišit u disků a SSD a podle toho, kolik jich je, tj. jestli počítání checksumů může generovat nějaké zatížení procesoru, které stojí za řeč, a jestli případná fragmentace související s CoW může vadit nebo ne (nebo jestli náhodou nemůže u SSD naopak prospět). Těžko se to odhaduje jen tak od stolu.
2.1.2015 18:55
Jendа | skóre: 78
| blog: Jenda
| JO70FB
checksumy a odolnost proti silent data corruptionTomu, že dokáže silent data corruption detekovat (ale nikoli opravit), bych rozhodně neříkal odolnost. Mimochodem kolikrát se ti to už stalo?
Proč si myslíš, že Btrfs nedokáže opravit silent data corruption? Rozhodně to umí v případě metadat, protože metadata mají implicitně „RAID“ režim DUP, tj. všechna Btrfs metadata jsou zapsaná dvakrát, má-li filesystém jen jeden disk. (Má-li víc disků, jsou obvykle jednou na každém disku, nenastaví-li to uživatel jinak.) V případě běžných dat je i samotná detekce velmi prospěšná, ale uživateli samozřejmě nic nebrání zapisovat i data v režimu DUP, chce-li (samozřejmě s náležitou režií). Dvě kopie metadat jsou každopádně velmi podstatnou výhodou Btrfs, na kterou se velmi často zapomíná. Tady by se jeden ostatních filesystémů zeptal: Kdo z vás to má?!
V případě RAID1 je oprava silent data corruption samozřejmostí — to asi není třeba nijak podrobněji popisovat.
(Oprava drobných poškození na jednom disku s jednou jedinou kopií dat by taky byla technicky možná — stačilo by jen zvolit algoritmus pro checksumy, který něco takového umožňuje, a počítat s trochu větší řežií. Pokud ale vím, momentálně tohle implementováno není.)
Kolikrát jsem já osobně viděl silent data corruption, to vůbec není podstatné. Neprovozuju totiž miliony disků — narozdíl od takového Facebooku, který Btrfs zkušebně používá a jistě velmi dobře ví proč. Na Ext4 jsem silent data corruption viděl několikrát a následky rozhodně nebyly silent. Nešlo o skryté hardwarové selhání, ale spíš o kombinaci bugů, výpadků napájení a obvyklého lhaní disků ohledně perzistentního zápisu dat. Užil jsem si pak všech klasických projevů takové situace — souborů o velikosti 100 PB, nesmazatelných adresářů plných smetí, nesourodých kusů dat v některých konfiguračních souborech (a trvalo mi fakt dlouho, než jsem zjistil, proč nemůžu spustit třeba KDM) a tak dále a tak podobně. Na Btrfs jsem zatím ještě nic podobného nezažil. Při přerušení zápisu v nevhodnou chvíli budou špatně buď data, nebo checksum. V obou případech se aspoň odhalí, byť s nějakými false positives, že je něco špatně.
Tiskni
Sdílej:
