On 01/28/2019 09:20 AM, Mihai Carabas wrote:
On Mon, Jan 28, 2019 at 10:04 AM Ludwig <lkrispen@xxxxxxxxxx> wrote:
On 01/24/2019 10:34 PM, William Brown wrote:
On 25 Jan 2019, at 10:08, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote:
On 1/24/19 3:35 PM, Mihai Carabas wrote:
On Thu, Jan 24, 2019 at 10:17 PM Mark Reynolds <mreynolds@xxxxxxxxxx> 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?
that issue is about the problem that after a db2index the
nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff entry is not found. And
the cause ist that the general reindex without any specified attribute
takes a different code path than when reindexing only one or more
specific attributes.
So just reindexing the entryrdn index can help
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
