OpenAFS – uživatel

15. 2. 2012 | Michal Švamberg | Návody | 6112×

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.

Obsah

• Uživatelský volume
• Nastavení práv
• Uživatelské skupiny
• Závěr

Uživatelský volume

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.bar

V 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

Nastavení práv

Č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.

Uživatelské skupiny

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.

Závěr

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.

Centrum informatizace a výpočetní techniky pro Západočeskou univerzitu v Plzni buduje a provozuje od roku 1996 prostředí Orion založené na  autentizačním systému Kerberos a distribuovaném síťovém souborovém systému AFS s více než 22 tisíci aktivních uživatelů.

       

Komentáře

[loki]

Pekny clanek. Btw nejste vy nejakej ten "von"?

[List]

Děkuji. Možná pár let zpátky s těmito pány