== nscd ==

Per ridurre le queries al server ldap puo` essere installato anche
il gestore di cache nscd. Attenzione quindi che ogni operazione
di modifica ai parametri di ldap necessita del restart di questo
daemon, che altrimenti si tiene in memoria i vecchi risultati.

== server non raggiungibile ==

LDAP ha tra i parametri di configurazione il timeout sulle
richieste, che a quanto pare pero` sono ignorati dalle librerie
di resolving, generando problemi e blocchi della macchina in
caso il server ldap non sia raggiungibile.

Il problema l'ho risolto a monte, usando un hack piuttosto grezzo
ma efficace: al momento del boot viene lanciato uno script di init
(disable-nss-ldap) che nel caso il server ldap non sia
raggiungibile ferma il daemon nscd e installa un /etc/nsswitch.conf
privo dell'accesso a ldap.

Similmente, se al boot il server e` raggiungibile, riabilita il
daemon nscd e reinstalla /etc/nsswitch.conf con il supporto abilitato.

In presenza di upstart (9.10 e superiori) lo script di controllo di
ldap (enable-nss-ldap) emette anche l'evento "ldap-checked", che
serve a dare il via al servizio display manager (gdm o kdm), i cui
files di configurazione sotto /etc/init devono essere patchati in
modo opportuno (se ne occupa il modulo base-x11).

== moduli PAM ==

Dopo numerosi tentativi e ricerce su Internet questa e` la configurazione
di PAM piu` funzionale, e che comporta meno problemi in caso di
server ldap non raggiungibile.

Nella maggior parte degli esempi riportati la sequenza di tentativi
e`, come pare logico, nell'ordine: LDAP, e poi files locali, ad
in caso di successo della query, attraverso un semplice (ad esempio)
{{{
auth	sufficient	pam_ldap.so
auth	required	pam_unix.so
}}}

L'approccio usato da noi invece e` il contrario, prima tenta un
accesso locale, in caso di successo, ignora la linea seguente
(e` un comportamento di PAM un po' contorto e poco usato, ma
funziona).

Se il primo tentativo (quello locale) non va a buon fine, viene
interpretata la riga successiva (accesso ldap).

Le regole a questo punto terminano obbligatoriamente con una
di permesso esplicito, che serve a chiudere l'algoritmo
rovesciato in uso:
{{{
auth	[success=1 default=ignore]	pam_unix.so
auth	required			pam_ldap.so use_first_pass
auth	required			pam_permit.so
}}}

== utenti di sistema ==

Anche se il lookup su LDAP non viene eseguito per gli utenti locali
(presenti in /etc/passwd), questo non vale per i gruppi.
Le funzioni ''nss_ldap'' dispongono di due parametri per forzare nullo
il lookup su LDAP per una serie di utenti: '''nss_initgroups_ignoreusers'''
e '''nss_initgroups_minimum_uid'''.

Il primo tentativo e` stato quello di usare la lista di ignore esplicita,
che funziona ma ha il difetto, appunto, di dover elencare una serie
piuttosto estesa di users (anche perche` con la normalizzazione degli
utenti di sistema questi sono arrivati ad essere oltre un centinaio).

La seconda opzione sembra la soluzione, possibile dopo la normalizzazione
perche` abbiamo noi il controllo della numerazione degli uid, quindi
vengono bloccati i groups lookups per tutti gli utenti che hanno uid
inferiore a 10000.

<!> attualmente il minimum_uid non funziona (non viene interpretato
correttamente dalle librerie), ubuntu risolve con uno script che '''al boot'''
va ad aggiornare /etc/ldap.conf aggiungendo gli utenti di /etc/passwd
che sono sotto il limite specificato da minumum_uid
