Hi, people!
My company asks me to build an LDAP server network where there is a big central server storing data from all the company and various minor servers, one for each branch office, where only the sensitive data for the office is stored. The good way is to do some replication with slurpd or syncrepl, copying data registered on the central server to the minor, local servers.
The problem is that they've requested me to follow the bad way: it was required that the data must be stored on the minor, local server first, and replicated to the central server after. I know it is multimaster replication and it is dangerous, not kosher and whatnot, but they insist on using this topology. Also, they don't want to use some other external application. The problem is that the Internet links are very unstable here, and expecting a write on the central server and its posterior replication can stop an office for some days.
So, I've followed the ugly way, doing some complex workarounds with slurpd and imposing some restrictions to the data. However, it is clear that what I have done is not correct: it is very hard to understand and to maintain, it uses some undocumented OpenLDAP features, it makes impossible to use TLS for authentication etc.
So, I'd like to ask: does anyone have some tip on what to do in this situation? Does anyone have an idea about how to implement this exotic replication model on a reasonably simple way? I hope so... :)
Thanks in advance!
Adam Brandizzi schrieb:
Hi, people!
The problem is that they've requested me to follow the bad way: it was required that the data must be stored on the minor, local server first, and replicated to the central server after. I know it is multimaster replication and it is dangerous, not kosher and whatnot, but they insist on using this topology. Also, they don't want to use some other external application. The problem is that the Internet links are very unstable here, and expecting a write on the central server and its posterior replication can stop an office for some days.
I'd setup the central server as a syncrepl consumer to all the branch offices, with one database context for each. Optionally those can be glued together with back-ldap. Using the chain overlay on the central server, writes will be internally redirected to the branch office and you won't have to deal with referrals manually. Of course, if the branch is down writes will fail... With a modern version you should be able to use refreshAndPersist sync replication with very low delays in replicating the changes back to the central server.
hth Paul
openldap-software@openldap.org