Repository 32bit  Forum
Repository 64bit  Wiki

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.

Re: openldap: accesso a cn=config

Messaggioda ZeroUno » mer mar 13, 2013 13:45

masalapianta ha scritto: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 :D

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.
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: 4412
Iscritto il: ven giu 02, 2006 13:52
Località: Roma / Castelli
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current

Precedente

Torna a Gnu/Linux in genere

Chi c’è in linea

Visitano il forum: Nessuno e 2 ospiti

cron