written by M.Liberi
26 Gennaio 2001
Michele Liberi
Obiettivo di questo documento è quello di definire un insieme di regole e pratiche di configurazione in ambiente operativo AIX per la gestione degli utenti, dei dati, e dei permessi di accesso ai dati comuni.
Punto di partenza dell'architettura è la presenza di un server AIX che contiene dati comuni, files di configurazione e licenze, e di un numero arbitrario di stazioni di lavoro AIX collegate tra loro ed al server in rete locale.
Obiettivo finale dell'architettura è realizzare un ambiente di lavoro che permetta agli utenti di sfruttare appieno la potenza del server, ma allo stesso tempo permetta loro di lavorare, seppur in condizioni degradate, quando il server o la rete locale dovessero essere non disponibili. L'esperienza insegna infatti che ogni macchina, non esclusi il server ed i dispositivi di rete, sono soggetti ad attività di manutenzione che ne pregiudicano il funzionamento per periodi più o meno lunghi.
Altro importante obiettivo è quello di non legare la stazione di lavoro ad un particolare utente. Ogni utente deve poter ritrovare il proprio ambiente di lavoro su ogni stazione di lavoro. Anche in ambienti dove le stazioni di lavoro sono assegnate agli utenti può succedere che un utente voglia o debba lavorare con una stazione diversa dalla propria.
La realizzazione operativa dell'architettura è resa possibile da un insieme di procedure da me realizzate. Per ognuna di esse è disponibile documentazione di dettaglio.
La condivisione di files tramite NFS e l'ipotesi di intercambiabilità delle stazioni di lavoro impone che il DB degli utenti sia definito in modo univoco e condiviso da tutte le stazioni ed il server.
Il NIS, lo strumento standard per realizzare il DB unico degli utenti in rete, presenta, a mio avviso, alcuni difetti:
Per superare i problemi appena esposti propongo di sostituire il NIS con un meccanismo di sincronizzazione dei files che definiscono a tutti gli effetti il DB degli utenti. Di fatto quindi ogni stazione possiede una copia locale del DB utenti e rimane svincolata dal server per le attività di autenticazione.
Tale attività di sincronizzazione, che viene fatta dal server ad intervalli di tempo regolari, normalmente due volte al giorno, comporta l'aggiornamento su tutte le stazioni di lavoro dei files che risultano modificati e la ricostruzione degli indici che ottimizzano gli accessi al DB.
La modifica del DB utenti da parte dell'amministratore di sistema deve avvenire sul server, che rappresenta la copia di riferimento. La propagazione della modifica alle stazioni di lavoro può essere immediatamente effettuata lanciando manualmente il programma di sincronizzazione oppure sarà effettuata al primo lancio schedulato.
Il cambio della password da parte dei singoli utenti dovrà avvenire utilizzando un opportuno strumento che aggiorna la password sia sulla stazione di lavoro locale, sia sul server. Alla prima sincronizzazione automatica tale informazione verrà propagata a tutte le stazioni di lavoro; fino a quel momento l'autenticazione avverrà sulle altre stazioni di lavoro utilizzando la vecchia password.
Esistono in genere un certo numero di files un certo numero di files con le seguenti caratteristiche:
La risposta più semplice e più ovvia a questa esigenza è quella di mantenere questi files sul server ed accedervi tramite NFS. Tale soluzione non è tuttavia efficiente in quanto le prestazioni di NFS sul server sono condizionate non soltanto, com'è ovvio, dal traffico di rete, ma anche dal numero di file aperti e dal numero di richieste. Senza contare che l'elevato numero di connessioni NFS comporta problemi in caso di spegnimento del server anche dopo la sua riaccensione
Potendo disporre di uno strumento di sincronizzazione di files e directories ha senso pensare di mantener sincronizzati sulle varie stazioni alcuni files di configurazione di sistema e applicativi.
Ciò produce alcuni vantaggi immediati:
Cito, a titolo di esempio, alcuni files di sistema che ha senso tener sincronizzati:
Nell'ipotesi che ogni utente debba poter lavorare indifferentemente su ognuna della stazioni di lavoro, sorge il problema di rendere disponibili le HOME directories in rete.
Soluzione ovvia, e diffusa, è quella di centralizzare tutte le HOME sul server e di accedervi tramite NFS. I problemi di prestazioni del server che si trova a dover servire moltissimi accessi sono analoghi a quelli evidenziati sopra.
La soluzione della sincronizzazione in questo caso non funziona in quanto:
Per questo problema risulta a mio avviso adeguato utilizzare il meccanismo dell'automount:
Il caso pessimo di questa configurazione, che si verifica nell'improbabile caso in cui tutti gli utenti lavorano con una stazione diversa da quella abituale, è comunque meglio del caso in cui tutti gli utenti lavorano appoggiandosi ad un unico server. Nel primo caso infatti, a parità di numero di mount attivi, il traffico di rete è molto meglio distribuito tra le varie macchine ognuna delle quali serve un numero limitato di utenti.
Nel caso la macchina di riferimento di un utente dovesse risultare indisponibile per un certo tempo, e disponendo di un backup della HOME directory, l'utente viene di nuovo messo in condizione di lavorare ripristinando i dati su un'altra macchina e modificando il file di configurazione dell'automount.
La tabella di tutti i mount deve essere attiva anche sul server sia per permettere di eseguire i backup, sia per consentire l'accesso alla HOME tramite SAMBA.
Volendo assegnare ad ogni utente una certa quantità di spazio disco si hanno due possibili soluzioni:
Nel primo caso il sistema non è gravato di nessun controllo aggiuntivo e quindi non degrada in termini di prestazioni, tuttavia nel caso la stazione dovesse ospitare molti utenti potrebbe essere poco agevole gestire molti file systems, senza contare che lo spazio non usato da un utente è perso in quanto non utilizzabile da altri utenti. Consiglio questa soluzione per un numero massimo di quattro utenti.
Nel secondo caso il file system è unico e condiviso, ma il sistema si prende carico di controllare che ogni utenti utilizzi un numero massimo di blocchi definibile utente per utente. E' molto flessibile, ed affidabile, ma carica il sistema in modo non trascurabile. Rappresenta tuttavia l'unica soluzione quando gli utenti da controllare sono molti.
Il sistema delle quote può essere attivato separatamente per ogni file system, ciò significa che un utente o gruppo di utenti può avere quote differenti su differenti file systems.
In un ambiente con molti utenti organizzati in gruppi di lavoro sorge naturale il problema di come proteggere i dati da accessi non autorizzati.
Il sistema operativo AIX, come tutti i sistemi UNIX, gestisce l'accesso a files e directories tramite tramite tre attributi:
La 'permissions mask' contiene tre gruppi di bit (rwx) per il controllo di accesso in lettura, scrittura ed esecuzione (per i files) o accesso (per le directories) da parte del proprietario, degli utenti appartenenti al gruppo, di tutti gli altri.
In altre parole possiamo dire che l'insieme degli utenti, escludendo il proprietario, è diviso da un'unica condizione: appartenere o meno al gruppo assegnato al file o directory.
Spesso invece sono necessari tre livelli di accesso:
In questi casi si deve utilizzare un meccanismo di controllo degli accessi denominato ACL (Access Control Lists) tramite il quale il proprietario del file (o root) può assegnare permessi ulteriori.
In pratica: per ogni directory per la quale si ha bisogno dei tre livelli si preparerà un file con i permessi di accesso estesi e si applicherà con il comando 'aclput'. Esempio: permessi base read-write per il gruppo, nessuno per gli altri; permessi estesi read-only per gli utenti di un altro gruppo.
ATTENZIONE! il comando 'chmod', se usato con il formato numerico (es. chmod 700 pippo), disabilita eventuali attributi estesi impostati con il comando 'aclput'. Se usato invece con il formato simbolico (es. chmod u+x pippo) gli attributi estesi vengono mantenuti.
Per una descrizione dettagliata si rimanda alla documentazione specifica dei singoli programmi.