Esperienza su AFS file system con openAFS
Esperienza su AFS file system con openAFS |
|
|
|
Per la realizzazione di questo modulo useremo
Netkit4TIC
con la
connettività
con la rete reale (leggere il file README).
Nella mappa
(pdf,
xml)
della rete in esame ci sono tre nodi collegati
allo stesso dominio di collisione 192.168.10.0/24.
Nel nodo kdc (192.168.10.4) sono configurati i
seguenti servizi:
ISTITUTO.IT.istituto.it
Nel nodo alfa (192.168.10.100) sarà configurato
il servizio AFS per la cella di nome istituto.it.
Il nodo client (192.168.10.200) rappresenta la
classica stazione di lavoro, ossia il posto destinato al login
dell'utenza.
Vogliamo configurare kerberos, LDAP e AFS in modo tale da sperimentare che
un utente già autenticato nel realm ISTITUTO.IT
possa ottenere servizio AFS per la propria home directory.
Per l'elenco dei pacchetti da installare per kerberos rimandiamo all'esperienza su Kerberos.
L'elenco dei pacchetti da installare per AFS è:
libpam-openafs-session,
openafs-client,
openafs-dbserver,
openafs-fileserver,
openafs-krb5,
openafs-modules-2.4.26-bs1.
Quest'ultimo pacchetto è generato
e confezionato per il mondo virtuale che stiamo usando. In
generale è legato al kernel della macchina.
Nella distribuzione Debian tali pacchetti hanno le seguenti rimappature dei cammini ("FHS-compatible path names"):
/usr/afs/etc /etc/openafs/server /usr/afs/local /etc/openafs/server-local /usr/afs/db /var/lib/openafs/db /usr/afs/logs /var/log/openafs /usr/afs/bin /usr/lib/openafs
Il file con l'esperienza deve essere decompresso su una sottodirectory della HOME. In seguito, dopo aver seguito le istruzioni presenti nel file README occorre lanciare lo script:
user@realHost$ ./lab start
(screenshot) che costruisce i tre nodi con i servizi già configurati e attivati.
In seguito gli argomenti vengono esposti suddivisi nelle seguenti sezioni:
./lab start).
Configurazione KDC |
|
Procediamo con i comandi sul nodo
krc per l'inizializzazione del database:
root@kdc# kdb5_util create -s Loading random data Initializing database '/var/lib/krb5kdc/principal' for realm 'ISTITUTO.IT', master key name 'K/M@ISTITUTO.IT' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: not24get Re-enter KDC database master key to verify: not24get
Il tratto evidenziato in colore indica l'attività di generare
numeri casuali. Nei mondo virtuale tutte le funzioni che utilizzano generazioni
casuali
basandosi sull'attività
dell'hardware subiscono rallentamenti e a volte dei blocchi
perchè l'entropia è molto bassa rispetto alla realtà.
In genere quindi
dopo lo start dell'esperienza aspetto qualche minuto e nel
frattempo genero dell'entropia battendo alcuni comandi alla
console della macchina virtuale. Nel caso di blocco dovuto a un comando che
usa /dev/random, lo sgancio dalla shell con CTRL-Z,
poi lo faccio proseguire in background con il comando
bg e nel frattempo genero entropia con
comandi dalla tastiera.
Costruiamo le utenze amministrative:
root@kdc# kadmin.local kadmin.local: ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin kadmin.local: ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/changepw kadmin.local: addprinc -pw secret krbadm@ISTITUTO.IT kadmin.local: addprinc -pw secret afsadm@ISTITUTO.IT kadmin.local: q
Ora facciamo partire il servizio:
root@kdc# /etc/init.d/krb5-kdc start
Per attivare la possibilità di amministrare il kdc da remoto dovremmo anche lanciare:
root@kdc# /etc/init.d/krb5-admin-server start
Configurazione iniziale di OpenAFS |
|
Ogni nodo file server AFS deve possedere almeno un volume
dedicato ai volumi AFS. A questo scopo ad ogni macchina virtuale
di tipo server è stato passato un backing-store di 20000 KB
che servirà da volume. Lo formattiamo ext3
e lo montiamo in /vicepa.
Inoltre ogni nodo AFS (client o server) deve possedere una cache
e quindi ad ogni macchina virtuale
è stato passato un backing-store di 12000 KB (nel
caso pratico sono consigliati 50000 KB). Questo valore è
memorizzato nel file /etc/openafs/cacheinfo:
/afs:/var/cache/openafs:10000
che formattiamo ext3
e che montiamo in /var/cache/openafs.
Occorre fare attenzione a questa fase poichè il Basic OverSeer (BOS) service è attivato con le autorizzazioni disabilitate e quindi nel caso pratico l'operazione deve essere eseguita con la macchina scollegata dalla rete o con altre accortezze che ne garantiscano l'inaccessibilità.
root@alfa# bosserver -noauth
La prima cosa da fare è scegliere un nome per la cella
che si vuole configurare. Tipicamente si sceglie il nome del proprio
dominio e si riporta
nel file /etc/openafs/ThisCell:
istituto.it
Aggiungiamo le informazioni della nostra cella al database
delle celle pubbliche /etc/openafs/CellServDB:
[...] >istituto.it #Netkit4TIC AFS cell 192.168.100.222 #alfa.istituto.it
Costruiamo la cella:
root@alfa# bos setcellname -server alfa.istituto.it \ -cell istituto.it -name istituto.it -localauth
Verifichiamo che il nome della cella sia corretto:
root@alfa# bos listhosts alfa.istituto.it -localauth
Cell name is istituto.it
Host 1 is alfa.istituto.it
Il file dove vengono memorizzate le precedenti informazioni
è /etc/openafs/server/Cell.
Ora costruiamo i processi server:
# Protection Server root@alfa# bos create -server alfa -instance ptserver -type simple \ -cmd /usr/lib/openafs/ptserver -cell istituto.it -localauth # Volume Location Server root@alfa# bos create -server alfa -instance vlserver -type simple \ -cmd /usr/lib/openafs/vlserver -cell istituto.it -localauth # Backup Server root@alfa# bos create -server alfa -instance buserver -type simple \ -cmd /usr/lib/openafs/buserver -cell istituto.it -localauth # Processo fs composto da File Server, Volume Server e Salvager root@alfa# bos create -server alfa -instance fs -type fs \ -cmd /usr/lib/openafs/fileserver \ -cmd /usr/lib/openafs/volserver \ -cmd /usr/lib/openafs/salvager -cell istituto.it -localauth
Proseguiamo costruendo i principals necessari per AFS. Poichè la nostra cella ha lo stesso nome del reame Kerberos costruiremo un principal chiamato afs@ISTITUTO.IT:
root@kdc# kadmin.local Authenticating as principal root/admin@ISTITUTO.IT with password. kadmin: addprinc -randkey afs/istituto@ISTITUTO.IT kadmin: ktadd -e des-cbc-crc:afs3 -k /etc/krb5.keytab.afs afs/istituto@ISTITUTO.IT kadmin: q
In seguito spostiamo la chiave sul database del server
/etc/openafs/server/KeyFile ma prima
verifichiamo la versione della chiave (che sappiamo essere 3):
root@kdc# kadmin.local -q "getprinc afs/istituto.it@ISTITUTO.IT" | grep ^Key: Key: vno 3, DES cbc mode with CRC-32, no salt root@alfa# asetkey add 3 /etc/krb5.keytab.afs afs/istituto.it root@alfa# rm -f /etc/krb5.keytab.afs
Ora dobbiamo costruire l'utenza amministrativa (afsadm):
root@alfa# bos adduser alfa afsadm -cell istituto.it -localauth root@alfa# pts createuser -name afsadm -cell istituto.it -id 2001 -noauth root@alfa# pts adduser afsadm system:administrators -cell istituto.it -noauth root@alfa# pts membership afsadm -cell istituto.it -noauth
Tale utenza viene registrata nel file
/etc/openafs/server/UserList.
Creiamo il volume root.afs:
root@alfa# vos create alfa /vicepa root.afs -localauth
Abbiamo terminato l'inizializzazione "senza protezione" e quindi chiuderemo il server e lo faremo ripartire in modalità sicura:
root@alfa# bos shutdown alfa -wait -localauth root@alfa# /etc/init.d/openafs-fileserver start root@alfa# /etc/init.d/openafs-client start
L'attivazione della parte client è ovviamente opzionale.
Costruzione della cella |
|
Per poter operare come amministratore occorre assumere le credenziale ed acquisire il token AFS:
root@alfa# kinit afsadm Password for afsadm@ISTITUTO.IT:secret root@alfa# aklog root@alfa# klist -5 Ticket cache: FILE:/tmp/krb5cc_0 Default principal: afsadm@ISTITUTO.IT Valid starting Expires Service principal 08/30/05 21:12:02 08/31/05 07:11:59 krbtgt/ISTITUTO.IT@ISTITUTO.IT 08/30/05 21:12:10 08/31/05 07:11:59 afs/istituto.it@ISTITUTO.IT
Creiamo il volume d'ingresso root.cell che
sarà montato come /afs/istituto.it e che
potrà essere leggibile da tutti:
root@alfa# vos create alfa /vicepa root.cell root@alfa# fs mkmount /afs/istituto.it root.cell root@alfa# fs setacl /afs system:anyuser read root@alfa# fs setacl /afs/istituto.it system:anyuser read
Indichiamo che entrambe i volumi devono avere repliche read-only e occorre creare il punto d'ingresso per l'albero in read/write usando un mount point speciale:
root@alfa# vos addsite alfa a root.afs Added replication site alfa /vicepa for volume root.afs root@alfa# vos addsite alfa a root.cell Added replication site alfa /vicepa for volume root.cell root@alfa# fs mkmount /afs/.istituto.it root.cell -rw root@alfa# vos release root.afs Released volume root.afs successfully root@alfa# vos release root.cell Released volume root.cell successfully
Costruzione delle home per l'utenza |
|
Iniziamo con la costruzione della home:
root@alfa# vos create alfa /vicepa home root@alfa# fs mkmount /afs/.istituto.it/home home root@alfa# fs setacl /afs/.istituto.it/home system:anyuser read root@alfa# vos addsite alfa /vicepa home root@alfa# vos release home root@alfa# vos release root.cell
Costruiamo un utente:
root@alfa# kadmin.local -q "addprinc -pw bianchi mrossi@ISTITUTO.IT" -w secret root@alfa# pts creategroup users -id -3001 root@alfa# pts createuser mrossi -id 2002 root@alfa# pts adduser mrossi users root@alfa# vos create alfa /vicepa home.mrossi root@alfa# fs mkmount /afs/.istituto.it/home/mrossi home.mrossi root@alfa# vos release home root@alfa# fs setacl /afs/istituto.it/home/mrossi mrossi all root@alfa# fs setquota /afs/istituto.it/home/mrossi -max 2000
Configurazione client |
|
Per prima cosa definiamo il principal associato al nostro utente
di prova mrossi@ISTITUTO.IT (con password bianchi)
e il principal associato al nodo client stesso:
root@client# kadmin -p krbadm
Authenticating as principal krbadm with password.
Password for krbadm@ISTITUTO.IT:secret
kadmin: addprinc -pw bianchi mrossi@ISTITUTO.IT
kadmin: addprinc -pw secret host/client.istituto.it@ISTITUTO.IT
kadmin: ktadd -k /etc/krb5.keytab host/client.istituto.it@ISTITUTO.IT
kadmin: q
Per la configurazione del nodo client ricorreremo
alla configurazione di PAM per l'autenticazione e poi a NSS in
combinazione con LDAP per la risoluzione dei nomi dei servizi.
Come sperimentato nell'esperienza legata al
PAM
occorre modificare i files common-* all'interno
della directory /etc/pam.d inserendo con
clausola sufficient il modulo kerberos:
# /etc/pam.d/common-account
account sufficient pam_krb5.so
account required pam_unix.so
# /etc/pam.d/common-auth
auth sufficient pam_krb5.so nullok_secure forwardable
auth required pam_unix.so nullok_secure use_first_pass
# /etc/pam.d/common-password
password sufficient pam_krb5.so nullok obscure
password required pam_unix.so nullok obscure min=4 max=8 md5 use_first_pass
# /etc/pam.d/common-session
session sufficient pam_krb5.so forwardable
session optional pam_openafs_session.so
session required pam_unix.so
In seguito configuriamo come il Name Service Switch (NSS) deve accedere a LDAP:
# /etc/libnss-ldap.conf host ldap.istituto.it base dc=istituto,dc=it nss_base_passwd ou=People,dc=istituto,dc=it nss_base_shadow ou=People,dc=istituto,dc=it nss_base_group ou=Group,dc=istituto,dc=it
e ora l'ultimo passo è quello di attivare il NSS a consultare LDAP:
# /etc/nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap
Configurazione client "reali" |
|
Per la configurazione dei client reali rimandiamo al già citato documento di Paternò. Ricordiamo solo che occorre configurare opportunamente le tabelle di routing.
Sperimentazione interattiva |
|
Da questo punto in poi iniziano le attività interattive
che si possono sperimentare alla conclusione dello script lab.
Login |
|
Per sperimentare il login ci posizioniamo
sul nodo client e diamo le nostre credenziali
(utente: mrossi, password: bianchi):
client login: mrossi Password for mrossi@ISTITUTO.IT:bianchi root@client$ klist -5 Ticket cache: FILE:/tmp/krb5cc_2002_jrceV7 Default principal: mrossi@ISTITUTO.IT Valid starting Expires Service principal 09/01/05 18:08:15 09/02/05 04:08:15 host/client.istituto.it@ISTITUTO.IT 09/01/05 18:08:15 09/02/05 04:08:15 krbtgt/ISTITUTO.IT@ISTITUTO.IT 09/01/05 18:08:16 09/02/05 04:08:15 afs/istituto.it@ISTITUTO.IT
(screenshot)
possiamo quindi verificate che il modulo pam_krb5
ha chiamato in automatico kinit ottenendo
il Ticket Granting Ticket (TGT) e che il modulo
pam_openafs_session
ha chiamato in automatico
aklog per ottenere
il token per l'utenza AFS.
È inoltre presente il token per la workstation.
Ora abbiamo accesso al file system AFS:
mrossi@client$ pwd /afs/istituto.it/home/mrossi mrossi@client$ df -h /afs Filesystem Size Used Avail Use% Mounted on AFS 8.6G 0 8.6G 0% /afs
Infatti nel database LDAP abbiamo definito la HOME in AFS e abbiamo
riportato lo stesso identificatore utente (uidNumber)
(screenshot).
Per poterlo velocemente verificare viene fornito
con l'esperienza il file d'impostazione che basta copiare
nella home. Al lancio di gq ricordarsi che la
password è secret:
user@realHost$ cp .gq ~ user@realHost$ gq
Possiamo controllare le autorizzazioni presenti (ACL):
mrossi@client$ fs la $HOME
Access list for /afs/istituto.it/home/mrossi is
Normal rights:
system:anyuser l
mrossi rlidwka
Visualizziamo i volumi attraversati:
mrossi@client$ fs exam /afs File /afs (536870913.1.1) contained in volume 536870913 Volume status for vid = 536870913 named root.afs.readonly [...] mrossi@client$ fs exam /afs/istituto.it/ File /afs/istituto.it/ (536870916.1.1) contained in volume 536870916 Volume status for vid = 536870916 named root.cell.readonly [...] mrossi@client$ fs exam /afs/istituto.it/home/ File /afs/istituto.it/home/ (536870919.1.1) contained in volume 536870919 Volume status for vid = 536870919 named home.readonly [...] mrossi@client$ fs exam /afs/istituto.it/home/mrossi/ File /afs/istituto.it/home/mrossi/ (536870921.1.1) contained in volume 536870921 Volume status for vid = 536870921 named home.mrossi [...]
Amministrazione Server |
|
Posizioniamoci sul file server alfa.
Per operare
come amministratore occorre identificarsi come principal
afsadm (e quindi ottenere un ticket TGT) e dal
quale ottenere un token AFS:
root@alfa$ kinit afsadm root@alfa$ aklog
Vediamo cosa
contiene la directory /vicepa:
root@alfa# ls -c /vicepa AFSIDat V0536870919.vol V0536870916.vol V0536870915.vol Lock V0536870921.vol V0536870918.vol V0536870913.vol V0536870912.vol root@alfa# ls -c /vicepa/AFSIDat/ 7 4 1 README + root@alfa# cat /vicepa/AFSIDat/README These files and directories are a part of the AFS namespace. Modifying them in any way will result in loss of AFS data, ownership and permissions included.
Costruiamo ora una seconda partizione AFS
(su un backing store /dev/ubd/3
passato al momento della costruzione della macchina virtuale):
root@alfa# /sbin/mkfs.ext3 -q /dev/ubd/3
root@alfa# bos shutdown alfa.istituto.it -wait
root@alfa# mkdir /vicepb
root@alfa# mount -rw /dev/ubd/3 /vicepb
root@alfa# bos restart alfa.istituto.it -all
root@alfa# vos partinfo alfa.istituto.it
Free space on partition /vicepa: 18534 K blocks out of total 19746
Free space on partition /vicepb: 18700 K blocks out of total 19746
Creazione di un volume:
root@alfa# vos create alfa.istituto.it /vicepb volume.di.prova
Volume 536870924 created on partition /vicepb of alfa.istituto.it
Accesso ai volumi:
root@alfa# fs mkm /afs/istituto.it/mp volume.di.prova root@alfa# fs sa /afs/istituto.it/mp mrossi write
Creiamo il volume Read-Only:
root@alfa# vos addsite alfa /vicepb volume.di.prova Added replication site alfa /vicepb for volume volume.di.prova root@alfa# vos rel volume.di.prova Released volume volume.di.prova successfully
Il volume è immediatamente disponibile:
root@alfa# fs exam /afs/istituto.it/mp
File /afs/istituto.it/mp (536870924.1.1) contained in volume 536870924
Volume status for vid = 536870924 named volume.di.prova
[...]
|
|
Sandro Doro (email me)