normalizzazione utenti (passwd/group locali)

== premesse ==

Indipendentemente dal tipo di sistema utilizzato per
l'autenticazione (files locali, LDAP, databases, ecc)
ci sono utenti che devono essere presenti localmente
sul sistema, nel file =/etc/passwd=, perche` sono
necessari allo startup dei servizi, i quali non sempre
possono contare sulla presenza di servizi di autenticazione
esterni (non locali).

Da qui la necessita` di avere questi utenti predefiniti
sui sistemi. Al giorno d'oggi tutti i packages che necessitano
di un determinato set di utenti si occupano anche di controllarne
l'esistenza durante l'installazione, e di crearli se mancano.

Tuttavia questo genera il problema che lo stesso utente puo`
avere UID differenti su sistemi differenti, sui sistemi Unix like
infatti esiste un solo utente il cui uid sia certo, l'utente *root*,
con il suo uid *0*.

Anche se di norma questo non e` problema, in quanto gli account
di cui stiamo parlando appartengono a servizi locali, puo` diventarlo
in caso di ambienti di rete (e i diversi meccanismi per ovviare alla
cosa sono, al massimo, dei palliativi).

Diventa sicuramente un grosso problema in un ambiente dinamico, dove
esiste la frequente possibilita`, ad esempio, che un disco o una partizione
siano trasferiti da un sistema ad un altro (casi tipici: dischi
rimovibili usb, o server virtualizzati), condivisi via nfs, clonati
per testing, ecc. Praticamente l'ambiente di lavoro quotidiano in
un datacenter, o in una struttura di sviluppo e/o manutenzione
informatica.

La soluzione, radicale, e` quella di normalizzare gli utenti di
base, assegnando forzatamente a ciascuno un uid predefinito e
conosciuto.


== esecuzione ==

Il modulo deve essere eseguito per conto proprio, possibilmente in
single user (vedi dopo), con un singolo lancio di *kusa-reconf*; per
evitare invocazioni involontarie del modulo, questo deve essere richiesto
specificando in chiaro il servizio omonimo:
{{{
kusa --service userbase userbase
}}}

Al termine dell'esecuzione molto probabilmente sara` richieso un riavvio
del sistema, necessaria dopo la modifica di uno o piu` account (la cosa e`
certa su sistemi appena installati, puo` non accadere aggiornando un
sistema esistente sul quale abbia gia` girato, in precedenza, l'esecuzione
di questo modulo).


== funzionamento ==

Il modulo e` fornito di due elenci, *standard_users* e *standard_groups*:
questi due elenchi contengono tutti gli utenti e i gruppi necessari e
considerati "di base" per ogni sistema.

I due elenchi sono frutto di analisi empirica su un grande numero di
sistemi in diversi anni di lavoro, sono essenzialmente focalizzati sulla
distribuzione Ubuntu, ma possono essere utilizzati (dopo verifica) anche
su altre distribuzioni Linux.

Gli elenchi sono senz'altro ridonanti, ma sono al momento completi.

Ciascun elenco presenta non solo il nome ed uid/gid predefiniti, ma
anche le informazioni di login, gecos, homedir, che risultano quindi
tutte standardizzate ed omogenee sui diversi sistemi.

Lo script *do-normalization* si occupa di controllare i files */etc/group*
e */etc/passwd*, nel caso un gruppo o utente non sia presente viene creato,
nel caso sia presente viene eseguito un controllo, se si discosta dalle
definizioni richieste:

   * le informazioni di sistema vengono aggiornate
   * tutti i filesystem presenti sono scansionati e le relative
   informazioni di ownership modificate in modo congruente

== filesystem montati ==

Nel modificare le ownership dei files si utilizzano particolari precauzioni
(vedi programmi appositi *verbatim_chown* e *verbatim_chmod*) che
mantengono inalterati tutti i permission (suid, sticky bit, ecc), in
questo quindi differiscono dal comportamento standard di chown e chgrp di
alcune varianti Unix/Linux.

Per evitare modifiche inopportune ai filesystem, il modulo controlla che
al momento dell'esecuzione sia montato solo il filesystem root (i filesystem
virtuali quali /proc, /sys, /dev, ecc non sono considerati), in caso
contrario l'esecuzione abortisce senza modificare il sistema.

E` possibile autorizzare la presenza di altri filesystem impostando la
variabile del db kusa *module-userbase.allowed_fs*, con un elenco di
elementi separati da spazio o virgola (es: /boot,/opt).


== servizi ==

Dato che non e` possibile modificare le informazioni di account se un utente
e` considerato loggato, ne` tantomeno opportuno modificare il filesystem in
caso che un servizio lo stia utilizzando, il modulo richiede di essere in
single user (runlevel *S*) per poter essere eseguito.

E` possibile (ma non consigliabile) un override su questo controllo, impostando
la variabile del db kusa *module-userbase.allow_multiuser* al valore yes o true.

Questo escamotage puo` essere usato, in condizioni controllate, per eseguire
il lancio su un sistema remoto, dove quindi occorre essere connessi tipicamente
tramite ssh: in questo caso il sistema non puo` essere in single user (altrimenti
il daemon ssh non sarebbe attivo), occorre tuttavia assicurarsi di fermare
manualmente tutti i servizi attivi, per arrivare quindi alle stesse condizioni
di un runlevel S.

In ogni caso alcuni servizi, se trovati attivi, saranno chiusi forzatamente,
quindi un reboot al termine del lancio si rende comunque necessario (vedi
script =run-install= per dettagli).

== classi ==

Il modulo ha un tentativo di approccio di definizione degli utenti basata
sulle classi, vedi a questo proposito il file *users_classes*. Le classi
definiscono la shell utilizzata, la posizione predefinita della homedir
e un eventuale elenco di gruppi aggiuntivi di appartenenza.

Al momento sono tre le classi definite:

   * *resadm* resident admin, utenti locali con ruolo di amministrazione del
   sistema, a parte root gli altri definiti al momento sono *kusa* stesso, e
   *prjadmin* (per ragioni storiche); hanno la homedir direttamente sulla
   root, per evitare problemi di filesystem non montati

   * *login* utenti con diritto di login diretto (accesso alla shell), la
   homedir di default e` sotto la directory /home/@SELF@, la shell /bin/bash

   * *nologin* utenti senza diritti di login diretto, la homedir di default
   e` sotto la directory /tmp/@SELF@, la shell /bin/false<BR>

%!% attualmente la classe *nologin* utilizza /bin/bash come shell, perche`
molti account, anche se non dovrebbero permettere il login, non
possono avere /bin/false come shell altrimenti i rispettivi servizi non
partono (problema di esecuzione tramite comando *su*?)

== overrides ==

   * *module-userbase.allowed_fs* db kusa (default: null), impostare
   con elenco di filesystem per autorizzarne la presenza (moint) durante il lancio,
   gli elementi sono separati da virgola o spazi

   * *module-userbase.allow_multiuser* db kusa (default: null) impostare true o
   yes per permettere il lancio del modulo anche in runlevel diverso da S

   *local_groups, local_users, local_users_classes* con questi files e` possibile
   impartire controordini o aggiungere i propri utenti/gruppi all'elenco base,
   i files sono da creare nella directory =/etc/kusa/files=; i files di esempio
   local_groups.sample, local_users.sample e local_users_classes.sample sono
   visibili della directory del modulo =/usr/lib/kusa/modules/userbase=
