Bug 578296 - Attribute type entrydn needs to be added when subtree rename switch is on.
Summary: Attribute type entrydn needs to be added when subtree rename switch is on.
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Database - Indexes/Searches
Version: 1.2.6
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 389_1.2.6 639035
TreeView+ depends on / blocked
 
Reported: 2010-03-30 19:21 UTC by Noriko Hosoi
Modified: 2015-12-07 16:42 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-12-07 16:42:05 UTC


Attachments (Terms of Use)
git diff entry.c (1.86 KB, patch)
2010-06-23 00:30 UTC, Noriko Hosoi
no flags Details | Diff
git patch file (9.0) (6.48 KB, patch)
2010-06-25 00:16 UTC, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff

Description Noriko Hosoi 2010-03-30 19:21:50 UTC
Description of problem:
1) Server should be able to handle a filter including (entrydn=<DN>).
2) The search result should contain entrydb: <DN>

Comment 1 Noriko Hosoi 2010-03-30 21:26:39 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>

Comment 2 Noriko Hosoi 2010-06-23 00:30:54 UTC
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
                                                       ^^^^^^^

Comment 3 Rich Megginson 2010-06-23 02:04:23 UTC
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.

Comment 4 Noriko Hosoi 2010-06-23 16:30:07 UTC
(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.

Comment 5 Rich Megginson 2010-06-23 16:44:36 UTC
(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.

Comment 6 Noriko Hosoi 2010-06-23 18:00:46 UTC
(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>))"

Comment 7 Rich Megginson 2010-06-23 18:04:49 UTC
(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.

Comment 8 Noriko Hosoi 2010-06-25 00:16:44 UTC
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.

Comment 9 Noriko Hosoi 2010-06-25 00:22:29 UTC
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.

Comment 10 Noriko Hosoi 2010-06-25 23:41:58 UTC
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

Comment 11 Noriko Hosoi 2010-09-13 19:11:30 UTC
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...

Comment 12 Noriko Hosoi 2010-09-13 20:42:12 UTC
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

Comment 13 Noriko Hosoi 2010-09-13 20:45:52 UTC
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

Comment 14 Noriko Hosoi 2010-09-14 20:51:46 UTC
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.

Comment 15 Amita Sharma 2011-05-23 13:36:54 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.