Newsgroup: it.comp.os.linux.sys
Titolo: autenticazione su server LDAP non va con Etch

>
Alle stesse macchine pero' da remoto con ssh, o via terminale, ci si
connette, per cui non sembra essere un problema di password.
Mi pare di impazzire. L'unica mia spiegazione e' che ci sia un problema di
bios di scheda di rete o qualcosa del genere per cui magari la scheda mi va
in standby. 
Grazie per l'attenzione scusate lo sofgo.
ecco il file /etc/pam.d/gdm (che mi pare normale, almeno con la sarge
funzionava)
-------------------------------------------------------------------------
#%PAM-1.0
auth    requisite       pam_nologin.so
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
auth    optional        pam_group.so
@include common-auth
@include common-account
session required        pam_limits.so
@include common-session
@include common-password
session required pam_mkhomedir.so skel=/etc/skel umask=0077
------------------------------------------------------------------------

 utenti su quelle macchine clonate via LDAP *a volte* funziona a volte no.
come spesso accade scrivere nei ng porta fortuna.
Lo scrivo qui perche' sicuramente me ne saro' dimenticato entro pochi
giorni:
perche' l'ldap client funzioni bisogna che sia attivo il demone nscd. Se il
demone nscd non ha la cache corretta dopo pochi minuti (e questo non lo so
spigare) muore. La cache del demone nscd su debian sta nella directory
/var/db/nscd
sono tutti file binari che pero', se una macchina e' stata clonata,
riportano la cache della macchina originale, con relativi nomi e ip quindi
non corretti.
Cancellando quei files l'nscd li ricrea e il prblema si risolve.
Parrebbe. 

 perche' l'ldap client funzioni bisogna che sia attivo il demone nscd. Se 
Giusto per la cronaca...
NO, perche' LDAP funzioni NON c'e' bisogno di NSCD...
NSCD e' semplicemente un sistema per avere una Cache di alcuni dati, utile
per esempio, se ti devi collegare a un server (LDAP, SQL, altro) remoto
per ottenere dei dati tipo passwd, shadow, group, hosts.
Se non ce l'hai funziona alla perfezione lo stesso, solo piu' lento!
E, ovviamente, generando piu' traffico di rete e carico di macchina...
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 E, ovviamente, generando piu' traffico di rete e carico di macchina...
anch'io guardando il man di nscd l'ho capita cosi', e infatti inizialmente
non me ne importava nulla che l'nscd fosse o non fosse attivo.
Poi cercando come un pazzo ho trovato questo bug:
https://bugzilla.novell.com/show_bug.cgi?id=298830#c5
che e' ovviamente l'*opposto* del mio problema. Ma tant'e' quand'uno e'
disperato le prova tutte e ho tirato su a mano l'nscd e ho visto che mi
autenticavo. Nscd su mi autentico sempre, nscd giu' certe volte mi
autentico (poche) certe volte no (molte).
Forse il server e' troppo lontano e qualcosa va in timeout ma ho provato
anche oggi e con l'nscd giu' e' proprio un terno al lotto.

 provato anche oggi e con l'nscd giu' e' proprio un terno al lotto.
Non ho seguito la discussione ma così da come la dici sembra un problema
noto, ma AFAIK poco pubblicizzato, aggiungi sul server in
/etc/ldap/slapd.conf
idletimeout 30
e vedi se migliora, in etch slapd gira come utente non privilegiato e fa
presto a finire i file handle in sarge girava come root e non si notava
il problema a meno di non farlo girare, come ho fatto io, come utente
non privilegiato.
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH