[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: cannot start instance
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.