O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
mount -t nfs 10.10.18.24:/mnt/space2 /mnt/nfsDále si vytvořím soubor, který bude pak obsahovat šifrovaný filesystém, o velikosti 500GB.
dd if=/dev/zero of=/mnt/space2/fs_backup.lks bs=1M count=500000Problém je, že pro šiforvání je vhodné, aby soubor obsahoval co možná nejnáhodnější data. Bylo by lepší sahat do /dev/random, ten je ale ukrutně pomalý, eventuelně do /dev/urandom který je rychlejší, méně kvalitní z hlediska náhody, nicméně pro vytvoření takto velkého souboru zase nevhodný. Můj postup který volím je vytvořit soubor obsahující samé nuly, dále soubor převedu do luks formátu a připojím. Pak toto šifrované zařízení přepíšu přes shread 1x náhodnýmy daty. Data nemusejí být podle mě nějak kvalitní protože po zašifrování už se bude jednat o kvalitní bordel. Dále odpojím přes cryptsetup luksClose šifrovaný kontainer a ještě přepíšu hlavičku, prvních 32mb mého souboru, tentokrát si na /dev/urandom počkám. Teď mám tedy soubor obsahující, doufejme, kvalitní náhodná data a bylo to o poznání rychlejší než čekat na /dev/urandom.
losetup /dev/loop0 /mnt/nfs/fs_backup.lksDále je třeba /dev/loop0 naformátovat do luks formátu. Dosáhnu toho pomocí příkazu.
cryptsetup -y luksFormat -c blowfish -s 256 /dev/loop0Zde bych se zase rád zeptal na názory, je vhodné použít blowfish? nebo raději aes? vzhledem k přístupu přes síť není třeba rychlost. Můžete doporučit nějaké dobré nastavení při formátu do luks? Jde mi zejména o bezpečnost.
cryptsetup luksOpen /dev/loop0 loop0Dál je třeba kontainer naformátovat do nějakého rozumného souborového systému
mkfs.ext3 /dev/mapper/loop0Nakonec připojit...
mount /dev/mapper/loop0 /mnt/zalohaTeď syncnout, rozhodl jsem se přes rsync...
rsync -av --delete /home/ /mnt/zaloha/Po skončení odpojit fs, zavřít šifrovaný kontainer, odpojit loop zařízení a odmountovat nfs
umount /mnt/zaloha cryptsetup luksClose loop0 losetup -d /dev/loop0 umount /mnt/nfsSamozřejmě že pro zálohování se pojede už jenom následující sekvence, s heslem v texťáku (zabijte mě! nevím jak jinak, neinteraktivně).
mount -t nfs 10.10.18.24:/mnt/space2 /mnt/nfs losetup /dev/loop0 /mnt/nfs/fs_backup.lks echo heslokterejetajne | cryptsetup luksOpen /dev/loop0 loop0 - mount /dev/mapper/loop0 /mnt/zaloha rsync -av --delete /home/ /mnt/zaloha/ umount /mnt/zaloha cryptsetup luksClose loop0 losetup -d /dev/loop0 umount /mnt/nfsCelé toto hodím do cronu a nastavím noční hodinu, třeba 2 hodiny v noci. Pak mi stačí notebook na noc nevypínat a ráno budu mít zálohy.
Tiskni Sdílej:
Táák, nějaké nápady, připomínky?Mno, imho, kdybys šifroval asymetricky (klidně pomocí gpg, nebo tak) tak budeš mít jeden klíč na zašifrování a druhý na dešifrování, tak se nemusíš sypat strachy, že ti někdo ukradne heslo
Pak bych ovšem nemohl šifrovat na úrovni fs, přišel bych o rsync. Což by pro mě bylo komplikované.Mno, zřejmě jo...
Navíc, ztráta hesla... když přijdu o heslo které mém jen na mém notebooku, pak nejspíš "jako bych přišel o vše". Ale děkuji za zajímavý podnět.Vytisknout klíč na papír a nechat uschovat u notáře? :-P
Mno, zřejmě jo...Bylo. Pořád čekám, jestli někdo napíše „distribuovanou P2P zálohovací síť“, kdy si vyhradíš třeba 30 GB pro cizí zálohy a za to si budeš moct zálohovat k někomu jinému (=geograficky odděleně).
Vytisknout klíč na papír a nechat uschovat u notáře? :-PK tomu podle mě např. policie může (řeknutí hesla by byla výpověď, ale tohle by bylo jen vydání věci).
(1) Každý má právo odepřít výpověď, jestliže by jí způsobil nebezpečí trestního stíhání sobě nebo osobě blízké.A co když to dáš "někomu" a policii neřekneš kde to je? A optimálně dotyčnému neřekneš, co v tom je...
Lidé s čistým svědomím a s dobrými úmysly nevymýšlejí, jak být anonymní, aby se na ně nepřišlo. To obvykle dělají pouze zločinci a obecně lidé patřící do kriminálu. Už jen založení diskuze na podobné téma je podezřelé a mělo by se prošetřit.
Taková činnost ale maří vyšetřování policejním institucím. Nedávno dávali ve zprávách, že právě šifrované hovory přes skype jim velmi ztěžují pachatele odhalit. Právě možnost sledování lidí na internetu umožní bojovat proti trestné činnosti a to právě chrání celou naši společnost a zajišťuje nám bezpečí.Zdroj; těžko říct, jak moc vážně je to myšleno.
...distribuovanou P2P zálohovací síť...Freenet?
K tomu podle mě např. policie může (řeknutí hesla by byla výpověď, ale tohle by bylo jen vydání věci).Ty pácháš trestnou činnost?
Pak bych ovšem nemohl šifrovat na úrovni fs, přišel bych o rsync.o rsync jsi prisel i tak, jaky smysl ma pretahnout data po siti (nfs) pak je rsyncem zanalyzovat na zmeny a pripadne zmeny zapsat? rsync ma smysl pokud bezi primo na vzdalenem stroji, pak se opravdu prenasi jen zmeny ale takhle to muzes klidne natvrdo prekopirovat a budes na tom stejne ne-li lip..
s heslem v texťáku (zabijte mě! nevím jak jinak, neinteraktivně)Google: luks keyfile Já zálohuji do encfs - výhodou je, že se záloha nafukuje nebo naopak zmenšuje podle toho, kolik dat v ní skutečně je. Musel jsem si patchnout rsync, protože v encfs je bug. encfs je buď na USB disku, nebo ho připojuji přes sshfs (pomalejší). Ta nejdůležitější data zálohuji do zvláštního encfs (má asi 4 GB) a ten pak rsyncuji po Internetu.
cbc-essiv
s minimálně jednou známou zranitelností. Momentálně je asi nejvhodnější mód xts
, nastavitelný třeba takto:
cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/zarizeniAle v tomhle případě bych opravdu raději doporučil Duplicity...
následující sekvence, s heslem v texťáku (zabijte mě! nevím jak jinak, neinteraktivně).Místo hesla můžeš použít klíč v souboru – takže klíč nebude na vzdáleném disku (zašifrovaný heslem), ale budeš ho mít hezky u sebe. Volba:
--key-file
A když už tam mít heslo, tak bych místo echo tajné_heslo | …
dal alespoň cat soubor_s_heslem.txt | …
(plus ošetřit práva k tomu souboru).
Nemáš možnost použít iSCSI? To by bylo pro sdílení blokového zařízení (nebo souboru) lepší než NFS.Ono by možná úplně stačilo i network block device (nbd), pomocí kterého jde v Linuxu přitupovat na libovolné blokové zářízení. Server navíc běží čistě v uživatelském prostoru, jen klient potřebuje modul v jádře.
Pokiaľ viem, z menej náhodných dát sa "náhodnejšie" spraviť nedajú bez použitia iných ešte "náhodnejších" dát, takže spôsob, akým sa ten súbor vytvára je naprd...
Nebolo by lepšie ťahať dáta z /dev/dsp (príp. /dev/audio) a do mikrofónu pustiť kvalitný šum z rádia? Prípadne ich ťahať z /dev/video0 a kameru namieriť na zrniacu TV... Alebo ešte lepšie použiť takto viac zdrojov a potom ich merge-núť (napr. bajty na striedačku) To by bola pravdepodobne oveľa kvalitnejšia náhoda...