In my configuration, I have a single administrative parent. This system is where we do all administrative level work. This includes adding users, adding groups, reporting, and the like. It is also the \u201cprovider\u201d store to all replicants in our environment. We learned earlier how to turn up a server that is queried directly. Now let\u2019s learn, instead, how to configure this system to replicate itself.<\/p>\n\n\n\n
Assume 3 systems total, ldap01.bob.com, ldap02.bob.com, and ldap03.bob.com. ldap01.bob.com is our master server and our replicants are ldap02 & ldap03. To tell the system it will be replicating, you will need to configure it to do so. Shut down LDAP on the primary like so:<\/p>\n\n\n\n
\/sbin\/service ldap stop<\/strong><\/em><\/p>\n\n\n\n This shuts down all daemons and associated processes. Next, we need to edit our \/etc\/openldap\/slapd.conf<\/strong> to include information regarding where our replicants will be. You must add a few lines to the master to make this happen. Like so:<\/p>\n\n\n\n replogfile \/var\/log\/ldap\/slapd.replog<\/p>\n\n\n\n replica uri=ldap:\/\/ldap02.bob.com:389 binddn=\u201ccn=admin,dc=bob,dc=com\u201d bindmethod=simple credentials=secret<\/p>\n\n\n\n replica uri=ldap:\/\/ldap03.bob.com:389 binddn=\u201ccn=admin,dc=bob,dc=com\u201d bindmethod=simple credentials=secret<\/p>\n\n\n\n This can be added at the end of the file.<\/p>\n\n\n\n Next, we take our fresh two servers, and turn up a similar system to what ldap01 was before adding the above lines. In these systems, there are only two important lines to tell them they are replicants and not masters. They are as follows:<\/p>\n\n\n\n updatedn \u201ccn=admin,dc=bob,dc=com\u201d updateref ldap:\/\/ldap01.bob.com<\/p>\n\n\n\n That is literally the entire configuration.<\/p>\n\n\n\n Populating the Replicants<\/strong><\/p>\n\n\n\n To have your schema transferred over, and to be working from the same general starting point, I find it important to copy your whole database over to start with. This is easily done utilizing standard LDAP tools.<\/p>\n\n\n\n First, start back up your master server:<\/p>\n\n\n\n \/sbin\/service ldap start<\/strong><\/em><\/p>\n\n\n\n Once you\u2019ve done this, the database is up and ready for queries. We will essentially dump our database for import on each of the replicants. To do this, we will use the slapcat <\/em>utility, redirecting the output to a file we can use to move around to the replicants. Run slapcat<\/em> as follows:<\/p>\n\n\n\n slapcat >> master.ldif<\/em><\/strong><\/p>\n\n\n\n this will output the contents of your LDAP store to a single LDIF-formatted file, suitable for import into other servers. Simply copy this file to a generic location (such as your personal home directory) on each of the other servers, and we are set for import.<\/p>\n\n\n\n Once your file is in the new location, you\u2019re ready to import. First, start LDAP as outlined above. Next, add the LDIF to your store:<\/p>\n\n\n\n slapadd -l master.ldif<\/strong><\/em><\/p>\n\n\n\n Probably unnecessary, but I usually restart my ldap server after the import, and now I\u2019m ready to go. Repeat the process on your third LDAP store, and your full environment is running.<\/p>\n\n\n\n Next Steps<\/strong><\/p>\n\n\n\n So let\u2019s see where we are.<\/p>\n\n\n\n Master server up and serving.. check. Two slaves configured as replicants, up and running.. check.<\/p>\n\n\n\n Now that you have your stores up, you have to do some testing. Primarily, that the master replicates to the slaves. The way I usually do this is use the Apache Directory Studio<\/a>I covered in an earlier article. I simply add a user on the master. Then, I connect to each of the slaves in turn to see that the user has appeared there. If so, then we\u2019re ready for the next steps: High Availability.<\/p>\n\n\n\n You have two query hosts that can equally provide query answers from remote clients. There are several ways you can make these available. Round-robin DNS, HA IP failover, and load-balancing via a hardware load balancer. I prefer the latter. However, to do so, you need a way to tell the load balancer that your LDAP store is up and responding.<\/p>\n\n\n\n I prefer to use a small script on the system that can be served up via HTTP to the load balancer that does a simple operation. First, it does an LDAP search, looks for information, and then prints out to the web page it creates a simple \u201cUP\u201d or \u201cDOWN\u201d message for the load balancer to key on. The script looks like the following:<\/p>\n\n\n\n As you can see, all we do is simply do an ldapsearch <\/em>against our bob.com domain, look for the home directory for the admin user to look like \u201c\/home\/admin\u201d. If the answer returns, we say \u201cUP\u201d, if not, we say \u201cDOWN\u201d.<\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/questy.org\/wp-content\/uploads\/2024\/08\/healthcheck.png?resize=691%2C726&ssl=1\")
<\/figure>\n\n\n\n