Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
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: