Re: [Pharo-dev] [Pharo3] The last test failing...

[btc]

Marcus Denker wrote: On 09 Jan 2014, at 17:29, b...@openinworld.com wrote: Marcus Denker wrote: 12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377 And this is just a build server artefact… (windows slave firewall problem). I wonder what to do… maybe we could just skip it on windows when running on the build slave ;-) Marcus Was the DNS lookup error cannot resolve ‘ci.inria.fr' the only problem? or would access to the server also be blocked? If only the former, did you consider preloading the DNS resolver cache from hosts file per [1], which provides a number of options: * refer to ci.inria.fr server via its a private subnet IP address, rather than the public facing IP address * fake up ci.inria.fr as a second IP address on the slave to which web server can be bound and configured to deliver the require file Of course the additional effort for these versus the gain needs to be balanced. btw, useful commands for testing these are [2]: * ipconfig /displaydns * ipconfig /flushdns [1] http://technet.microsoft.com/en-us/library/cc780585(v=ws.10).aspx [2] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ipconfig.mspx?mfr=true No, the thing is: Does it make sense to invest a lot of time into this or are there not more important things? There is a point where I get endlessly tired… so many many many things, sometimes a simple workaround is just the easiest. Marcus Very true.  Hence my disclaimer "the additional effort for these versus the gain needs to be balanced".  Actually it turns out my suggestions were over the top, since it seems the root cause is not the firewall but a difference in DNS resolver configuration between Windows and Linux.  I had a poke around the pharo-contribution slaves since they are presumably similar to the pharo slaves.  Slave pharo-contribution-linux64 was using nameserver 172.21.8.87 with a working 'ping ci.inria.fr', while slave pharo-contribution-win7 was using nameserver 172.21.32.8 (obtained from DHCP) with a non-working 'ping ci.inria.fr'.  Forcing win7 DNS manually to use 172.21.8.87 allowed 'ping ci.inria.fr' to work and further the URL [1] worked fine from the Chrome browser returning [2].  Now it seems that bumping the network config has fixed this, since after undoing the manual win7 DNS setting, the DNS server (obtained from DHCP) is now 172.21.8.87. Someone with access to the Pharo Windows slaves might like to try the same. cheers -ben [1] https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description [2] <description>2.0 #20628</description> _Appendix - Detailed Transcript_ On slave pharo-contribution-linux64... # ping ci.inria.fr PING ci.inria.fr (193.51.193.223) 56(84) bytes of data. 64 bytes from ci.inria.fr (193.51.193.223): icmp_req=1 ttl=62 time=0.569 ms #cat /etc/resolv.conf nameserver 172.21.8.87 nameserver 193.51.196.130 nameserver 193.51.196.131 search cs1cloud.internal On slave pharo-contribution-win7... C:\Users\ci> ping ci.inria.fr Ping request could not find host ci.inria.fr. Please check the name and try again. C:\Users\ci> ipconfig /all Ethernet adapter Local Area Connection:    Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection    DHCP Server . . . . . . . . . . . : 172.21.8.87    DNS Servers . . . . . . . . . . . : 172.21.38.8   193.51.196.130   193.51.196.131 Through the GUI manually forced pharo-contribution-win7 to use nameserver 172.21.8.87, then... C:\Users\ci> ping ci.inria.fr Pinging ci.inria.fr [193.51.193.223] with 32 bytes of data: Reply from 193.51.193.223: bytes=32 time<1ms TTL=62 And after undoing that manual force... C:\Users\ci> ipconfig /all Ethernet adapter Local Area Connection:    Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection    DHCP Server . . . . . . . . . . . : 172.21.8.87    DNS Servers . . . . . . . . . . . : 172.21.8.87   193.51.196.130   193.51.196.131 C:\Users\ci> ping ci.inria.fr Pinging ci.inria.fr [193.51.193.223] with 32 bytes of data: Reply from 193.51.193.223: bytes=32 time<1ms TTL=62