http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36649 <pre>Richard Lowden created DIRSERVER-1727: ----------------------------------------- Summary: LDAP Searches against boolean attributes with booleanMatch equality never return matches Key: DIRSERVER-1727 URL: https://issues.apache.org/jira/browse/DIRSERVER-1727 Project: Directory ApacheDS Issue Type: Bug Affects Versions: 2.0.0-M6 Reporter: Richard Lowden If you carry out a search trying to match on a boolean attribute (syntax: 1.3.6.1.4.1.1466.115.121.1.7) and an equality matching rule of booleanMatch then searching for classes with the attribute value equalling TRUE or FALSE never return results. Changing the equality matching rule on the attribute to caseIgnoreMatch will return results. Used to work in 1.5.7 but no longer works in 2.0.0-M6. To recreate try searching ober the ou=config entry for "ads-enabled = TRUE" as per the example below from the search logs, which should return "ads-directoryServiceId=default,ou=conf</pre> Richard Lowden (JIRA 2012-05-16T15:39:02 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36648 <pre>Aleks M created DIRSTUDIO-814: --------------------------------- Summary: eDirectory networkAddress attribute Key: DIRSTUDIO-814 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-814 Project: Directory Studio Issue Type: Improvement Affects Versions: 2.0.0-M3 Reporter: Aleks M Priority: Minor It seems that the eDirectory networkAddress attribute is hard for Studio to read. There are several more attributes that use the same syntax (2.16.840.1.113719.1.1.5.1.12) When looking at a ncpServer object (objectClass=ncpServer) it has several values in that attribute. Studio displays them pretty well, they look like this: 13#l d a p : / / 1 7 2 . 1 6 . 2 4 2 . 7 4 : 6 3 6 Notice the space between each character. I believe its a \u0000 but I'm 100% sure. Anyway selecting a value and pressing CTRL+C gives me: 13#l I.e. only the first four characters up to the first "space". If I double click the value to edit it the</pre> Aleks M (JIRA 2012-05-16T15:11:03 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36647 <pre>Aleks M created DIRSTUDIO-813: --------------------------------- Summary: Add default value editors for eDirectory Key: DIRSTUDIO-813 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-813 Project: Directory Studio Issue Type: Improvement Affects Versions: 2.0.0-M3 Reporter: Aleks M Priority: Minor Is it possible for Studio to open these eDirectory attributes in the correct editor by default so that I don't have to add them manually to Studio preferences on each computer? GUID = Entry UUID Editor userCertificate = Certificate Editor nDSPKIPublicKeyCertificate = Certificate Editor cACertificate = Certificate Editor ndsCrossCertificatePair = Certificate Editor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.a</pre> Aleks M (JIRA 2012-05-16T14:57:02 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36646 <pre>Aleks M created DIRSTUDIO-812: --------------------------------- Summary: Error while performing search Key: DIRSTUDIO-812 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-812 Project: Directory Studio Issue Type: Bug Affects Versions: 2.0.0-M3 Environment: Windows 7 SP1 64-bit Reporter: Aleks M I've come across a a directory where they have alot of objects named with #, e.g. 12345678911#38SA Sometimes the LDAP search fails in Studio while it works in other tools. If I search for something like this: (workforceID=200511230101) I should get two DNs back, Studio failes after retrieving the first one named 200511230101, the other is named 200511230101#38SA and Studio gives me this error: Error while performing search - expecting EOF, found '38' org.apache.directory.shared.ldap.model.exception.LdapInvalidDnException: expecting EOF, found '38' at org.apache.directory.shared.ldap.model.name.ComplexDnParser.par</pre> Aleks M (JIRA 2012-05-16T14:51:02 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36645 <pre> [ https://issues.apache.org/jira/browse/DIRSERVER-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13276745#comment-13276745 ] Emmanuel Lecharny commented on DIRSERVER-1724: ---------------------------------------------- What is strange is that the test I have added into the Ldap-client tests works, even for substring searches : http://svn.apache.org/viewvc/directory/apacheds/trunk/ldap-client-test/src/test/java/org/apache/directory/shared/client/api/operations/search/OperationWithIndexTest.java?view=markup Check the testModify() test, where you can find : 262 connection.modify( dn, new DefaultModification( ModificationOperation.REPLACE_ATTRIBUTE, "displayName", "test" ) ); 263 264 results = connection.search("dc=example,dc=com", "(displayName=t*)", SearchScope.SUBTREE, "*" ); 265 266 while ( results.next() ) 267 { 268 Entry result = results.get(); 269 assertTrue( result.contains( "displayName", "test" ) ); 270 } -- This me</pre> Emmanuel Lecharny (JIRA 2012-05-16T13:59:02 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36644 <pre>Richard Lowden created DIRSERVER-1726: ----------------------------------------- Summary: DefaultPasswordValidator always throws PasswordPolicyException when consecutive non-letter chars are in RDN Key: DIRSERVER-1726 URL: https://issues.apache.org/jira/browse/DIRSERVER-1726 Project: Directory ApacheDS Issue Type: Bug Affects Versions: 2.0.0-M6 Reporter: Richard Lowden When adding an entry with a userPassword attribute and the entry RDN contains two non-letter characters in a row (such as cn=test1-EHIbwFwGAZ1BDgjK7y7TUQ&lt; at &gt;public.gmane.org) then a CONSTRAINT_VIOLATION error is always received with the message "Password shouldn't contain parts of the username" regardless of what password you enter. If you remove the "1" character or the "&lt; at &gt;" character then the entry will be created successfully Believe the issue is caused by the regex expressions used within org.apache.directory.server.core.authn.ppolicy.DefaultPasswordVali</pre> Richard Lowden (JIRA 2012-05-16T13:39:02 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36643 <pre> [ https://issues.apache.org/jira/browse/DIRSERVER-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13276714#comment-13276714 ] Carlo Accorsi commented on DIRSERVER-1724: ------------------------------------------ This issue is limited to a substring search. As you can see from the results below (displayName=Index, Test) yields a result, while (displayName=Index, Tes*) does not. Is there any way to explain this? Am i doing something wrong? #!SEARCH REQUEST (130) OK #!CONNECTION ldap://10.1.2.112:10389 #!DATE 2012-05-16T08:56:25.248 # LDAP URL : ldap://10.1.2.112:10389/ou=users,ou=int,o=cpro?hasSubordinates,objectClass?one?(displayName=Index,%20Test) # command line : ldapsearch -H ldap://10.1.2.112:10389 -x -D "uid=admin,ou=system" -W -b "ou=users,ou=int,o=cpro" -s one -a always -z 1000 "(displayName=Index, Test)" "hasSubordinates" "objectClass" # baseObject : ou=users,ou=int,o=cpro # scope : singleLevel (1) # derefAliases : derefAlways (3) # s</pre> Carlo Accorsi (JIRA 2012-05-16T13:03:02 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36642 <pre>Josef Cacek created DIRKRB-85: --------------------------------- Summary: &lt; at &gt;CreateKdcServer should include searchBaseDn attribute Key: DIRKRB-85 URL: https://issues.apache.org/jira/browse/DIRKRB-85 Project: Directory Kerberos Issue Type: Bug Reporter: Josef Cacek Assignee: Emmanuel Lecharny Priority: Critical CreateKdcServer annotation doesn't contain searchBaseDn, so the KdcServer instance created by calling org.apache.directory.server.factory.ServerAnnotationProcessor.getKdcServer(DirectoryService, int) can't be used for domain other than "example.com". The KdcServer created from &lt; at &gt;CreateKdcServer configuration searches users always in "ou=users,dc=example,dc=com" (see to KdcServer constructor). For a LDAP server it's possible to change the search domain after the retrieving an instance from ServerAnnotationProcessor, but it doesn't work for the KdcServer, because the original value is already stored</pre> Josef Cacek (JIRA 2012-05-16T08:55:02 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36641 <pre>hi Göktürk, I'll check that tonite. I'm a bit on hold atm, dealing with some familly stuff. thanks Le 16 mai 2012 05:58, "Göktürk Gezer" &lt;gokturk.gezer-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; a écrit : </pre> Emmanuel Lecharny 2012-05-16T06:44:05 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36640 <pre>Hi Everyone, As i told you in OSGI branch update, JDBM is so immutable in runtime. Almost every setter calls checkInitialized() method first which throws an exception when its already initialized. We have to change that behavior in as much aspects of it as we can. Otherwise there is no point in going into OSGI. However i can't always be sure what my changes might lead on runtime. I need some serious help here, especially from those are actively working on JDBM, otherwise i'll jump into trial and error cycle which will probably last long. Here is the current configuration points for JdbmPartition: - cacheSize(int) - optimizerEnabled(boolean) - partitionPath(File) - suffixDn(Dn) - syncOnWrite(boolean) - indexedAttributes(List&lt;Index&gt;) Currently none of them is reconfigurable, once the partition is initialized. However i need to know which are actually reconfigurable among these ones. And which are not really reconfigurable and why? Every reconfiguration will invoke some setter method at </pre> Göktürk Gezer 2012-05-16T03:58:10 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36639 <pre> [ https://issues.apache.org/jira/browse/DIRSERVER-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13275907#comment-13275907 ] Carlo Accorsi commented on DIRSERVER-1724: ------------------------------------------ BTW, displayName is an indexed attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Carlo Accorsi (JIRA 2012-05-15T16:07:06 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36638 <pre> [ https://issues.apache.org/jira/browse/DIRSERVER-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13275900#comment-13275900 ] Carlo Accorsi commented on DIRSERVER-1724: ------------------------------------------ Hi, yes I rebuilt everything from scratch from the trunk yesterday. Still cannot search after modification. I'm limiting my testing to Apache Directory Studio. Version: 1.5.3.v20100330 Here is the log of my modification. #!RESULT OK #!CONNECTION ldap://10.1.2.112:10389 #!DATE 2012-05-15T11:23:51.400 dn: uid=1337085976640,ou=users,ou=int,o=cpro changetype: modify replace: displayName displayName: CATest User New A couple mins later, I try and search for 'CATest*' and there are no results. Is there an internal timeout for searching? Is there a parameter for this? If I dump the user out (ldif) and re-import, I can find it via search. #!SEARCH REQUEST (146) OK #!CONNECTION ldap://10.1.2.112:10389 #!DATE 2012-05-15T11:26:23.495 # LDAP URL : ld</pre> Carlo Accorsi (JIRA 2012-05-15T15:51:47 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36637 <pre>Good luck. Thanks for the heads up Emm. On Tue, May 15, 2012 at 12:21 PM, Emmanuel Lécharny &lt;elecharny-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;wrote: </pre> Alex Karasulu 2012-05-15T09:58:16 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36636 <pre>Hi guys, just FYI, I'm currently trying to merge the txn branch into trunk. Not sure Il'll be able to do it completely today, but I'll try. Thanks ! </pre> Emmanuel Lécharny 2012-05-15T09:21:59 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36635 <pre></pre> houmles (JIRA 2012-05-15T07:24:44 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36634 <pre></pre> Emmanuel Lecharny (JIRA 2012-05-14T22:08:33 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36633 <pre> [ https://issues.apache.org/jira/browse/DIRSERVER-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13274761#comment-13274761 ] Emmanuel Lecharny commented on DIRSERVER-1724: ---------------------------------------------- Is this against the trunk ? Have you tried against the latest released version (ie 2.0.0-M7, available here : http://people.apache.org/~elecharny/). ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Emmanuel Lecharny (JIRA 2012-05-14T17:13:53 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36632 <pre> [ https://issues.apache.org/jira/browse/DIRSERVER-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13274729#comment-13274729 ] Carlo Accorsi commented on DIRSERVER-1724: ------------------------------------------ To clarify 'modification' this was done two ways. Manually editing the value in the using the Apache Studio and programatically with the JNDI javax.naming.ldap.LdapContext interface. Subsequent searches for the new value return no result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Carlo Accorsi (JIRA 2012-05-14T16:39:50 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36631 <pre>This vote has closed: 72 hours are up. Emmanuel is dealing with some family related matters and Pierre is on vacation so I'm closing it on Emmanuel's behalf. +1 binding votes --------------------- Alex Karasulu Pierre A. Marcelot Felix Knecht Kiran Ayyagari Thanks Emmanuel for your hard work. This release was not the easiest one due to the various issues that popped up. On Fri, May 11, 2012 at 1:12 PM, Emmanuel Lécharny &lt;elecharny-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;wrote: </pre> Alex Karasulu 2012-05-14T09:31:13 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36630 <pre>[X] +1 | Release Apache Directory Server 2.0.0-M7 thanks Emmanuel On Sun, May 13, 2012 at 10:51 AM, Felix Knecht &lt;felixk-1oDqGaOF3Lkdnm+yROfE0A&lt; at &gt;public.gmane.org&gt; wrote: </pre> Kiran Ayyagari 2012-05-13T06:08:11 http://permalink.gmane.org/gmane.comp.apache.incubator.directory.devel/36629 <pre> Regards Felix </pre> Felix Knecht 2012-05-13T05:21:22 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.incubator.directory.devel