SsaslGssapiBind test failure problem identified

[Richard Feezel <rf...@gmail.com>]

On Thu, Aug 12, 2010 at 10:51 AM, Emmanuel Lecharny <el...@gmail.com>wrote:

>  On 8/12/10 4:24 PM, feezelr@gdls.com wrote:
>
>> Gentlemen,
>>
> Hi,
>
>  My home system is Fedora Core 13 Linux with the Sun JDK 1.6_20,
>> Subversion, Maven 2.2.1, and Eclipse 3.6 installed.
>>
> Perfect.
>
>  Back at a command prompt I tried running the following to make sure
>> everything was working.
>>
>> 4)      "mvn test"
>>
>> Only one test "testSaslGssapiBind" is failing, and, looking at the test
>> code, it appears that the author doesn't expect this one to work yet.
>>
> Strange. All the tests are passing on our linux machines.
>
> Have you tried mvn clean install -Dintegration ?


I have not tried that.  I don't know how that differs from not specifying
"integration".

However, after looking at the error I was getting which indicated that the
LDAP service principle wasn't being found I set "sun.security.krb5.debug" to
"true".  This didn't help much so I put a breakpoint in the TGS service code
and stepped through it.  The service principle being requested is "ldap/
richard.feezel.net@EXAMPLE.COM" rather than "ldap/localhost@EXAMPLE.COM".
 I'm guessing the switch is being made in the sun code for some reason,
probably in some obscure way related to the configuration of my machine
(which is named "richard.feezel.net").

I just discovered the source of the problem... In my etc/hosts file, on the
127.0.0.1 line the name richard.feezel.net was listed first.  I moved
"localhost" to be the first name on the line and the error is gone.


>  At my day job I have a Windows XP SP-3 with Sun JDK 1.6_17, Maven 2.2.1,
>> Subversion, and Eclipse 3.6 installed.
>>
>> Access to the Internet from this system is restricted to using an HTTP
>> proxy that requires NTLM authentication.
>>
> Thanks a lot, M$ ...
>

It's an on-going source of frustration.


> <snip/>
>
>  Again the same three steps mentioned above were completed successfully
>> (despite the erratic operation of the proxy server).
>>
>> When I tried "mvn test", however, I got several failures.
>>
>> One of the failures, "testSaslGssapiBind", is the same as on Linux.  For
>> now I'm assuming this is a known problem that is being worked on.
>>
>> Using Eclipse to investigate each of the others I've discovered that two
>> of them are related to Windows's use of the "\" character as the path
>> separator and one is related to incorrect handling of "escaping" of
>> characters in filenames.  I'm developing fixes for these issues now and
>> will post suggested patches after I complete testing.
>>
> Great ! We don't use W$ at all, so it's likely we have some tests failure
> if we are not cautious enough. That's the price to pay for being
> efficient...


I realized after writing this morning that there are other tests failing as
well on XP.  Yesterday I had only been running "mvn test" in the
trunk/apacheds directory.  When run in the "trunk" directory there are other
problems.

I will investigate the errors on Windows as I have time but it won't be a
priority.


>  The only remaining test failure, is "testSearchUTF8" in
>> "ClientSearchRequestTest" which is not throwing the expected Exception.  I
>> haven't investigated this one yet but plan to when time is available.
>>
>
> Hmmmm... I don't find this class. In which module did you found it ?


It's in "ldap-client-test"

-- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Thanks once again for responding to the queries of a stumbling beginner.

-- 
Richard M Feezel
rfeezel@gmail.com

Re: SsaslGssapiBind test failure problem identified

[Emmanuel Lécharny <el...@apache.org>]

  On 8/13/10 7:15 AM, Richard Feezel wrote:
> On Thu, Aug 12, 2010 at 10:51 AM, Emmanuel Lecharny<el...@gmail.com>wrote:
>
>> Strange. All the tests are passing on our linux machines.
>>
>> Have you tried mvn clean install -Dintegration ?
>
> I have not tried that.  I don't know how that differs from not specifying
> "integration".
It's running what we call 'integration tests'. Not sure if it's still a 
good idea to have separate them from so called 'normal test', but 
anyway. Let me explain : we have tests name xxxITest.java which are 
activated via the integration maven's profile, so it's important to run 
it when testing after a commit.

In your case, it should not make ny difference, but see below for some 
more comment...
> However, after looking at the error I was getting which indicated that the
> LDAP service principle wasn't being found I set "sun.security.krb5.debug" to
> "true".  This didn't help much so I put a breakpoint in the TGS service code
> and stepped through it.  The service principle being requested is "ldap/
> richard.feezel.net@EXAMPLE.COM" rather than "ldap/localhost@EXAMPLE.COM".
>   I'm guessing the switch is being made in the sun code for some reason,
> probably in some obscure way related to the configuration of my machine
> (which is named "richard.feezel.net").

> I just discovered the source of the problem... In my etc/hosts file, on the
> 127.0.0.1 line the name richard.feezel.net was listed first.  I moved
> "localhost" to be the first name on the line and the error is gone.
Yeah, this is a side effect. I think we should analyze further this part 
of the code. Kerberos needs love, here...
>
> I realized after writing this morning that there are other tests failing as
> well on XP.  Yesterday I had only been running "mvn test" in the
> trunk/apacheds directory.  When run in the "trunk" directory there are other
> problems.
You *have* to feed your maven repo with shared jars before being able to 
build the server itself. Building the apacheds module alone won't work.

Now, that does not mean you don't have issues on window$

If you get some errors on W$, the best would be to create a JIRA with a 
copy of the logs, so that we know there is something broken.

JIRA is the long memory of this project, it's way better than mails !

> I will investigate the errors on Windows as I have time but it won't be a
> priority.
>
>
>>   The only remaining test failure, is "testSearchUTF8" in
>>> "ClientSearchRequestTest" which is not throwing the expected Exception.  I
>>> haven't investigated this one yet but plan to when time is available.
>>>
>> Hmmmm... I don't find this class. In which module did you found it ?
>
> It's in "ldap-client-test"
Ok found it. I have to investigate this one, it's very likely that I've 
injected a wrong filter, which will only work on my computer, where my 
local encoding should be different than yours (I'm not using ISO-8859).

I will have a look at it.


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