Portál AbcLinuxu, 26. dubna 2024 09:44
V tomto díle se budeme věnovat čerstvě vytvořenému uživateli z minulého dílu. Založíme mu volume, nastavíme mu jednoduché zálohování a ukážeme, jak si může vytvořit vlastní skupinu.
Takto založíme uživatelský volume, který pojmenujeme
user.svamberg podle jeho loginu. Pro provedení operace
nezapomeňte na
kinit a aklog
vaší správcovské identity:
~$ vos create afsfs.foo.bar /vicepa user.svamberg Volume 536870921 created on partition /vicepa of afsfs.foo.barV pátem díle jsme si ukazovali typickou strukturu AFS, ve které se nachází adresář
users:
Ve skutečnosti půjde o malý samostatný volume users, do kterého
budeme připojovat uživatelské volumy. Výhodou tohoto „drobení“ je, že až
budeme připojovat další uživatelský volume, nebudeme muset releasovat
celý základní
volume root.cell, ale pouze volume users. Ten
vytvoříme včetně RO kopie (pro příkaz vos addsite vizte
sedmý díl ) a připojíme do
/afs/foo.bar/:
~$ vos create afsfs.foo.bar /vicepa users Volume 536870930 created on partition /vicepa of afsfs.foo.bar ~$ vos addsite afsfs.foo.bar /vicepa users Added replication site afsfs.foo.bar /vicepa for volume users ~$ vos release users Released volume users successfully ~$ fs mkmount /afs/.foo.bar/users users ~$ ls /afs/foo.bar users
Máme tedy připojen volume users do volumu root.cell,
a přestože jsme jej připojili do RW cesty (použili jsme tečkovanou cestu),
objevil se mount point i v netečkované cestě. To je dáno tím, že jsme pro
volume root.cell ještě nevytvořili RO kopii. Opět
nadefinujeme lokaci, kam umístíme RO kopii (v našem virtuálu
máme jen jednu partition) a provedeme její release:
~$ vos addsite afsfs.foo.bar /vicepa root.cell Added replication site afsfs.foo.bar /vicepa for volume root.cell ~$ vos release root.cell Released volume root.cell successfully
Tím jsme vytvořili RO kopii pro cestu /afs/foo.bar/,
na první pohled se nic nezměnilo, protože již existující obsah RW,
který nám byl již nabízen, se okopíroval do RO a začal se v této cestě
ukazovat. A taky zcela určitě opět zafungovala cache klienta, které
bude chvilku trvat než zjistí změnu. Nás to trápit nemusí, obsahy jsou
stejné a my máme jinou práci, musíme připojit ještě uživatelský volume
user.svamberg.
Při vytváření AFS stromu by jste se měli vyvarovat místům, kde se vám
budou hromadit mount pointy. Rozdíl je hlavně v tom, zda chcete
zjistit pouze jméno (ls) nebo i další
informace (ls -l). Nejvíce je to pak vidět při použití
souborových manažerů. Takovým typickým adresářem s mnoha mount pointy
je část s domovskými adresáři uživatelů. Samozřejmě záleží na počtu
vašich uživatelů, my si ukázkově uděláme rozhození podle prvního písmenka
z loginu. Předpřipravíme si tedy adresáře (jako shell byl použit bash):
~$ cd /afs/.foo.bar/users
/afs/.foo.bar/users$ mkdir `echo {a..z}`
/afs/.foo.bar/users$ ls
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
A každý uživatelský volume připojíme do patřičného umístění:
/afs/.foo.bar/users$ fs mkmount s/svamberg user.svamberg
Čerstvě vytvořený volume vždy obsahuje pouze oprávnění pro skupinu
system:administrators. Je tedy potřeba nastavit práva tak,
aby uživatel mohl do svého volumu zapisovat.
Uživateli ale nedáme rovnou celý volume, ale vytvoříme v něm 3 adresáře:
/afs/.foo.bar/users$ cd s/svamberg /afs/.foo.bar/users/s/svamberg$ mkdir home mail public
Adresář home mu přidělíme jako domovský, který může používat
na různých strojích. Do tohoto adresáře nastavíme oprávnění pouze pro
něj a přidáme mu právo ADMINISTER (popis práv najdete v
šestém díle) tak, aby si oprávnění mohl upravovat.
Při té příležitosti odebereme oprávnění skupině system:administrators,
nebude tak plést uživatele a zároveň donutí správce si rozmyslet,
zda opravdu chtějí šahat uživatelům do dat. To sice stále mohou, ale napřed
by si znova museli povolit přístup. V tomto případě záleží na politice
organizace.
/afs/.foo.bar/users/s/svamberg$ fs listacl home Access list for home is Normal rights: system:administrators rlidwka /afs/.foo.bar/users/s/svamberg$ fs setacl home svamberg all system:administrators none /afs/.foo.bar/users/s/svamberg$ fs listacl home Access list for home is Normal rights: svamberg rlidwka
Pro adresář public nastavíme oprávnění tak, aby tam mohl číst
kdokoliv. Na tyto adresáře můžete nasměrovat webový server a dát tak uživatelům
snadnou možnost vytvářet stránky nebo dávat něco ke stažení. Přitom jim zůstane
ochráněn domovský adresář. Tentokrát správcovskou skupinu
vyměníme za system:anyuser:
/afs/.foo.bar/users/s/svamberg$ fs listacl public Access list for public is Normal rights: system:administrators rlidwka /afs/.foo.bar/users/s/svamberg$ fs setacl public svamberg all system:administrators none system:anyuser read /afs/.foo.bar/users/s/svamberg$ fs listacl public Access list for public is Normal rights: system:anyuser rl svamberg rlidwka
S adresářem mail se nebudeme zabývat, ale může sloužit
jako úložiště pro mailbox. Do něj může mít pak přístup pouze mailový server,
ale pošta se bude započítávat do kvóty uživatele. Pokud máte raději oddělenou
kvótu pro maily, je možné vytvořit například volume mail.svamberg
a připojit jej místo adresáře. Obdobně lze postupovat pro adresář
public, ale nedoporučoval bych to. A chybí nám nastavit oprávnění
pro kořen uživatelova volumu, zde stačí aby měla skupina system:anyuser
pouze právo lookup, uživateli nastavíme jen čtení, nechceme přeci,
aby nám do struktury zasahoval. Nastavení oprávnění na 'all' pro skupinu
system:administrators ponecháme, protože je budeme
využívat pro správcovské operace v budoucnu:
/afs/.foo.bar/users/s/svamberg$ fs setacl . svamberg read system:anyuser l
Zbývá nastavit práva v podadresářích (abecední struktuře) volumu
users.
Rozumné by bylo to udělat hned po připojení čerstvě vytvořeného volumu, ale
ukážeme si, jak si poradit i s tímto případem. Protože příkazy pro práci
s ACL neumí rekurzi, musíme si pomoci externím programem. Pro tyto operace
se výborně hodí find a v návodech k AFS jej potkáte relativně často.
My chceme projít jen aktuální adresář a všechny jeho přímé podadresáře
(-maxdepth 1), hledáme
pouze adresáře (-type d), protože práva lze nastavit jen
na adresář a vypneme optimalizaci (-noleaf), protože může
působit potíže, viz man find:
/afs/.foo.bar/users/s/svamberg$ cd /afs/.foo.bar/users
/afs/.foo.bar/users$ find . -noleaf -maxdepth 1 -type d -exec fs setacl {} system:anyuser l \;
/afs/.foo.bar/users$ fs listacl .
Access list for . is
Normal rights:
system:administrators rlidwka
system:anyuser l
Opět jsme použili pouze právo lookup, protože zde není plánováno
nic na čtení, chceme pouze dát šanci procházet se po adresářové struktuře.
Tím bychom měli mít zajištěno, že po celé délce cesty až do public
se dostane kdokoliv, zároveň se dostane do svých adresářů i uživatel.
AFS umožňuje nativně uživateli vytvářet a spravovat vlastní skupiny,
které se používají pro nastavování ACL v AFS stromu. Díky tomu mohou sami
uživatelé efektivně spravovat přístupová práva ke svým datům. Takovou
vlastnost mají jen některé souborové systémy a jde o velmi užitečnou záležitost.
Každý uživatel si může vytvořit své vlastní skupiny,
podmínkou je, aby před jménem skupiny byl jeho login oddělený
dvojtečkou. Takže pro mého uživatele svamberg si mohu
vytvořit skupinu svamberg:project. Napřed zrušíme identitu
administrátora a získáme uživatelovu identitu, se kterou si požadovanou
skupinu vytvoříme:
~$ unlog; kdestroy ~$ kinit svamberg ; aklog Password for svamberg@FOO.BAR: ~$ pts creategroup svamberg:project group svamberg:project has id -1001
Pokud se pokusím vytvořit skupinu pro někoho jiného i existujícího, získám chybu:
~$ pts creategroup afsadmin:project pts: Badly formed name (group prefix doesn't match owner?) ; unable to create group afsadmin:project
Vypsat si skupiny, které vlastním, nelze příkazem pts listentries,
který známe od administrátora, ale můžeme použít pts listowned:
~$ pts listentries Name ID Owner Creator pts: Permission denied ; unable to list entries ~$ pts listowned svamberg Groups owned by svamberg (id: 1001) are: svamberg:project
Přidání do skupiny už známe a protože jde o vlastní skupinu, opět na to
budeme mít oprávnění. Protože nemáme žádného rozumného uživatele, přidáme
do svamberg:project skupiny uživatele svamberg.admin.
Předtím si zahrajeme na zlého a zkusíme se přidat do
system:administrators:
~$ pts adduser -user svamberg -group system:administrators pts: Permission denied ; unable to add user svamberg to group system:administrators ~$ pts adduser -user svamberg.admin -group svamberg:project ~$ pts membership svamberg:project Members of svamberg:project (id: -1001) are: svamberg.admin
Přidávat sám sebe do skupiny by mělo význam, kdyby skupinu využíval i někdo jiný než vy sami. Pokud to bude jen ve vašich vlastních datech, pak to postrádá smysl, protože vy sám budete mít vždy více oprávnění než skupina. To vychází z předpokladu, že o přístupech chcete rozhodovat sami a nikoliv to nechávat na někom ze skupiny.
Teď už jen pro skupinu nastavit práva tam, kde si projekt založíme. A jako uživatel máme práva jen na jednom místě:
~$ mkdir /afs/foo.bar/users/s/svamberg/public/project ~$ cd /afs/foo.bar/users/s/svamberg/public/project /afs/foo.bar/users/s/svamberg/public/project$ fs listacl Access list for . is Normal rights: system:anyuser rl svamberg rlidwka /afs/foo.bar/users/s/svamberg/public/project$ fs setacl . svamberg:project rliwk fs listacl Access list for . is Normal rights: svamberg:project rliwk system:anyuser rl svamberg rlidwka /afs/foo.bar/users/s/svamberg/public/project$ echo "dokumentace" > project.txt
Teď si můžeme vyzkoušet, že to funguje podle oprávnění. Všichni jej mohou číst, pokud bychom to nechtěli, tak to už zrušit umíme, zapisovat do něj můžeme my sami a naše skupina, která ovšem nemá oprávnění mazat (chybí ji 'd'). Sebe jsme právě vyzkoušeli vytvořením dokumentu, zrušíme si oprávnění a vyzkoušíme to jako anonymní uživatel:
/afs/foo.bar/users/s/svamberg/public/project$ unlog /afs/foo.bar/users/s/svamberg/public/project$ cat project.txt dokumentace /afs/foo.bar/users/s/svamberg/public/project$ echo "bububu" > strasidlo.txt bash: strasidlo.txt: Permission denied /afs/foo.bar/users/s/svamberg/public/project$ rm -f project.txt rm: cannot remove `project.txt': Permission denied
Přihlásíme se tedy jako uživatel patřící do skupiny a vyzkoušíme, zda můžeme přidávat soubory a jak to dopadne s mazáním:
/afs/foo.bar/users/s/svamberg/public/project$ kinit svamberg/admin Password for svamberg/admin@FOO.BAR: /afs/foo.bar/users/s/svamberg/public/project$ aklog /afs/foo.bar/users/s/svamberg/public/project$ echo "prace" > TODO /afs/foo.bar/users/s/svamberg/public/project$ rm -f TODO rm: cannot remove `TODO': Permission denied
I když jako administrátor jsme ve skupině system:administrators
máme zde defaultně pouze právo LOOKUP (l) a instantní právo
ADMINISTER (a), a to bez ohledu na to, co je v oprávněních nastaveno.
A tak si mohu dovolit i takový nehezký zásah, kdy si dočasně přidám oprávnění:
/afs/foo.bar/users/s/svamberg/public/project$ fs setacl . svamberg.admin all /afs/foo.bar/users/s/svamberg/public/project$ rm -f TODO /afs/foo.bar/users/s/svamberg/public/project$ fs setacl . svamberg.admin none
Takto se postupuje, pokud potřebujete něco upravit tam, kde práva nemáte.
Uživatel má ve svém domovském prostoru právo 'a', tudíž i v případě, kdy
se přidáte, může vás odstranit. To by ale pro správce nebylo zrovna nejlepší,
proto má skupina system:administrators „instantní“ oprávnění
'a' pro úpravu ACL a procházení adresářovou strukturou 'l'. Ale ani
administrátor nemůže změny provádět v RO nebo BK (backup) volumech.
Práva v nově vzniklém adresáři se vždy zdědí z nadřazeného, ale platí to pouze v rámci daného volumu. Každý volume se tváří jako malý souborový systém a při svém založení obsahuje pouze kořen, proto je vhodné po připojení volumu práva zkontrolovat a případně upravit. Uživateli jsme volume pěkně předpřipravili a jeho práva se budou dědit správně.
Nastavení domovského volumu uživatele je jen ukázkové. Můžete si jej upravit dle svých zvyklostí a potřeb. Avšak ještě než s úpravami začnete vyčkejte do dílu o zálohování, kde si s uživatelským volumem ještě trochu pohrajeme.
Možnosti nastavení oprávnění a vlastních skupin dělá z AFS vhodný souborový systém i pro organizace s velkým počtem uživatelů. Uživatelé se ale musejí tuto výhodu naučit používat ve svůj prospěch.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.