Loading
Home » Computer » Linux » opends e sunds
opends e sunds [messaggio #39701] |
mar, 21 giugno 2011 11:09 ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Matteo Rossini Messaggi: 10 Registrato: giugno 2011 |
Junior Member |
|
|
Salve.
Ho un ldap SunDS installato su una macchina.
Ora devo installare un altro server con un ldap free; pensavo ad
OpenDS (ma anche 389-directory server, di fedora) per la maggiore
compatibilità trovata con SunDS.
Poi ho bisogno di mettere i due in replica, per la precisione l'OpenDS
va messo come consumer di SunDS (quindi l'OpenDS sarebbe in read-
only).
Finora non sono riuscito a configurare tale replica e su google non
sono riuscito a trovare niente.
Qualcuno sa se e come si può fare?
Grazie,
Matteo
|
|
| |
Re: opends e sunds [messaggio #39729 è una risposta a message #39720] |
mer, 22 giugno 2011 10:52 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Matteo Rossini Messaggi: 10 Registrato: giugno 2011 |
Junior Member |
|
|
Il directory server SunDS è stato scelto per la piattaforma,
all'inizio dello scorso anno, non da me (non so se sono stati gli
sviluppatori o chi; a suo tempo poi devo dire che ero ignorante in
materia di DS, il che non è buona cosa per mettere in piedi una
piattaforma che si basa su di esso).
Ora abbiamo bisogno di una copia dell'ldap in sola lettura.
Fortunatamente in mancanza di repliche posso permettermi un
allineamento non in realtime (export/import notturno).
L'opzione di cambiare ldap è pura utopia anche se l'ambiente non fosse
in produzione (comporterebbe la riscrittura di metà o forse più degli
applicativi, verificare se è ufficialmente supportato dai prodotti
proprietari che usiamo, e mesi di test funzionali e prestazionali
dell'intera piattaforma...! no! già ci sono voluti mesi per migrare la
piattaforma su hardware più potente di quello iniziale, ma comunque
stesso tipo di hardware e stessa distribuzione (ad eccezione del
database, passato da aix a redhat).
Ora non mi resta che aspettare la prossima settimana che torna lo
sviluppatore dalle ferie e tirargli le orecchie per aver consigliato
OpenDS (noi stavamo puntanto su "389-directory server" di fedora;
stavamo cercando il DS che meglio poteva importare lo schema -
99user.ldif per intenderci). Tale sviluppatore ha detto che OpenDS si
può anche mettere in replica con SunDS (ma ce lo ha solo accennato...;
mi sembra strano però, non so se lo ha provato; questo è tra gli
sviluppatori in gamba e autorevole - mezza piattaforma è sviluppata da
lui... e funziona discretamente - e mi sembra strano che abbia preso
una tale toppa).
Vabbé, intanto provo OpenDJ e vedo se importa meglio il 99user.ldif
(OpenDS mi ha dato qualche problema con un paio di attributi, 389-
directory server mi sembra di no, ma ho fatto prove superficiali), poi
vedremo il da farsi.
Grazie,
Matteo
|
|
|
Re: opends e sunds [messaggio #39768 è una risposta a message #39729] |
gio, 23 giugno 2011 01:16 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Enrico 'Henryx' Bianc Messaggi: 212 Registrato: febbraio 2011 |
Senior Member |
|
|
Matteo Rossini wrote:
> Fortunatamente in mancanza di repliche posso permettermi un
> allineamento non in realtime (export/import notturno).
Domanda mia: SunDS non supporta le repliche? Quali sarebbero i problemi nel
creare una seconda macchina con questo prodotto?
> (comporterebbe la riscrittura di metà o forse più degli
> applicativi, verificare se è ufficialmente supportato dai prodotti
> proprietari che usiamo, e mesi di test funzionali e prestazionali
> dell'intera piattaforma...!
Errato, in quanto la dipendenza lato applicativo verso il server LDAP e`
meno sentita rispetto a quella che si avrebbe utilizzando un RDBMS. Per
spiegarmi meglio, devi considerare che LDAP e` un protocollo stanrdard, di
conseguenza la differenza fra i vari server in circolazione non e` basata su
come tale standard e` implementato, ma sulle caratteristiche di gestione dei
dati salvati nella directory
> no! già ci sono voluti mesi per migrare la
> piattaforma su hardware più potente di quello iniziale,
Personalmente farei una prova, anche informale
> (noi stavamo puntanto su "389-directory server" di fedora;
> stavamo cercando il DS che meglio poteva importare lo schema -
> 99user.ldif per intenderci).
Se quello schema funziona con 389ds, e quello schema e` essenziale per i
vostri scopi, allora ti consiglio vivamente la migrazione
> Tale sviluppatore ha detto che OpenDS si
> può anche mettere in replica con SunDS (ma ce lo ha solo accennato...;
Perche` sul wiki di OpenDS e` scritto chiaramente che nelle future versioni
avrebbero supportato le repliche con SunDS
> Vabbé, intanto provo OpenDJ e vedo se importa meglio il 99user.ldif
> (OpenDS mi ha dato qualche problema con un paio di attributi, 389-
> directory server mi sembra di no, ma ho fatto prove superficiali), poi
> vedremo il da farsi.
La strada e` quella, togliete SunDS e passate a qualcos'altro che meglio si
adatta alle vostre esigenze
Enrico
|
|
|
Re: opends e sunds [messaggio #39776 è una risposta a message #39768] |
gio, 23 giugno 2011 12:46 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Matteo Rossini Messaggi: 10 Registrato: giugno 2011 |
Junior Member |
|
|
> Domanda mia: SunDS non supporta le repliche? Quali sarebbero i problemi nel
> creare una seconda macchina con questo prodotto?
>
licenze
> > (comporterebbe la riscrittura di metà o forse più degli
> > applicativi, verificare se è ufficialmente supportato dai prodotti
> > proprietari che usiamo, e mesi di test funzionali e prestazionali
> > dell'intera piattaforma...!
>
> Errato, in quanto la dipendenza lato applicativo verso il server LDAP e`
> meno sentita rispetto a quella che si avrebbe utilizzando un RDBMS. Per
> spiegarmi meglio, devi considerare che LDAP e` un protocollo stanrdard, di
> conseguenza la differenza fra i vari server in circolazione non e` basata su
> come tale standard e` implementato, ma sulle caratteristiche di gestione dei
> dati salvati nella directory
>
Non sono un esperto ldap, ma dall'esperienza che ho fatto in un anno e
mezzo che ci lavoro ti assicuro che a seconda dei tipi di utilizzo che
ne fanno gli applicativi talvolta può non bastare il protocollo
standard. Abbiamo faticato, a suo tempo, a trovare un ldap compatibile
con un paio di prodotti proprietari. Basti pensare che alcuni schema
di base non sono identici o non sono presenti tra sunds e opendj e per
fare l'import ho dovuto fare un overwrite ed in più importare i dati
con --skipSchemaValidation
> > no! già ci sono voluti mesi per migrare la
> > piattaforma su hardware più potente di quello iniziale,
>
> Personalmente farei una prova, anche informale
>
BUM!!!
abbiamo tre ambienti, sviluppo, collaudo e produzione; ognuno di
questi ambienti è diviso in 3 parti, gestito da 3 gruppi separati per
tipologia per dislocazione geografica, per ditta di appartenenza e per
server gestiti (anche se sono sulla stessa lan); ognuno di questi
gruppi non parla in modo diretto l'uno con l'altro ma via un tramite.
L'ambiente di sviluppo, quello in teoria candidato per l'esperimento,
non è gestito applicativamente da me (io ho la gestione sistemistica,
il resto è demandato agli sviluppatori).
La modifica di una sola virgola in collaudo (ogni nuovo aggiornamento,
anche minor) comporta il test della componente modificata e di quelle
coinvolte... L'ldap è usato da tutte le componenti. E a seconda del
tipo di modifica anche gli stress test vanno rifatti. Non parliamo poi
del fatto che l'ldap incide prestazionalmente sullo storage esterno
(su cui in passato abbiamo avuto seri problemi).
Già in collaudo lo _stop_ di una componente è spesso necessario
comunicarlo se questo comporta un disservizio (il collaudo è in uso
quasi quanto lo è produzione).
Trasla tutto sull'ambiente di produzione e moltiplica per 10 (abbiamo
un milione di utenze).
> Se quello schema funziona con 389ds, e quello schema e` essenziale per i
> vostri scopi, allora ti consiglio vivamente la migrazione
>
Lo schema personalizzato è chiaramente essenziale per il funzionamento
della piattaforma.
Per 389ds l'import dello schema era andato ok, ma l'import dei dati
era stato fatto con un export non completo. Non saprei come si
potrebbe comportare con l'export completo, non ho ancora provato.
> Perche` sul wiki di OpenDS e` scritto chiaramente che nelle future versioni
> avrebbero supportato le repliche con SunDS
>
1) non sono riuscito a trovarlo sul wiki, né altrove
2) opends è morto; opendj non è un clone di opends ma una rinomina
(confronta date, versioni e timeline presente passata e futura).
3) A dire la verità anche SunDS è morto, sostituito da OracleDS
|
|
| |
Re: opends e sunds [messaggio #39790 è una risposta a message #39776] |
ven, 24 giugno 2011 00:51 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Enrico 'Henryx' Bianc Messaggi: 212 Registrato: febbraio 2011 |
Senior Member |
|
|
Matteo Rossini wrote:
> licenze
Posto che non sarebbe un discorso da fare, ma infischiarsene ed installarne
una copia per la replica? :)
> Non sono un esperto ldap, ma dall'esperienza che ho fatto in un anno e
> mezzo che ci lavoro ti assicuro che a seconda dei tipi di utilizzo che
> ne fanno gli applicativi talvolta può non bastare il protocollo
> standard.
Cosa intendi? Tieni presente che il protocollo lato comunicazione
applicativo/server e` standard, di conseguenza da quel punto di vista
sei/siete a posto
> Basti pensare che alcuni schema
> di base non sono identici o non sono presenti tra sunds e opendj
Beh, gli schemi sono parte integrante di come il server gestisce i dati, non
di come li comunica al client :)
>ognuno di questi
> gruppi non parla in modo diretto l'uno con l'altro ma via un tramite.
Posto che sono vostre scelte, la reputerei una brutta cosa
> L'ambiente di sviluppo, quello in teoria candidato per l'esperimento,
> non è gestito applicativamente da me (io ho la gestione sistemistica,
> il resto è demandato agli sviluppatori).
Non vedo dove sia il problema, alla fine si tratta di creare una macchina
virtuale dove installare 389ds (che, da quello che ho capito, e` il server
LDAP che ti creerebbe meno problemi di migrazione), vedere se gli schemi
vengono correttamente riconosciuti e fare un import dei dati via LDIF
> La modifica di una sola virgola in collaudo (ogni nuovo aggiornamento,
> anche minor) comporta il test della componente modificata e di quelle
> coinvolte...
Ecco, questo e` il vero problema, anche se non vedo molte soluzioni per
eliminarlo
> Già in collaudo lo _stop_ di una componente è spesso necessario
> comunicarlo se questo comporta un disservizio (il collaudo è in uso
> quasi quanto lo è produzione).
C'e` qualcosa che non mi torna, come puo` il fermo di un server di test
comportare un disservizio?
> Trasla tutto sull'ambiente di produzione e moltiplica per 10 (abbiamo
> un milione di utenze).
Ecco, questo e` un altro problema (minore del primo ma tant'e`): la mole di
dati non e` indifferente :)
> Per 389ds l'import dello schema era andato ok, ma l'import dei dati
> era stato fatto con un export non completo. Non saprei come si
> potrebbe comportare con l'export completo, non ho ancora provato.
Personalmente, per test interni, ho provato l'import dei dati da OpenLDAP
verso 389ds o OpenDJ. In tutti e due i casi, a parte il riconoscimento
iniziale degli schemi (lo schema Samba non e` direttamente disponibile per
OpenDS), l'import e` andato a buon fine ed il server era direttamente
funzionante. C'e` comunque da dire che non ho mai usato direttamente questi
server LDAP (la sostituzione di OpenLDAP mi e` decisamente difficile per
svariati motivi), ma una interrogazione tramite strumenti agnostici (e.g.
LDAP Browser) non mi diede alcun problema
> 1) non sono riuscito a trovarlo sul wiki, né altrove
https://www.opends.org/wiki/page/Replication e` in fondo alla pagina
> 2) opends è morto; opendj non è un clone di opends ma una rinomina
> (confronta date, versioni e timeline presente passata e futura).
OpenDJ e` un fork di OpenDS, punto. I motivi per cui preferire OpenDJ
rispetto all'originale sono dovuti al fatto che OpenDS e` in una fase di
stallo (ovvero Oracle non ha piu` rilasciato aggiornamenti da ottobre 2010),
ma da nessuna parte e` scritto che il progetto e` morto
> 3) A dire la verità anche SunDS è morto, sostituito da OracleDS
Motivo in piu` per spingere ad una migrazione verso un altro prodotto
Enrico
|
|
| |
Re: opends e sunds [messaggio #39901 è una risposta a message #39893] |
lun, 27 giugno 2011 20:05 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) |
Enrico 'Henryx' Bianc Messaggi: 212 Registrato: febbraio 2011 |
Senior Member |
|
|
Matteo Rossini wrote:
> La replica master->consumer viene fatta perfettamente, ma mi viene
> consentito anche l'ldapmodify sul consumer
Detta cosi` sembra che tu abbia una configurazione multimaster. Sei sicuro
che sia impostato come consumer?
Enrico
|
|
|
Vai al forum:
Ora corrente: lun set 02 22:17:28 CEST 2024
Tempo totale richiesto per generare la pagina: 0.02444 secondi
|