On Fri, 2015-01-02 at 10:22 +0100, Michael Ströder wrote:
Brendan Kearney wrote:
On Thu, 2015-01-01 at 23:17 +0100, Michael Ströder wrote:
Brendan Kearney wrote:
On Thu, 2015-01-01 at 22:35 +0100, Michael Ströder wrote:
Brendan Kearney wrote:
On Wed, 2014-12-31 at 13:50 -0800, Quanah Gibson-Mount wrote: > --On Wednesday, December 31, 2014 3:31 PM -0500 Brendan Kearney > bpk678@gmail.com wrote: > > >> /usr/sbin/slapd -u ldap -h "ldapi:/// ldap:///" -4 -d9 > >> olcServerID: 1 ldap://ldap1.bpk2.com >> olcServerID: 2 ldap://ldap2.bpk2.com >> >> not sure what is wrong. can someone point me in the right direction? > > Your -h argument clearly does not match anything in olcServerID. Seems > fairly clear to me, which is what the error message you received was > pointing out. ;)
its looking for cn=Subschema, which does not exist on the instance that wont start, does not exist on the MMR mirror instance, and cannot be added to the MMR mirror instance.
54a5a578 send_ldap_result: conn=-1 op=0 p=0 54a5a578 >>> dnNormalize: <cn=Subschema> 54a5a578 <<< dnNormalize: <cn=subschema> 54a5a578 read_config: no serverID / URL match found. Check slapd -h arguments.
Why don't you read Quanah's clear answer more carefully?
because it is irrelevant.
clearly, the above proves that the parameters i am using are not the problem.
You're wrong: If you use LDAP URIs in server IDs this LDAP URI has to be used with -h.
But of course you're free to ignore advice. But don't whine if you're ignored then.
stated where?
In Quanah's response to you referring to the error message during startup.
-h URLlist[..] serverID <integer> [<URL>]
Patches for the docs are surely welcome.
Ciao, Michael.
so this was communicated quieter than a church mouse's whisper in some obscure corner, as there is no documentation update in man pages, admin guide or changelog. i quickly searched for a reference in the release notes online, and did not find anything concrete, either.
to me, if a "FATAL" error with a change in a setting like this is being introduced, those making the change should be screaming it from the rooftops, not putting onus on the community that did not know the change was made. i see no such behavior in any of the docs.
moreover, why am i able to start an instance, configure it while running and even have replication working in the "broken" state of not having the -h parameters configured correctly, only to have the instance break upon restart? if the conditions are wrong, they should not work in any configuration, no? logic fail.
now, you have this new behavior that requires DNS resolution. well, i am trying to put my DNS zone data into the directory, using bind-dyndb-ldap, so the BIND/named daemon is dependent on LDAP. But LDAP is dependent on BIND/named. chicken and egg.
i have 2 nameservers. one wont start becuase LDAP wont start because DNS wont start because LDAP wont start because... and i get vertigo.
a tcpdump on the second nameserver validates that the logic fail continues. there is no attempt to resolve the LDAP URL or serverID on the second configured nameserver.
so further down the rabbit hole of frustration and failure i go. put the effing entry in /etc/hosts. well that only goes so far. the instance is at least able to bring up the listeners, but i still run into the problem where the -h parameter list now does have the right values, but the instance wont start.
what is now broken and how do i work around this failed logic.