Utilizzo della riga di comando

Modifica in linea

È possibile emettere i comandi qui forniti alla riga di comando per creare un sottoalbero.

Questo scenario presuppone che si stia creando un nuovo sottoalbero replicato e che solo server1 contenga dati di ingresso. Tutti gli altri server sono di recente installati, hanno un database configurato e sono stati avviati almeno una volta per scopi di inizializzazione. Il suffisso della struttura secondaria replicata deve essere già configurato su altri server. (Assicurarsi di leggere la sezione Sincronizzazione della crittografia bidirezionale tra istanze del server , nella documentazione IBM® Security Directory Server nella sezione Amministrazione prima di avviare le istanze del server.)
Nota: Il sottoalbero che si desidera creare è mostrato qui:
dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext
o: sample
Se questa voce esiste già, modificarla per aggiungere objectclass=ibm-replicationContext invece di aggiungere l'intera voce.
  1. Creare un file ldif suffix_update.ldif con le seguenti informazioni per aggiungere il suffisso objectclass=ibm-replicationContext al suffisso o al ramo già esistente:
    dn: o=sample
changetype: modify
add: objectclass
objectclass: ibm-replicationContext
  2. Utilizzare il comando idsldapmodify per modificare la voce suffisso su server1. Su server1 immettere il seguente comando:
    idsldapmodify -D <adminDN> -w <adminPW> -i suffix_update.ldif

server1 e server2 sono server peer - master. Il che significa che mentre ricevono aggiornamenti l'uno dall'altro, replicano solo le voci ricevute dai client. Mentre entrambi i master hanno lo stesso contenuto di ingresso, solo il server che ha ricevuto la richiesta client replica la voce. Entrambi i master sono fornitori e consumatori a vicenda e fornitori verso gli altri server.

È possibile utilizzare un metodo offline o un metodo online.

Per creare i peer master (server1 e server2) per la sottostruttura o=sample utilizzando il metodo offline:
  1. Avviare i server server1 e server2 in modalità solo configurazione. Su ciascuno dei server emettere il comando:
    idsslapd -I <instance_name> -a
  2. Se il server di gestione (idsdiradm) non è in esecuzione per nessuna istanza, avviare idsdiradm:
    idsdiradm -I <LDAP_instance>
  3. È necessario configurare server1 e server2 per essere server peer. Utilizzare il comando idsldapadd per aggiungere la seguente voce al file ibmslapd.conf su server1 e server2. Su server1 e server2 , immettere il seguente comando:
    idsldapadd -D <adminDN> -w <adminPW> -i<filename>
    dove <filename> contiene:
    dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret123
    Nota: È fondamentale che queste voci siano esattamente le stesse su entrambi i server perché questo esempio utilizza un oggetto credenziali condiviso su tutti i server. La password è inserita in cleartext, ma è crittografata nel file. ibm-slapdMasterDN deve essere univoco e non può essere uguale ad alcun DN già esistente.
  4. Stop server1 e server2. Per arrestare i server emettere il seguente comando su ciascuno dei server:
    idsslapd -I <instance_name> -k
    dove <nome_istanza> è il nome dell'istanza del server di directory che si desidera arrestare.
  5. Salvare i file ibmslapd.conf .
  6. Al computer dove si trova il server master, server1, creare un file da utilizzare per gli aggiornamenti delle informazioni di accordo; ad esempio mycredentialsfile, dove mycredentialsfile contiene:
    dn: cn=replication,cn=IBMpolicies
objectclass: container
 
###Bind Credentials/method to peer server - replication agreement
###points to this.
dn: cn=simple,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple
cn: simple
replicaBindDN: cn=any
replicaCredentials: secret123
description: Bind method of the peer master (server1)to the peer (server2)
    I valori replicaBindDN e replicaCredentials devono corrispondere rispettivamente ai valori ibm-slapdMasterDN e ibm-slapdMasterPW dalla voce del server principale nel passo 3.
  7. Emettere il comando:
    idsldif2db -i<mycredentialsfile> -I <instance_name>
  8. Copiare <mycredentialsfile> al computer dove server2 si trova e emettere il comando:
    idsldif2db -i<mycredentialsfile> -I <instance_name>
  9. Al computer dove si trova server1 si crea un file, <mytopologyfile>, dove < mytopologyfile> include la seguente impostazione:
    Nota: Sostituire tutte le occorrenze di <server1-uuid> nei file seguenti con il valore dell'attributo ibm-slapdServerId della voce cn=Configuration del server master. Questo valore viene generato dal server la prima volta che viene avviato. È possibile trovarlo eseguendo una idsldapsearch della voce cn = Configuration oppure utilizzando il comando grep nel file ibmslapd.conf , se si dispone di un sistema AIX®, Linux®o Solaris. Allo stesso modo, tutte le occorrenze di <serverx-uuid> (dove x rappresenta 1 o 2) devono essere sostituite con il valore dell'attributo ibm-slapdServerId della voce cn=Configuration del rispettivo server.
    dn: ibm-replicaGroup=default, o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: server 1 (peer master) ibm-replicaSubentry 

dn: ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: true
cn: server2
description: server2 (peer master) ibm-replicaSubentry 

#server1 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(master) to server2(master) agreement

#server2 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(master) to server1(master) agreement
  10. Per caricare questa topologia, emettere il comando:
    idsldif2db -r no -i<mytopologyfile> -I <instance_name>
    dove -r no impedisce la replica della serie di voci.
  11. A questo punto potresti voler caricare ulteriori dati per il tuo subalbero.
    Nota: utilizzare l'indicatore -r no per evitare la replica della serie di voci.
  12. Una volta terminato il caricamento dei dati, per poter esportare la topologia ed eventuali ulteriori dati per il contesto di replica per popolare gli altri server, emettere il comando:
    idsdb2ldif -s"o=sample" -o <mymasterfile.ldif> -I <instance_name> \
		-k <key seed> -t <key salt>
    Nota: è necessario utilizzare l'opzione -I se è presente più di un'istanza. È necessario utilizzare le opzioni -k e -t se le chiavi sul server non sono sincronizzate. Consultare le informazioni sul comando idsdb2ldif nel manuale Command Reference per ulteriori informazioni.
    Attenzione: se si stanno esportando dati che verranno importati in un server abilitato ad AES (Advanced Encryption Standard) e se i due server non sono sincronizzati crittograficamente, consultare Sincronizzazione della crittografia bidirezionale tra le istanze del server , per informazioni sulla sincronizzazione crittografica dei server.

    Quando il server di origine (il server da cui si sta esportando i dati da) e il server di destinazione (il server in cui si sta importando i dati) si utilizzano file di stash della directory non corrispondenti e si specificano i valori di seed di codifica e di sale del server di destinazione, qualsiasi dato codificato AES verrà decodificato utilizzando i tasti AES del server di origine, quindi ricrittografato utilizzando i valori seed e sale di codifica del server di destinazione. Questi dati crittografati vengono memorizzati nel file LDIF.

    Il seme di cifratura viene utilizzato per generare una serie di valori chiave segreti AES. Questi valori sono memorizzati in un file stash di directory e utilizzati per crittografare e decodificare la password memorizzata e gli attributi chiave segreti. Il valore seed di crittografia deve contenere soltanto caratteri ASCII ISO-8859-1 stampabili con valori compresi tra 33 e 126 e la sua lunghezza deve essere compresa tra 12 e 1016 caratteri. Consultare ASCII characters from 33 to 126 , nella documentazione IBM Security Directory Server nella sezione Administering per informazioni su questi caratteri.

    Il sale di crittografia è un valore generato casualmente che viene utilizzato per generare chiavi di crittografia AES. È possibile ottenere il valore del sale del server di destinazione ricercando (utilizzando l'utility idsldapsearch) la voce "cn = crypto, cn = localhost" del server di destinazione. Il tipo di attributo è ibm-slapdCryptoSalt.

  13. Riavviare server1.
  14. Copiare il file <mymasterfile.ldif> nel computer in cui si trova server2 .
  15. Sul computer dove si trova server2 , emettere il seguente comando:
    idsldif2db -r no -i <mymasterfile.ldif> -I <instance_name>
    dove -r no impedisce la replica della serie di voci. Per importazioni di dati ldif di grandi dimensioni, utilizzare il comando idsbulkload (senza l'opzione -r no ).
  16. Dopo aver completato l'importazione dei dati su server2, immettere il comando idsrunstats per ottimizzare le statistiche della tabella:
    idsrunstats -I <instance_name>
  17. Inizio server2:
    idsslapd -I <instance_name> -n
Per creare i peer master (server1 e server2) per la struttura secondaria o=sample utilizzando il metodo online:
  1. Si presuppone che il server server1 sia già caricato con i dati necessari e che sia attivo e serva le applicazioni client. Se necessario, avviare server1 con il comando:
    idsslapd -I <instance_name> -n
  2. Avviare il server server2 in modalità di sola configurazione. Su ciascuno dei server emettere il comando:
    idsslapd -I <instance_name> -a
  3. È necessario configurare server1 e server2 per essere server peer. Utilizzare il comando idsldapadd per aggiungere la seguente voce al file ibmslapd.conf su server1 e server2. Su server1 e server2 , immettere il seguente comando:
    idsldapadd -D <adminDN> -w <adminPW> -i<filename>
    dove <filename> contiene:
    dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret123
    Nota: È fondamentale che queste voci siano esattamente le stesse su entrambi i server perché questo esempio utilizza un oggetto credenziali condiviso su tutti i server. La password è inserita in cleartext, ma è crittografata nel file. ibm-slapdMasterDN deve essere univoco e non può essere uguale ad alcun DN già esistente.
  4. Su server1, rileggere la configurazione aggiornata nel processo ibmslapd in esecuzione. Immettere il comando su server1:
    idsldapexop -D <adminDN> -w <adminPW> -op readconfig -scope entire
  5. Arrestare server2. Per arrestare l'esecuzione del seguente comando su server2:
    idsslapd -I <instance_name> -k
    dove <nome_istanza> è il nome dell'istanza del server di directory che si desidera arrestare.
  6. Salvare i file ibmslapd.conf su server1 e server2.
  7. Sul computer su cui si trova il server primario, server1, creare un file da utilizzare per gli aggiornamenti alle informazioni di accordo; ad esempio mycredentialsfile, dove mycredentialsfile contiene:
    dn: cn=replication,cn=IBMpolicies
objectclass: container
 
###Bind Credentials/method to peer server - replication agreement
###points to this.
dn: cn=simple,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple
cn: simple
replicaBindDN: cn=any
replicaCredentials: secret123
description: Bind method of the peer master (server1)to the peer (server2)
    I valori replicaBindDN e replicaCredentials devono corrispondere rispettivamente ai valori ibm-slapdMasterDN e ibm-slapdMasterPW dalla voce del server principale nel passo 3.
  8. Immettere il comando su server1:
    idsldapadd -D <adminDN> -w <adminPW> -i<mycredentialsfile>
  9. Copiare <mycredentialsfile> nel computer in cui si trova server2 ed emettere il comando su server2:
    idsldif2db -i<mycredentialsfile> -I <instance_name>
  10. Al computer dove si trova server1 si crea un file, <mytopologyfile>, dove < mytopologyfile> include la seguente impostazione:
    Nota: Sostituire tutte le occorrenze di <server1-uuid> nei file seguenti con il valore dell'attributo ibm-slapdServerId della voce cn=Configuration del server master. Questo valore viene generato dal server la prima volta che viene avviato. È possibile individuarlo eseguendo una idsldapsearch della voce cn = Configuration oppure utilizzando il comando grep sul file ibmslapd.conf , se si dispone di un sistema AIX, Linuxo Solaris. Allo stesso modo, tutte le occorrenze di <serverx-uuid> (dove x rappresenta 1 o 2) devono essere sostituite con il valore dell'attributo ibm-slapdServerId della voce cn=Configuration del rispettivo server.
    dn: ibm-replicaGroup=default, o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: server 1 (peer master) ibm-replicaSubentry

dn: ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: true
cn: server2
description: server2 (peer master) ibm-replicaSubentry

#server1 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(master) to server2(master) agreement
ibm-replicationOnHold: TRUE

#server2 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(master) to server1(master) agreement
ibm-replicationOnHold: TRUE
  11. Per caricare questa topologia, su server1, immettere il comando:
    idsldapadd -D <adminDN> -w <adminPW> -l -i<mytopologyfile>
    dove l'opzione -l impedisce la replica della serie di voci.
  12. Ora il peer server1 è a conoscenza del peer server2 e tiene traccia di tutte le modifiche (aggiornamenti) nella coda di replica sospesa.
  13. Se è necessario che la sincronizzazione dei dati abbia esito positivo, è importante disattivare server1 per renderlo di sola lettura fino a quando l'estrazione dei dati non viene completata. Per sospendere server1 , immettere il comando:
    idsldapexop -D <adminDN> -w <adminPW> -op quiesce -rc o=sample
    Se è necessario che server1 funzioni in modalità di lettura e scrittura, è possibile che vi sia una serie di modifiche replicate che verranno estratte anche nel file ldif tramite idsdb2ldif.
  14. Esportare i dati server1 (che includono anche informazioni sulla topologia di replica) per il contesto di replica, immettere il comando su server1:
    idsdb2ldif -s "o=sample" -o <server1data.ldif> -I <instance_name> \
		-k <key seed> -t <key salt>
    Nota: è necessario utilizzare l'opzione -I se è presente più di un'istanza. È necessario utilizzare le opzioni -k e -t se le chiavi sul server non sono sincronizzate. Consultare le informazioni sul comando idsdb2ldif nel manuale Command Reference per ulteriori informazioni.
    Attenzione: se si stanno esportando dati che verranno importati in un server abilitato ad AES (Advanced Encryption Standard) e se i due server non sono sincronizzati crittograficamente, consultare Sincronizzazione della crittografia bidirezionale tra le istanze del server , per informazioni sulla sincronizzazione crittografica dei server.

    Quando il server di origine (il server da cui si sta esportando i dati da) e il server di destinazione (il server in cui si sta importando i dati) si utilizzano file di stash della directory non corrispondenti e si specificano i valori di seed di codifica e di sale del server di destinazione, qualsiasi dato codificato AES verrà decodificato utilizzando i tasti AES del server di origine, quindi ricrittografato utilizzando i valori seed e sale di codifica del server di destinazione. Questi dati crittografati vengono memorizzati nel file LDIF.

    Il seme di cifratura viene utilizzato per generare una serie di valori chiave segreti AES. Questi valori sono memorizzati in un file stash di directory e utilizzati per crittografare e decodificare la password memorizzata e gli attributi chiave segreti. Il valore seed di crittografia deve contenere soltanto caratteri ASCII ISO-8859-1 stampabili con valori compresi tra 33 e 126 e la sua lunghezza deve essere compresa tra 12 e 1016 caratteri. Consultare ASCII characters from 33 to 126 , nella documentazione IBM Security Directory Server nella sezione Administering per informazioni su questi caratteri.

    Il sale di crittografia è un valore generato casualmente che viene utilizzato per generare chiavi di crittografia AES. È possibile ottenere il valore del sale del server di destinazione ricercando (utilizzando l'utility idsldapsearch) la voce "cn = crypto, cn = localhost" del server di destinazione. Il tipo di attributo è ibm-slapdCryptoSalt.

  15. Una volta eseguita correttamente l'esportazione dei dati utilizzando idsdb2ldif , attivare server1 in modo che possa funzionare in modalità di lettura e scrittura.
    idsldapexop -D <adminDN> -w <adminPW> -op quiesce -rc o=sample -end
  16. Copiare il file <server1data.ldif> sul computer in cui si trova server2 .
  17. Sul computer dove si trova server2 , emettere il seguente comando:
    idsldif2db -r no -i <server1data.ldif> -I <instance_name>
    dove -r no impedisce la replica della serie di voci. Per importazioni di dati ldif di grandi dimensioni, utilizzare il comando idsbulkload (senza l'opzione -r no ).
  18. Dopo aver completato l'importazione dei dati su server2, immettere il comando idsrunstats per ottimizzare le statistiche della tabella:
    idsrunstats -I <instance_name>
  19. Inizio server2:
    idsslapd -I <instance_name> -n
  20. Sul server1, riprendere l'accordo di replica sospeso su server2:
    idsldapexop -D <adminDN> -w <adminPW> -op controlrepl -action resume \
             -ra "cn=server2,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample"
  21. Su server2, riprendere l'accordo di replica sospeso su server1: :
    idsldapexop -D <adminDN> -w <adminPW> -op controlrepl -action resume \
             -ra "cn=server1,ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample"