Archive for the 'sun' Category

Create Directory Server 5.2 replication agreements

Published by Mike on November 13, 2007 under ldap, replication, sun

In a Sun Directory Server 5.2 multi-master replication (MMR) topology, the instances that are to master the data, ie: accept changes and push those changes to other instances; need to have a replication agreement per-replicated-suffix / per-replicated-instance.

To create a replication agreement, the instance being replicated to needs to be configured to accept replicated changes. We create this LDIF with the full contents of a replication agreement for a Directory Server 5.2 instance. Replace all italicized items with the appropriate values for your deployment.

dn: cn=ds1.example.com:389, cn=replica, cn=”dc=example,dc=com“,cn=mapping tree,cn=config
changetype: add
objectClass: nsDS5ReplicationAgreement
objectClass: top
nsDS5ReplicaHost: ds1.example.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaBindDN: cn=replication manager, cn=replication, cn=config
nsDS5ReplicaUpdateSchedule: *
description: user and group data to ds1:389
nsDS5ReplicaRoot: dc=example,dc=com
cn: ds1.example.com:389
nsDS5ReplicaCredentials: remotereplmanpwd

I created and saved my replication agreement as /tmp/replagmt.ldif; and ran the ldapmodify command to create the above replication agreement.

/usr/bin/ldapmodify -h host -p port -D ‘rootdn‘ -w ‘password‘ -c -f /tmp/replagmt.ldif

Sun Directory Server 5.2 6-Way MMR – part 5 – Enabling replication on a back-end

Published by Mike on November 12, 2007 under ldap, replication, sun

In order to participate in replication, each of the suffixes that are to be replicated need to be configured for replication. Each MMR suffix should have a unique replication identifier associated with it, numbered 0 to 65536.

With our choice of applications and associated schema, we have 6 unique suffixes, each with their own purpose:

dc=example,dc=com

The primary user/group suffix. We used the numbers 10000 to 10005 to identify MMR instances.

ds0 / dc=example,dc=com : 10000

ds1 / dc=example,dc=com : 10001

ds2 / dc=example,dc=com : 10002

ds3 / dc=example,dc=com : 10003

ds4 / dc=example,dc=com : 10004

ds5 / dc=example,dc=com : 10005

o=comms-config

The location of the Communications configuration information. We used the numbers 20000 to 20005 to identify MMR instances of this type.

ds0 / o=comms-config : 20000

ds1 / o=comms-config : 20001

ds2 / o=comms-config : 20002

ds3 / o=comms-config : 20003

ds4 / o=comms-config : 20004

ds5 / o=comms-config : 20005

o=internet

Holds the schema1 mail routing information for local domains. We used the numbers 30000 to 30005 to identify MMR instances of this type.

ds0 / o=internet : 30000

ds1 / o=internet : 30001

ds2 / o=internet : 30002

ds3 / o=internet : 30003

ds4 / o=internet : 30004

ds5 / o=internet : 30005

o=NetscapeRoot

Holds primarily console information, if all instances are configured in the same instance, all instances can show up in the console. We used the numbers 40000 to 40005 to identify MMR instances of this type.

ds0 / o=NetscapeRoot : 40000

ds1 / o=NetscapeRoot : 40001

ds2 / o=NetscapeRoot : 40002

ds3 / o=NetscapeRoot : 40003

ds4 / o=NetscapeRoot : 40004

ds5 / o=NetscapeRoot : 40005

o=pab

Sun Messaging Personal Address Book. We used the numbers 50000 to 50005 to identify MMR instances of this type.

ds0 / o=pab : 50000

ds1 / o=pab : 50001

ds2 / o=pab : 50002

ds3 / o=pab : 50003

ds4 / o=pab : 50004

ds5 / o=pab : 50005

o=PiServerDB

Sun Unified Web Client Address Book. We used the numbers 60000 to 60005 to identify MMR instances of this type.

ds0 / o=PiServerDB : 60000

ds1 / o=PiServerDB : 60001

ds2 / o=PiServerDB : 60002

ds3 / o=PiServerDB : 60003

ds4 / o=PiServerDB : 60004

ds5 / o=PiServerDB : 60005

To enable replication, for each of the hostname and suffix combinations, please follow the instructions I have created.

Preparing Sun LDAP Directory Server 5.2 Suffix for Replication

Published by Mike on November 11, 2007 under ldap, replication, sun

In order for a directory server instance to participate in multi-master replication, each suffix that is to participate in MMR needs to be configured with a unique (at the very least among MMR for the suffix) integer that identifies this master in MMR. The numbers can range from 0 to 65535 to identify these MMR instances.

To identify the type of replica this instance should be, we need to address the nsDS5ReplicaType attribute. A value of 2 means this instance will be a consumer instance only, a value of 3 means this instance will be a read/write (master) instance. Values of 0 and 1 should not be used. More information about the nsDS5ReplicaType attribute.

dn: cn=replica, cn=”suffixname“,cn=mapping tree,cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
cn: replica
nsDS5ReplicaBindDN: cn=replication manager, cn=replication, cn=config
nsDS5ReplicaRoot: suffixname
nsDS5Flags: 1
nsDS5ReplicaType: 3
nsDS5ReplicaId: uniqueidentifier

Create a file with the above contents and save it to disk (I saved mine as /tmp/enablereplsuffix.ldif).

Update your directory server instance via ldapmodify to enable replication to this suffix on this host.

/usr/bin/ldapmodify -h host -p port -D ‘rootdn‘ -w ‘password‘ -c -f /tmp/enablereplsuffix.ldif







    

    
  

    

    
 
      Sun Directory Server 5.2 6-Way MMR – part 4 – Creating the replication manager       

     
Published by Mike on November 9, 2007 		
		under changelog, ldap, replication, sun		
		     

    

      
In order to perform replication, a replication manager entry must exist on each replication consumer.  A replication consumer is a directory server instance that is configured to accept changes from another directory server instance.   This differs from a consumer directory server instance, which is configured to refer all updates to its (possibly multiple) master instance(s).


For the purposes here, in a controlled replication environment, a single replication manager is all that is needed.  We will use the typical setting for this entry, cn=Replication Manager, cn=replication, cn=config


Create a replication manager for this instance.




    

    
  

    

    
 
      Creating cn=Replication Manager in Directory Server 5.2       

     
Published by Mike on November 9, 2007 		
		under ldap, replication, sun		
		     

    

      
In the Sun Directory Server, the Replication Manager has a special purpose; it is the ID which is used to push updates to replication consumer directory server instances.  By this, it means it can update ANY entry in the replication consumer’s directory that is allowed to be replicated to.  This ID must exist outside of any replication scope (ie: in the cn=config tree); there can be multiple replication managers if such a need arises (ie: one per replicated backend).


An example LDIF for creating a replication manager:


dn: cn=Replication Manager, cn=replication, cn=config

changetype: add

objectClass: top

objectClass: person

cn: Replication Manager

sn: Replication Manager

userPassword: password


Create a file with the above contents and save it to disk (I saved mine as /tmp/createrepman.ldif).


Update your directory server instance via ldapmodify to create the changelog database.


/usr/bin/ldapmodify -h host -p port -D ‘rootdn‘ -w ‘password‘ -c -f /tmp/createrepman.ldif


 Official Sun documentation on the replication manager.




    

    
  

    

    « Previous Page — Next Page »