Multi-Master LDAP replication

It’s interesting when you would like to improve the reliability of our LDAP servers or simply the number of queries has increased considerably you need to increase the number of ldap servers to balance the query request to the different servers. It’s also important to maintain the data is consistent between the servers and updated with the last changes. One solution may be partition the tree structure of our ldap database with the different data distributed between the different servers but still you have the problem of high availability. The solution to these problems is the replication, simply consist in maintain the same information between the different servers. LDAP offers different solutions for replication,one of them is slurpd that consist in push replication the new changes in the master slave and replicate the new data to the slave server, if you try to update the database in the slave server, it will send a reference to the master server indicating the correct server to do updates.Other solution the most used and integrated with LDAP called syncrepl, act as intermediary between the slapd core and the database backend, and all the data updates to the ldap tree are tracked by syncrepl. Syncrepl is initialized by the salve server called consumer and establishes a connection to the master server called provider.



You have two possibilities with syncrepl configuration one called refreshOnly the consumer receives all the alerts from the provider modified since the last update, also request a cookie from the provider with the last change and then the consumer disconnects from the provider. Other mode is refreshAndPersist, it’s like refreshOnly but the consumer doesn’t close the communication with the provider and any change is immediately received by the provider. With syncrepl, as mentioned above we have the role of master (provider) and slave (consumer), but it may be interesting to configure a multi-master servers to increase the reliability to our scenario for the reads and writes to the ldap tree. Simply consist in the both servers acts as master and slave in the same time and all the data maintains updated in both servers. In this scenario I’ll show the configuration with a basic ldap tree structure and a configuration with syncrepl multi-master:



- The root ldif schema of ldap used in this scenario:











dn: ou=groups,dc=opentodo,dc=net

objectClass: organizationalunit

ou: groups


dn: ou=people,dc=opentodo,dc=net

objectClass: organizationalunit

ou: people


dn: cn=sales,ou=groups,dc=opentodo,dc=net

objectclass: posixgroup

cn: sales

gidnumber: 10001


dn: cn=operations,ou=groups,dc=opentodo,dc=net

objectclass: posixgroup

cn: operations

gidnumber: 10002


dn: cn=john,ou=people,dc=opentodo,dc=net

objectclass: posixaccount

objectclass: inetorgperson

objectclass: shadowaccount

sn: john

cn: john

uid: john

uidnumber: 10001

gidnumber: 10001

homedirectory: /home/john

loginshell: /bin/bash

userpassword: {MD5}6ZoYxCjLONXyYIU2eJIuAw==


dn: cn=ivan,ou=people,dc=opentodo,dc=net

objectclass: posixaccount

objectclass: inetorgperson

objectclass: shadowaccount

sn: ivan

cn: ivan

uid: ivan

uidnumber: 100002

gidnumber: 100002

homedirectory: /home/ivan

loginshell: /bin/bash

userpassword: {MD5}6ZoYxCjLONXyYIU2eJIuAw==




Installing ldap server and utils










1


# apt-get install slapd ldap-utils




Reconfigure slapd package










1


# dpkg-reconfigure slapd




Edit /etc/ldap/slapd.conf configuration file in both servers

Server 1











#######################################################################

# Global Directives:

# Schema and objectClass definitions

include /etc/ldap/schema/core.schema

include /etc/ldap/schema/cosine.schema

include /etc/ldap/schema/nis.schema

include /etc/ldap/schema/inetorgperson.schema

include /etc/ldap/schema/ppolicy.schema

# Where the pid file is put. The init.d script

# will not stop the server if you change this.

pidfile /var/run/slapd/slapd.pid


# List of arguments that were passed to the server

argsfile /var/run/slapd/slapd.args


# Read slapd.conf(5) for possible values

loglevel none


# Where the dynamically loaded modules are stored

modulepath /usr/lib/ldap

moduleload back_bdb

moduleload syncprov


# The maximum number of entries that is returned for a search operation

sizelimit 500

# The tool-threads parameter sets the actual amount of cpu's that is used

# for indexing.

tool-threads 1


#######################################################################

# Specific Backend Directives for @BACKEND@:

# Backend specific directives apply to this backend until another

# 'backend' directive occurs

backend bdb


# Specific Directives for database #1, of type @BACKEND@:

# Database specific directives apply to this databasse until another

# 'database' directive occurs

database bdb


# The base of your directory in database #1

suffix "dc=opentodo,dc=net"


# rootdn directive for specifying a superuser on the database. This is needed

# for syncrepl.

rootdn "cn=admin,dc=opentodo,dc=net"

rootpw ldapadmin

# Where the database file are physically stored for database #1

directory "/var/lib/ldap"

# The dbconfig settings are used to generate a DB_CONFIG file the first

# time slapd starts. They do NOT override existing an existing DB_CONFIG

# file. You should therefore change these settings in DB_CONFIG directly

# or remove DB_CONFIG and restart slapd for changes to take effect.


# For the Debian package we use 2MB as default but be sure to update this

# value if you have plenty of RAM

dbconfig set_cachesize 0 2097152 0


# Number of objects that can be locked at the same time.

dbconfig set_lk_max_objects 1500

# Number of locks (both requested and granted)

dbconfig set_lk_max_locks 1500

# Number of lockers

dbconfig set_lk_max_lockers 1500


# Indexing options for database #1

index objectClass eq

# Necessary for syncprov specific indexes

index entryUUID eq

index entryCSN eq


# Save the time that the entry gets modified, for database #1

lastmod on


# Checkpoint the BerkeleyDB database periodically in case of system

# failure and to speed slapd shutdown.

checkpoint 512 30


# The admin dn has full write access, everyone else

# can read everything.

access to *

by dn="cn=admin,dc=opentodo,dc=net" write

by * read


#Replica LDAP

syncrepl rid=001

provider=ldap://172.16.0.101:389

type=refreshOnly

interval=00:00:00:01

searchbase="dc=opentodo,dc=net"

bindmethod=simple

binddn="cn=admin,dc=opentodo,dc=net"

credentials=ldapadmin

#mirror mode allow writes to the ldap tree

mirrormode true

#Sync provider directive must be declared for replica

overlay syncprov

#Checkpoints is produced after 100 write operations

#or after 10 minutes

syncprov-checkpoint 100 10




Server 2











#######################################################################

# Global Directives:

# Schema and objectClass definitions

include /etc/ldap/schema/core.schema

include /etc/ldap/schema/cosine.schema

include /etc/ldap/schema/nis.schema

include /etc/ldap/schema/inetorgperson.schema

include /etc/ldap/schema/ppolicy.schema

# Where the pid file is put. The init.d script

# will not stop the server if you change this.

pidfile /var/run/slapd/slapd.pid


# List of arguments that were passed to the server

argsfile /var/run/slapd/slapd.args


# Read slapd.conf(5) for possible values

loglevel none


# Where the dynamically loaded modules are stored

modulepath /usr/lib/ldap

moduleload back_bdb

moduleload syncprov


# The maximum number of entries that is returned for a search operation

sizelimit 500

# The tool-threads parameter sets the actual amount of cpu's that is used

# for indexing.

tool-threads 1


#######################################################################

# Specific Backend Directives for @BACKEND@:

# Backend specific directives apply to this backend until another

# 'backend' directive occurs

backend bdb


# Specific Directives for database #1, of type @BACKEND@:

# Database specific directives apply to this databasse until another

# 'database' directive occurs

database bdb


# The base of your directory in database #1

suffix "dc=opentodo,dc=net"


# rootdn directive for specifying a superuser on the database. This is needed

# for syncrepl.

rootdn "cn=admin,dc=opentodo,dc=net"

rootpw ldapadmin

# Where the database file are physically stored for database #1

directory "/var/lib/ldap"

# The dbconfig settings are used to generate a DB_CONFIG file the first

# time slapd starts. They do NOT override existing an existing DB_CONFIG

# file. You should therefore change these settings in DB_CONFIG directly

# or remove DB_CONFIG and restart slapd for changes to take effect.


# For the Debian package we use 2MB as default but be sure to update this

# value if you have plenty of RAM

dbconfig set_cachesize 0 2097152 0


# Number of objects that can be locked at the same time.

dbconfig set_lk_max_objects 1500

# Number of locks (both requested and granted)

dbconfig set_lk_max_locks 1500

# Number of lockers

dbconfig set_lk_max_lockers 1500


# Indexing options for database #1

index objectClass eq

# Necessary for syncprov specific indexes

index entryUUID eq

index entryCSN eq


# Save the time that the entry gets modified, for database #1

lastmod on


# Checkpoint the BerkeleyDB database periodically in case of system

# failure and to speed slapd shutdown.

checkpoint 512 30


# The admin dn has full write access, everyone else

# can read everything.

access to *

by dn="cn=admin,dc=opentodo,dc=net" write

by * read


#Replica LDAP

syncrepl rid=002

provider=ldap://172.16.0.100:389

type=refreshOnly

interval=00:00:00:01

searchbase="dc=opentodo,dc=net"

bindmethod=simple

binddn="cn=admin,dc=opentodo,dc=net"

credentials=ldapadmin

#mirror mode allow writes to the ldap tree

mirrormode true

#Sync provider directive must be declared for replica

overlay syncprov

#Checkpoints is produced after 100 write operations

#or after 10 minutes

syncprov-checkpoint 100 10




- Edit /etc/default/slapd:










1


SLAPD_CONF=/etc/ldap/slapd.conf




- Restart slapd:










1


# service slapd restart




Adding new user in one of the servers and test if sync successful










1

2

3

4

5

6

7

8

9

10

11

12

13

14

15


# vi users.ldif


dn: cn= tbombadil,ou=people,dc=opentodo,dc=net

objectclass: posixaccount

objectclass: inetorgperson

objectclass: shadowaccount

uid: tbombadil

homedirectory: /home/tbombadil

loginshell: /bin/bash

userpassword: {MD5}6ZoYxCjLONXyYIU2eJIuAw==

mail: tbombadil@opentodo.net

uidnumber: 10005

gidnumber: 10001

cn: tbombadil

sn: tbombadil














1


# ldapadd -x -D "cn=admin,dc=opentodo,dc=net" -W -f users.ldif




Search user in both servers










1


# ldapsearch -x -D "cn=admin,dc=opentodo,dc=net" -b "dc=opentodo,dc=net" "uid=tbombadil" -w ldapadmin




ldap-replica
 Sources

http://www.zytrax.com/books/ldap/
http://www.ibm.com/developerworks/linux/tutorials/l-lpic3303/section3.html

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

CLEANING UP THE ZABBIX DATABASE

My Zabbix database size increased a lot in the last few months and since my disk was running out space, I decided to clean up the old events from the database. Looking at the database tables, the biggest one was  history_uint , which holds the items history data – over 400 millions of records and over 30 Gb of disk space before the clean up. Since deleting the old records from this table directly would be a very slow process, I decided to create a new table and insert the latest records from the  history_uint  table and then just replace the old table with a new one. Since this is not an offical procedure, use it at your own risk. Environment: Zabbix v2.2 MySql 5.1 – InnoDB with  innodb_file_per_table=ON Step 1 – Stop the Zabbix server Step 2 – Open your favourite MySQL client and create a new table CREATE TABLE  history_uint_new  LIKE  history_uint; Step 3 – Insert the latest records from the  history_uint  table to the...
Đọc thêm

Configuring DHCP Relay service on the FortiGate unit

Configuring DHCP Relay service on the FortiGate unit If the clients are configured to obtain a IP address using DHCP relay, configure the FortiGate server as below: To configure DHCP relay on the FortiGate unit   1. Go to System > Network > Interfaces and select Interface want to configure DHCP relay.   2. Enable DHCP Server in the interface and choose Advanced   3. For Mode, select Relay.   4. In Type select Regular.   5. Select OK.   6. If a router is installed between the FortiGate unit and the DHCP server, define a static route to the DHCP server. Note : Sometimes it is required to specify more than one DHCP relay IP, to allow for the coverage of additional LAN subnets. Although the Web Based Manager (GUI) does not provide an option to configure this, it is possible to set up to 8 IPs from the CLI.       config system interface             edit <REQUIRED_INTERFACE_HERE>   ...
Đọc thêm

[Resolved] Amazon EC2 Redhat 7 using 6GB for the root space

Hình ảnh
I create new server with 10GB of HDD, but when i check on the command line, the root space only show 6GB. I'm using t2.micto and Redhat 7.0, disk type: XFS. - xvda1: boot partition - xvda2: root partition Fix Step: We have instance A with the volume VA. 1) Stop the current instace A 2) Snapshot the current volume VA of the instance A 3) Start the instance A 4) Create new volume with 25GB by using the snapshot of volume VA then we have new volume VB 5) Attach the new volume VB to the instance A as default (/dev/sdf) 6) From the ssh console, i use the lsblk command to list the disk. # lsblk 7) Using the xfs_repair to repair the /dev/xvdf2 ( yum install xfsprogs) # xfs_repair /dev/xvdf2 8) Continue as the image below 9) Remove the /dev/xvdf2, remember the start of this disk then we will create the new one with the same. 10) Using XFS command to repair the /dev/xvdf2 again. # xfs_repair /dev/xvdf2 11) Use the lsblk co...
Đọc thêm