Byla vydána nová verze 9.10 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Český LibreOffice tým vydává překlad příručky LibreOffice Math 24.8. Math je modul editoru vzorců v kancelářském balíku LibreOffice a poskytuje možnosti rozvržení pro zobrazení matematických, chemických, elektrických nebo vědeckých vzorců ve standardní písemné notaci. Příručka je ke stažení na stránce dokumentace.
Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2024. Ke konci roku 2024 vlastnila 305 180 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250211 mikrokódů pro své procesory řešící 5 bezpečnostních chyb.
Byla vydána nová verze 1.24 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
Jiří Eischmann upozorňuje, že GNOME nemá české překladatele: "Posledních minimálně 15 let byly překlady GNOME do češtiny ve výborném stavu. U každého vydání jsem jen hlásil, že je vše přeložené, poslední roky to platilo i pro drtivou většinu dokumentace. Poslední rok se to ale začalo zadrhávat. Přispěvatelé, kteří to dlouhé roky táhli, odešli a není nikdo, kdo by to po nich převzal. Proto jsme se rozhodli jít s pravdou ven: GNOME momentálně nemá české překladatele a pokud se toho neujme někdo nový, překlady začnou postupně upadat."
Otevřený zvukový bezztrátový kodek FLAC (Free Lossless Audio Codec, Wikipedie) byl vydán v nové verzi 1.5.0. Hlavní novinkou je podpora vícevláknového kódování. V prosinci loňského roku byl FLAC formálně specifikován v RFC 9639.
Evropská unie hodlá iniciovat investice do rozvoje umělé inteligence v hodnotě 200 miliard eur, v přepočtu zhruba pět bilionů korun. V projevu na summitu o umělé inteligenci v Paříži to v úterý řekla předsedkyně Evropské komise Ursula von der Leyenová. Umělá inteligence podle ní může přispět mimo jiné ke zvýšení konkurenceschopnosti.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.3 (Mastodon). Přehled novinek i s videi a se snímky obrazovky v oficiálním oznámení. Podrobný přehled v seznamu změn.
Lennart Poettering se na Mastodonu rozepsal o novince v systemd, na které pracuje: systemd bude umět nabootovat z obrazu disku staženého pomocí HTTP v rámci initrd.
O replikaci mluvíme, když z RW volumu vytváříme RO volum(y) jako jeho kopie.
Operaci vos release
, která replikaci provádí,
použijeme vždy, když chceme promítnout jakékoliv změny z RW do RO, a to včetně
změny ACL nebo úprav mount pointů uvnitř volumu. Původní obsah RO není nijak zachován.
K tomuto účelu se používají zálohovací mechanismy o nichž bude samostatný díl.
Již dříve jsem psal, že volumy root.afs
a root.cell
jsou nejdůležitější a rozhodně by měly být replikovány. To zatím ani jeden
z nich není, například root.afs
má jen RW kopii
(vizte řádek 3 a výpis VLDB na řádkách 11-13):
~$ vos examine root.afs | nl 1 root.afs 536870912 RW 3 K On-line 2 afssrv.foo.bar /vicepa 3 RWrite 536870912 ROnly 0 Backup 0 4 MaxQuota 5000 K 5 Creation Tue Feb 22 22:11:22 2011 6 Copy Tue Feb 22 22:11:22 2011 7 Backup Never 8 Last Access Mon Mar 7 08:02:42 2011 9 Last Update Sun Mar 6 18:09:49 2011 10 1 accesses in the past day (i.e., vnode references) 11 RWrite: 536870912 12 number of sites -> 1 13 server afssrv.foo.bar partition /vicepa RW Site
Na každém serveru lze vytvořit pouze jednu RO kopii, více jich stejně postrádá smysl, protože RO má sloužit zvláště jako prostředek pro zvýšení dostupnosti dat a rozložení zátěže mezi servery. Na serveru, který vlastní RW kopii, je vhodné vytvořit RO na stejné partition jako je RW, šetří se tak místem, na disk jsou zapisovány pouze rozdíly.
Napřed nadefinujeme (s administrátorským oprávněním, takže nezapomenout na
kinit
a aklog
), na kterou lokaci
(server a partition) umístíme RO
kopii. My máme pouze jeden server s jednou partition, ale to pro vytvoření
a kontrolu stačí:
~$ vos addsite -server afsfs.foo.bar -partition vicepa -id root.afs Added replication site afsfs.foo.bar /vicepa for volume root.afs ~$ vos examine root.afs | nl 1 root.afs 536870912 RW 3 K On-line 2 afssrv.foo.bar /vicepa 3 RWrite 536870912 ROnly 0 Backup 0 4 MaxQuota 5000 K 5 Creation Tue Feb 22 22:11:22 2011 6 Copy Tue Feb 22 22:11:22 2011 7 Backup Never 8 Last Access Mon Mar 7 08:02:42 2011 9 Last Update Sun Mar 6 18:09:49 2011 10 1 accesses in the past day (i.e., vnode references) 11 RWrite: 536870912 12 number of sites -> 2 13 server afssrv.foo.bar partition /vicepa RW Site 14 server afssrv.foo.bar partition /vicepa RO Site -- Not released
Oproti minulému výpisu nám přibyl pouze řádek 14, přitom si všimněte, že na řádku 3 je identifikátor RO volumu stále nastaven na nulu. To znamená, že existuje pouze záznam ve VLDB a nemáme žádnou validní RO kopii (přestože číselný identifikátor byl rezervován už při vytvoření RW volumu). Provedeme tedy release a opět zkontrolujeme výpis:
~$ $ vos release root.afs Released volume root.afs successfully ~$ vos examine root.afs | nl 1 root.afs 536870912 RW 3 K On-line 2 afssrv.foo.bar /vicepa 3 RWrite 536870912 ROnly 536870913 Backup 0 4 MaxQuota 5000 K 5 Creation Tue Feb 22 22:11:22 2011 6 Copy Tue Feb 22 22:11:22 2011 7 Backup Never 8 Last Access Mon Mar 7 08:02:42 2011 9 Last Update Sun Mar 6 18:09:49 2011 10 1 accesses in the past day (i.e., vnode references) 11 RWrite: 536870912 ROnly: 536870913 12 number of sites -> 2 13 server afssrv.foo.bar partition /vicepa RW Site 14 server afssrv.foo.bar partition /vicepa RO Site
Nyní je vše v pořádku, máme RW i RO kopie sesynchronizované, což nám dokazují řádky 3, 11, 13 a 14. Vidíme přidělený identifikátor RO kopie; ten je vždy lichý a o jedna vyšší než identifikátor RW volumu.
Tím nám ale vznikl trochu problém, protože AFS klient se primárně pokouší
o přístup k RO volumu root.afs
, což znamená, že bychom měli do
/afs/
ztratit zápis. Ve skutečnosti klient používá mapovací tabulku
s informacemi o volumech, které si typicky obnovuje jednou za hodinu. Pamatuje
si, že k našemu RW volumu neexistuje RO, proto bude nejdéle ještě hodinu
nabízet RW. Mechanismus mapování opět urychluje přístup k datům, protože
se takto vyhneme opakovaným kontaktováním Volume Location serverů.
Proto napřed použijeme příkaz fs checkvolumes
, který
mapování volumů
pročistí. Dále uvolníme z klienta informace o volumech příkazem
fs flushvolume
. Cílem je, aby adresář (mount point)
/afs
byl brán z volumu root.afs.readonly
což si
ověříme příkazem fs examine
. Při testech se mi stávalo,
že to chvilku klientovi trvalo a to obzvláště, když pracovní adresář
flush příkazů byl v dotčeném volumu.
~$ fs checkvolumes All volumeID/name mappings checked. ~$ fs flushvolume /afs/foo.bar ~$ fs examine /afs File /afs (536870913.1.1) contained in volume 536870913 Volume status for vid = 536870913 named root.afs.readonly Current disk quota is 5000 Current blocks used are 3 The partition has 18395132 blocks available out of 19593852 ~$ mkdir /afs/test mkdir: cannot create directory `/afs/test': Read-only file system
Abychom v kořenovém volumu mohli provádět změny, musíme si připojit jeho RW
kopii, ale to můžeme udělat pouze v nějakém RW volumu, naštěstí máme ještě
volume root.cell
, kterému jsme RO repliku nevytvořili, klientovi
tak nezbude nic jiného, než nám nabídnout RW. Pro jistotu si vynutíme
mount point odkazující na RW (ale není nutné):
~$ fs mkmount -dir /afs/foo.bar/root -vol root.afs -rw ~$ cd /afs/foo.bar/root /afs/foo.bar/root$ ls -A foo.bar
Tím se nám podařilo vytvořit smyčku, kterou nám detekuje
také find .
. To důležité je, že jsme v RW kopii volumu
a můžeme začít provádět změny.
Zvláště aby si administrátoři ušetřili práci a nemuseli pracně hledat RW volume nebo jej někde po kradmu připojovat jako teď, tak si připravují RW větev své buňky, uživatelům jej schovávají jako skrytý tečkový adresář:
/afs/foo.bar/root$ fs mkmount .foo.bar root.cell -rw /afs/foo.bar/root$ ls -A .foo.bar foo.bar
Tuto logicky náročnější operaci se pokusím shrnout. Po vytvoření RO kopie
nám ji začal automaticky klient nabízet. Problém nám nastal
ve chvíli, kdy jsme chtěli do kořene zapsat. To lze udělat tak, že si
vytvoříme nový mount point s vynucenou cestou k RW volumu. Vytvořit mount
point lze v libovolném RW volumu a takový máme v podobě volumu
root.cell
v cestě /afs/foo.bar/
. Po připojení RW
volumu do /afs/foo.bar/root
do něj můžeme zapisovat a to jsme
chtěli. V této chvíli tedy máme RO a RW volumy připojeny na různých místech,
a to dokonce tak, že nám tvoří smyčku, protože můžeme použít například
cestu /afs/foo.bar/root/foo.bar/root/foo.bar/root
. Na konci
dílu dáme vše do původního stavu, předtím si ještě vytvoříme odkazy na jiné
buňky abychom se mohli porozhlédnout po světě.
AFS klienta máme přednastaveného tak, aby se nesnažil při startu
zjistit jak to vypadá ve světě, ale použil přímo volume root.afs
ze své domovské buňky. Toto je doporučené řešení, protože nezpomaluje start
systému snahou o kontaktování ostatních buněk. Problém je, že se nedostaneme
nikam jinam, pokud si nevytvoříme statické mount pointy, obvykle v cestě
/afs/world/
. Existující buňky ve veřejném prostoru jsou dobrovolně
registrovány u grand.central.org. Tento
seznam známý jako CellServDB
se pak přidává do distribucí a
my jej použijeme pro vytvoření mount pointů do světa.
Ze seznamu musíme napřed vypreparovat názvy buněk
(označeny prefixem >
) a zbavit se všeho ostatního.
Pro vytvoření mount pointu použijeme známý fs mkmount
s parametry
-cell
a -fast
, jenž nám vypne kontrolu volumu vůči VLDB
a významně urychlí tvorbu mount pointů. Celá konstrukce není úplně nejhezčí,
ale je funkční:
/afs/foo.bar/root$ mkdir world && cd world /afs/foo.bar/root/world$ for i in `cat /etc/openafs/CellServDB | sed -rn 's/^>([^ ]*).*/\1/p'` ; do fs mkmount $i root.cell -cell $i -fast ; done /afs/foo.bar/root/world$ ls grand.central.org archive cvs doc local project service software user www
První přístup do adresáře vždy trvá delší dobu, pak už to docela jde. Vytvářet
mount pointy na cizí root.afs
volumy je také možné, ale v nich
většinou naleznete podobné věci jako máme teď my, tedy odkazy do
ostatních buněk.
Z minula si ještě procvičíme nastavování práv.
Přístup do adresáře world
dáme pouze našim vlastním uživatelům,
ať si každý administrátor své buňky vytváří svůj vlastní rozcestník. Primárně
záleží na vaší bezpečnostní politice, zda dáte přístup všem nebo jen
vybrané skupině (např. autentizovaným uživatelům v našem případě):
/afs/foo.bar/root/world$ fs listacl . Access list for . is Normal rights: system:administrators rlidwka system:anyuser rl /afs/foo.bar/root/world$ fs setacl . system:anyuser none system:authuser rl /afs/foo.bar/root/world$ fs listacl . Access list for . is Normal rights: system:administrators rlidwka system:authuser rl
Zrušili jsme oprávnění pro skupinu system:anyuser
a místo
něj přidali skupinu system:authuser
. Příkaz lze
rozdělit na dva samostatné, ale setacl
umožňuje
serializovat oprávnění, tak proč to nevyužít. Od teď musíte mít platný
token pro buňku foo.bar
pro přístup do adresáře world
.
Nyní volume root.afs
musíme releasovat, aby se změny
projevily v RO volumu v cestě /afs
.
/afs/foo.bar/root/world$ vos release root.afs Released volume root.afs successfully /afs/foo.bar/root/world$ cd /afs /afs$ ls -A .foo.bar foo.bar world
A nyní nezbývá než úklid v podobě zrušení mount
pointu na RW kopii volumu root.afs
:
/afs$ fs rmmount /afs/foo.bar/root
Pokud se hodláte otevřít světu, měli byste upravit pravidla pro
firewall. Pro klienty je to relativně jednoduché, stačí povolit
port 7001 na UDP z celého světa, protože AFS file servery se nás mohou snažit
kontaktovat zpátky, tzv. callback. Větší překážkou bývají konfigurace conntracku u NATu,
který uzavře spojení předčasně, proto je vhodné zvýšit na firewallu
tyto hodnoty v souboru /etc/sysctl.conf
net.ipv4.netfilter.ip_conntrack_udp_timeout=780 net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=900
a zavést do systému příkazem sysctl -p
.
Pro přístup klientů k vašemu serveru je třeba nyní povolit UDP porty 7000 (fileserver), 7002 (ptserver), 7003 (vlserver), 7005 (volserver) a 7007 (bosserver). Pokud nechcete být příliš restriktivní, můžete povolit celou skupinu AFS portů v rozmezí od 7000 do 7009 na UDP, a to všem potencionálním klientům. V případě veřejné adresy serveru by to mělo být celému světu.
Tím naprosto vyřazujeme funkčnost firewallu pro AFS porty včetně klienta. Důvodem u klienta nejsou jen zpětná volání (callbacks) jež se dají řešit nastavením firewallu, ale i možnost ladění a sledování. Součástí AFS je několik nástrojů pro vzdálené sledování jak serverů tak klientů. Pokud si někdo stěžuje na potíže, můžete si vzdáleně přečíst informace o klientovi. A z hlediska správce by byla velká škoda se o takovou možnost připravit.
Koncept RW a RO volumů se může zdát v této chvíli trochu zmatený, ale berte to z pohledu velké organizace. Potřebujete mít co nejvyšší dostupnost, což vám zajišťují RO kopie rozprostřené přes více serverů, ale jako správci máte potřebu provádět v systému úpravy. Typickým příkladem je například softwarové vybavení, uživatelům nabídnete verzi v RO kopiích volumu, přitom sami můžete připravovat novou verzi v RW volumu. Až to budete mít vyzkoušené, provedete release a všichni uživatelé dostanou připravenou a odzkoušenou verzi programu. Když do toho zapojíte i systém mount pointů můžete mít pro každou verzi samostatné volumy (např. prog1.1, prog1.2) a jen uživatelům vyměňovat mount point. Pokud si někdo bude stěžovat na problém, můžete jej řešit a ladit v RW části dané verze. Nezřídka se stává, že potřebujete tentýž program provozovat v různých verzích. Nepropadejte panice, v příštích dílech budeme s volumy opět pracovat a časem vám to přijde naprosto samozřejmé.
Nyní můžete zkoumat, jak to mají vyřešené na jiných AFS buňkách, můžete
používat všechny informativní příkazy i na cizí buňky (například
vos examine root.cell -cell grand.central.org
nebo
fs listacl
). V příštím díle se vrátíme zpátky k oprávněním,
uživatelům a skupinám, přitom budeme stále vylepšovat naši buňku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: