openldap: accesso a cn=config

[ZeroUno]

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)

Che alla fine è quello che stavo cercando di fare io

oppure hanno modificato gli schema per far apparire una delle due, sottoclasse dell'altra (altra porcheria ignobile)

e che è ancora una delle cose che avevo pensato di fare (non così ma simile) cercando di fare per risolvere

oppure hanno creato un'altra classe, sottoclasse di entrambe (altra porcheria solo lievemente meno ignobile delle precedenti)

a questa non ci ho pensato.. buona idea

Alla fine ho risolto con nessuna di quelle sopra perchè non mi andava di modificare core.schema (anche perchè i tentativi che ho fatto sono tutti miserabilmente falliti).
Alla fine ho modificato la classe custom che falliva (ufficio) togliendo il "SUP organizationalUnit" e aggiungendo 'ou' agli attributi in in MAY (). Poi prima dell'import faccio una sed che mi toglie tutte le occorrenze di organizationalUnit dal'ldif di origine. Tanto alla fine i dati vengono rielaborati e spostati su un sunds.

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?

L'ldif me lo prendo io con un ldapsearch. Sono solo 65.000 entry, ci mette un minuto a scaricarle. Il fatto è che questo è un ldap che sta su internet e acceduto da tanti, quindi metterlo in replica non è fattibile (e nemmeno sicuro). Poi ho notato, dal createtimestamp, che anche quell'ldap viene distrutto e ricreato ogni giorno.
Al momento noi abbiamo uno script che
scarica la entry #1 (stabilendo connessione), elabora, trasforma ed inserisce nel sunds
scarica la entry #2 (stabilendo una nuova connessione), elabora, trasforma ed inserisce nel sunds
e così via per tutte e 65000. Il tutto dura un paio di ore.

Il fornitore si è giustamente venuto a lamentare che 65000 query al giorno non gli stanno bene.
Le soluzioni sono 2:
1) modificare lo script per fare una unica query e buttarsi tutto in ram e poi cominciare la trasformazione
2) mettere un ldap buffer locale e poi fare le query su quello

La seconda è la più semplice, e quindi abbiamo optato per quella.