Konference LinuxDays 2026 proběhne již tento víkend 3. a 4. října v Praze v areálu ČVUT v Dejvicích na FIT. Konference LinuxDays 2026 znamená desítky přednášek a workshopů, zástup zajímavých osobností, místo pro setkání, spoustu nových nápadů a informací a stánky řady různých projektů: Fedora, openSUSE, vpsFree.cz, Mozilla, MacGyver - bastlíři SH, OpenAlt a mnoho dalších. Vstup je volný.
Microsoft oznámil, že WSL kontejnery (WSLC) aneb linuxové kontejnery ve Windows Subsystem for Linux (WSL) jsou již obecně dostupné. Současně popsal jejich architekturu.
openSUSE Leap 16.1 vstoupil do RC fáze. Nově lze instalovat jako standardní systém (Standard) nebo jako neměnný systém s atomickými aktualizacemi (Immutable). Samostatná neměnná distribuce openSUSE Leap Micro končí.
Byl vydán Mozilla Firefox 157.0. S nejvýraznější vizuální proměnou za poslední roky. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 157 bude brzy k dispozici také na Flathubu a Snapcraftu.
Rodina produktů Raspberry Pi se rozšířila o Raspberry Pi Smart Display Module. Deska pro Raspberry Pi Compute Module 5 se zasouvá přímo do displejů dle specifikace Intel SDM. Cena desky je 30 dolarů.
Byla vydána nová verze 2.56.0 distribuovaného systému správy verzí Git. Přispělo 104 vývojářů, z toho 39 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Hackerská skupina ShinyHunters oznámila průnik do informačních systémů FBI, prostřednictvím zero-day zranitelnosti v platformě Oracle PeopleSoft, kterou úřad využívá mimo jiné pro náborový portál FBIJobs.gov. Útočníci tvrdí, že získali až 3 TB dat o současných i bývalých zaměstnancích a uchazečích o práci. Jako důkaz zveřejnili vzorek přibližně 5 000 záznamů obsahující jména, adresy, telefonní čísla, data narození, čísla
… více »Doba kompilace linuxového jádra se díky rychlejšímu hardwaru a optimalizacím kbuildu snižuje k deseti sekundám. Nejnovější patche Lorenza Stoakse (vznikají i s pomocí SI) zkrátily na testovacím stroji dobu sestavení z dlouhých 22 vteřin na pouhých 15, a to bez použití RAMdisku. Testovací systém tvořily dva procesory AMD EPYC 9575F (oba dohromady poskytují celkem 128 jader a 256 vláken), čtyřiadvacet 64GB DDR5-6400 paměťových modulů a
… více »Před rokem a půl vývojáři postmarketOS informovali, že pro projekt hledají nové jméno. Včera bylo oznámeno: postmarketOS se nově jmenuje Nura.
Hra Factorio dorazila na Printables. Hned teď si můžete stáhnout 65 různých modelů a nechat celou mimozemskou planetu oživnout na svém stole.
Klasické gui nad rsync, diff, cp. Už to fakt chce pořádný FS s podporou snapshotů, cow a deduplikace.
Blog je skoro dobrý, hodil by se i na článek z praxe (jak na to). To "skoro" proto, že mi tam chybí dost podstatná věc: obnovení zálohy.
rdiff-backup je užitečný, ale v otevřeném stavu je pouze poslední záloha. Na starší zálohy je potřeba už použít příkazy (nebo ale zálohu připojit pomocí ArchFS). Ale zase je velmi úsporný (co se místa na disku týče). Já používal rsnapshot. Ten uchovával data v otevřeném stavu z každé zálohy (úspora místa se řešila pomocí hardlinků). Tam stačilo vykopírovat soubory z daného data, bez nějakých dalších příkazů. Velice praktické. Jenže problém (a dokládá to i mnoho dotazů na mailling listech FS), představují právě ty hardlinky (100mil linků pro 1mil souborů už představuje výkonnostní problém).
IMO není moc dobrý nápad vzdáleně zálohovat pod rootem, spíš si vytvoř speciálního uživatele s omezenými právy.... na cílovém stroji jsem vytvořil uživatele "zalohator", na zálohovaných strojích jsem pod každým uživatelem vytvořil ssh klíče (pokud neměli), dal veřejné zálohátorovi do authorized_keys, a každému zálohovanému uživateli vytvořil zálohovací cronjob bezpečnostní chybkou tohoto řešení je, že kterýkoliv zálohovaný uživatel může vidět (a modifikovat) všechny zálohy, ale dokud mám ty účty pod palcem, tak mě to netrápí - jinak by to samozřejmě chtělo zvláštního zálohovacího uživatele pro každý zálohovaný účet
V mém případě je většina souborů fotky a muzika, které prostě žádné verze nebudou mít.No také jsem v to doufal, ale ono stačí opravit špatné ID3 u hudby, přidat tagy k fotkám a hned je nová verze souboru na světě. Je ale fakt, že to není kritické, jako u některých konfiguráků, které se mění každou chvilku (třeba v .kde).
command="rdiff-backup --server --restrict-read-only /",from="nejakystroj",no-port-forwarding,no-
X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1 ...
Tím se dosáhne toho, že při kompromitaci zálohovacího stroje není ohrožen stroj zálohovaný. Samozřejmě útočník získá data, s tím nejde dělat nic (leda je zálohovat šifrovaná).
Nakonec dělám zálohy radši pomocí nástroje dirvish (totožná funkce s rsnapshot, ale líbí se mi víc, má dobře ošetřené i chybové stavy, kdy se během zálohování stroj vypne; pochopit konfiguraci ale nebylo vůbec snadné). Výhoda je snadná "viditelnost" všech záloh. Tam zase člověk narazí na problémy s množstvím hardlinků, jak už tu bylo zmíněno. Jen mazání jedné staré zálohy trvá desítky minut. Zálohuju 1 milion souborů, 90 GB, a smazání jedné zálohy + udělání nové je na 2 hodiny i když se skoro nic nezmění. Ale je to slabý stroj (Celeron 1.7 GHz, 256 MB RAM) a zálohuje se na obyčejný SATA disk.
Všechny tyhle zálohovací programy typu rsnapshot a rdiff vypadají hezky, ale pro větší nasazení můžou přijít problémy, na to pozor! Pak je často nejlepší volba klasický inkrementální TAR nebo něco obdobného. Skutečně by to chtělo pořádný filesystem typu ZFS, a tohle řešit na jeho úrovni.
Doporučuji logovací file system nilfs2 + rsync.
Udržuje historii zápisů, FS dá se namountovat tak, jak vypadal v určitém bodě v čase (readonly). Staré logy (starší než tzv. protection period) se automaticky mažou, aby se uvolňovalo místo.
Další nespornou výhodou je, že máte „zadarmo“ ošetřenou kontrolu integrity dat (i v historických snapshotech) – v rámci metadat se ukládají SHA-1 součty souborů, takže se dá ověřit, že data na záložním médiu tiše nedegradují. Dokud nebude počítání kontrolních součtů všech dat běžnou funkcí filesystémů (jako to dělá Btrfs či ZFS), tak je to k nezaplacení.
Tichá degradace dat totiž dle mého bude v budoucnu asi docela závažný problém a je dobře, že nadcházející filesystémy už to řeší. Zajistit bezchybnost dat na 2/4/8... TB disku je totiž podstatně obtížnější úkol, než zajisti bezchybnost dat na 40 GB disku, i když disky sami mají nejrůznější mechanismy pro kontrolu předávaných dat.
Tiskni
Sdílej: