Andrew Findlay wrote:
On Wed, Jan 24, 2018 at 09:43:58AM -0800, Quanah Gibson-Mount wrote:
How about adding a flag to slapd to specify the server ID so that it can go the other way through the config, convert ID to FQDN, and drop that FQDN from the set of replication sources?
I'll discuss with Howard, and see. I hate seeing more options added to slapd, but it may be the only option (no pun intended!) for this scenario. ;) The cloud was fairly nascent when this was all designed, so this case wasn't really a consideration at that point in time. If you were to pass in the server ID, I think you could get rid of the multi-valued serverID bit entirely, since every server would know who it was already.
I think you would still need that. Maybe I have missed something else here, but how does slapd avoid making a syncrepl connection to itself in the replicated-config scenario?
Usually I avoid this by config management vars.
I was assuming that it just ignores syncrepl clauses where the provider URL matches its own hostname. If it is done by IP then more thought will be required.
My recommendation for multi-homed scenarios and/or rapidly changing IP addresses is simply to avoid multi-valued serverID config.
The multi-valued attribute is neat in the case of servers with simple IP<->hostname mappings so we would probably want to keep it for that.
It's also useful for a client to ask slapd for the current effective serverID of a provider replica.
E.g. in Æ-DIR there's a script which sends notification about added user entry with further information to the user. If I have n replicas I don't want n e-mails to be sent out. So the script searches new entries created locally by using serverID part in entryCSN assertion value. Would be cumbersome to sort out the right serverID from a multi-valued serverID set.
So yet another idea for a feature request was having a separate operational attribute in cn=config or cn=monitor reporting the current effective serverID.
Ciao, Michael.