Andrew Findlay wrote:
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).
I'd recommend to solely use the public IP addresses and avoid to use the cloud's system DNS. Add DNS RRs for the public IP addresses to a DNS namespace you control.
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.
These issues are the reason why the ansible role for installing Æ-DIR servers internally strictly distinguishs between system's hostname (canonical FQDN) and the service's FQDNs for accessing the slapd instances. In ansible the system's hostnames more less match what you would add as so-called inventory hostname and I use this as a key to look up the appropriate individual service FQDN specified by host_vars. This gets provisioned to slapd.conf, web2ldap config, and even OpenSSL config snippets to produce CSRs with all appropriate FQDNs put into subjectAltName, etc.
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.
Despite the system's hostname not resolvable is there another constraint why you cannot use -h <public-IP> or just the need for the FQDN?
Ciao, Michael.