> Now, I can create the objectClass: domain with ldif2db for the backend. > But the goal is to do this live. I think I'm getting the no_such_object, > because DS doesn't know *what* backend this entry should be put into, > because there is no parent, so the NO_SUCH_OBJECT comes from the rootdse > code. >
Dug a bit more, the issue is in op_shared_add. Because the operation doesn't match a backend, it gets put on to the defbackend.c code, which fails the operation. So the problem could be in slapi_mapping_tree_select, which isn't getting the right backend ... > Right now, I don't really have a great solution here. My thought is that > when we create the backend in ldbm_instance_create we create the > objectClass domain type that is correct as the first entry into the > database. This way we avoid the problem. > > Alternately, because this operation has a specific DN, we should be able > to select the right backend because nsslapd-suffix should match the > entry I'm trying to add. But this seems more complicated as a fix (but > likely more correct). > > Does this seem like a reasonable solution? Does anyone else have any > better ideas? > > Thanks, > > _______________________________________________ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
