directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRSERVER-2235) After renaming an entry in ApacheDS, the directory loses the new entry
Date Tue, 12 Jun 2018 04:46:00 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509182#comment-16509182
] 

Emmanuel Lecharny commented on DIRSERVER-2235:
----------------------------------------------

FTR, we have unit tests that I have modified to cover your scenario :

{code:java}
@RunWith(FrameworkRunner.class)
@ApplyLdifs(
    { 
        "dn: cn=modDn,ou=system", 
        "objectClass: person", 
        "cn: modDn", 
        "sn: snModDn",
        "",
        "dn: employeeNumber=test,ou=system", 
        "objectClass: person", 
        "objectClass: inetorgPerson",
        "cn: modDn",
        "employeeNumber: test",
        "sn: snModDn",
        "",
        "dn: ou=container,ou=system", 
        "objectClass: organizationalUnit", 
        "ou: container"
    })
@CreateLdapServer(transports =
    { @CreateTransport(protocol = "LDAP"), @CreateTransport(protocol = "LDAPS") })
public class ClientModifyDnRequestTest extends AbstractLdapTestUnit
{
    ...
    private static final String DN = "cn=modDn,ou=system";
    private static final String DN_CONTAINER = "ou=container,ou=system";
    ...

   @Test
    public void testMoveAndRenameWithDeleteOldRdnShouldDeleteOldRdn() throws Exception
    {
        Dn newDn = new Dn( "cn=modifiedDn", DN_CONTAINER );
        connection.moveAndRename( new Dn( DN ), newDn, true );

        assertTrue( connection.exists( newDn ) );
        assertFalse( connection.exists( DN ) );
        Entry entry = connection.lookup( newDn, "*", "+" );
        assertTrue( entry.contains( "cn", "modifiedDn" ) );
        assertFalse( entry.contains( "cn", "modDn" ) );
        assertTrue( entry.containsAttribute( SchemaConstants.MODIFIERS_NAME_AT ) );
        assertTrue( entry.containsAttribute( SchemaConstants.MODIFY_TIMESTAMP_AT ) );
        
        SearchRequest searchRequest = new SearchRequestImpl();
        searchRequest.setBase( new Dn( "ou=system" ) );
        searchRequest.setFilter( "(objectClass=*)" );
        searchRequest.setScope( SearchScope.SUBTREE );
        SearchCursor cursor = connection.search( searchRequest );
        
        while ( cursor.next() )
        {
            System.out.println( cursor.get() );
        }
        
        cursor.close();
    }
{code}

The output is :

{noformat}
Entry
    dn[n]: ou=interceptors,ou=configuration,ou=system
    objectClass: top
    objectClass: organizationalUnit
    ou: interceptors

Entry
    dn[n]: cn=modifiedDn,ou=container,ou=system
    objectclass: person
    objectclass: top
    cn: modifiedDn
    sn: snModDn

Entry
    dn[n]: ou=users,ou=system
    objectClass: top
    objectClass: organizationalUnit
    ou: users

Entry
    dn[n]: ou=groups,ou=system
    objectClass: top
    objectClass: organizationalUnit
    ou: groups

Entry
    dn[n]: ou=system
    objectClass: top
    objectClass: organizationalUnit
    objectClass: extensibleObject
    ou: system

Entry
    dn[n]: uid=admin,ou=system
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: tlsKeyInfo
    uid: admin
    userPassword: 0x73 0x65 0x63 0x72 0x65 0x74 
    publicKey: 0x30 0x81 0x9F 0x30 0x0D 0x06 0x09 0x2A 0x86 0x48 0x86 0xF7 0x0D 0x01 0x01
0x01 ...
    publicKeyFormat: X.509
    userCertificate: 0x30 0x82 0x01 0xF8 0x30 0x82 0x01 0x61 0x02 0x06 0x01 0x63 0xF2 0x46
0xE3 0xB2 ...
    privateKey: 0x30 0x82 0x02 0x76 0x02 0x01 0x00 0x30 0x0D 0x06 0x09 0x2A 0x86 0x48 0x86
0xF7 ...
    keyAlgorithm: RSA
    privateKeyFormat: PKCS#8
    cn: system administrator
    sn: administrator
    displayName: Directory Superuser

Entry
    dn[n]: ou=container,ou=system
    objectclass: organizationalUnit
    objectclass: top
    ou: container

Entry
    dn[n]: prefNodeName=sysPrefRoot,ou=system
    objectClass: top
    objectClass: organizationalUnit
    objectClass: extensibleObject
    prefNodeName: sysPrefRoot

Entry
    dn[n]: cn=Administrators,ou=groups,ou=system
    objectClass: top
    objectClass: groupOfUniqueNames
    uniqueMember: 0.9.2342.19200300.100.1.1= admin ,2.5.4.11= system 
    cn: Administrators

Entry
    dn[n]: ou=configuration,ou=system
    objectClass: top
    objectClass: organizationalUnit
    ou: configuration

Entry
    dn[n]: ou=services,ou=configuration,ou=system
    objectClass: top
    objectClass: organizationalUnit
    ou: services

Entry
    dn[n]: ou=partitions,ou=configuration,ou=system
    objectClass: top
    objectClass: organizationalUnit
    ou: partitions

Entry
    dn[n]: employeeNumber=test,ou=system
    objectclass: organizationalPerson
    objectclass: person
    objectclass: inetorgPerson
    objectclass: top
    cn: modDn
    sn: snModDn
    employeenumber: test
{noformat}

As you can see, the old entry has been properly moved and renamed, and it's not anymore present
in the LDAP server, either through an {{exists}} call or through a {{search}} request.

I have one question : when you say 'the old entry is still returned in searches but it cannot
be read', what is the code you use to get the old entry and to read it?

Otherwise, can you provide the server logs ?

Thanks !

> After renaming an entry in ApacheDS, the directory loses the new entry
> ----------------------------------------------------------------------
>
>                 Key: DIRSERVER-2235
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-2235
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 2.0.0-M20, 2.0.0-M24
>         Environment: Debian Linux, x64
>            Reporter: Roland Szabó
>            Priority: Major
>         Attachments: tesztelek.ldif
>
>
> When I rename an entry in our directory, the old entry is still returned in searches
but it cannot be read. The new entry exists, but only when referred directly by its DN. I
have to restart the server to clean this mess up.
> I tried to use the rename operation in JNDI, then I switched to the ApacheDS LDAP-API,
but both method results in the same problem. We use the CN attribute as the RDN, and after
renaming, the CN attribute of the entry is all lowercase, however the DN maintains the correct
casing. If I update the CN attribute to the correct case, I can use the rename operation on
the entry 1 more time. If I also close the connection between rename operations, I can rename
the same entry 1 more time, but then it fails again.
> I tried to upgrade from M20 to M24, but the problem is still there.
> I do not really understand the reason...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message