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
