maybe we should add an issue tracker entry to not lose this? And no, sadly I have no time to do anything…
On 11 Jan 2014, at 17:48, b...@openinworld.com wrote: > 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
