Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Po pěti měsících vývoje byla vydána nová verze 0.15.1 programovacího jazyka Zig (GitHub, Wikipedie). Verze 0.15.0 byla přeskočena. Přispělo 162 vývojářů. Přehled novinek v poznámkách k vydání.
Před sedmi lety společnost Valve představila fork projektu Wine s názvem Proton umožňující v Linuxu přímo ze Steamu hrát počítačové hry do té doby běžící pouze ve Windows. Aktuální přehled podporovaných her na stránkách ProtonDB
Společnost DuckDuckGo rozšířila svůj AI chat Duck.ai o GPT-5 mini (𝕏). Duck.ai umožňuje anonymní přístup bez vytváření účtů k několika modelům umělé inteligence. Aktuálně k GPT-4o mini, GPT-5 mini, Llama 4 Scout, Claude Haiku 3.5 a Mistral Small 3.
Marek Tóth v příspěvku DOM-based Extension Clickjacking: Data ve správcích hesel v ohrožení na svém blogu popsal novou clickjacking techniku s několika variantami útoků a otestoval ji proti 11 správcům hesel. Výsledkem bylo nalezení několika 0-day zranitelností, které mohly ovlivnit uložená data desítek milionů uživatelů. Jedno kliknutí kdekoliv na webové stránce kontrolované útočníkem umožňovalo ukrást uživatelská data ze
… více »Na dnešní akci Made by Google 2025 (YouTube) byly představeny telefony Pixel 10 s novým čipem Google Tensor G5 a novými AI funkcemi, hodinky Pixel Watch 4 a sluchátka Pixel Buds 2a.
Dobry den,
prosim zkusenejsi o pomoc s DRBD. Doted jsem ho znal jen z doslechu. Snazim se v rychlosti neco nacist, ale zatim je to malo.
Pokousim se vydolovat data z noveho QNAPu, kteremu po par mesicich odesla zakladni deska. Podle recenzi na internetu to potkalo hodne lidi. Servis v NL nestiha a po nejake dobe vraci penize.
Oba disky jsou vporadku. MD raidy se sestavi a na oddilech, kde je rovnou EXT4 pro system, jsou videt data - konfiguracni soubory, logy, atd. Horsi je to s oddilem pro uzivatelova data. Ta jsou na think provisioned LVM, pod kterym bezi DRDB.
Pokus nahodit DRDB dopadne takto:
# drbdadm up r1 strange bm_offset -2112 (expected: -1928) No valid meta data found
A ted se ptam:
- Muzu prikazem "drbdadm create-md r1" vytvorit znovu metadata, aniz bych poskodil data na disku?
- Da se pomoci nejakeho offsetu dumpnout disk, abych z DRDB oddilu dostal Physical Extends pro PV?
Nerad bych to resil stylem pokus/omyl, protoze vytvorit pracovni kopii disku trva DDckem 10 hodin.
Dekuji
dl
.
----------
Puvodni originalni konfiguraky a info ze stroje, kde to zkousim:
# lsmod | grep drb
drbd 425984 0
lru_cache 16384 1 drbd
libcrc32c 16384 2 btrfs,drbd
# rpm -qa | grep drb drbd-utils-9.13.0-lp152.2.3.1.x86_64 drbd-9.0.22~1+git.fe2b5983-lp152.2.2.1.x86_64
# blkid -c /dev/null /dev/md126 /dev/md126: UUID="43c1a77e5b530960" TYPE="drbd"
# cat /etc/drbd.d/global_common.conf
global {
usage-count no;
}
common {
handlers {
}
startup {
}
options {
}
disk {
}
net {
}
}
# cat /etc/drbd.d/r1.res resource r1 { syncer { rate 4G; } on HomeHost { device /dev/drbd1; disk /dev/md126; meta-disk internal; address 127.0.0.1:7789; } on FakeHost { device /dev/drbd1; disk /dev/md126; meta-disk internal; address 1.0.0.1:7789; } }
# drbdadm up r1 strange bm_offset -2112 (expected: -1928) No valid meta data found
# cat /proc/drbd version: 8.4.11 (api:1/proto:86-101) srcversion: B5223DD0E70DC76DE10377F 1: cs:Unconfigured
LOG z puvodniho NASu:
# grep drb pstore_2_201907101733.log
[ 14.619019] drbd: initialized. Version: 8.4.5 (api:1/proto:86-101)
[ 14.625194] drbd: GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by @U16BuildServer40, 2019-06-20 06:15:46
[ 14.635647] drbd: registered as block device major 147
[ 39.414676] drbd r1: Starting worker thread (from drbdsetup-84 [2460])
[ 39.421491] block drbd1: disk( Diskless -> Attaching )
[ 39.426832] drbd r1: Method to ensure write ordering: flush
[ 39.432392] block drbd1: Adjusting my ra_pages to backing device's (32 -> 1024)
[ 39.439668] block drbd1: drbd_bm_resize called with capacity == 7794125112
[ 39.446521] drbd_realloc_pages use the Default memory
[ 39.451747] block drbd1: resync bitmap: bits=7611451 words=118929 pages=233
[ 39.458682] block drbd1: size = 3717 GB (3897062556 KB)
[ 39.483867] block drbd1: recounting of set bits took additional 0 jiffies
[ 39.490650] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[ 39.498546] block drbd1: Suspended AL updates
[ 39.502897] block drbd1: disk( Attaching -> UpToDate )
[ 39.508111] block drbd1: attached to UUIDs 9EBFAD153C603FE5:0000000000000004:0000000000000000:0000000000000000
[ 39.556553] drbd r1: conn( StandAlone -> Unconnected )
[ 39.561792] drbd r1: Starting receiver thread (from drbd_w_r1 [2461])
[ 39.568374] drbd r1: receiver (re)started
[ 39.572393] drbd r1: conn( Unconnected -> WFConnection )
[ 40.603095] drbd r1: conn( WFConnection -> Disconnecting )
[ 40.603103] drbd r1: Discarding network configuration.
[ 40.613849] drbd r1: Connection closed
[ 40.617616] drbd r1: conn( Disconnecting -> StandAlone )
[ 40.622996] drbd r1: receiver terminated
[ 40.626915] drbd r1: Terminating drbd_r_r1
[ 40.634108] block drbd1: role( Secondary -> Primary )
[851456.448823] block drbd1: role( Primary -> Secondary )
[851456.454085] block drbd1: bitmap WRITE of 0 pages took 0 jiffies
[851456.460100] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[851456.501104] block drbd1: disk( UpToDate -> Failed )
[851456.506178] block drbd1: bitmap WRITE of 0 pages took 0 jiffies
[851456.512172] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[851456.520147] block drbd1: disk( Failed -> Diskless )
[851456.525389] block drbd1: drbd_bm_resize called with capacity == 0
[851456.531594] drbd r1: Terminating drbd_w_r1
Ta jsou na think provisioned LVM, pod kterym bezi DRDB.Co to je za zběsilost? A v rámci jednoho fyzického stroje? To jako to drbd běželo přes localhost? Tedy…
MD RAID → LVM → DRBD → BtrfsA s čím se to jako synchronizovalo? A proč je to blokové zařízení rovnou nad MD raidem a ne nad LV oddílem?
strange bm_offset -2112 (expected: -1928) No valid meta data found
Dekuji vsem za ochotu. Jeste doplnim:
Proc je to tak blbe udelane? - Nevim. Je to nesmyslne, souhlasim. Udelalo se to samo behem instalace. Asi pokrok. Do ted nebyl problem disky z Qnapu precist v linuxu. S tim je ted konec. Pujcil jsem si od znamych 2 ruzne starsi modely, ale ani jeden neobsahuje drbd. Nova doba, nove modely, nova funkcionalita, nove problemy...
Pripojil jsem disk v Centosu 7.1 ale dopadlo to stejne. Zkusim jeste Centos 6, snad tam bude drbd verze 8.
Zkusim nekde pujcit identicky model QNAPu a pripojit to v nem.
Diky moc
Zjistil jsem, ze DRBD uklada metadata na konec diskoveho oddilu. Minimalni velikost metadat je 128 MB (pro disky < 8 TB). Ve verzich si myslim problem nebude, jak Centos 7.1 tak onen QNAP bezi na verzi DRBD8.
QNAP # cat /proc/drbd version: 8.4.5 (api:1/proto:86-101) GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by @UBuildServer40, 2019-03-28 06:16:13, HA:disabled
CentOS71# cat /proc/drbd version: 8.4.11 (api:1/proto:86-101) srcversion: B5223DD0E70DC76DE10377F
Dalsi problem bude v LVM, jsou tam nejake nezname atributy. Asi vlastni rozsireni LVM. Nejde aktivovat na openSUSE Tumbleweed ani na CentOSu 8.2, ktere by podporu THIN LVM2 meli umet.
# pvscan WARNING: Unrecognised segment type tier-thin-pool WARNING: Unrecognised segment type thick WARNING: Unrecognised segment type flashcache WARNING: PV /dev/md126 in VG vg1 is using an old PV header, modify the VG to update. LV tp1, segment 1 invalid: does not support flag ERROR_WHEN_FULL. for tier-thin-pool segment. Internal error: LV segments corrupted in tp1. Cannot process volume group vg1 No matching physical volumes found
Nakonec nezbylo, nez sehnat ten samy model QNAPu, pripojit disky - vsechny filesystemy nabehly se statusem CLEAN, aktivovat jednotlive vrtvy dle videa https://youtu.be/cvuLTgvnTjY a odsypat data po siti.
Protoze nekterym nedosla tragicnost cele situace, tak znovu opakuji. Byla to bezna NASka, pravdepodobne v defaultni konfiguraci, porizena uzivatelem domu za ucelem zalohovani blbosti z mobilu a notebooku. Ne firemni uloziste v HA konfiguraci.
Dekuji vsem za ochotu a brzy na videnou, treba u disku ze Synology
Tiskni
Sdílej: