Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.
Společnost Meta otevírá svůj operační systém Meta Horizon OS pro headsety pro virtuální a rozšířenou realitu. Vedle Meta Quest se bude používat i v připravovaných headsetech od Asusu a Lenova.
Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
O backup volume (BK) jsme mluvili již dříve a představili jsme si jej jako snapshot a i tak funguje. Když záložní volume vytvoříme, ukládají se do něj pouze rozdíly vůči RW volumu. Backup volume se povinně nachází na shodném umístění, jako je RW, proto není nutné v příkazu zadávat cestu. BK volume můžeme vytvořit ručně (bez administrátorského oprávnění to nejde):
~$ vos backup root.cell Created backup volume for root.cell
Tím jsme získali volume root.cell.backup
a můžeme jej připojit
tam, kam máme práva. Mount point může vytvořit i uživatel pokud má
v daném adresáří právo INSERT (i) a ADMINISTER (a).
Tyto práva má v domovském adresáři. Prakticky si může připojit libovolný
volume, ale práva uvnitř neobejde. Proto byste nikdy neměli spoléhat na
nastavení práv v nadřazeném adresáři, protože může být součástí jiného
volumu a při připojení do jiného místa už vám data nadřazený adresář neochrání.
Připojení nově vzniklého volumu provedeme v některém RW volumu, použijeme tedy tečkovou cestu, a vyzkoušíme do něj zápis:
~$ cd /afs/.foo.bar /afs/.foo.bar$ fs mkmount zaloha root.cell.backup /afs/.foo.bar$ ls users zaloha
Provedli jsme připojení volumu root.cell.backup
do volumu
root.cell
pod názvem zaloha
. Protože jsme BK volume
vytvořili ještě před mount pointem (což je zápis), tak bychom jej neměli
v adresáři zaloha
vidět. Po tom, co znovu vyvoláme vytvoření
BK volumu, už uvidíme i tento mount point.
/afs/.foo.bar$ ls zaloha users /afs/.foo.bar$ vos backup root.cell Created backup volume for root.cell /afs/.foo.bar$ ls zaloha/ ls: cannot access zaloha/zaloha: No such device users zaloha
V BK volumu jsou samozřejmě zálohovány i mount pointy. Ale ty, které vedou na záložní BK volumy, jsou zneplatněny, aby se zabránilo zbytečným smyčkám v adresářové struktuře. Ostatní mount pointy fungují regulérně:
/afs/.foo.bar$ cd zaloha /afs/.foo.bar/zaloha$ fs lsmount * 'users' is a mount point for volume '#users' 'zaloha' is a mount point for volume '#root.cell.backup' /afs/.foo.bar/zaloha$ ls zaloha ls: cannot access zaloha: No such device /afs/.foo.bar/zaloha$ ls users a b c d e f g h i j k l m n o p q r s t u v w x y z
Všechny výše uvedené operace jsme dělali na RW volumu. Pro volume
root.cell
nám existuje i RO kopie. S tou se ale nic nestalo,
protože jsme zatím nevyvolali její releasování. Podíváme se tedy, jak
je na tom netečkovaná (RO) větev našeho AFS stromu:
/afs/.foo.bar$ cd /afs/foo.bar /afs/foo.bar$ ls users /afs/foo.bar$ vos release root.cell Released volume root.cell successfully /afs/foo.bar$ ls users zaloha /afs/foo.bar$ ls zaloha ls: cannot access zaloha/zaloha: No such device users zaloha
BK volume lze zrušit stejně jako jakýkoliv jiný volume. Lokace BK volume je na stejném místě, jako je RW volume. Proto při jeho rušení není povinné uvádět jeho umístění:
/afs/foo.bar$ vos remove -id root.cell.backup Volume 536870917 on partition /vicepa server afssrv.foo.bar deleted /afs/foo.bar$ fs lsmount * 'users' is a mount point for volume '#users' 'zaloha' is a mount point for volume '#root.cell.backup' /afs/foo.bar$ ls zaloha ls: cannot access zaloha: Connection timed out
Volume už neexistuje, ale mount point jsme ještě nezrušili, to dává
AFS najevo právě chybou Connection timed out
. Zrušíme tedy
mount point v RW volumu a provedeme release, abychom změnu dostali i do
RO kopie:
/afs/foo.bar$ fs rmmount /afs/.foo.bar/zaloha /afs/foo.bar$ vos release root.cell Released volume root.cell successfully /afs/foo.bar$ ls users
Správný postup při rušení jakéhokoliv volumu by měl být, že nalezneme všechny mount pointy pro rušený volume. Ty odpojíme a pokud v daném volumu existuje replika, tak provedeme release volumu. Pak rušený volume zazálohujeme a odstraníme.
Do teď jsme vytvářeli BK volumy po jednom a s právy administrátora.
Lepší by bylo, kdyby se nám o to automaticky postaral systém. K tomu
slouží příkaz vos backupsys
, který provádí to samé co
vos backup
, ale dělá to hromadně dle názvů volumů.
A to je jeden z důvodů, proč byste měli v názvech volumů udržovat
nějaký systém.
Protože je to trochu citlivá operace, můžeme si nechat
vypsat jen seznam volumů, kterých se to dotkne, například:
/afs/foo.bar$ vos backupsys -dryrun -prefix user user.svamberg users done Total volumes backed up: 0; failed to backup: 0
Do záloh se nám tak nezapočítal volume tmp.user.svamberg
,
který jsme v
minulém díle
vytvořili po obnově ze souboru.
Backup volumy můžete vytvořit k libovolnému RW volumu, ale vzhledem k šetření místa se většinou tvorba těchto volumů omezuje pouze na ty, kde nemáme RO repliky. Což jsou nejčastěji uživatelské volumy. Po zadání příkazu se nám vytvoří backup volumy:
/afs/foo.bar$ vos backupsys -prefix root done Total volumes backed up: 2; failed to backup: 0
Základní konfiguraci bosserveru jsme udělali v instalačním díle. Jeho další vlastností je, že obsahuje jednoduchý cron. Můžete tedy některé operace plánovat dle času a spouštět je přímo na serveru s lokálním ověřením. Tím se vyhnete potřebě vytvářet administrátorský token. Druhou výhodou tohoto mechanismu je, že můžete úlohy plánovat a spouštět, aniž byste potřebovali na serveru účet. Za tímto účelem vám stačí (coby správce zálohování) administrátorské oprávnění do AFS a nepotřebujete mít přístup na servery AFS nebo Kerberos.
Bosserver umožňuje definovat pouze den a hodinu, kdy se má spustit
úloha. Pokud je definice dne vynechána, pak se bude provádět záloha každý den.
My si vyzkoušíme oba případy, uživatelům necháme zálohy vytvářet každý den,
a volumy s prefixem root.
budeme zálohovat vždy na konci týdne.
Každý záznam v konfiguraci bosserveru musí mít jednoznačný identifikátor v podobě názvu instance. Napřed si příkaz vyzkoušíme nanečisto:
/afs/foo.bar$ bos exec afsfs.foo.bar -cmd "/usr/bin/vos backupsys -prefix user"
Zpátky dostanete pouze chybu, pokud se program nepodařilo spustit,
ale nedostanete žádné chybové hlášení o tom, že se příkaz nepovedl, což
si můžeme dokázat výpisem volumů, kde chybí users.backup
a user.svamberg.backup
:
/afs/foo.bar$ vos listvol afsfs.foo.bar | grep backup root.afs.backup 536870914 BK 214 K On-line root.cell.backup 536870917 BK 3 K On-line
Bohuzel ani v logu nenajdete nic. Nejsnadnější je přihlásit se na server
a vyzkoušet příkaz bez tokenů. A to je právě to, co jsme zapomněli. My sice
token máme, ale bosserver nikoliv. Proto příkazu vos
řekneme,
že má použít autentizaci ze souboru /etc/openafs/server/KeyFile
.
/afs/foo.bar$ bos exec afsfs.foo.bar -cmd "/usr/bin/vos backupsys -prefix user -localauth" /afs/foo.bar$ vos listvol afsfs.foo.bar | grep backup root.afs.backup 536870914 BK 214 K On-line root.cell.backup 536870917 BK 3 K On-line user.svamberg.backup 536870923 BK 8234 K On-line users.backup 536870932 BK 55 K On-line
Nyní odzkoušený příkaz můžeme přidat do bosserveru
jako typ cron
:
/afs/foo.bar$ bos create -server afsfs.foo.bar -instance userbackup -type cron -cmd "/usr/bin/vos backupsys -prefix user -localauth" 01:30 /afs/foo.bar$ bos status afsfs.foo.bar Instance ptserver, currently running normally. Instance vlserver, currently running normally. Instance fs, currently running normally. Auxiliary status is: file server running. Instance userbackup, currently running normally. Auxiliary status is: run next at Wed Apr 20 01:30:00 2011.
Na posledních dvou řádcích vidíme náš nově přidaný záznam. Detaily o dané instanci lze zobrazit následovně:
/afs/foo.bar$ bos status afsfs.foo.bar -instance userbackup -long Instance userbackup, (type is cron) currently running normally. Auxiliary status is: run next at Wed Apr 20 01:30:00 2011. Command 1 is '/usr/bin/vos backupsys -prefix user -localauth' Command 2 is '01:30'
Ještě naplánujeme vždy na konci týdne zálohování
volumů s prefixem root.
. Navíc přidáme do nastavení
času název dne a upravíme příkaz a název instance.
/afs/foo.bar$ bos create -server afsfs.foo.bar -instance rootbackup -type cron -cmd "/usr/bin/vos backupsys -prefix root. -localauth" "sun 23:50" /afs/foo.bar$ bos status afsfs.foo.bar Instance ptserver, currently running normally. Instance vlserver, currently running normally. Instance fs, currently running normally. Auxiliary status is: file server running. Instance userbackup, currently running normally. Auxiliary status is: run next at Wed Apr 20 01:30:00 2011. Instance rootbackup, currently running normally. Auxiliary status is: run next at Sun Apr 24 23:50:00 2011.
Pokud bychom chtěli zálohovat jen v pracovní dny, pak bychom pro každý takový den museli vytvořit samostatné instance.
Od teď, pokud vytvoříme nového uživatele, se mu v noci automaticky vytvoří záložní volume, ten si může sám přípojit do svého domovského adresáře. Pokud chcete být na uživatele hodní, můžete jim to udělat už předem. Uživatelům je třeba vysvětlit, že tam najdou zálohu z druhého dne a nikdy starší. Proto pokud něco smazali, lze si to obnovit z předchozího dne nejpozději do 1:30 (v našem případě). Jinak vás musí požádat o rozbalení většinou starší zálohy z dumpu, tak jak jsme si ukázali v minulém díle.
Proces vytváření backup volumů probíhá sekvenčně, což nezatěžuje tolik
souborové servery, ale u velkého množství (desetitisíce) volumů se může
protáhnout na několik hodin. Při plánování vhodného začátku je potřeba
zkontrolovat i konec zálohování, zda se nepřekrývá s běžným začátkem
práce uživatelů. K tomu stačí vylistovat si seznam dotčených volumů
(viz výše příkaz vos backupsys -dryrun)
a provést vos examine
na poslední volume, ve výpisu bude
uveden datum a čas vytvoření BK volumu.
V minulém dílu jsme udělali drobný nepořádek, je na čase jej uklidit:
~$ cd /afs/foo.bar/users/s/svamberg /afs/foo.bar/users/s/svamberg$ rm -rf home/tmp /afs/foo.bar/users/s/svamberg$ fs setacl home system:administrators none
Dále nám zůstal z minulého dílu volume tmp.user.svamberg
,
odstraníme jeho mount point i vlastní volume:
/afs/foo.bar/users/s/svamberg$ fs rmmount backup /afs/foo.bar/users/s/svamberg$ vos remove -id tmp.user.svamberg
Toto je druhý způsob, jak provádět v AFS zálohování. Jde o snadné řešení,
které je jednoduše přístupné a konfigurovatelné. Existuje ještě třetí možnost,
využít Backup Server (proces buserver
). Ale vzhledem k náročnosti
tohoto řešení si jej necháme na některý z jiných dílů.
V příštím díle si k souborovému serveru připojíme druhé úložiště a vyzkoušíme přesun volumu mezi nimi. Dále si řekneme co je to PAG a jak jej můžete využít v praxi.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: