directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: ApacheDS and Java 6 build pb
Date Wed, 22 May 2013 08:41:24 GMT
Le 5/22/13 9:30 AM, Emmanuel Lécharny a écrit :
> Le 5/22/13 9:20 AM, Stefan Seelmann a écrit :
>> On 21.05.2013 01:31, Emmanuel Lécharny wrote:
>>> Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
>>>> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>>>>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>>>>> Hi Emmanuel,
>>>>>>
>>>>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>>>>> So the problem appears to be that we create an entry which 
>>>>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some
unknown
>>>>>>> reason, we are looking for an entry which kerberos principal
is
>>>>>>> ldap/localhost@EXAMPLE.COM.
>>>>>>>
>>>>>>> It looks like that there is some name resolution occuring somewhere
on
>>>>>>> Mac OSX... Either we don't store the correct KerberosPrincipal,
or we
>>>>>>> have a conversion we don't asked for.
>>>>>>>
>>>>>>> I'm investigating...
>>>>>>>
>>>>>> Please check the constructor of SaslBindIT. I remember that I added
some
>>>>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>>>>> 7 made some trouble.
>>>>> Yes, saw that.
>>>>>
>>>>> I just committed some code that fixes the issue on Mac OSX, it would
be
>>>>> cool to check if it still works on windows and linux !
>>>>> See
>>>>>
>>>>> http://svn.apache.org/r1484387
>>>>>
>>>> On Windows two GSSAPI SASL bind tests fail:
>>>> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>>>>
>>>>
>>>> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
>>>> debug into TicketGrantingService,getRequestPrincipalEntry() the
>>>> tgsContext.getRequest().getKdcReqBody().getSName() contains
>>>> "localhost.localdomain". I checked my /etc/hosts and there I have the
>>>> following entry:
>>>>
>>>>     127.0.0.1	localhost.localdomain	localhost
>>>>
>>>>
>>>> When I change that entry to the following the test works.
>>>>
>>>>     127.0.0.1	localhost
>>>>
>>>>
>>>> When I revert your commit the test also works as
>>>> InetAddress.getByName("127.0.0.1").getHostName() returns
>>>> "localhost.localdomain"
>>>>
>>>>
>>>> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
>>> Here is what I have :
>>>
>>> 127.0.0.1       localhost
>>>
>>>> More important: Somewhere in the production code the IP 127.0.0.1 is
>>>> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
>>>> Where does that happen? Does the KRB client does that and sends the
>>>> resolved name to the server? Or does the server resolve the name when a
>>>> connection is made? In the end the principal name contains
>>>> "localhost.localdomain". I think to have a stable test the test setup
>>>> needs to use the same mechanism to lookup the hostname as the production
>>>> code.
>>> The thing is that I think that the conversion to ldaphost is done
>>> internaly but some of the JDK code. It was working fine before I
>>> upgraded my JVM.
>> I found the place where the DNS lookup is done, it is in an JDK internal
>> class sun.security.krb5.PrincipalName. I changed the test again, now it
>> creates a KerberosPrincipal which internally calls the code and does the
>> DNS lookup. I started a Windows build on Jenkins, let's see if it works
>> there. Can you please also check if this works on your machine? If not
>> feel free to rollback.
> Running tests while I take my shower.

Works like a charm (except a failure in the middle on
CollectiveAttributeServiceIT tests :/)

I hate this issue. It's probably related to some pb with the cache we
use to manage Administrative model... It's really hard to investigate,
because it only happens randomly, and not frequently :/


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


Mime
View raw message