openldap: accesso a cn=config

[ZeroUno]

Salve.

Devo mettere in piedi un server openldap (2.3.43 su redhat). Finora ho sempre configurato solo il directory server della Sun.

Ho fatto nuova installazione, ma dopo averlo startato non riesco ad accedere - neanche in sola lettura - al ramo cn=config, come invece faccio di solito con SunDS.
In slapd.conf c'è scritto, nei commenti:

# rootdn can always read and write EVERYTHING!

ma se provo ad accedere con l'utente specificato in rootdn mi risponde con
ldap_search: Insufficient access

Qualcuno sa come si risolve?

[Meskalamdug]

Ti conviene partire da zero.
Io farei così

Codice: Seleziona tutto

cp -a /etc/openldap /etc/openldap .old
rm -fr /etc/openldap/slap.d
ti configuri uno slapd.conf fatto bene(in rete trovi un sacco di documentazione e file di esempio
slaptest -f slapd.conf -F /etc/openldap/slap.d
service slapd restart
adesso configuri un file di init simile a questo
#fileinit.ldif
dn: dc=dominio,dc=com
objectclass: dcObject
objectclass: organization
o: vostraorganizzazione

dc: dc=dominio,dc=com
dn: cn=root,dc=dominio,dc=com
objectclass: organizationalRole
cn: root

#
ldapadd -D cn=root,dc=dominio,dc=com -w password < fileinit.ldif


Dovresti così ottenere l'albero iniziale.

[ZeroUno]

Domani provo, ma quello a cui non accedo io è il cn=config, cioè il ramo dove sono le configurazioni, gli schemi ecc.

Al ramo "dati" ci accedo tranquillamente.

[Meskalamdug]

Domani provo, ma quello a cui non accedo io è il cn=config, cioè il ramo dove sono le configurazioni, gli schemi ecc.

Al ramo "dati" ci accedo tranquillamente.

Allora controlla le acl.

[ZeroUno]

Allora controlla le acl.

ci avevo provato, comunque nei commenti c'è
"# rootdn can always read and write EVERYTHING!"


ora però devo scappare. Domani vedo di fare un po' di altre prove.

[ZeroUno]

Al momento questo problema l'ho smarcato e non è prioritario.

Ne ho un altro più importante.

Ho importato uno schema che inserisce, tra i vari attributi, questo:

Codice: Seleziona tutto

attributetype ( 16572.1.2.7
        NAME 'servizioTelematico'
        DESC 'URL di un servizio fruibile da Internet'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.26'
        )

Non è specificato "SINGLE-VALUE" il che significa che quando vado ad inserire una entry che ha questo attributo duplicato dovrebbe inserirla, invece fallisce:
slapd[5915]: conn=0 op=2048 RESULT tag=105 err=20 text=servizioTelematico: value #1 provided more than once

Questo è abbastanza bloccante.

[Meskalamdug]

Al momento questo problema l'ho smarcato e non è prioritario.

Ne ho un altro più importante.

Ho importato uno schema che inserisce, tra i vari attributi, questo:

Codice: Seleziona tutto

attributetype ( 16572.1.2.7
        NAME 'servizioTelematico'
        DESC 'URL di un servizio fruibile da Internet'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.26'
        )

Non è specificato "SINGLE-VALUE" il che significa che quando vado ad inserire una entry che ha questo attributo duplicato dovrebbe inserirla, invece fallisce:
slapd[5915]: conn=0 op=2048 RESULT tag=105 err=20 text=servizioTelematico: value #1 provided more than once

Questo è abbastanza bloccante.

C'è una stringa duplicata.
Io la cercherei sia nel database sia nelle configurazioni
e ci metterei rimedio.
Altrimenti una soluzione brutta(fatti un backup prima)
è quella di usare lo switch -c che vuol dire continua in caso
di errori.
Ma non te la consiglio..

[ZeroUno]

Se ti riferisci alla entry da inserire, c'è PIU' di una riga duplicata.
servizioTelematico è multivalue, cioè l'utenza può avere più di un servizio telematico. Questo è supportato da ldap.


O pensi ad un doppione dello schema?
Ora controllo.


edit:
strano però, perchè molti attributi sono duplicabili, ma solo quello fallisce

edit2: ho scoperto l'arcano (forse è quello che dici tu ma non l'avevo capito).
la entry che fallisce non ha semplicemente 'servizioTelematico' duplicato, ma ha anche il CONTENUTO di 'servizioTelematico' duplicato. Quì il fallimento.
A questo punto però devo indagare, perchè l'ldif che ho è preso da un ldapsearch, il che significa che quello mi ha tirato fuori l'anomalia.

[ZeroUno]

slapadd riesce ad aggiungere anche le entry sporche

[Meskalamdug]

Felice che tu abbia risolto.
Ti trovi meglio con openldap o ldap di solaris?
Parere mio: meglio openldap.

ps=che infatti in solaris 11 è installata di default

[ZeroUno]

in verità la scelta é dettata dalle compatibilità con le applicazioni. Questo ldap é un DS 'usa e getta'. In pratica scarico il contenuto di un ldap, lo importo, lo lavoro, lo distruggo. E il giorno successivo ricomincio. L'ldap remoto é openldap e quello ho usato.

Per un altra applicazione uso sunds, per un'altra 389ds e un'altra critical path ds.
Avevo testato anche opends e opendj ma non andavano bene.
Colleghi hanno provato oracle ds che sembra andare un po' meglio di sunds.

openldap l'ho usato ieri per la prima volta, quindi non saprei fare il confronto.

Edit: sun si era buttata molto sull'open, e difatti solaris 10 ha inserito di default la /usr/sfw; oracle solaris é tutto un punto interrogativo ancora

[ZeroUno]

Altre due cose:

prima cosa) DB_CONFIG: dalla documentazione dovrei dare una tunata a questo file prima di creare il db. Solo che non saprei proprio cosa metterci. Al momento ho lasciato i valori già presenti in quello di default:
# one 0.25 GB cache
set_cachesize 0 268435456 1
# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152

Considera che l'uso di questo ldap è:
1) inserimento in blocco di 65000 entry con slapadd (durata pochi minuti). La dimensione finale di /var/lib/ldap è di 200MB, ma devo ancora tunare gli indici.
2) elaborazione (accesso readonly una entry per volta con un programma in java). durata qualche ora (per accesso a componenti esterni e per elaborazione)
3) distruzione dell'ldap

seconda cosa.
Le 65000 entry sono prese da un export (con ldapsearch) di un altro openldap stessa versione (2.3.43) a cui non ho accesso per vedere la configurazione e altro.
Durante l'import (con i log in debug) per ogni entry ho
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989)

Per le prime c.a. 36000 entry l'inserimento avviene con successo. Per tutte le rimanenti ottengo
slapadd: dn="ou=serfin,o=c_f335,c=it" (line=737462): (65) invalid structural object class chain (organization/organizationalUnit)

l'ldif è

Codice: Seleziona tutto

dn: ou=serfin,o=c_f335,c=it
objectClass: top
objectClass: organization
objectClass: organizationalUnit
objectClass: ufficio
description: Descrizione
ou: serfin
o: c_f335
street: via xxxxxxxxxx
postalCode: 10024
l: AAAAAAAAA
provincia: TO
regione: Piemonte
nomeResp: Nome
cognomeResp: Cognome
telephonenumberResp: 011xxxxxx
telephoneNumber: 011xxxxxx
mailResp: aaaa@bbbb.it
mail: xxxx@yyyy.it
contatti: cccc@dddd.it#pec
aooRef: aoo=aooac,o=c_f335,c=it
CodiceUnivocoUO: XXXXXX

(ho offuscato i dati, ma in verità sono di pubblico dominio)

Cercando su internet sembra come se quegli objectClass non possono stare insieme perchè conflittano tra loro, ma in tal caso non dovrebbe essere presente nemmeno sull'ldap di origine.
Lo schema è di pubblico dominio quindi dovrebbero essere uguali.


edit: la definizione di organization e organizationalUnit sono quelli di core.schema
la definizione di ufficio è custom:

Codice: Seleziona tutto

objectclass ( 16572.1.1.3
        NAME 'ufficio'
        DESC 'Ufficio o Unita Organizzativa'
        SUP organizationalUnit
        MUST ( description )
        MAY
         ( servizioTelematico $ telephoneNumber $ CAurl $ mail $
        mailPEC $ facsimileTelephoneNumber $ l $ street $
        postalcode $ nomeS $ descrizioneS $ fruibS $ mailS $
        mailSPEC $ aooRef $ telephoneNumberS $ st $ nomeResp $
        cognomeResp $ mailResp $ mailRespPEC $ telephoneNumberResp $
        regione $ provincia $ dataUltimoAggiornamentoDaSecondario $
        codiceUO $ contatti $ nomeSFE $ canaletrasmissivoSFE $
        telephonenumberRespSFE $ MailRespSFE $ intermediarioSFE $
        mailSFE $ URISFE $ mailSPub $ mailSFEPEC $ dataVerifica $
        CodiceUnivocoUO ) )

[Meskalamdug]

Altre due cose:

prima cosa) DB_CONFIG: dalla documentazione dovrei dare una tunata a questo file prima di creare il db. Solo che non saprei proprio cosa metterci. Al momento ho lasciato i valori già presenti in quello di default:
# one 0.25 GB cache
set_cachesize 0 268435456 1
# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152

Considera che l'uso di questo ldap è:
1) inserimento in blocco di 65000 entry con slapadd (durata pochi minuti). La dimensione finale di /var/lib/ldap è di 200MB, ma devo ancora tunare gli indici.
2) elaborazione (accesso readonly una entry per volta con un programma in java). durata qualche ora (per accesso a componenti esterni e per elaborazione)
3) distruzione dell'ldap

seconda cosa.
Le 65000 entry sono prese da un export (con ldapsearch) di un altro openldap stessa versione (2.3.43) a cui non ho accesso per vedere la configurazione e altro.
Durante l'import (con i log in debug) per ogni entry ho
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989)

Per le prime c.a. 36000 entry l'inserimento avviene con successo. Per tutte le rimanenti ottengo
slapadd: dn="ou=serfin,o=c_f335,c=it" (line=737462): (65) invalid structural object class chain (organization/organizationalUnit)

l'ldif è

Codice: Seleziona tutto

dn: ou=serfin,o=c_f335,c=it
objectClass: top
objectClass: organization
objectClass: organizationalUnit
objectClass: ufficio
description: Descrizione
ou: serfin
o: c_f335
street: via xxxxxxxxxx
postalCode: 10024
l: AAAAAAAAA
provincia: TO
regione: Piemonte
nomeResp: Nome
cognomeResp: Cognome
telephonenumberResp: 011xxxxxx
telephoneNumber: 011xxxxxx
mailResp: aaaa@bbbb.it
mail: xxxx@yyyy.it
contatti: cccc@dddd.it#pec
aooRef: aoo=aooac,o=c_f335,c=it
CodiceUnivocoUO: XXXXXX

(ho offuscato i dati, ma in verità sono di pubblico dominio)

Cercando su internet sembra come se quegli objectClass non possono stare insieme perchè conflittano tra loro, ma in tal caso non dovrebbe essere presente nemmeno sull'ldap di origine.
Lo schema è di pubblico dominio quindi dovrebbero essere uguali.


edit: la definizione di organization e organizationalUnit sono quelli di core.schema
la definizione di ufficio è custom:

Codice: Seleziona tutto

objectclass ( 16572.1.1.3
        NAME 'ufficio'
        DESC 'Ufficio o Unita Organizzativa'
        SUP organizationalUnit
        MUST ( description )
        MAY
         ( servizioTelematico $ telephoneNumber $ CAurl $ mail $
        mailPEC $ facsimileTelephoneNumber $ l $ street $
        postalcode $ nomeS $ descrizioneS $ fruibS $ mailS $
        mailSPEC $ aooRef $ telephoneNumberS $ st $ nomeResp $
        cognomeResp $ mailResp $ mailRespPEC $ telephoneNumberResp $
        regione $ provincia $ dataUltimoAggiornamentoDaSecondario $
        codiceUO $ contatti $ nomeSFE $ canaletrasmissivoSFE $
        telephonenumberRespSFE $ MailRespSFE $ intermediarioSFE $
        mailSFE $ URISFE $ mailSPub $ mailSFEPEC $ dataVerifica $
        CodiceUnivocoUO ) )

Qui sul forum non riesco a darti una risposta in tempi immediati.
Dovrei metterci le mani su ed eventualmente googleggiarci
,per il momento consiglio:
Google,con megaricerca(io a volte ci ho messo ore..ma ho sempre risolto )
riguardo il tuning ci penserei in un secondo memento,ciao.

[ZeroUno]

Ho fatto un test.

Ho eliminato lo schema custom e lasciato solo core.schema

Ho tentato di inserire la entry:
dn: o=prova,c=it
objectClass: top
objectClass: organization
objectClass: organizationalUnit
o: prova

e da lo stesso fallimento. invalid structural object class chain (organization/organizationalUnit)
infatti organization e organizationalUnit sono entrambi nel core.schema

Codice: Seleziona tutto

objectclass ( 2.5.6.4 NAME 'organization'
        DESC 'RFC2256: an organization'
        SUP top STRUCTURAL
        MUST o
        MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
                x121Address $ registeredAddress $ destinationIndicator $
                preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
                telephoneNumber $ internationaliSDNNumber $
                facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
                postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

objectclass ( 2.5.6.5 NAME 'organizationalUnit'
        DESC 'RFC2256: an organizational unit'
        SUP top STRUCTURAL
        MUST ou
        MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
                x121Address $ registeredAddress $ destinationIndicator $
                preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
                telephoneNumber $ internationaliSDNNumber $
                facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
                postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

Il fatto è che l'ldap sorgente ha la stessa versione e quindi stesso core.schema suppongo.
Possibile che nella configurazione abbiano qualcosa tipo "fregatene degli errori" ?

Adesso cerco. Se esiste qualcosa del genere ce la metto pure io e buonanotte al secchio




edit: che differenza c'è tra core.schema e core.ldif?

[masalapianta]

Ho tentato di inserire la entry:
dn: o=prova,c=it
objectClass: top
objectClass: organization
objectClass: organizationalUnit
o: prova

e da lo stesso fallimento. invalid structural object class chain (organization/organizationalUnit)

è normale, organization ed organizationalUnit non appartengono alla medesima catena di classi: entrambe sono sottoclassi strutturali di top ma non viene usata una sottoclasse di entrambe.

Come detto, per poterle avere entrambe, dovrebbe essere presente anche una sottoclasse di entrambe (cosa che comunque è sbagliata dal punto di vista logico, perchè o un oggetto è un'organizzazione oppure è un'unità organizzativa (non entrambe le cose).

Se sul ldap server, da cui è tratto l'ldif che cerchi di importare, funziona significa che o hanno trovato il modo di non far fare al server il controllo sulla catena delle classi appartenenti al medesimo oggetto (porcheria ignobile) oppure hanno modificato gli schema per far apparire una delle due, sottoclasse dell'altra (altra porcheria ignobile), oppure hanno creato un'altra classe, sottoclasse di entrambe (altra porcheria solo lievemente meno ignobile delle precedenti), che però non risulta nel ldif che ti han passato.

Per quanto riguarda il fare l'export di un ldif da un ldap server, mandare il file a te, importarlo in un altro ldap server e fare delle elaborazioni sui dati interrogando l'ldap server (per poi distruggere tutto una volta finito), non fate prima e meglio a metterli in replica master/slave?