On Mon, Jan 28, 2019 at 10:04 AM Ludwig <lkrispen(a)redhat.com> wrote:
On 01/24/2019 10:34 PM, William Brown wrote:
>
>> On 25 Jan 2019, at 10:08, Mark Reynolds <mreynolds(a)redhat.com> wrote:
>>
>>
>> On 1/24/19 3:35 PM, Mihai Carabas wrote:
>>> On Thu, Jan 24, 2019 at 10:17 PM Mark Reynolds <mreynolds(a)redhat.com>
wrote:
>>>> On 1/24/19 1:54 PM, Mihai Carabas wrote:
>>>>
>>>> Hello,
>>>>
>>>> [root@ldap ~]# dsctl slapd-ldap db2ldif --replication cursdb
cursdb.ldif
>>>>
>>>> cursdb.ldif doesn't seem to contain any replication related info.
What
>>>> should contain related to replication?
>>>>
>>>> You should at least see an entry with "dn:
nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff", if you don't see this entry in
the LDIF then it might not be working (sigh). You can then use the legacy tool:
>>>>
>>> Is there. All is ok.
>>>
>>> After exporting LDIF and importing again, the search still is buggy.
>>>
>> Yeah this is looking like a known bug that we will be working on soon…
> Looking at the entryid and indexes, everything seems correct, so this does seem like
a bug. Have we got an issue id Mark?
I think it is:
https://pagure.io/389-ds-base/issue/50103, the fix is not
yet ready
I am a little confused. I have read the issue: is this issue about my
ldapsearch problem or about the reindex problem?
you can repair it by explicitely reindexing the entryrdn index. ..... -t
entryrdn
Why on entryrdn will work? When you say entryrdn in my case, you are
refering at what rdn?
Thank you and sorry for the dumb questions,
Mihai
> >
> >> Question, would you be willing to try a "special logging" build to
see we can figure out why the reindex task is hanging? The stacktraces did not show
anything helpful, so we need to see which entry is causing the issue and the easiest way,
besides walking you through using gdb (which I would be willing to do), would be to
provide a special build that logs extra info to the errors log. I know that is a lot to
ask, so no worries if you aren't comfortable with it.
> >>
> >> Thanks,
> >> Mark
> >> _______________________________________________
> >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> >> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> >> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
> > —
> > Sincerely,
> >
> > William Brown
> > Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>