openldap: accesso a cn=config
Moderatore: Staff
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.
- ZeroUno
- 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
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?
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
-
- Iper Master
- Messaggi: 3961
- Iscritto il: ven 14 mag 2004, 0:00
Re: openldap: accesso a cn=config
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
- ZeroUno
- 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
Al ramo "dati" ci accedo tranquillamente.
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
-
- Iper Master
- Messaggi: 3961
- Iscritto il: ven 14 mag 2004, 0:00
Re: openldap: accesso a cn=config
Allora controlla le acl.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.
- ZeroUno
- 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
ci avevo provato, comunque nei commenti c'èMeskalamdug ha scritto:Allora controlla le acl.
"# rootdn can always read and write EVERYTHING!"
ora però devo scappare. Domani vedo di fare un po' di altre prove.
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- ZeroUno
- 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
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'
)
slapd[5915]: conn=0 op=2048 RESULT tag=105 err=20 text=servizioTelematico: value #1 provided more than once
Questo è abbastanza bloccante.
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
-
- Iper Master
- Messaggi: 3961
- Iscritto il: ven 14 mag 2004, 0:00
Re: openldap: accesso a cn=config
C'è una stringa duplicata.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:Non è specificato "SINGLE-VALUE" il che significa che quando vado ad inserire una entry che ha questo attributo duplicato dovrebbe inserirla, invece fallisce: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' )
slapd[5915]: conn=0 op=2048 RESULT tag=105 err=20 text=servizioTelematico: value #1 provided more than once
Questo è abbastanza bloccante.
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
- 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
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.
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- ZeroUno
- 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
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
-
- Iper Master
- Messaggi: 3961
- Iscritto il: ven 14 mag 2004, 0:00
Re: openldap: accesso a cn=config
Ti trovi meglio con openldap o ldap di solaris?
Parere mio: meglio openldap.
ps=che infatti in solaris 11 è installata di default
- ZeroUno
- 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
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
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- ZeroUno
- 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
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
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 ) )
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
-
- Iper Master
- Messaggi: 3961
- Iscritto il: ven 14 mag 2004, 0:00
Re: openldap: accesso a cn=config
Qui sul forum non riesco a darti una risposta in tempi immediati.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 è(ho offuscato i dati, ma in verità sono di pubblico dominio)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
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 ) )
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
- 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
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 ) )
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?
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- masalapianta
- 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
è 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.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)
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?