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.
Mám 2 servery - první velice výkonný se používá skoro nonstop a druhý je postarší ne moc výkonný. Chtěl bych udělat mirrorování dat přes síť z 1. na 2. server aby při výpadku nebylo tak velké zlo - lepší pomalý server než žádný server. Mám ideu: pomocí drbd mirrorovat disk ze serveru 1 na server 2 na zvláštní disk a pokud by server 1 padnul, tak bych server 2 restartoval do "dat ze serveru 1". Jenomže nevím jak se drbd ve skutečnosti chová. Brzdí drbd práci s diskem čekáním ne přenos po síti nebo je to asynchronní zápis? Mohu očekávat jiné problémy se stabilitou/rychlostí toho 1. rychlého serveru?
Brzdí drbd práci s diskem čekáním ne přenos po síti nebo je to asynchronní zápis?
No, jestli se na zápis čeká nebo ne definuješ vybranym protokolem:
Viz http://www.drbd.org/home/mirroring/ :
Synchronous mirroring (called protocol C in DRBD speak) is the right choice for HA clusters where you dare not lose a single transaction in case of the complete crash of the active (primary in DRBD speak) node.
Zcela souhlasím s příspěvky výše. Určitě bych jako sekundární stranu drbd nepoužíval nějakou šunku, která má pomalé diskové operace. CPU ani paměť nejsou kritické (i když musí stíhat pár set megabitů komunikace po gigabitové síťovce, ale to není tak náročné), ale průchodnost sběrnic a rychlost řadiče a disků je zcela klíčová pro celkový výkon mirroru.
Tak to asi bude drbd nepoužitelné, sekundární server (ač má gigovou síťovku), tak má pomalou sběrnici a hdparm se dostane na 70MB/s, kdežto primár je 160MB/s. Co by se dalo použít jiného? Nejedná se o přesně aktuální kopii disku, stačilo by tak starou do 10 minut nebo možná i déle, ale hlavně aby to nebrzdilo síťový provoz na serveru, který má 2 hodně užívané síťovky.
Myslím si, že by se v tvém případě by se dal akceptovat režim B (zápis je dokončen v okamžiku příjmu TCP paketu na druhé straně. Pak by zpomalený zápis na sekundátu nemusel vadit, pokud nepůjde o kontinuální zápis. Chce to vyzkoušet, jde jen o pár příkazů.
Určitě bych dal do obou serverů samostatné gigabitové síťovky a propojit extra kabelem. Skoro nic to nestojí.
rsync z cronu nebo seznamfs treba
nebo treba 1x za hodinu rdiff-backupem a budes to mit i s historii
Na rdiff, rsync a podobné nástroje pozor, v případě velkého množství souborů může synchronizace trvat třeba i půl dne 
(vlastní zkušenost)
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz