[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Using virtual IP and N-way mutlimaster mode



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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature