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: [email protected] 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 <[email protected]> An: Apache Directory Developers List <[email protected]>, 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 <[email protected]> wrote: On Thu, Oct 15, 2015 at 1:57 PM, Stefan Seelmann <[email protected]> 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
