Fail to download: https://update.sonarsource.org/update-center.properties (no proxy) about docker-sonarqube

[Godin]

@jeubank12 Container stops when application inside it stops. So the case when application stops whereas shouldn't - is not in responcibility of container/image, but application. However AFAIK SonarQube doesn't stop in case of inability to retrieve update center data - even if in logs I have

...
2018.02.09 20:36:05 INFO  web[][o.s.s.p.UpdateCenterClient] Update center: http://foo (no proxy)
...
2018.02.09 20:36:50 ERROR web[AWF8SM/SoGBn6bsfAAAg][o.s.s.p.UpdateCenterClient] Fail to connect to update center
org.sonar.api.utils.SonarException: Fail to download: http://foo (no proxy)
	at org.sonar.core.util.DefaultHttpDownloader.failToDownload(DefaultHttpDownloader.java:155)
...

container continues to work. If this is not the case for you under some conditions, then this should be improved/fixed in application and not here - please use https://www.sonarqube.org/community/

And you already can easily deactivate update center :

docker run -it --rm -p 9000:9000 sonarqube:6.7.1-alpine -Dsonar.updatecenter.activate=false

and no exceptions in log. This image uses default settings of application, all customization are up to you.

[Godin]

@fekle which exactly image are you using? version of docker? have you tried not inside of a docker inside of a VM, but for example in docker on your machine or on a machine in completely different network environment?

On my side can't reproduce this:

$ docker run -it --rm sonarqube:5.6.6 /bin/bash

root@330d4ecc2b9a:/opt/sonarqube# curl -I https://update.sonarsource.org/update-center.properties
HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Thu, 20 Apr 2017 15:17:02 GMT
Content-Type: text/plain
Content-Length: 233207
Last-Modified: Tue, 18 Apr 2017 13:58:58 GMT
Connection: keep-alive
ETag: "58f61ba2-38ef7"
Accept-Ranges: bytes

root@330d4ecc2b9a:/opt/sonarqube# exit

$ docker run -it --rm sonarqube:6.3 /bin/bash

root@42c1db2697f6:/opt/sonarqube# curl -I https://update.sonarsource.org/update-center.properties
HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Thu, 20 Apr 2017 15:19:06 GMT
Content-Type: text/plain
Content-Length: 233207
Last-Modified: Tue, 18 Apr 2017 13:58:58 GMT
Connection: keep-alive
ETag: "58f61ba2-38ef7"
Accept-Ranges: bytes

root@42c1db2697f6:/opt/sonarqube# exit

$ docker images --digests
REPOSITORY          TAG                 DIGEST                                                                    IMAGE ID            CREATED             SIZE
sonarqube           6.3                 sha256:8849d848d42c4dc1d3ef9d385722fbeb54cc1dcb9274a079fd93b39e132c9871   752d427d3de6        4 weeks ago         770 MB
sonarqube           5.6.6               sha256:9ffc6cbd7a962f08b798d1004ed4af90d5952dbb4eeb5875aab8bdcdb87f0b44   c08b683d5ef3        4 weeks ago         777 MB

$ docker --version
Docker version 17.03.1-ce, build c6d412e

[Godin]

Also can't reproduce on a different machine (this time Linux instead of Mac) in a completely different network.

[Godin]

From the above I believe that issue is unrelated to the content of an image and hence to this repository.

[fekle]

HI @Godin ,

Thanks for your replies!
After a while I was now able to further investigate this problem,
It looks like you're right, it doesn't seem to be an issue regarding the docker image itself.
However, I still think this is the best location for this issue, as it concerns docker and sonarqube.
Now, I tried curl'ing again on different machines, with CentOS, Fedora and Ubuntu, the issue still persists for me.
Outside of docker, I can curl http://update.sonarsource.org/update-center.properties without any issues, however inside a docker container It doesn't work, no matter which image, docker version or host OS.
This issue still really puzzles me, as we never had or have any network issues whatsoever, and update.sonarqube.org is the only domain that ever caused this problems for us.
Curl/Wget/SonarQube are able to resolve the address, as well as using traceroute shows that the connection to the server is successful, using curl -v shows that even the SSL/TLS handshake succeeds.
However after that, the connection just waits, until the connection times out due to no reply from the server:

root@2f9733f20f33:~# time curl -v http://update.sonarsource.org/update-center.properties
* Hostname was NOT found in DNS cache
*   Trying 75.101.133.159...
* Connected to update.sonarsource.org (75.101.133.159) port 80 (#0)
> GET /update-center.properties HTTP/1.1
> User-Agent: curl/7.38.0
> Host: update.sonarsource.org
> Accept: */*
> 
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

real	3m0.650s
user	0m0.000s
sys	0m0.012s
root@2f9733f20f33:~# time curl -v https://update.sonarsource.org/update-center.properties
* Hostname was NOT found in DNS cache
*   Trying 75.101.133.159...
* Connected to update.sonarsource.org (75.101.133.159) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to update.sonarsource.org:443 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to update.sonarsource.org:443 

real	2m0.497s
user	0m0.004s
sys	0m0.004s
root@2f9733f20f33:~# 

It could be that OpenStack is the issue somehow, however this seems extremely unlikely, as it works find in a OpenStack VM without docker, as well as our OpenStack network configuration being the stock/default configuration, with no special options - we even tried disabling the firewall for the sonarsource VMs, to no avail.

[jangrewe]

@Godin Same issue here with the latest alpine image.
I can download it from my desktop machine in the same network, and the host on which the container runs, but not inside the container:

bash-4.4# curl -v https://update.sonarsource.org/update-center.properties
*   Trying 75.101.133.159...
* TCP_NODELAY set
* Connected to update.sonarsource.org (75.101.133.159) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):

Docker version:

Server:
 Engine:
  Version:      17.12.0-ce
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2
  Git commit:   c97c6d6
  Built:        Wed Dec 27 20:09:54 2017
  OS/Arch:      linux/amd64
  Experimental: false

[Godin]

@jangrewe same as before - I strongly believe that this problem is unrelated to content of the image:

$ docker images --digests
REPOSITORY          TAG                 DIGEST                                                                    IMAGE ID            CREATED             SIZE
sonarqube           6.7.1-alpine        sha256:6d382546a2dd3f51610f72134a0ae3668dc5636d12d04011290ee4627d634114   b42c16afb3e0        5 days ago          314MB

$ docker run -it --rm sonarqube:6.7.1-alpine bash

bash-4.4# apk add --no-cache curl
etch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
(1/3) Installing libssh2 (1.8.0-r2)
(2/3) Installing libcurl (7.57.0-r0)
(3/3) Installing curl (7.57.0-r0)
Executing busybox-1.27.2-r7.trigger
OK: 123 MiB in 80 packages

bash-4.4# curl -I https://update.sonarsource.org/update-center.properties
HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Mon, 15 Jan 2018 11:45:05 GMT
Content-Type: text/plain
Content-Length: 319112
Last-Modified: Mon, 15 Jan 2018 11:18:10 GMT
Connection: keep-alive
ETag: "5a5c8df2-4de88"
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Accept-Ranges: bytes

bash-4.4# curl -v https://update.sonarsource.org/update-center.properties
*   Trying 75.101.133.159...
* TCP_NODELAY set
* Connected to update.sonarsource.org (75.101.133.159) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: OU=Domain Control Validated; OU=Gandi Standard SSL; CN=update.sonarsource.org
*  start date: Sep  8 00:00:00 2016 GMT
*  expire date: Sep  8 23:59:59 2019 GMT
*  subjectAltName: host "update.sonarsource.org" matched cert's "update.sonarsource.org"
*  issuer: C=FR; ST=Paris; L=Paris; O=Gandi; CN=Gandi Standard SSL CA 2
*  SSL certificate verify ok.
> GET /update-center.properties HTTP/1.1
> Host: update.sonarsource.org
> User-Agent: curl/7.57.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.10.1
< Date: Mon, 15 Jan 2018 11:48:13 GMT
< Content-Type: text/plain
< Content-Length: 319112
< Last-Modified: Mon, 15 Jan 2018 11:18:10 GMT
< Connection: keep-alive
< ETag: "5a5c8df2-4de88"
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET
< Accept-Ranges: bytes
<
#Generated file
#Mon Jan 15 12:16:18 CET 2018
...

[jeubank12]

This is happening with LTS image for me as well. I have not configured any proxy settings. I don't think the entire container should fail just because it can't reach this url -- what about offline installations?

[jangrewe]

Reminded by the recent replies, i tried to investigate some more...
Logged into the container, ran curl https://update.sonarsource.org/update-center.properties, and lo and behold, i actually got a reply!
I went to the web interface, and now the Marketplace also works. This is very strange.
... but at least it works now! ;-)

(And no, my infrastructure did not change. Seriously.)

[jeubank12]

@Godin Thank you. Changing the settings hasn't been documented where I can find. Note that I am also new to docker so if its built in to docker, I apologize

[jangrewe]

Damn, now i'm hitting that same issue again, even a curl inside the container doesn't work. But requesting any other public URL works fine!

[reinierkors]

I'm having the same issues, any other url works fine.

[crramirez]

Hello,

This is the same problem when you try to issue a docker build inside an Open Stack instance. Just run the container using network_mode: host

In compose:

network_mode: "host"

Regards

[jangrewe]

@crramirez that would be a bit overkill, especially because "all other" containers on that host work fine.

I've switched to using a proxy for that particular container now, which seems to do the job good enough for me.

[crramirez]

Did you install squid on the host or something like that? It sounds like a good idea, I will test it. Thanks El mar., 12 de jun. de 2018 3:31 a. m., Jan Grewe <[email protected]> escribió:

…

@crramirez <https://github.com/crramirez> that would be a bit overkill, especially because "all other" containers on that host work fine. I've switched to using a proxy for that particular container now, which seems to do the job good enough for me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIAiQwY0sMDSY2RdlrA5-n27jKEM1EM2ks5t73xvgaJpZM4NBzin> .

[tomkuba]

In my case it was docker-compose and MTU settings. I had to lower MTU on docker interface to get it working.

[lusu007]

Hey @tomkuba ,
can you provide some examples?
I ran into the same problem and cant solve it.

[tomkuba]

Hey @tomkuba ,
can you provide some examples?

It was network issue in our server infrastructure. I did not know that we have MTU 1450 and I had to manually set dockerd/docker-compose to use lower MTU.
See https://mlohr.com/docker-mtu/ for details.