Newsgroup: it.comp.os.linux.sys
Titolo: LDAP

Su Debian dopo 5 minuti, grazie allo script di post installazione, il
server era già attivo ed esplorabile, e pronto per essere popolato. Su
RedHat dopo due giorni sto ancora smadonnando (gli dei fulminino
l'inventore di RPM), in pratica ho installato openldap, openldap-server
e openldap-client ma non riesco ad usare slapcat, non mi è ben chiaro
come mettere in piedi un primo abbozzo di albero consultabile e, quel che
è peggio, non capisco per quale motivo rifiuta le connessioni dalle
altre macchine in rete.
 
Avete suggerimenti?
Grazie in anticipo.
-- 
Troppo vino o troppo poco: se non gliene date, non puo' trovare la verita';
se gliene date troppo, neppure.
		-- Blaise Pascal

 Grazie in anticipo.
 
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-ldap.html
 
 
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Reference_Guide/s1-ldap-quickstart.html
 
 
visto che non specifichi la versione..
 
inoltre dissento su rpm, ma libero ovviamente di pensarla come vuoi..
 
S.

 Avete suggerimenti?
 
Si: non usare OpenLDAP. Detto questo, il problema e` dovuto al fatto che da 
una parte il mantainer ha degli script post installazione che ti creano 
l'installazione in modalita` semigrafica, dall'altra no
 
Enrico

 inoltre dissento su rpm, ma libero ovviamente di pensarla come vuoi..
 
Se il problema sono gli script post installazione (o la mancanza di essi), 
allora il problema e` del mantainer che gestisce il pacchetto. Detto questo, 
eniamo anche presente che la filosofia Red Hat e` "ti installo il servizio 
ma te lo metti in piedi da solo" (che non e` del tutto sbagliata)
 
Enrico

 l'installazione in modalita` semigrafica, dall'altra no
 
Non direi affatto, il problema è che i deb ti configurano il servizio per il primo utilizzo, gli rpm no. Il fatto che ci sia un'mterfaccia ncurses è assolutamente superfluo.

 Si: non usare OpenLDAP.
 
Cosa proponi in alternativa? Attualmente uso OpenDJ perche' ho un nuovo 
server a 64 bit, ma sulla vecchia macchina con poca ram non potevo usare 
queste idrovore di RAM basate su Java, per cui mi ero adattato ad usare 
openldap, compilato da sorgenti (era una slack su PIII con 380 MB di ram).
 

 
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Reference_Guide/s1-ldap-quickstart.html
 
 
Sto usando openldap 2.4 su CentOS6.3, la cosa per che al momento non capisco è la seguente:
 
sul server:
[root@localhost ~]# netstat -nlp | grep 389
tcp        0      0 
0.0.0.0:389
                 0.0.0.0:*                   LISTEN      3731/slapd
tcp        0      0 :::389                      :::*                        LISTEN      3731/slapd
 
sul client:
$ telnet 10.17.201.74 389
Trying 10.17.201.74...
telnet: Unable to connect to remote host: No route to host
 
però
 
$ ping 10.17.201.74
 
Esecuzione di Ping 10.17.201.74 con 32 byte di dati:
 
Risposta da 
10.17.201.74
: byte=32 durata=9ms TTL=64
Risposta da 
10.17.201.74
: byte=32 durata=1ms TTL=64
Risposta da 
10.17.201.74
: byte=32 durata=1ms TTL=64
 
Come fa a dire "no route"? A me sembra che la route ci sia eccome.

 Come fa a dire "no route"? A me sembra che la route ci sia eccome.
 
iptables? selinux?
 
S.
 


Non vedo particolari restrizioni:
 
[root@localhost slapd.d]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited
 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited
 
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 
Ho anche disattivato SElinux tramite "echo 0 /selinux/enforce", niente, telnet continua a fallire.

 Cosa proponi in alternativa?
 
OpenDJ anche perche`, a conti fatti, OpenLDAP non e` poi cosi` leggero
 
Enrico

 il primo utilizzo, gli rpm no.
 
Ovvio, perche` e` il mantainer del pacchetto che ha creato degli script post 
installazione che lo fanno per te, e non per qualche altro magico motivo. 
Come ho detto da un'altra parte, la differenza e` data dal fatto che in 
questo dettaglio la filosofia di Red Hat e` differente dalla filosofia di 
Debian, e cio` crea questi inconvenienti (se cosi` si possono chiamare)
 
Enrico
P.S. per inciso, il mantainer di 389ds segue la filosofia Red Hat mettendo a 
disposizione uno script di setup da lanciare a mano dopo aver installato il 
server
P.P.S. sempre per inciso, un modo per far funzionare (per ora) OpenLDAP 
senza sbattersi troppo e` creare uno file slapd.conf (vecchia 
configurazione) e lanciare il servizio (all'avvio ci pensera il demone a 
convertirlo nella nuova tipologia di configurazione)

 Cosa proponi in alternativa?
 
Un paio di anni fa installai Sun Directory Server, 5 minuti di installazione e hai un ambiente LDAP già pronto.
 
Ora è passato sotto Oracle, non so come sia il nuovo licensing.
 


 
Si, il mio problema era cosa usare su macchine con poca ram o a 32 bit. 
Tutti questi software basati su JAVA (ammesso che lo sia anche il 
prodotto che citi) consumano vagonate di ram, cosa del tutto inutile se 
uso LDAP solo per avere una rubrica condivisa con un centinaio di indirizzi.
 
Per quell'uso mi ero trovato bene con OpenLDAP, mentre i vari "Apache 
directory servers" e assimilabili erano inutilizzabili.

 convertirlo nella nuova tipologia di configurazione)
 
il servizio credi di essere riuscito a farlo partire, in effett l'RPM contiene uno slapd.conf da importare dopo averlo modificato opportunamente. Quello che mi blocca adesso è che il servizio sembra sordo alle chiamate esterne. Mistero.

 telnet continua a fallire.
 
Disabilitalo da /etc/sysconfig/selinux e riavvia la macchina, non mi 
stupirei se ci sia un qualche processo che lo riabiliti in automatico. 
Inoltre, elimina tutte quelle regole di iptables, non ricordo se quel 
reject-with icmp-host-prohibited sia una catena a parte ma di sicuro hai il 
servizio bloccato
 
Enrico

 Avete suggerimenti?
 
Usare su red hat la suite specificadi ID management, che non fa uso di 
openldap e che è sicuramente superiore.


nuovo licensing?
A occhio direi che useranno l'id management di oracle e che Sun DS (sul 
quale lavoravo in Sun) farà una brutta fine.
 
Comunque, Fedora DS e Red Hat DS sono quasi identici a Sun DS.

 openldap e che è sicuramente superiore.
 
Per fare un po' di nomi, FreeIPA, che usa 389ds e SSSD (piu` kerberos e un 
altro po' di roba)
 
Enrico

 Comunque, Fedora DS e Red Hat DS sono quasi identici a Sun DS.
 
FedoraDS e RedhatDS non esistono piu` ora esiste solo 389ds :)
Per inciso, i due software da te citati (389ds e SunDS) non erano altro che 
il vecchio Netscape Directory Server (si, la storia dei server LDAP e` 
qualcosa che somiglia di piu` ad una telenovela che ad uno sviluppo 
software)
 
Enrico


Alla fine il problema con openldap l'ho risolto, mancava una regola
opportuna su hosts.allow. Ma avete ragione, bisogna usare IPA-server che
è assemblato apposta.
-- 
 Il sex-appeal di un vogon e' uguale a quello di un incidente stradale.
 		-- Douglas Adams, "Guida Galattica per gli Autostoppisti"