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 07:30:45 GMT
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.

What you have found confirm that the Java update I did causes the test
to fail on Mac. This is worrysome though, because the KrbPrincipalName
stored in the entry is hard wired. OTOH, it's an extremely wrong thing
to have a kerberosPrincipal containing localhost (except for tests...)


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


Mime
View raw message