Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.2.11 only] DN normalization should be the same than in 389-ds-base-1.3.X #2136

Closed
389-ds-bot opened this issue Sep 13, 2020 · 8 comments
Closed
Labels
closed: won't fix Migration flag - Issue
Milestone

Comments

@389-ds-bot
Copy link

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49077


Description of problem:

This issue is similar to this bug fixed some time ago:

https://fedorahosted.org/389/ticket/48223

for winsync.

In this case DN normalization at import time is considering that, for instance,
these two dn's are duplicated:

================================
dn: cn=user nuevo,ou=people,o=redhat
objectclass: inetorgperson
cn: user nuevo
sn: usernuevo
userpassword: user49

dn: cn=user  nuevo,ou=people,o=redhat
objectclass: inetorgperson
cn: user  nuevo
sn: us
userpassword: user49
================================

errors:

[04/Jan/2017:15:02:50.356169698 +0100] entryrdn-index - _entryrdn_insert_key:
Same DN (dn: cn=user nuevo,ou=people,o=redhat) is already in the entryrdn file
with different ID 53.  Expected ID is 54.
[04/Jan/2017:15:02:50.399342349 +0100] import userRoot: Duplicated DN detected:
"cn=user nuevo,ou=people,o=redhat": Entry ID: (54)


To reproduce, just import both entries in the same ldif file.

not sure if this is, in fact a feature (it does not seem to me from rfc4514) or
if fixing this could break something else.

If this is not corresponding or too risky, let's close this.

Thanks.

German.
@389-ds-bot 389-ds-bot added the closed: won't fix Migration flag - Issue label Sep 13, 2020
@389-ds-bot 389-ds-bot added this to the 1.2.11 milestone Sep 13, 2020
@389-ds-bot
Copy link
Author

Comment from nhosoi (@nhosoi) at 2017-01-05 00:38:06

Thanks to German for figuring out the cause. It's likely this bug was introduced by the ticket 47720.

(In reply to German Parente from comment 2)
> probably related to this ?
> 
> https://fedorahosted.org/389/ticket/47720
> 
> ==========
> else if (ISSPACE(*s)) { 
>     while (ISSPACE(*s)) { 
> 	   s++; 
> ===========
> 
> that seems to be the difference in DN norm. from rhds9 code.

@389-ds-bot
Copy link
Author

Comment from nhosoi (@nhosoi) at 2017-01-19 06:28:58

See also the closed bug: https://bugzilla.redhat.com/show_bug.cgi?id=1410131.

@389-ds-bot
Copy link
Author

Comment from nhosoi (@nhosoi) at 2017-02-11 22:49:59

Metadata Update from @nhosoi:

  • Issue set to the milestone: 1.2.11.33

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2017-07-05 17:30:26

This is a backport request to 1.2.11

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2017-07-05 17:30:27

Metadata Update from @mreynolds389:

  • Issue close_status updated to: None

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2017-10-18 21:42:55

Metadata Update from @mreynolds389:

  • Custom field reviewstatus adjusted to None
  • Custom field version adjusted to None
  • Issue set to the milestone: 1.2.11 (was: 1.2.11.33)

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2017-10-26 17:56:00

Closing too risky for 1.2.11

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2017-10-26 17:56:00

Metadata Update from @mreynolds389:

  • Issue close_status updated to: wontfix
  • Issue status updated to: Closed (was: Open)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed: won't fix Migration flag - Issue
Projects
None yet
Development

No branches or pull requests

1 participant