openldap: accesso a cn=config

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

openldap: accesso a cn=config

Messaggio da 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?
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Meskalamdug
Iper Master
Iper Master
Messaggi: 3961
Iscritto il: ven 14 mag 2004, 0:00

Re: openldap: accesso a cn=config

Messaggio da 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.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da 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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Meskalamdug
Iper Master
Iper Master
Messaggi: 3961
Iscritto il: ven 14 mag 2004, 0:00

Re: openldap: accesso a cn=config

Messaggio da Meskalamdug »

ZeroUno ha scritto: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.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da ZeroUno »

Meskalamdug ha scritto: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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da 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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Meskalamdug
Iper Master
Iper Master
Messaggi: 3961
Iscritto il: ven 14 mag 2004, 0:00

Re: openldap: accesso a cn=config

Messaggio da Meskalamdug »

ZeroUno ha scritto: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..

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da 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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da ZeroUno »

slapadd riesce ad aggiungere anche le entry sporche :)
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Meskalamdug
Iper Master
Iper Master
Messaggi: 3961
Iscritto il: ven 14 mag 2004, 0:00

Re: openldap: accesso a cn=config

Messaggio da 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 \:D/

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da 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
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da 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 ) )
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Meskalamdug
Iper Master
Iper Master
Messaggi: 3961
Iscritto il: ven 14 mag 2004, 0:00

Re: openldap: accesso a cn=config

Messaggio da Meskalamdug »

ZeroUno ha scritto: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 \:D/ )
riguardo il tuning ci penserei in un secondo memento,ciao.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: openldap: accesso a cn=config

Messaggio da 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?
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Re: openldap: accesso a cn=config

Messaggio da masalapianta »

ZeroUno ha scritto: 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?

Rispondi