Bug 578296
| Summary: | Attribute type entrydn needs to be added when subtree rename switch is on. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Noriko Hosoi <nhosoi> | ||||||
| Component: | Database - Indexes/Searches | Assignee: | Noriko Hosoi <nhosoi> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 1.2.6 | CC: | amsharma, edewata, rmeggins | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-12-07 16:42:05 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 543590, 639035 | ||||||||
| Attachments: |
|
||||||||
|
Description
Noriko Hosoi
2010-03-30 19:21:50 UTC
(In reply to comment #0) > Description of problem: > 1) Server should be able to handle a filter including (entrydn=<DN>). > 2) The search result should contain entrydb: <DN> 2) entrydn: <DN> Created attachment 426123 [details]
git diff entry.c
This patch adds entrydn attribute to the internal entry.
The added entrydn value could be used when evaluating the filter in the non-indexed style.
/usr/lib64/mozldap/ldapsearch -b "ou=Payroll,dc=example,dc=com" "(&(entrydn=uid=htappert9155,ou=payroll,dc=example,dc=com)(cn=*App*))" entrydn
dn: uid=HTappert9155,ou=Payroll,dc=example,dc=com
entrydn: uid=htappert9155,ou=payroll,dc=example,dc=com
[] conn=8 op=1 SRCH base="ou=Payroll,dc=example,dc=com" scope=2 filter="(&(entrydn=uid=htappert9155,ou=payroll,dc=example,dc=com)(cn=*App*))" attrs="entrydn"
[] conn=8 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U
^^^^^^^
This patch will add entrydn when reading from LDIF or reading from the database - what happens if the user adds the entry via LDAP? Who needs to perform searches like entrydn=<DN>? It's always better to just do a base scope search with dn <DN> instead. (In reply to comment #3) > This patch will add entrydn when reading from LDIF or reading from the > database - what happens if the user adds the entry via LDAP? > > Who needs to perform searches like entrydn=<DN>? It's always better to > just do a base scope search with dn <DN> instead. A good point... I've just run db2ldif, then it issued these errors. # ./db2ldif -n userRoot [] - Entry "cn=schema" -- attribute "entrydn" not allowed [] ... [] - Entry "" -- attribute "entrydn" not allowed [] config - Unknown attribute entrydn will be ignored [] - Entry "cn=encryption,cn=config" -- attribute "entrydn" not allowed [] ... And the exported ldif does not contain entrydn. # egrep entrydn /var/lib/dirsrv/slapd-kiki/ldif/kiki-userRoot-2010_06_23_085633.ldif This should be fixed... How about this issue? > Since entrydn is considered a non-indexed attribute, it'll be slower than > the indexed search if it's used in the filter. Considering the nature of > the attribute in the 8.x and older versions, users would use the attribute > for the fast search. But it cannot be expected any more. > Do you think it is a problem to fix? If yes, I think (entrydn=<DN>) filter > should be treated specially and converted to the entryrdn index search. (In reply to comment #4) > (In reply to comment #3) > > This patch will add entrydn when reading from LDIF or reading from the > > database - what happens if the user adds the entry via LDAP? > > > > Who needs to perform searches like entrydn=<DN>? It's always better to > > just do a base scope search with dn <DN> instead. > > A good point... I've just run db2ldif, then it issued these errors. > # ./db2ldif -n userRoot > [] - Entry "cn=schema" -- attribute "entrydn" not allowed > [] ... > [] - Entry "" -- attribute "entrydn" not allowed > [] config - Unknown attribute entrydn will be ignored > [] - Entry "cn=encryption,cn=config" -- attribute "entrydn" not allowed > [] ... > > And the exported ldif does not contain entrydn. > # egrep entrydn > /var/lib/dirsrv/slapd-kiki/ldif/kiki-userRoot-2010_06_23_085633.ldif > > This should be fixed... Does the exported ldif need to have entrydn? Is that how it worked in previous versions that used entrydn instead of entryrdn? > > How about this issue? I think we need to identify a use case for (entrydn=<DN>) vs. search -s base -b <DN> > > Since entrydn is considered a non-indexed attribute, it'll be slower than > > the indexed search if it's used in the filter. Considering the nature of > > the attribute in the 8.x and older versions, users would use the attribute > > for the fast search. But it cannot be expected any more. > > > Do you think it is a problem to fix? If yes, I think (entrydn=<DN>) filter > > should be treated specially and converted to the entryrdn index search. (In reply to comment #5) [...] > > And the exported ldif does not contain entrydn. > > # egrep entrydn > > /var/lib/dirsrv/slapd-kiki/ldif/kiki-userRoot-2010_06_23_085633.ldif > > > > This should be fixed... > > Does the exported ldif need to have entrydn? Nope. That's one of the operational attributes. The 8.2 and older version store the attribute value in the db, but it does not export it to the ldif. As you pointed out, the entrydn attribute should be added only for the search result. If we do it in the str2entry, it could be added permanently, which is not expected. Doing it in a plugin should be better. > Is that how it worked in previous > versions that used entrydn instead of entryrdn? > > > > > How about this issue? > > I think we need to identify a use case for (entrydn=<DN>) vs. search -s > base -b <DN> How about this type of search -- getting specific entries in one search? -b <suffix> "(|(entrydn=<DN1>)(entrydn=<DN2>)(entrydn=<DN3>))" (In reply to comment #6) > (In reply to comment #5) > [...] > > > And the exported ldif does not contain entrydn. > > > # egrep entrydn > > > /var/lib/dirsrv/slapd-kiki/ldif/kiki-userRoot-2010_06_23_085633.ldif > > > > > > This should be fixed... > > > > Does the exported ldif need to have entrydn? > > Nope. That's one of the operational attributes. The 8.2 and older version > store the attribute value in the db, but it does not export it to the ldif. > > As you pointed out, the entrydn attribute should be added only for the search > result. If we do it in the str2entry, it could be added permanently, which is > not expected. Doing it in a plugin should be better. How did we handle the entrydn operational attribute in earlier versions? > > > Is that how it worked in previous > > versions that used entrydn instead of entryrdn? > > > > > > > > How about this issue? > > > > I think we need to identify a use case for (entrydn=<DN>) vs. search -s > > base -b <DN> > How about this type of search -- getting specific entries in one search? > -b <suffix> "(|(entrydn=<DN1>)(entrydn=<DN2>)(entrydn=<DN3>))" Ok. Then yes, we need to be able to index entrydn. Created attachment 426726 [details]
git patch file (9.0)
Files:
ldap/servers/slapd/back-ldbm/back-ldbm.h
ldap/servers/slapd/back-ldbm/id2entry.c
ldap/servers/slapd/back-ldbm/index.c
ldap/servers/slapd/back-ldbm/ldbm_search.c
ldap/servers/slapd/back-ldbm/proto-back-ldbm.h
Change Description:
1) ldbm_back_next_search_entry_ext (ldbm_search.c)
When getting an entry from ID using id2entry_ext, pass a flag
ID2ENTRY_ADD_ENTRYDN to add entrydn to the entry.
2) id2entry_ext (id2entry.c)
Added id2entry_ext to handle the flag ID2ENTRY_ADD_ENTRYDN.
If ID2ENTRY_ADD_ENTRYDN is set in the flags variable and
entryrdn switch is enabled, entrydn is added to the entry.
3) index_read_ext (index.c)
If entryrdn switch is on and the attribute type is entrydn and
the search type is equality, then call entryrdn_index_read
to get the ID directly.
Sample command-line: ldapsearch -b "dc=example,dc=com" "(|(entrydn=uid=lnestor999, ou=product development ,dc=example, dc=com)(entrydn=uid=JOshinski2, ou=Payroll, dc=example,dc=com)(cn=Phylis Leafloor))" entrydn cn dn: uid=JOshinski2,ou=Payroll,dc=example,dc=com entrydn: uid=joshinski2,ou=payroll,dc=example,dc=com cn: Joon Oshinski dn: uid=PLeafloor993,ou=Accounting,dc=example,dc=com entrydn: uid=pleafloor993,ou=accounting,dc=example,dc=com cn: Phylis Leafloor dn: uid=LNestor999,ou=Product Development,dc=example,dc=com entrydn: uid=lnestor999,ou=product development,dc=example,dc=com cn: Lizette Nestor Corresponding access log: [] conn=2 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(|(entrydn=uid=lnestor999, ou=product development ,dc=example, dc=com)(entrydn=uid=JOshinski2, ou=Payroll, dc=example,dc=com)(cn=Phylis Leafloor))" attrs="entrydn cn" [] conn=2 op=1 RESULT err=0 tag=101 nentries=3 etime=0 NOTE: There's no "notes=U" in the RESULT line. Thanks to Rich for reviewing the change. Pushed to master. $ git merge 578296 Updating 7094777..7482698 Fast-forward ldap/servers/slapd/back-ldbm/back-ldbm.h | 3 ++ ldap/servers/slapd/back-ldbm/id2entry.c | 31 +++++++++++++++++++++++- ldap/servers/slapd/back-ldbm/index.c | 31 +++++++++++++++++++++++- ldap/servers/slapd/back-ldbm/ldbm_search.c | 3 +- ldap/servers/slapd/back-ldbm/proto-back-ldbm.h | 2 + 5 files changed, 67 insertions(+), 3 deletions(-) $ git push Counting objects: 20, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 9.37 KiB, done. Total 11 (delta 8), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 7094777..7482698 master -> master The implementation includes a bug. Steps to reproduce: 1) adding new entry ou=OU0, dc=example,dc=com 2) moving the entry: dn: ou=OU0, dc=example,dc=com changetype: modrdn newrdn: ou=ou1 deleteoldrdn: 1 newsuperior: uid=tvradmin0,ou=newpeople, dc=Example,dc=COM modifying RDN of entry ou=OU0, dc=example,dc=com and/or moving it beneath a new parent 3) ldapsearch returns the old entrydn. ldapsearch ... -b "dc=example,dc=com" "(ou=*)" dn entrydn dn: ou=ou1,uid=TVradmin0,ou=newpeople,dc=example,dc=com entrydn: ou=ou0,dc=example,dc=com When an entry is moved, the entry in the cache itself should be updated. Reopening a bug... Note: children are okay since once parent entry is renamed, the child entries are deleted from the entry cache. dn: ou=finance,ou=Payroll,dc=example,dc=com <== renamed/moved entry entrydn: ou=accounting,dc=example,dc=com <== BAD dn: uid=BDipace9,ou=finance,ou=Payroll,dc=example,dc=com <== child entrydn: uid=bdipace9,ou=finance,ou=payroll,dc=example,dc=com <== OK Another bug was found.
When an entry in the entry cache is flushed to the DB, entrydn must be filtered out if it has. Currently, it's blindly dumped.
# dbscan -f id2entry.db4
id 2
rdn: ou=finance
[...]
entrydn: ou=accounting,dc=example,dc=com
parentid: 6
ou: finance
id 6
rdn: ou=Payroll
[...]
entrydn: ou=payroll,dc=example,dc=com
The newly found bugs (comment 11 and 13) are fixed by the patch (Created attachment 447272 [details]) in the bug: Bug 631862 - crash - delete entries not in cache + referint https://bugzilla.redhat.com/show_bug.cgi?id=631862#c13 Change the status back to MODIFIED. Testing Comment#9 ===================== [root@testvm /]# ldapsearch -h localhost -p 389 -D "cn=Directory Manager" -w xxx -b "ou=people,dc=test,dc=com" "(|(entrydn=cn=Managerami,ou=people,dc=test,dc=com)(entrydn=cn=Userami,ou=people,dc=test,dc=com))" entrydn cn # extended LDIF # # LDAPv3 # base <ou=people,dc=test,dc=com> with scope subtree # filter: (|(entrydn=cn=Managerami,ou=people,dc=test,dc=com)(entrydn=cn=Userami,ou=people,dc=test,dc=com)) # requesting: entrydn cn # # Managerami, people, test.com dn: cn=Managerami,ou=people,dc=test,dc=com entrydn: cn=managerami,ou=people,dc=test,dc=com cn: Managerami # Userami, people, test.com dn: cn=Userami,ou=people,dc=test,dc=com entrydn: cn=userami,ou=people,dc=test,dc=com cn: Userami # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Access Logs: [23/May/2011:18:46:06 +051800] conn=1184 op=1 SRCH base="ou=people,dc=test,dc=com" scope=2 filter="(|(entrydn=cn=Managerami,ou=people,dc=test,dc=com)(entrydn=cn=Userami,ou=people,dc=test,dc=com))" attrs="entrydn cn" [23/May/2011:18:46:06 +051800] conn=1184 op=1 RESULT err=0 tag=101 nentries=2 etime=0 Testing Comment# 11 ====================== [root@testvm ~]# ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w xxx << EOF > dn: ou=people,dc=test,dc=com > changetype: modrdn > newrdn: ou=group > deleteoldrdn: 1 > newsuperior: dc=test,dc=com > EOF modifying rdn of entry "ou=people,dc=test,dc=com" [root@testvm ~]# ldapsearch -h localhost -p 389 -D "cn=Directory Manager" -w xxx -b "dc=test,dc=com" "(ou=*)" dn entrydn # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope subtree # filter: (ou=*) # requesting: dn entrydn # # group, test.com dn: ou=group,dc=test,dc=com entrydn: ou=group,dc=test,dc=com # Groups, test.com dn: ou=Groups,dc=test,dc=com entrydn: ou=groups,dc=test,dc=com # search result search: 2 result: 0 Success Testing Comment 13 ============= dbscan -f /var/lib/dirsrv/slapd-testvm/db/testdb/id2entry.db4 id 7 rdn: ou=Groups ou;vucsn-4dd2594e0000000b0000;mdcsn-4dd2594e0000000b0000: Groups objectClass;vucsn-4dd2594e0000000b0000: top objectClass;vucsn-4dd2594e0000000b0000: organizationalunit creatorsName;vucsn-4dd2594e0000000b0000: cn=directory manager modifiersName;vucsn-4dd2594e0000000b0000: cn=directory manager createTimestamp;vucsn-4dd2594e0000000b0000: 20110517111733Z modifyTimestamp;vucsn-4dd2594e0000000b0000: 20110517111733Z nsUniqueId: 26b56303-807711e0-83f6b85c-b3c05de4 parentid: 1 entryid: 7 No entrydn found. |