Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.
Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.
Meta převezme sociální síť pro umělou inteligenci (AI) Moltbook. Tvůrci Moltbooku – Matt Schlicht a Ben Parr – se díky dohodě stanou součástí Meta Superintelligence Labs (MSL). Meta MSL založila s cílem sjednotit své aktivity na poli AI a vyvinout takovou umělou inteligenci, která překoná lidské schopnosti v mnoha oblastech. Fungovat by měla ne jako centralizovaný nástroj, ale jako osobní asistent pro každého uživatele.
nějakou dobu už mi běží na backup serveru FreeBSD 9.1 se souborovým systémem ZFS (ostatně kvůli tomu tam mám také freebsd). Zálohuji na něj servery a většinou pomocí BackupPC - pro každý server 1x týdně full backup, 1x denně inkrementální. Serverů je celkem 13 a až na 2 výjimky to jsou linuxové servery. U nich je velikost full backup +-20 GB. 2 servery jsou Windows zálohované přes rsync skrze ssh tunel a u nich je velikost plné zálohy cca 600 GB pro každého. Všechny tyto servery se zálohují do nekomprimovaného zfs poolu. Kromě BackupPC také zálohuji 1x týdně virtuální stroje, resp. jejich disky manuálně pomocí vlastního skriptu (+-50GB * 6) - tady využívám zfs snapshoty a pomocí rsync posílám pouze rozdílová data (trvá to déle, ale ušetří to díky zfs veliké množství místa na disku anichž bych musel používat deduplikaci).
Teď k jádru problému: zálohovací stroj přestal stíhat zálohování. Má na toto dost slabý hardware a není dost finančních prostředků na nějakou jeho změnu. Je to taková skládačka - AMD Dual-Core Athlon X2 4450e (45W), 2300MHz, 5 GB RAM (nonECC - vím že je to risk na ZFS...), 4x SATA 2 TB disky. Jak nabobtnalo množství zálohovaných a i již zazálohovaných dat, tak prudce klesl výkon - pravděpodobně za to může ZFS v raidz1.
Mám několik oẗázek: Jak je na tom nyní btrfs s ohledem na spolehlivost a rychlost na linuxu oproti zfs na freebsd? Když jsem před rokem zkoušel asi měsíc btrfs, pokaždé se mi nakonec rozsypal. Nebo si myslíte, že na takové množství dat bude lepší klasika např. ext4 (tam bych ale zase přišel o snapshoty)? Šel bych určitě do linuxu, protože po roční zkušenosti s freebsd mi připadá, že linuxové jádro daleko lépe zvládá vysokou zátěž (asi lepší IO scheduler či co).
atop a také se to zobrazuje na grafech munin. Typický čas pro úplnou zálohu je 120Min a pro inkrementální 20-40min. Z každé stanice je to cca 200-400 000 souborů. Celkem má záloha kolem 1,2 mil souborů.
Nejdříve mě to připadalo strašně dlouhé. Ale když jsem se díval, co zálohování na cíli vyrobí, tak jsou to soubory nazvané svými hash hodnotami, rozdělené do 3 úrovní adresářů podle prvních 3 hexa znaků hashe. V jednotlivých zálohách konkrétních systémů jsou pak hardlinkované odkazy na tento hashový pool. A protože při jak inkrementální tak úplné záloze stejně musí sytém projít všechny soubory jestli je má zazálohované v aktuální verzi, tak jsem dospěl k názoru, že stejně to rychleji nepůjde, protože když u disku je tak cca 100 IOPS tak 200 000 souborů je odhadem 2000 sekund. Pro mne výhoda je, že jak mají všechny systémy stejné distro, tak soubor, který je stejný je hardlinkovaný ze záloh všech strojů (vyzkoušeno pomocí find /var/lib/BackupPC -samefile fvi) (konkrétně záloha vi má u mne 170 hardlinků). A čistě ten find běžel asi 35 minut, jak je ten strom velký. Takže si myslím, že změna file systému nepomůže. A
Tím záloha serverů myslím opravdu všechno, co na těch strojích je. V podstatě těch systémových souborů moc není, jde o uživatelská data - typicky nejhorší asi bude několik gigabajtů mailů v malých souborech či rozsáhlé webové stránky a hlavně stovky tisíc malých souborů na windows serverech (jsou to fileservery).
Ono ten backup server se jeví podle monitorování jako nezatížený - nízké využití sítě, malé rychlosti zápisu na disky, procesor podle topu nevyužitý - nicméně v něčem mi freebsd asi kecá. Disky mají dost práce - přes dd naměřím rychlost zápisu kolem 2-5 MB/s, pořád běží dost procesů find programu BackupPC. Načtení web statistiky BackupPC trvá i přes 30 sekund. Podle mě to padlo na limity HW + ZFS filesystému (i bez zálohování výkonnost ZFS nic moc na tomto HW). Proto nevím jestli bych si třeba btrfs na linuxu nepolepšil ...
Tiskni
Sdílej: