Full_Name: Pierre Schweitzer Version: 2.4.40 OS: Ubuntu LTS 12.04.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.95.158) Hi, We are currently facing an issue with Jira 6.0.8 while interfacing it with OpenLDAP. When loging in, Jira attempts to query the following attributes: "uid mail sn givenName displayName objectClass javaSerializedData javaClassName javaFactory javaCodeBase javaReferenceAddress javaClassNames javaRemoteLocation" Unfortunately, javaRemoteLocation isn't in java.schema and appears to be deprecated. OpenLDAP replies with (ldapsearch result): # search result search: 2 result: 65 Object class viatation Seen from OpenLDAP logs: Apr 22 13:09:27 rose-java slapd[25272]: conn=1177 op=2 SEARCH RESULT tag=101 err=65 nentries=0 text= According to Jira support, this is an incorrect behavior from OpenLDAP, not matching the LDAP RFCs. Quoting them: "OpenLDAP should not be returning an error when querying for javaRemoteLocation, even if it is deprecated." If required for testing, we can provide more details such as Jira queries. Cheers,
First, the issue tracker is not for usage questions. Please redirect your question to openldap-technical mailing list. On 2015-06-03 10:47, pierre@reactos.org wrote: > Unfortunately, javaRemoteLocation isn't in java.schema and appears to > be > deprecated. > > OpenLDAP replies with (ldapsearch result): > # search result > search: 2 > result: 65 Object class viatation > Seen from OpenLDAP logs: > Apr 22 13:09:27 rose-java slapd[25272]: conn=1177 op=2 SEARCH RESULT > tag=101 > err=65 nentries=0 text= > > According to Jira support, this is an incorrect behavior from OpenLDAP, > not > matching the LDAP RFCs. Quoting them: "OpenLDAP should not be returning > an error > when querying for javaRemoteLocation, even if it is deprecated." I can confirm that OpenLDAP works correctly in this regard. You did not post the accompanying SEARCH log line with filter and scope. You should check that. Ciao, Michael.
This is not a question, but really a bug report about a broken behavior. I quote them again: "Potentially, OpenLDAP should have a bug raised to make it impossible to get into a situation where error 65 is returned on a query, as it likely does not conform to the RFC." Here is the log extract you're asking for (I just filtered out the base DN): Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis spiter))" Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH attr=javaRemoteLocation Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT tag=101 err=65 nentries=0 text= On 06/03/2015 11:10 AM, Michael Ströder wrote: > First, the issue tracker is not for usage questions. Please redirect > your question to openldap-technical mailing list. > > On 2015-06-03 10:47, pierre@reactos.org wrote: >> Unfortunately, javaRemoteLocation isn't in java.schema and appears to be >> deprecated. >> >> OpenLDAP replies with (ldapsearch result): >> # search result >> search: 2 >> result: 65 Object class viatation >> Seen from OpenLDAP logs: >> Apr 22 13:09:27 rose-java slapd[25272]: conn=1177 op=2 SEARCH RESULT >> tag=101 >> err=65 nentries=0 text= >> >> According to Jira support, this is an incorrect behavior from >> OpenLDAP, not >> matching the LDAP RFCs. Quoting them: "OpenLDAP should not be >> returning an error >> when querying for javaRemoteLocation, even if it is deprecated." > > I can confirm that OpenLDAP works correctly in this regard. > You did not post the accompanying SEARCH log line with filter and scope. > You should check that. > > Ciao, Michael. > -- Pierre Schweitzer <pierre@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.
On 2015-06-03 11:20, Pierre Schweitzer wrote: > This is not a question, but really a bug report about a broken > behavior. Again: I can confirm that requesting an attribute which does not exist in the subschema does not affect whether an entry is returned. > I quote them again: "Potentially, OpenLDAP should have a bug raised to > make it impossible to get into a situation where error 65 is returned > on > a query, as it likely does not conform to the RFC." Again: This statement is right and AFACIS OpenLDAP always worked correctly. > Here is the log extract you're asking for (I just filtered out the base > DN): > Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX" > scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis > spiter))" > Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH > attr=javaRemoteLocation > Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT > tag=101 err=65 nentries=0 text= Up to now there's absolutely no evidence in the information you provided that this is a bug. How did you make sure that an entry should be returned for exactly this search with the bound identity and your configuration? I suspect a configuration or data error on your side. Many things can be wrong. Without seeing your config, data and the bound identity nobody can track this down for you. Ciao, Michael.
On 06/03/2015 11:47 AM, Michael Ströder wrote: > On 2015-06-03 11:20, Pierre Schweitzer wrote: >> This is not a question, but really a bug report about a broken behavior. > > Again: > I can confirm that requesting an attribute which does not exist in the > subschema does not affect whether an entry is returned. > >> I quote them again: "Potentially, OpenLDAP should have a bug raised to >> make it impossible to get into a situation where error 65 is returned on >> a query, as it likely does not conform to the RFC." > > Again: This statement is right and AFACIS OpenLDAP always worked correctly. OK, so you confirm that what we see here is an incorrect behavior. >> Here is the log extract you're asking for (I just filtered out the >> base DN): >> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX" >> scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis spiter))" >> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH >> attr=javaRemoteLocation >> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT >> tag=101 err=65 nentries=0 text= > > Up to now there's absolutely no evidence in the information you provided > that this is a bug. > > How did you make sure that an entry should be returned for exactly this > search with the bound identity and your configuration? > > I suspect a configuration or data error on your side. Many things can be > wrong. > Without seeing your config, data and the bound identity nobody can > track this down for you. One technical information that would make sense: we are using the SQL backend. I've just checked, there's some attributes management in backend code, and the issue *may* come from this. The Atlassian support cannot reproduce the error with "out-of-the-box" OpenLDAP server not using SQL backend. I will setup a dedicated test env for this issue so that I can more easily track & debug the issue. I'll come back at you when I've more information (or even a patch). -- Pierre Schweitzer <pierre@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.
Finally, some more information thanks to the testing env. It seems that the SQL backend is indeed responsible for this and apparently makes OpenLDAP no longer RFC-compliant. You'll find the log extract from the server here: https://www3.heisspiter.net/query_uid https://www3.heisspiter.net/query_javaRemoteLocation https://www3.heisspiter.net/query_javaCodeBase The first one is the query of the uid attribute which exists and returns fine. The second one is the query of the javaRemoteLocation attribute which doesn't exist and thus, doesn't return fine. The third one is the query of the javaCodeBase attribute which exists in schema but that we don't use at all but returns fine. The guilty function *might* be backsql_get_attr_vals() which is the last one called, raising the error. On 06/03/2015 01:47 PM, Pierre Schweitzer wrote: > On 06/03/2015 11:47 AM, Michael Ströder wrote: >> On 2015-06-03 11:20, Pierre Schweitzer wrote: >>> This is not a question, but really a bug report about a broken behavior. >> >> Again: >> I can confirm that requesting an attribute which does not exist in the >> subschema does not affect whether an entry is returned. >> >>> I quote them again: "Potentially, OpenLDAP should have a bug raised to >>> make it impossible to get into a situation where error 65 is returned on >>> a query, as it likely does not conform to the RFC." >> >> Again: This statement is right and AFACIS OpenLDAP always worked correctly. > > OK, so you confirm that what we see here is an incorrect behavior. > >>> Here is the log extract you're asking for (I just filtered out the >>> base DN): >>> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX" >>> scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis spiter))" >>> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH >>> attr=javaRemoteLocation >>> Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT >>> tag=101 err=65 nentries=0 text= >> >> Up to now there's absolutely no evidence in the information you provided >> that this is a bug. >> >> How did you make sure that an entry should be returned for exactly this >> search with the bound identity and your configuration? >> >> I suspect a configuration or data error on your side. Many things can be >> wrong. >> Without seeing your config, data and the bound identity nobody can >> track this down for you. > > One technical information that would make sense: we are using the SQL > backend. I've just checked, there's some attributes management in > backend code, and the issue *may* come from this. > The Atlassian support cannot reproduce the error with "out-of-the-box" > OpenLDAP server not using SQL backend. > > I will setup a dedicated test env for this issue so that I can more > easily track & debug the issue. I'll come back at you when I've more > information (or even a patch). > -- Pierre Schweitzer <pierre@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.
pierre@reactos.org wrote: > This is a cryptographically signed message in MIME format. > > --------------ms070202050304000100090907 > Content-Type: text/plain; charset=windows-1252 > Content-Transfer-Encoding: quoted-printable > > Finally, some more information thanks to the testing env. > > It seems that the SQL backend is indeed responsible for this and > apparently makes OpenLDAP no longer RFC-compliant. back-sql currently has no maintainer and is not recommended for use. The primary database backends are back-bdb,hdb, and mdb. All of these are RFC-compliant. > You'll find the log extract from the server here: > https://www3.heisspiter.net/query_uid > https://www3.heisspiter.net/query_javaRemoteLocation > https://www3.heisspiter.net/query_javaCodeBase > > The first one is the query of the uid attribute which exists and returns > fine. > The second one is the query of the javaRemoteLocation attribute which > doesn't exist and thus, doesn't return fine. > The third one is the query of the javaCodeBase attribute which exists in > schema but that we don't use at all but returns fine. > > The guilty function *might* be backsql_get_attr_vals() which is the last > one called, raising the error. > > On 06/03/2015 01:47 PM, Pierre Schweitzer wrote: >> On 06/03/2015 11:47 AM, Michael Str=F6der wrote: >>> On 2015-06-03 11:20, Pierre Schweitzer wrote: >>>> This is not a question, but really a bug report about a broken behavi= > or. >>> >>> Again: >>> I can confirm that requesting an attribute which does not exist in the= > >>> subschema does not affect whether an entry is returned. >>> >>>> I quote them again: "Potentially, OpenLDAP should have a bug raised t= > o >>>> make it impossible to get into a situation where error 65 is returned= > on >>>> a query, as it likely does not conform to the RFC." >>> >>> Again: This statement is right and AFACIS OpenLDAP always worked corre= > ctly. >> =20 >> OK, so you confirm that what we see here is an incorrect behavior. >> =20 >>>> Here is the log extract you're asking for (I just filtered out the >>>> base DN): >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D= > "XXXX" >>>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dh= > eis spiter))" >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH >>>> attr=3DjavaRemoteLocation >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESU= > LT >>>> tag=3D101 err=3D65 nentries=3D0 text=3D >>> >>> Up to now there's absolutely no evidence in the information you provid= > ed >>> that this is a bug. >>> >>> How did you make sure that an entry should be returned for exactly thi= > s >>> search with the bound identity and your configuration? >>> >>> I suspect a configuration or data error on your side. Many things can = > be >>> wrong. >>> Without seeing your config, data and the bound identity nobody can >>> track this down for you. >> =20 >> One technical information that would make sense: we are using the SQL >> backend. I've just checked, there's some attributes management in >> backend code, and the issue *may* come from this. >> The Atlassian support cannot reproduce the error with "out-of-the-box" >> OpenLDAP server not using SQL backend. >> =20 >> I will setup a dedicated test env for this issue so that I can more >> easily track & debug the issue. I'll come back at you when I've more >> information (or even a patch). >> =20 > > > --=20 > Pierre Schweitzer <pierre@reactos.org> > System & Network Administrator > Senior Kernel Developer > ReactOS Deutschland e.V. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 06/03/2015 03:52 PM, Howard Chu wrote: > pierre@reactos.org wrote: >> This is a cryptographically signed message in MIME format. >> >> --------------ms070202050304000100090907 >> Content-Type: text/plain; charset=windows-1252 >> Content-Transfer-Encoding: quoted-printable >> >> Finally, some more information thanks to the testing env. >> >> It seems that the SQL backend is indeed responsible for this and >> apparently makes OpenLDAP no longer RFC-compliant. > > back-sql currently has no maintainer and is not recommended for use. > The primary database backends are back-bdb,hdb, and mdb. All of these > are RFC-compliant. Unfortunately, these backends are not matching our use-case... I'll try to see whether I can (hack)fix it, even though, I'm not used to LDAP nor to OpenLDAP. And regarding my previous mail, the failing call is actually the call to structural_class() at line 1057 of entry-id. -- Pierre Schweitzer <pierre@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.
pierre@reactos.org wrote: > It seems that the SQL backend is indeed responsible for this and > apparently makes OpenLDAP no longer RFC-compliant. Simply don't use back-sql. And next time please provide exact config information. Ciao, Michael.
back-sql is experimental and broken in many respects
changed notes moved from Incoming to Software Bugs
patches welcome