[VOTE] Apache DS 2.0.0.AM25 release

[Emmanuel Lecharny]

Hi,

This is a major release of ApacheDS.

It uses the Apache LDAP API 2.0.0.AM1 release, which itself
brings a lot of improvements and bug fixes.

But the major improvement is the cross-indexes transaction
support that has been added, which is expecting to solve the
database corruption issue we are facing for years.


Here are the fixed issues :


Bugs :
--
* DIRSERVER-2109 - Apply LDIF with special crafted DN creates two CN attributes
* DIRSERVER-2220 - ApacheDS should not log credentials
* DIRSERVER-2231 - NPE in AbstractBTreePartition when cacheService is not used
* DIRSERVER-2234 - Kinit via TCP causes ApacheDS to create a
NioProcessor thread at 100% CPU

Improvements :
--
* DIRSERVER-2242 - Keystore change from JKS to PKCS12
* DIRSERVER-2225 - Usage of maven-source-plugin goal jar-no-fork instead of jar
* DIRSERVER-2230 - SCM pointing to gitbox instead of svn
* DIRSERVER-2229 - Remove duplicated declaration of
versions-maven-plugin in pom.xml

Tasks :
---

* DIRSERVER-2244 - Support AES Encryption with HMAC-SHA2 for Kerberos
5 defined in RFC 8009

 Here are the associated links :

ApacheDS 2.0.0.AM25
--
- GIT tag :
https://gitbox.apache.org/repos/asf?p=directory-server.git;a=commit;h=40ab08d93c6125ccb59d692b25759361307195d3
- Nexus 
repository:https://repository.apache.org/content/repositories/orgapachedirectory-1172

- Distribution packages and sources
:https://dist.apache.org/repos/dist/dev/directory/apacheds/2.0.0.AM25/



[ ] +1 : release ApacheDS 2.0.0.AM25
[ ] ± 0 : I don't care
[ ] -1 : No, don't release ApacheDS 2.0.0.AM25

--
Regards,
Cordialement,
Emmanuel Lécharnywww.iktek.com



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Shawn McKinney]

> On Aug 14, 2018, at 4:18 AM, Emmanuel Lecharny  wrote:
> 
> This is a major release of ApacheDS.
> 
> It uses the Apache LDAP API 2.00.AM1 release, which itself 
> brings a lot of improvements and bug fixes
> 
> But the major improvement is the cross-indexes transaction 
> support that has been added, which is expecting to solve the 
> database corruption issue we are facing for years.
> 
> ...
> 
> [ ] +1 : release ApacheDS 2.0.0.AM25
> [ ] ± 0 : I don't care
> [ ] -1 : No, don't release ApacheDS 2.0.0.AM25

+1, built from source, installed to centos7/java8 platform. Passed all tests 
including w/ fortress.

—Arkanshawn

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Colm O hEigeartaigh]

+1, built from source + tested with WSS4J/CXF.

Just a note - the link for the dist actually links to the previous release (
https://dist.apache.org/repos/dist/dev/directory/apacheds/2.0.0-M24/).

On Tue, Aug 14, 2018 at 3:36 PM, Shawn McKinney 
wrote:

>
> > On Aug 14, 2018, at 4:18 AM, Emmanuel Lecharny 
> wrote:
> >
> > This is a major release of ApacheDS.
> >
> > It uses the Apache LDAP API 2.00.AM1 release, which itself
> > brings a lot of improvements and bug fixes
> >
> > But the major improvement is the cross-indexes transaction
> > support that has been added, which is expecting to solve the
> > database corruption issue we are facing for years.
> >
> > ...
> >
> > [ ] +1 : release ApacheDS 2.0.0.AM25
> > [ ] ± 0 : I don't care
> > [ ] -1 : No, don't release ApacheDS 2.0.0.AM25
>
> +1, built from source, installed to centos7/java8 platform. Passed all
> tests including w/ fortress.
>
> —Arkanshawn




-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Emmanuel Lécharny]

Le 15/08/2018 à 18:19, Colm O hEigeartaigh a écrit :
> +1, built from source + tested with WSS4J/CXF.
> 
> Just a note - the link for the dist actually links to the previous release (
> https://dist.apache.org/repos/dist/dev/directory/apacheds/2.0.0-M24/).

The magic of copy/paste ;-)

Sorry...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Stefan Seelmann]

+1

* Verified checksums and signatures
* Built source on Linux with OpenJDK 8 and 11-ea25
* Run installer tests:
* bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24
* rpm on Fedora 21 (very old!) with Java 8

Note: when starting the server there is output like this:
[18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] -
ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to
handle NameAndOptionalUID normalization with obje...

Kind Regards,
Stefan


On 08/14/2018 11:18 AM, Emmanuel Lecharny wrote:
> Hi,
> 
> This is a major release of ApacheDS.
> 
> It uses the Apache LDAP API 2.0.0.AM1 release, which itself
> brings a lot of improvements and bug fixes.
> 
> But the major improvement is the cross-indexes transaction
> support that has been added, which is expecting to solve the
> database corruption issue we are facing for years.
> 
> 
> Here are the fixed issues :
> 
> 
> Bugs :
> --
> * DIRSERVER-2109 - Apply LDIF with special crafted DN creates two CN 
> attributes
> * DIRSERVER-2220 - ApacheDS should not log credentials
> * DIRSERVER-2231 - NPE in AbstractBTreePartition when cacheService is not used
> * DIRSERVER-2234 - Kinit via TCP causes ApacheDS to create a
> NioProcessor thread at 100% CPU
> 
> Improvements :
> --
> * DIRSERVER-2242 - Keystore change from JKS to PKCS12
> * DIRSERVER-2225 - Usage of maven-source-plugin goal jar-no-fork instead of 
> jar
> * DIRSERVER-2230 - SCM pointing to gitbox instead of svn
> * DIRSERVER-2229 - Remove duplicated declaration of
> versions-maven-plugin in pom.xml
> 
> Tasks :
> ---
> 
> * DIRSERVER-2244 - Support AES Encryption with HMAC-SHA2 for Kerberos
> 5 defined in RFC 8009
> 
>  Here are the associated links :
> 
> ApacheDS 2.0.0.AM25
> --
> - GIT tag :
> https://gitbox.apache.org/repos/asf?p=directory-server.git;a=commit;h=40ab08d93c6125ccb59d692b25759361307195d3
> - Nexus 
> repository:https://repository.apache.org/content/repositories/orgapachedirectory-1172
> 
> - Distribution packages and sources
> :https://dist.apache.org/repos/dist/dev/directory/apacheds/2.0.0.AM25/
> 
> 
> 
> [ ] +1 : release ApacheDS 2.0.0.AM25
> [ ] ± 0 : I don't care
> [ ] -1 : No, don't release ApacheDS 2.0.0.AM25
> 
> --
> Regards,
> Cordialement,
> Emmanuel Lécharnywww.iktek.com
> 
> 
> 

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Emmanuel Lécharny]

Le 15/08/2018 à 21:01, Stefan Seelmann a écrit :
> +1
> 
> * Verified checksums and signatures
> * Built source on Linux with OpenJDK 8 and 11-ea25
> * Run installer tests:
> * bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24
> * rpm on Fedora 21 (very old!) with Java 8
> 
> Note: when starting the server there is output like this:
> [18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] -
> ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to
> handle NameAndOptionalUID normalization with obje...

Yes, this should be a warning.

What happens is that the server will load all the schemas, recursively,
and for each schema, the AT, OC, etc Some of them are loaded before
the parts they depend on. Each of the attributeTypes and Object classes
are checked against the registries, and if they don't exist, such an
error is produced. Then a workaround is applied:

...
entry.addAttribute( attributeType, attributeValue ); //
Here, we will get an exception
}
catch ( Exception e )
{
// The attribute does not exist already, create a fake one
if ( ( schemaManager != null ) && schemaManager.isRelaxed() )
// Here, we create a fake object waiting for the real one to be loaded

Later on, when all the schemas has finally been loaded, all those
temporary objects are discarded, and a global check is done, which means
if there is some missing AT, OC or anything else, and error will be
produced.

Typically, here, an attributeType's super attribute is not yet loaded in
the registry (apacheDnsDomainName):

version: 1
dn:
m-oid=1.3.6.1.4.1.18060.0.4.2.2.6,ou=attributeTypes,cn=apachedns,ou=schema
m-singlevalue: TRUE
m-obsolete: FALSE
m-description: The domain name of the name server that was the primary
source of data for this zone
m-usage: USER_APPLICATIONS
creatorsname: uid=admin,ou=system
m-collective: FALSE
m-oid: 1.3.6.1.4.1.18060.0.4.2.2.6
m-supattributetype: apacheDnsDomainName
m-nousermodification: FALSE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-name: apacheDnsSoaMName
m-equality: caseIgnoreIA5Match

because attribute files are loaded in an order that is not the one we
can guaranty. That would be another story if the schema elements were
not in a distinct file for each one of them.

I agree there is room for improvement here, typically not storing each
AT, OC, etc in a separated file, but as a whole in a .schema file, as
it's done in OpenLDAP. OTOH, that would make the schema update way more
complex, as we would have to modify the schema file and create a new one
for each modification, while the way we work allows us to simply update
one single fle when we modify the schema.

It's a implementation choice.

Ideally speaking, we should mute the logs in this case, or make it a
warning, not a error.


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Lucas Theisen]

+1

However, test fail on Windows during attempts to delete test files.  Not
sure if that is much of a concern...

[ERROR] Errors:
[ERROR]   JdbmIndexTest.cleanup:127 ▒ IO ERR_17010_UNABLE_DELETE_FILE
Unable to delete f...
[ERROR]   JdbmRdnIndexTest.cleanup:128 ▒ IO ERR_17010_UNABLE_DELETE_FILE
Unable to delet...
[INFO]
[ERROR] Tests run: 124, Failures: 0, Errors: 2, Skipped: 0



On Aug 15, 2018 4:44 PM, "Emmanuel Lécharny"  wrote:



Le 15/08/2018 à 21:01, Stefan Seelmann a écrit :
> +1
>
> * Verified checksums and signatures
> * Built source on Linux with OpenJDK 8 and 11-ea25
> * Run installer tests:
> * bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24
> * rpm on Fedora 21 (very old!) with Java 8
>
> Note: when starting the server there is output like this:
> [18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] -
> ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to
> handle NameAndOptionalUID normalization with obje...

Yes, this should be a warning.

What happens is that the server will load all the schemas, recursively,
and for each schema, the AT, OC, etc Some of them are loaded before
the parts they depend on. Each of the attributeTypes and Object classes
are checked against the registries, and if they don't exist, such an
error is produced. Then a workaround is applied:

...
entry.addAttribute( attributeType, attributeValue ); //
Here, we will get an exception
}
catch ( Exception e )
{
// The attribute does not exist already, create a fake one
if ( ( schemaManager != null ) && schemaManager.isRelaxed() )
// Here, we create a fake object waiting for the real one to be loaded

Later on, when all the schemas has finally been loaded, all those
temporary objects are discarded, and a global check is done, which means
if there is some missing AT, OC or anything else, and error will be
produced.

Typically, here, an attributeType's super attribute is not yet loaded in
the registry (apacheDnsDomainName):

version: 1
dn:
m-oid=1.3.6.1.4.1.18060.0.4.2.2.6,ou=attributeTypes,cn=apachedns,ou=schema
m-singlevalue: TRUE
m-obsolete: FALSE
m-description: The domain name of the name server that was the primary
source of data for this zone
m-usage: USER_APPLICATIONS
creatorsname: uid=admin,ou=system
m-collective: FALSE
m-oid: 1.3.6.1.4.1.18060.0.4.2.2.6
m-supattributetype: apacheDnsDomainName
m-nousermodification: FALSE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-name: apacheDnsSoaMName
m-equality: caseIgnoreIA5Match

because attribute files are loaded in an order that is not the one we
can guaranty. That would be another story if the schema elements were
not in a distinct file for each one of them.

I agree there is room for improvement here, typically not storing each
AT, OC, etc in a separated file, but as a whole in a .schema file, as
it's done in OpenLDAP. OTOH, that would make the schema update way more
complex, as we would have to modify the schema file and create a new one
for each modification, while the way we work allows us to simply update
one single fle when we modify the schema.

It's a implementation choice.

Ideally speaking, we should mute the logs in this case, or make it a
warning, not a error.



-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Emmanuel Lécharny]

Hi Lucas,

Yes, Windows is having hard time deleting transient files. This is
visible on jenkins.

Not sure we can do anythig regarding this problem, to me it seems that
there is some kind of temporary lock put of those files, and the
deletion just fails...

Le 16/08/2018 à 06:30, Lucas Theisen a écrit :
> +1
> 
> However, test fail on Windows during attempts to delete test files.  Not
> sure if that is much of a concern...
> 
> [ERROR] Errors:
> [ERROR]   JdbmIndexTest.cleanup:127 ▒ IO ERR_17010_UNABLE_DELETE_FILE
> Unable to delete f...
> [ERROR]   JdbmRdnIndexTest.cleanup:128 ▒ IO ERR_17010_UNABLE_DELETE_FILE
> Unable to delet...
> [INFO]
> [ERROR] Tests run: 124, Failures: 0, Errors: 2, Skipped: 0
> 
> 
> 
> On Aug 15, 2018 4:44 PM, "Emmanuel Lécharny"  wrote:
> 
> 
> 
> Le 15/08/2018 à 21:01, Stefan Seelmann a écrit :
>> +1
>>
>> * Verified checksums and signatures
>> * Built source on Linux with OpenJDK 8 and 11-ea25
>> * Run installer tests:
>> * bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24
>> * rpm on Fedora 21 (very old!) with Java 8
>>
>> Note: when starting the server there is output like this:
>> [18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] -
>> ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to
>> handle NameAndOptionalUID normalization with obje...
> 
> Yes, this should be a warning.
> 
> What happens is that the server will load all the schemas, recursively,
> and for each schema, the AT, OC, etc Some of them are loaded before
> the parts they depend on. Each of the attributeTypes and Object classes
> are checked against the registries, and if they don't exist, such an
> error is produced. Then a workaround is applied:
> 
> ...
> entry.addAttribute( attributeType, attributeValue ); //
> Here, we will get an exception
> }
> catch ( Exception e )
> {
> // The attribute does not exist already, create a fake one
> if ( ( schemaManager != null ) && schemaManager.isRelaxed() )
> // Here, we create a fake object waiting for the real one to be loaded
> 
> Later on, when all the schemas has finally been loaded, all those
> temporary objects are discarded, and a global check is done, which means
> if there is some missing AT, OC or anything else, and error will be
> produced.
> 
> Typically, here, an attributeType's super attribute is not yet loaded in
> the registry (apacheDnsDomainName):
> 
> version: 1
> dn:
> m-oid=1.3.6.1.4.1.18060.0.4.2.2.6,ou=attributeTypes,cn=apachedns,ou=schema
> m-singlevalue: TRUE
> m-obsolete: FALSE
> m-description: The domain name of the name server that was the primary
> source of data for this zone
> m-usage: USER_APPLICATIONS
> creatorsname: uid=admin,ou=system
> m-collective: FALSE
> m-oid: 1.3.6.1.4.1.18060.0.4.2.2.6
> m-supattributetype: apacheDnsDomainName
> m-nousermodification: FALSE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
> objectclass: metaAttributeType
> objectclass: metaTop
> objectclass: top
> m-name: apacheDnsSoaMName
> m-equality: caseIgnoreIA5Match
> 
> because attribute files are loaded in an order that is not the one we
> can guaranty. That would be another story if the schema elements were
> not in a distinct file for each one of them.
> 
> I agree there is room for improvement here, typically not storing each
> AT, OC, etc in a separated file, but as a whole in a .schema file, as
> it's done in OpenLDAP. OTOH, that would make the schema update way more
> complex, as we would have to modify the schema file and create a new one
> for each modification, while the way we work allows us to simply update
> one single fle when we modify the schema.
> 
> It's a implementation choice.
> 
> Ideally speaking, we should mute the logs in this case, or make it a
> warning, not a error.
> 
> 
> 

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Ludovic Poitou]

This is typical on Windows, if the file hasn’t been closed and released by
a process… Could be a sign of a bug, or not !

My 2 cents.

Ludo

—
Ludovic Poitou
http://ludopoitou.com

On 16 August 2018 at 06:50:20, Emmanuel Lécharny (elecha...@gmail.com)
wrote:

Hi Lucas,

Yes, Windows is having hard time deleting transient files. This is
visible on jenkins.

Not sure we can do anythig regarding this problem, to me it seems that
there is some kind of temporary lock put of those files, and the
deletion just fails...

Le 16/08/2018 à 06:30, Lucas Theisen a écrit :
> +1
>
> However, test fail on Windows during attempts to delete test files. Not
> sure if that is much of a concern...
>
> [ERROR] Errors:
> [ERROR] JdbmIndexTest.cleanup:127 ▒ IO ERR_17010_UNABLE_DELETE_FILE
> Unable to delete f...
> [ERROR] JdbmRdnIndexTest.cleanup:128 ▒ IO ERR_17010_UNABLE_DELETE_FILE
> Unable to delet...
> [INFO]
> [ERROR] Tests run: 124, Failures: 0, Errors: 2, Skipped: 0
>
>
>
> On Aug 15, 2018 4:44 PM, "Emmanuel Lécharny"  wrote:
>
>
>
> Le 15/08/2018 à 21:01, Stefan Seelmann a écrit :
>> +1
>>
>> * Verified checksums and signatures
>> * Built source on Linux with OpenJDK 8 and 11-ea25
>> * Run installer tests:
>> * bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24
>> * rpm on Fedora 21 (very old!) with Java 8
>>
>> Note: when starting the server there is output like this:
>> [18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] -
>> ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to
>> handle NameAndOptionalUID normalization with obje...
>
> Yes, this should be a warning.
>
> What happens is that the server will load all the schemas, recursively,
> and for each schema, the AT, OC, etc Some of them are loaded before
> the parts they depend on. Each of the attributeTypes and Object classes
> are checked against the registries, and if they don't exist, such an
> error is produced. Then a workaround is applied:
>
> ...
> entry.addAttribute( attributeType, attributeValue ); //
> Here, we will get an exception
> }
> catch ( Exception e )
> {
> // The attribute does not exist already, create a fake one
> if ( ( schemaManager != null ) && schemaManager.isRelaxed() )
> // Here, we create a fake object waiting for the real one to be loaded
>
> Later on, when all the schemas has finally been loaded, all those
> temporary objects are discarded, and a global check is done, which means
> if there is some missing AT, OC or anything else, and error will be
> produced.
>
> Typically, here, an attributeType's super attribute is not yet loaded in
> the registry (apacheDnsDomainName):
>
> version: 1
> dn:
>
m-oid=1.3.6.1.4.1.18060.0.4.2.2.6,ou=attributeTypes,cn=apachedns,ou=schema
> m-singlevalue: TRUE
> m-obsolete: FALSE
> m-description: The domain name of the name server that was the primary
> source of data for this zone
> m-usage: USER_APPLICATIONS
> creatorsname: uid=admin,ou=system
> m-collective: FALSE
> m-oid: 1.3.6.1.4.1.18060.0.4.2.2.6
> m-supattributetype: apacheDnsDomainName
> m-nousermodification: FALSE
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
> objectclass: metaAttributeType
> objectclass: metaTop
> objectclass: top
> m-name: apacheDnsSoaMName
> m-equality: caseIgnoreIA5Match
>
> because attribute files are loaded in an order that is not the one we
> can guaranty. That would be another story if the schema elements were
> not in a distinct file for each one of them.
>
> I agree there is room for improvement here, typically not storing each
> AT, OC, etc in a separated file, but as a whole in a .schema file, as
> it's done in OpenLDAP. OTOH, that would make the schema update way more
> complex, as we would have to modify the schema file and create a new one
> for each modification, while the way we work allows us to simply update
> one single fle when we modify the schema.
>
> It's a implementation choice.
>
> Ideally speaking, we should mute the logs in this case, or make it a
> warning, not a error.
>
>
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [VOTE] Apache DS 2.0.0.AM25 release

[Emmanuel Lécharny]

Le 15/08/2018 à 21:01, Stefan Seelmann a écrit :
> +1
> 
> * Verified checksums and signatures
> * Built source on Linux with OpenJDK 8 and 11-ea25
> * Run installer tests:
> * bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24
> * rpm on Fedora 21 (very old!) with Java 8
> 
> Note: when starting the server there is output like this:
> [18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] -
> ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to
> handle NameAndOptionalUID normalization with obje...


Reviewing the code, I think this is kind of problematic. What happens is
that as soon as an attributeType with syntax NameAndOptionalUid contains
a value that is not an OID, but a name, and that this name is not
already in the registries, then an exception is thrown, and the
attribute is ignored and not added in the resulting entry

That leads to discrepencies, like for this entry :

dn:
m-oid=1.3.6.1.4.1.18060.0.4.2.3.2,ou=objectClasses,cn=apachedns,ou=schema
m-must: apacheDnsIpAddress
m-oid: 1.3.6.1.4.1.18060.0.4.2.3.2
m-obsolete: FALSE
m-supobjectclass: apacheDnsAbstractRecord
m-description: An address A record
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-name: apacheDnsAddressRecord
m-typeobjectclass: STRUCTURAL
creatorsname: uid=admin,ou=system

is not fully read, and we end with an object containing only those
attributes :

dn:
m-oid=1.3.6.1.4.1.18060.0.4.2.3.2,ou=objectClasses,cn=apachedns,ou=schema
m-typeobjectclass: STRUCTURAL
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-oid: 1.3.6.1.4.1.18060.0.4.2.3.2
m-name: apacheDnsAddressRecord
m-description: An address A record
m-obsolete: FALSE
creatorsname: uid=admin,ou=system


As you can see, the 'm-must' and 'm-supobjectclass' attributeType are't
present in the entry.

This is bad...

Note that we can workaround this issue by setting the schema in relaxed
mode, but it's clearly just a workaround, as the invalid values will be
replaced by some stub.

What are the consequences ? Actually, not so much, because we are just
trying to load *all* the schemas and compare their content to the
registries, which has previously been initialized with a *subset* of
those schemas. That's pretty obvious some of the schema elements will be
missing. So we will have a lacking Schema partition in memory and so
far, we are good to go. Except... if we decide to enable a schema, and
to modify it, we wil write a partial version of entries that weren't
loaded fully because of this problem.

Can we solve this issue ? Well, this is not really simple. Ideally
speaking, we should load *all* the schema in a temporary registries, so
that we will never face an issue with some missing attribute (except if
the schema is invalid, of course), and ditch this registries once the
schema LdafPartition has been loaded, and re-create a registries with
just the enabled schema. Or we can also ignore the wrong attributes, to
have a full schema partition.

The first solution is server-side, the second solution requires that we
modify the LDAP API.

I still have to review our options here.

I don't consider that to be a critical issue, because you generally
start the server with the schemas you need, and most of the time, one
does not change the schema while the server is started.

Still, this is something that needs to be fixed.

I'll create a JIRA.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Result, was: [VOTE] Apache DS 2.0.0.AM25 release

[Emmanuel Lécharny]

Hi !

I'm closing this vote, with 5 binding votes :

* Shawn,
* Colm
* Stefan
* Lucas
* me


I will close the nexus repository, update the site, and do the
annoucement this week-end.


FTR, I have done some performance tests on this version, and I found
that writes are now 2 times faster (thanks to operation transactions),
but sadly reads are two times slower :/

I investigated, and I found a pretty stupid thing : we do update the
contextCSN for every read we do :/ This is because a flag is not
properly set when a write is completed. Once thsi flag is turned off,
writes are on pair with what we had on the previous version.

Anyway, expect a new release soon (one month ?) as I intend to make
transaction visible from the client. That would make it possible to
implement a faster bulk load of entries, by starting a transaction,
injecting N entries, and committing, all driven by the client.

In any case, this version should be usable, and I hoep its integration
in Studi will be easy :-)

Thanks for the votes !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys