Man Yue Mo z GitHub Security Lab se podrobně rozepsal o již opravené zranitelnosti CVE-2023-6241 v Arm Mali GPU umožňující získání roota na telefonu Pixel 8 s povoleným MTE (Memory Tagging Extension).
V San José probíhá vývojářská konference NVIDIA GTC 2024. CEO společnosti NVIDIA Jensen Huang měl dvouhodinovou keynote, ve které představil celou řadu novinek: NVIDIA Blackwell platform, NVIDIA NIM microservices, NVIDIA Omniverse Cloud APIs, Project GR00T, …
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Od 21. do 23. března proběhnou Arduino Days 2024. Sledovat bude možné oficiální streamy. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.
Letošní ročník konference LinuxDays se uskuteční o víkendu 12. a 13. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během letošního ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru, Facebooku nebo na Mastodonu, přidat se můžete také do telegramové diskusní skupiny.
Byla vydána nová major verze 2.0.0 a krátce na to opravné verze 2.0.1 open source online editoru Etherpad (Wikipedie) umožňujícího společné úpravy v reálném čase.
Matematický software GNU Octave byl vydán ve verzi 9.1.0. Podrobnosti v poznámkách k vydání. Nově je preferovaný grafický backend Qt a preferovaná verze Qt 6. V tomto vydání byly přepracovány funkce pro převod čísel z desítkové soustavy. Jako obvykle jsou zahrnuta také výkonnostní vylepšení a zlepšení kompatibility s Matlabem.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu březnový souhrn novinek. Vypíchnout lze, že pracují na virtuálním asistentu PineVox a zatím bezejmenných sluchátkách na lícní kosti (bone conduction).
Hyprland, kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, je již dva roky starý. Při té příležitosti byla vydána verze 0.37.0 (a záhy opravná 0.37.1 řešící chybu ve vykreslování oken). Nově závisí na knihovně hyprcursor, která poskytuje škálovatelné kurzory myši.
V minulých dílech proběhly diskuse, zda termín volume by neměl být v článcích překládán jako svazek. Oslovil jsem tedy několik administrátorů i uživatelů AFS a všichni se shodli na anglickém volume. Český jazyk má oproti angličtině skloňování a použití neskloňovaného tvaru může při četbě působit rušivým dojmem, proto jej v textu navíc skloňuji. Dalším důvodem je, že většina dokumentace k AFS je v angličtině a český ekvivalent mi nepřišel tak zavedený jako anglický. Chtěl jsem se tím vyhnout případným nedorozuměním, na což je vhodnější opět anglický termín. Tento odstavec neznamená, že pojem svazek zavrhuji, ale technická dokumentace by měla být konzistentní a přitom zachovat dobrou čtivost, kterou nebudou narušovat hrubky, špatné skloňování nebo struktura textu. Berte to tak, že jako autor (ať to zní sebevíc despoticky) jsem se rozhodl pro termín volume, který hodlám dále používat.
Tak jako každý souborový systém, i tento má své limity. Maximální velikost
jednotlivých partition (/vicepX) může být 16 zettabytů (2^64 KB), u starších
verzí to bývaly 2 TB. Doporučovaná maximální velikost volumu a zároveň
největšího souboru v AFS je do 2 TB (2^41 bytů). Větší volumy lze vytvářet,
ale není to příliš praktické a mohou se vyskytnout drobné problémy, například
nemožnost nastavit kvótu. Název volumu je omezen na 22 znaků, ve skutečnosti
je to 32 znaků, ale 10 je vyhrazeno pro systémové přípony
(známe už .readonly
nebo .backup
).
Vývojáři OpenAFS připravují prodloužení názvu volumu.
Dalším limitem je počet souborů v jednom adresáři. Maximum je sice stanoveno na 64 tisíc, ale v praxi se doporučuje 16-24 tisíc v závislosti na délce názvů souborů.
AFS používá pro řízení přístupu Access Control List (ACL), které se aplikují na adresář (ve vývoji je možnost přiřadit ACL jednotlivým souborům). Na každý adresář lze aplikovat až 20 přístupových pravidel. Pokud potřebujete více, musíte si vytvořit skupinu. Toto omezení má významné pozitivum – nutí vás udržovat pořádek. V AFS, na rozdíl od unixových skupin, si může uživatel vytvořit a spravovat vlastní skupiny, což je jedna ze zajímavých vlastností.
Při tom všem nesmíte zapomínat na limity souborového systému na partitionách (/vicepX), doporučuje se souborový systém XFS či ZFS, ale je možné použít i jiné. Volnost pro výběr souborového systému platí pro servery, u klientů je výběr omezen a záleží na operačním systému klienta. Z vlastní zkušenosti doporučuji vyhnout se na produkčních serverech ReiserFS a Ext2/3, protože mají dlouho trvající kontroly konzistence a tím výrazně snižují dostupnost serveru.
Existují dva důležité volumy, které byste měli mít replikované.
Volume root.afs
obsahuje přípojné body (mount pointy) pro
klienty. Tento volume je vstupním bodem do AFS stromu. Klient se může
rozhodnout, zda použije předpřipravený od administrátora, nebo jej bude
dynamicky vytvářet z informací v souboru CellServDB či speciálních záznamů
uvedených v DNS.
Druhý volume root.cell
je kořenem vaší AFS buňky. Do tohoto
volumu připojujete další volumy a tak vytváříte adresářovou strukturu.
Pro oba volumy platí, že by neměly obsahovat vlastní data, ale pouze
mount pointy. Zároveň by měly být replikovány na co nejvíce serverů, protože
je budou používat všichni klienti.
Níže je příklad základní struktury AFS stromu. Inspiraci lze také nalézt v ostatních buňkách, ty se naučíme připojovat v příštím díle.
/ `-- afs # volume root.afs `-- foo.bar # volume root.cell |-- amd64_linux26 # volume sw.amd64_linux26 |-- common # volume common |-- i386_linux26 # volume sw.i386_linux26 |-- public # volume public `-- users # volume users |-- l # adresář "l" ve volumu users | |-- list # volume user.list | `-- lojza # volume user.lojza `-- m # adresář "m" ve volumu users `-- moula # volume user.moula
První dva adresáře v AFS stromu nám zajišťují
volumy root.afs
a root.cell
.
V třetí úrovni je to už jen na vás. Nejčastěji zde naleznete adresáře
(mount pointy na volumy) s názvy:
common
etc
.public
rl
pro skupinu
system:anyuser
, o právech a skupinách bude samostatný díl.users
users/l/lojza
nebo users/l/lo/lojza
. Důvodem je snížení počtu mount pointů ve
stejném adresáři a tím zkrácení doby čekání klienta na kompletní výpis
obsahu. Pro každého uživatele se předpokládá samostatný volume.@sys
, více v dalších odstavcích.
Mount pointy jsou pojmenovanými odkazy na jiné volumy, které se na první
pohled tváří jako adresář. Je to podobné jako mount point, který vytvoříte
příkazem mount
v Unixu – do daného adresáře se připojí souborový
systém, jen s tím rozdílem, že v AFS budeme takto propojovat volumy.
Ve skutečnosti existuje několik typů mount pointů, které se podle toho
také vytvářejí příkazem fs mkmount
:
fs mkmount <dir> <volume> -rw
fs lsmount
bude uveden jako %volume
fs mkmount <dir> <volume>
#volume
.
Cache manager (klient) se snaží držet stejného typu volumu z jakého přistupujeme
k mount pointu. Pokud ale RO volume neexistuje, automaticky
použije RW volume. Jestliže se nacházíme v RW volumu,
pak nám nabídne opět RW volume. Z toho nám
vyplývá, že pro každou buňku existují dvě základní AFS větve: RW určená
spíše pro administrátory a RO pro uživatele.
fs mkmount <dir> <volume.readonly>
volumentame.readonly
.
fs mkmount <dir> <volume.backup>
#volume.backup
.
fs mkmount <dir> <volume> -cell <buňka>
#zcu.cz:root.cell
Na příkladu cesty /afs/zcu.cz/software/i386_linux26/usr/lib
si ukážeme, jak to funguje. Cache manager (AFS klient) připojí AFS strom
do adresáře /afs
a pro jeho obsah použije automaticky volume
root.afs
ze své domovské buňky. Tento volume slouží výhradně
jako rozcestník pro jednotlivé AFS buňky, proto tedy pod názvem
zcu.cz
je připojen volume root.cell
s obsahem
podstromu vlastní buňky.
Na obrázku je také vidět odkazy do jiných AFS buňek, jako je
kiv.zcu.cz
. Zajímavou vlastností AFS klienta je, že řetězec
@sys
v cestě vždy nahradí definovanou hodnotou odvislou od
architektury klienta. Tuto hodnotu zjistíme příkazem
fs sysname
a můžeme
ji také změnit. Výhodou je, že získáme pod jedinou cestou
/afs/zcu.cz/software/bin/
použitou ve skriptu
nebo proměnném prostředí přístup ke správné cestě pro danou architekturu.
Pokud je systémové jméno (sysname) nastaveno na amd64_linux26
,
pak nás AFS klient odkáže do cesty /afs/zcu.cz/software/amd64_linux26/bin
.
V případě jiné architektury bude cestu expandovat k jiným binárkám. Tato
vlastnost se používá u symbolických linků nebo ve skriptech.
Protože @sys
je trochu nezvyklý, ukážeme si na příkladu,
jak na něj. Řekněme, že pro zlepšení vztahů na pracovišti jste připravili
uživatelům hru Quake v podobě OpenArena. Ale jako s každým binárním programem
je zde problém, jak uživatelům distribuovat na počítače správnou architekturu.
Podle obrázku výše, umístíte jednotlivé architektury do zvláštních adresářů.
Takže pro amd64 architekturu na jádře linuxu řady 2.6 soubory rozbalíme do
adm64_linux26
, pro i386 obdobně do i386_linux26
.
Do proměnného prostředí všech klientů, nezávisle na architektuře,
nám stačí přidat cestu:
PATH=$PATH:/afs/zcu.cz/software/bin/
AFS klient pak symbolický link bin -> @sys/bin
expanduje dle svého prostředí, pro 32bit architekturu to
bude bin -> i386_linux26/bin
čímž se automaticky
dostává uživatel ke správné binárce.
Tuto vlastnost si můžete snadno vyzkoušet, ale musíte si vzpomenout na heslo z druhého dílu:
~$ kinit afsadmin@FOO.BAR Password for afsadmin@FOO.BAR: ~$ aklog ~$ cd /afs/foo.bar/ /afs/foo.bar$ mkdir i386_linux24 i386_linux26 amd64_linux26 /afs/foo.bar$ fs sysname Current sysname is 'amd64_linux26' /afs/foo.bar$ ln -s @sys arch /afs/foo.bar$ ls -l celkem 7 drwxr-xr-x 2 daemon svamberg 2048 27. bře 12.48 amd64_linux26 lrwxr-xr-x 1 daemon root 4 27. bře 12.49 arch -> @sys drwxr-xr-x 2 daemon svamberg 2048 27. bře 12.47 i386_linux24 drwxr-xr-x 2 daemon svamberg 2048 27. bře 12.47 i386_linux26 /afs/foo.bar$ touch @sys/touch_sys arch/touch_arch /afs/foo.bar$ find . . ./i386_linux24 ./i386_linux26 ./amd64_linux26 ./amd64_linux26/touch_sys ./amd64_linux26/touch_arch ./arch /afs/foo.bar$ rm -rf * ; cd ; unlog ; kdestroy
Jak je vidět, soubory touch_*
se vytvořily pouze v adresáři
dle mé architektury, kterou byla amd64_linux26
, přestože
jsem je v příkazu touch
vůbec nepoužil a ani symbolický
link arch
na žádný konkrétní neukazuje. Posledním sadou
příkazů po sobě uklidíme, a také si zrušíme všechna oprávnění, protože
to bude potřeba pro vysvětlení v další kapitole.
Pokud jste si podle druhého dílu zprovoznili AFS, můžete
si nyní vyzkoušet pár příkazů ve kterých zhodnotíme získané znalosti. Vaše
AFS buňka foo.bar
by nyní měla být funkční, avšak nic v ní
nevidíte, přestože je připojená.
~$ df /afs Filesystem 1K-blocks Used Available Use% Mounted on AFS 9000000 0 9000000 0% /afs ~$ ls -la /afs ls: cannot open directory /afs: Permission denied
To je způsobené tím, že jsme při instalaci sice vytvořili kořenový volume
root.afs
, ale nenastavili jsme žádná práva k němu, defaultně tedy
k němu mají přístup pouze administrátoři. Nepomůžou vám ani oprávnění uživatele
root:
~# id uid=0(root) gid=0(root) groups=0(root) ~# ls -la /afs ls: cannot open directory /afs: Permission denied
Potřebujeme se napřed ověřit u Kerbera:
~$ kinit afsadmin Password for afsadmin@FOO.BAR: ~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: afsadmin@FOO.BAR Valid starting Expires Service principal 03/06/11 14:39:46 03/07/11 00:39:46 krbtgt/FOO.BAR@FOO.BAR renew until 03/07/11 14:39:43
a následně vytvořit token pro AFS:
~$ aklog ~$ tokens Tokens held by the Cache Manager: User's (AFS ID 1) tokens for afs@foo.bar [Expires Mar 7 00:39] --End of list--
Při opakovaném příkazu klist
si všimněte, že přibyl další
záznam, a to pro službu afs
v doméně (buňce) foo.bar
z Kerberos realmu FOO.BAR
.
~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: afsadmin@FOO.BAR Valid starting Expires Service principal 03/06/11 14:39:46 03/07/11 00:39:46 krbtgt/FOO.BAR@FOO.BAR renew until 03/07/11 14:39:43 03/06/11 14:41:40 03/07/11 00:39:46 afs/foo.bar@FOO.BAR renew until 03/07/11 14:39:43
AFS má vlastní systém práv i uživatelů, proto teď s pověřením platným do 00:39
můžeme přistupovat jako uživatel afsadmin (ve skutečnosti s principalem
afsadmin@FOO.BAR
) k naší buňce. Trik totiž spočívá v tom, že
tento principal je součástí skupiny system:administrators
, což
jsme zařídili při instalaci, detailněji v samostatném článku. Výsledkem je,
že nám bude fungovat ls
:
~$ ls -la /afs total 6 drwxrwxrwx 2 root root 2048 Feb 22 22:11 . drwxr-xr-x 24 root root 4096 Feb 22 17:43 ..
Už jsme se zbavili otravného Permission denied
, ale stále nic nevidíme,
přesto tam volume je, jen nemá obsah. Pro jistotu zjistíme, v jakém volumu se
nacházíme (měl by to být root.afs
, viz druhý řádek výpisu) a
jeho vlastnosti již známým příkazem vos examine
:
~$ fs examine /afs | nl 1 File /afs (536870912.1.1) contained in volume 536870912 2 Volume status for vid = 536870912 named root.afs 3 Current disk quota is 5000 4 Current blocks used are 2 5 The partition has 18395280 blocks available out of 19593852 ~$ vos examine root.afs root.afs 536870912 RW 2 K On-line afssrv.foo.bar /vicepa RWrite 536870912 ROnly 0 Backup 0 MaxQuota 5000 K Creation Tue Feb 22 22:11:22 2011 Copy Tue Feb 22 22:11:22 2011 Backup Never Last Access Sun Mar 6 14:56:14 2011 Last Update Tue Feb 22 22:11:22 2011 12 accesses in the past day (i.e., vnode references) RWrite: 536870912 number of sites -> 1 server afssrv.foo.bar partition /vicepa RW Site
Z instalace máme ještě volume root.cell
, bylo by záhodno jej
připojit do kořenového volumu a zkontrolovat:
~$ cd /afs /afs$ fs mkmount foo.bar root.cell /afs$ ls -la total 8 drwxrwxrwx 2 root root 2048 Mar 6 15:16 . drwxr-xr-x 23 root root 4096 Mar 6 15:08 .. drwxrwxrwx 2 root root 2048 Feb 22 22:11 foo.bar /afs$ fs lsmount * 'foo.bar' is a mount point for volume '#root.cell'
V příkladech jste si mohli všimnout, že je rozpor mezi nápovědou jednotlivých příkazů a tím, co občas v příkladech uvádím. Všechny příkazy od AFS podporují vlastnost, že když zachováváte pořadí parametrů bez jejich vynechávání, tak nemusíte uvádět jejich přepínače. Dokonce, pokud jsou přepínače jednoznačné, můžete je i zkracovat. Zápisy níže jsou ekvivalentní k uvedené nápovědě:
~$ fs help mkmount fs mkmount: make mount point Usage: fs mkmount -dir <directory> -vol <volume name> [-cell <cell name>] [-rw] [-fast] [-help] Where: -rw force r/w volume -fast don't check name with VLDB ~$ fs mkmount foo.bar root.cell ~$ fs mkmount foo.bar -vol root.cell ~$ fs mkmount -vol root.cell -dir foo.bar ~$ fs mk -v root.cell -d foo.bar
Ačkoliv ze začátku je hodně práce, tak v budoucnu budete při administraci rádi za to, jak je to zařízené. Postupně se dostáváme od základního vysvětlování pojmů k praktickým věcem a tento poměr se bude stále vylepšovat.
Příští díl bude věnován uživatelům, skupinám a jejich oprávněním. Pokud stále zvažujete, zda si máte OpenAFS nainstalovat, tak je nejvyšší čas, protože to bude čím dál zajímavější a bez řádného vyzkoušení to není ono.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
bytů/bajtů/bitů
, nejsem si jistý, ale to první je spíše na bydlení