directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Linscheid <Sven.Linsch...@minden.edeka.de>
Subject Antwort: Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Date Fri, 16 Oct 2015 05:41:29 GMT
Great looking forward for the next release to check this against our LDAP 
- Structure - great Stuff here ! 



Mit freundlichen Grüßen 

Sven Linscheid 
Systembetreuung ITSM / IDM

IT-Qualitätsmanagement
EDEKA Minden-Hannover IT-Service GmbH 
Wittelsbacherallee 61, 32427 Minden

Tel.:       +49 571 64660-3707
Fax:       +49 571 64660-3829
E-Mail:   Sven.Linscheid@minden.edeka.de
Web:      www.edeka-minden.de 

EDEKA - Wir ♥ Lebensmittel. 

EDEKA Minden-Hannover IT-Service GmbH 
Sitz der Gesellschaft: Minden 
Amtsgericht Bad Oeynhausen HRB 4532
Geschäftsführer: Ines Parthum-Becker, Gerhard Riechmann, Dietmar Thake

Diese E-Mail enthält vertrauliche und / oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie den Absender und vernichten Sie 
diese E-Mail. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser 
E-Mail ist nicht gestattet. 

Sparen Sie pro Seite ca. 200 ml Wasser, 2 g CO2 und 2 g Holz. EDEKA Minden 
setzt sich für eine nachhaltige Wirtschaftsweise und den schonenden Umgang 
mit Ressourcen ein. Bitte drucken Sie nur, wenn es wirklich notwendig ist. 





Von:    Lucas Theisen <lucastheisen@pastdev.com>
An:     Apache Directory Developers List <dev@directory.apache.org>, 
Datum:  15.10.2015 20:58
Betreff:        Re: [VOTE] Apache LDAP API 1.0.0-M32 release



On Thu, Oct 15, 2015 at 2:32 PM, Lucas Theisen <lucastheisen@pastdev.com> 
wrote:
On Thu, Oct 15, 2015 at 1:57 PM, Stefan Seelmann <mail@stefan-seelmann.de> 
wrote:
On 10/15/2015 07:44 PM, Stefan Seelmann wrote:
> On 10/15/2015 07:26 PM, Lucas Theisen wrote:
>>
>> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think 
it
>> has to do with java version.  I tried turning off firewalld, but no 
dice.
>> Could be SELinux, i could try booting without...
>>
>
> Lucas,
>
> What is the output of `nslookup localhost`?
> And is locahost in your /etc/hosts?
>

So in [1] we see the code that starts the forked JVM. It also starts a
RMI LocateRegistry, I think on localhost.

Then the forked process should also try to connect to that registry,

Here [2] [3] are some other examples where connection to RMI registry
failed.

HTH,
Stefan

[1]
https://github.com/ops4j/org.ops4j.pax.exam2/blob/25d5181a00b2e433537e4b53dce50b8925236bc3/containers/pax-exam-container-forked/src/main/java/org/ops4j/pax/exam/forked/ForkedFrameworkFactory.java#L103

[2]
https://stackoverflow.com/questions/6180383/rmi-registry-connecting-to-wrong-adress

[3]
http://knowledgebase.progress.com/articles/Article/AdminServerattemptstobindtothewrongIPAddress

Soooooo.  Thanks Stefan, the stackoverflow solution pointed out that the 
RMI registry gets the the hostname as follows:

java.net.InetAddress.getLocalHost().getHostAddress();

And from the javadoc [1]:

Returns the address of the local host. This is achieved by retrieving
 the name of the host from the system, then resolving that name into
 an InetAddress.

The key part here is the "resolving that name".  At the top of the javadoc 
page for InetAddress in the general comments we see:

Host name-to-IP address resolution is accomplished through
 the use of a combination of local machine configuration information
 and network naming services such as the Domain Name System (DNS)
 and Network Information Service(NIS).

This means that if you are using a machine whose "name of the host from 
the system" is NOT registered by name in the "local machine configuration" 
then it will attempt to look it up on a "network naming service".  If, 
like me, your name is not registered in your configured "network naming 
service", then the behavior is undefined.  In my case it was getting 
redirected by my ISP (Verizon FIOS), who sends any name it cannot resolve 
to the Non Existent Domain provider "barefruit" with IP address 
92.242.140.21.  This is then used as the IP address of localhost rather 
than the loopback interface.  This seems like a really dangerous way to 
run unit tests...  It seems like bad behavior all around.  First, the DNS 
server resolving that way is COMPLETELY wrong, but they love their 
advertisement.  Second, java's getLocalHost() method not confirming that 
the IP resolution from the "network naming service" is an IP of a local 
interface (after all, the method is NAMED getLocalHost).  And, third, 
using getLocalHost() with this being the behavior is inherently dangerous 
(as request to connect to a service you think is on your localhost is 
getting sent somewhere else).

Anyway, I can resolve this build issue by adding my hostname to 
/etc/hosts, but we should probably consider switching away from using 
InetAddress.getLocalHost().

Lucas


On a side note, i submitted a bug to the PAX folks [1] to avoid using 
getLocalHost().

Also, I finished the build succesfully, so:

+1 for release.

[1]https://ops4j1.jira.com/browse/PAXEXAM-740


Mime
View raw message