On Tue, Jan 16, 2018 at 10:24:42AM +0400, Jephte Clain wrote:
all nodes run with -h ldap:// and I have as many olcServerID as defined nodes my cn=config is also replicated between all nodes
for example, I have:
olcServerID: 1 ldap://ldapm3.univ.run/ olcServerID: 2 ldap://ldapm4.univ.run/
olcSyncrepl: {0}... rid=0 provider="ldap://ldapm3.univ.run/" ... olcSyncrepl: {1}... rid=3 provider="ldap://ldapm4.univ.run/" ...
There is an important variation of this problem when running cloud machines in services like AWS. The actual machines have IPv4 addresses in private address space - usually 10.x.x.x - but if you need to access them from outside their own availability zone (datacentre) you must use a different (public) IP address. The machines usually have hostnames of the form ip-10-x-x-x and there is no way to resolve those globally.
So, we might have one server in each of three zones and need to set up MMR between them:
Zone A: Server IP: 10.21.0.1 Public IP: 134.82.17.63 Default hostname: ip-10-21-0-1
Zone B: Server IP: 10.22.0.71 Public IP: 193.17.65.123 Default hostname: ip-10-22-0-71
Zone C: Server IP: 10.35.0.5 Public IP: 7.45.81.52 Default hostname: ip-10-35-0-5
Not too much of a problem if each server has a separate config, but if we want replicated configs it gets harder.
The first problem is that the private IP ranges used by the three zones may overlap. Indeed, there are cases where the three servers could have identical local IPs (and thus identical default hostnames).
Even without that, we have to cope with the fact that the servers are on private addresses but have to contact each other using public addresses.
One option would be to set new hostnames on the servers and use those to key into the appropriate config values. The hostnames would need to be resolvable to public IP addresses so that the MMR config would work properly. Does anything check that the hostname actually resolves to an IP address bound to the server I wonder? Even if OpenLDAP is OK with that, it might break something else running on the machine.
Another option would be to use the new hostnames in the -h URL list, but as has already been mentioned this will fail because the server cannot bind to the public IP.
What is best practice here? I am leaning towards *not* replicating config because it makes some updates really hard (think changing the max size of an MDB database without stopping all the servers at the same time). I still like the idea that the config should be identical on all servers during normal operation though.
[ Note that I am not considering the OP's virtual IP problem here, as load-balancing/failover in this environment would be done separately ]
Andrew