Schema updates in a distributed directory

Edit online

When schema updates are requested by a global administrator group member, the schema updates are first applied to the Security Directory Proxy server and then the updates are propagated to its backend servers. Additionally, global administrator group member can request for schema update directly on the backend servers. However, if the schema updates are requested on the proxy server by the primary administrator, a local admin group member having SchemaAdmin role, or the Master Server DN, then the schema updates are applied only to the proxy server.

To enforce schema updates to all the backend servers that the proxy server is serving to, the global policies must be synchronized. Security Verify Directory supports replication of schema updates to the consumer servers in a replication topology if the replication is set up for the CN=IBMPOLICIES context among all the backend servers that the proxy server is serving to. To implement this, you need to setup replication on the CN=IBMPOLICIES context amongst all the backend servers that are served by the proxy server. To ensure that the schema updates are made properly even in a failure of the primary write server, directory administrators must include at least one other write server in the replication topology of the CN=IBMPOLICIES context. The proxy re-routes the schema update to the next available write server if the primary write server fails. Once the primary write server is restored back, the schema updates received in its absence is pushed to it by the second write server. To create this setup, you must consider the following actions:
  1. Set up a distributed directory with proxy server. See Setting up the proxy server.
  2. Create replication topology for the cn=ibmpolicies subtree. For more information about setting up replication, see Replication and see Setting up a topology for global policies.
    Note: If all the write server are offline, then the proxy server returns an appropriate error message to the LDAP client.
An example extract of proxy server configuration to propagate the schema updates: 
cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, cn=Schemas, cn=Configuration
cn=Proxy Backend
ibm-slapdDNPartitionPlugin=libldapdnhash.so dnHashInit
ibm-slapdPagedResAllowNonAdmin=TRUE
ibm-slapdPagedResLmt=3
ibm-slapdPlugin=database libback-proxy.so proxy_backend_init
ibm-slapdPlugin=extendedoplibback-proxy.soinitResumeRole
ibm-slapdProxyEnableDistDynamicGroups=true
ibm-slapdProxyEnableDistGroups=true
ibm-slapdSuffix=o=sample
ibm-slapdSuffix=cn=ibmpolicies
objectclass=top
objectclass=ibm-slapdConfigEntry
objectclass=ibm-slapdProxyBackend

cn=Server1, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, 
 cn=Schemas, cn=Configuration
cn=Server1
ibm-slapdProxyBindMethod=Simple
ibm-slapdProxyConnectionPoolSize=5
ibm-slapdProxyDN=cn=root
ibm-slapdProxyHealthCheckOlimit=24
ibm-slapdProxyMaxPendingOpsPerClient=5
ibm-slapdProxyPW={AES256}LM3NvpMrOFvYhTnEdmeTbw==
ibm-slapdProxyTargetURL=ldap://ServerA:389
ibm-slapdServerID=8c440640-6e1f-102e-88a8-ff9133d50edd
ibm-slapdStatusInterval=5
objectClass=top
objectClass=ibm-slapdProxyBackendServer
objectClass=ibm-slapdConfigEntry

cn=Server2, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, 
 cn=Schemas, cn=Configuration
cn=Server2
ibm-slapdProxyBindMethod=Simple
ibm-slapdProxyConnectionPoolSize=5
ibm-slapdProxyDN=cn=root
ibm-slapdProxyHealthCheckOlimit=24
ibm-slapdProxyMaxPendingOpsPerClient=5
ibm-slapdProxyPW={AES256}LM3NvpMrOFvYhTnEdmeTbw==
ibm-slapdProxyTargetURL=ldap://ServerB:389
ibm-slapdServerID=aaaa01c0-6e1f-102e-8ea9-8d957fd1611f
ibm-slapdStatusInterval=5
objectClass=top
objectClass=ibm-slapdProxyBackendServer
objectClass=ibm-slapdConfigEntry

cn=cn\=ibmpolicies split, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, 
 cn=Schemas, cn=Configuration
cn=cn=ibmpolicies split
ibm-slapdProxyAutoFailBack=true
ibm-slapdProxyFailbackBasedOnQueueEnabled=true
ibm-slapdProxyFailbackQueueThreshold=5
ibm-slapdProxyHighConsistency=true
ibm-slapdProxyNumPartitions=1
ibm-slapdProxyPartitionBase=cn=ibmpolicies
ibm-slapdProxySplitName=ibmpoliciessplit
objectclass=ibm-slapdConfigEntry
objectclass=ibm-slapdProxyBackendSplitContainer
objectclass=top

cn=split1, cn=cn\=ibmpolicies split, cn=ProxyDB, cn=Proxy Backends, 
 cn=IBM Directory, cn=Schemas, cn=Configuration
cn=split1
ibm-slapdProxyBackendServerDN=cn=Server1,cn=ProxyDB,cn=Proxy Backends,
 cn=IBM Directory,cn=Schemas,cn=Configuration
ibm-slapdProxyBackendServerRole=primarywrite
ibm-slapdProxyPartitionIndex=1
ibm-slapdProxyTier=1
objectclass=top
objectclass=ibm-slapdConfigEntry
objectclass=ibm-slapdProxyBackendSplit

cn=split2, cn=cn\=ibmpolicies split, cn=ProxyDB, cn=Proxy Backends, 
 cn=IBM Directory, cn=Schemas, cn=Configuration
cn=split2
ibm-slapdProxyBackendServerDN=cn=Server2,cn=ProxyDB,cn=Proxy Backends,
 cn=IBM Directory,cn=Schemas,cn=Configuration
ibm-slapdProxyBackendServerRole=any
ibm-slapdProxyPartitionIndex=1
ibm-slapdProxyTier=1
objectclass=top
objectclass=ibm-slapdConfigEntry
objectclass=ibm-slapdProxyBackendSplit