[JENKINS-23654] UpdateCenter stuck at preparation phase when jenkins server is behind GFW

[timja]

Try to install a plugin in PluginManager; click "Install and restart".
in UpdateCenter, screen stuck at "Preparation Checking internet connectivity".

No logs printed out in `var/log/jenkins/jenkins.log`

This bug is caused by method `getConnectionCheckUrl` using url "google.com" to check connectivity.
https://github.com/jenkinsci/jenkins/blob/afd8da49901775900a80eb2b2a9746b01156b0ba/core/src/main/java/hudson/model/UpdateCenter.java#L841

------- update:
I just built jenkins.war replaced the google.com with another url. But It still not work.

I got these warnings, and the log is the same when using 'google.com' url. So it may not be the url problem.

七月 02, 2014 7:49:14 下午 hudson.model.UpdateSite$Plugin deploy
警告: Adding dependent install of ssh-credentials for plugin git
七月 02, 2014 7:49:14 下午 hudson.model.UpdateSite$Plugin deploy
警告: Adding dependent install of credentials for plugin ssh-credentials
七月 02, 2014 7:49:14 下午 hudson.model.UpdateSite$Plugin deploy
警告: Adding dependent install of git-client for plugin git
七月 02, 2014 7:49:14 下午 hudson.model.UpdateSite$Plugin deploy
警告: Dependent install of ssh-credentials for plugin git-client already added, skipping
七月 02, 2014 7:49:14 下午 hudson.model.UpdateSite$Plugin deploy
警告: Adding dependent install of scm-api for plugin git
七月 02, 2014 7:49:14 下午 hudson.model.UpdateSite$Plugin deploy
警告: Dependent install of credentials for plugin git already added, skipping

---

Originally reported by seganw, imported from: UpdateCenter stuck at preparation phase when jenkins server is behind GFW

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

danielbeck:

The connection check URL actually used is part of the update center metadata, see the comment.

You'll need to host your own update center and replace the URL with one that can be reached from your network.

[timja]

seganw:

@Daniel
In my update, I mentioned that I changed google url in source code, but still not work.
According to the logs I attached, this maybe lead to another problem. It seems connected to UpdateSite.java line no. 789
After some test, I found that "job" in "UpdateCenter.InstallationJob job = uc.getJob(dep);" returned null.

How would it be null then?

[timja]

danielbeck:

Why do you think that that value being null is a problem?

Did you change the connectionCheckUrl entry in updated/default.json (replace default by the update center name if you changed its configuration)? Because the hard-coded value you're referencing is never actually used...

[timja]

seganw:

Finally, I know what's the cause.
As you said, the log did nothing wrong.

It's due to two other hard-coded google urls:

Line 333 in method getConnectionCheckUrl() of UpdateSite.java:
if(dt==null) return "http://www.google.com/";

and

key-value "connectionCheckUrl": "http://www.google.com/" in $JENKINS_HOME/updates/default.json

[timja]

danielbeck:

This is a weird one.

On one hand, it makes sense to allow update centers to do their own connectivity check configuration, to account for corporate intranets. And it's a very rare situation that Google cannot be reached while still having actual connectivity, so it's a good default for the public update center. So I'd really like to resolve this as Won't Fix, unless you have a nice, generally applicable solution available.

OTOH, telling you to fix your network issues would lead nowhere. And I assume this affects all Chinese users, so a straightforward solution would be good. How easy (or difficult) would it be to route google.com to a host you can connect to, such as baidu, in your hosts file or local DNS?

[timja]

seganw:

I do not think changing hosts file is a good idea.

IMHO, the best solution at present is a graceful error notice appearing when checking connectivity hang there after some time. That notice should guide user to change the url in `key-value "connectionCheckUrl": "http://www.google.com/" in $JENKINS_HOME/updates/default.json `

[timja]

danielbeck:

That advice would have very limited geographical relevance, as google.com was specifically chosen because of it's solid availability. In most countries, if google.com isn't available, nothing else is either.

That said, maybe something like Microsoft's http://www.msftncsi.com/ncsi.txt would be a better choice. Can you connect to that site?

[timja]

danielbeck:

JENKINS-15124 notes that some shit proxies return nice looking error pages instead of error responses, so having a reference URL with defined content that can be compared would be nice.

[timja]

danielbeck:

Please answer the question in the comment from Oct 11 if you're still interested in a solution to this.

[timja]

netappbluedevil:

If the need in the end is that it is possible to reach the update site, then why bother checking www.google.com, why not check that you can reach the update site?

It is possible to rsync the update site and update the update site URL in Jenkins, so it appears to be a valid use case to have an internal update site anyway. In that case this internet issue is artificial and should be able to be avoided if desired as a configuration option within the update management IMO.

[timja]

pipehappy:

Any update on this problem?

I can ping updates.jenkins-ci.org and download package manually but cannot use the update center.

I guess the problem is because the server is behind GFW. But why bother test against other site when you want to connect to THE SITE if I follow the comments correctly.

[timja]

tdxmgy:

If you want to update some plugins, you can modify jenkins_home/updates/default.json ,change connectionCheckUrl from http://www.google.com/ to some one you can access ,maybe https://www.baidu.com for china, then reload configuration,and install plugins.But jenkins will get this file daily,so if you need,you can do it.

[timja]

tdxmgy:

pipehappy

[timja]

orrc:

danielbeck: What do you think?

Could we just set http://updates.jenkins-ci.org/ as the connectivity check URL in the JSON? It is reliable, and is what the code currently checks anyway at the moment (after checking Google):
https://github.com/jenkinsci/jenkins/blob/jenkins-1.647/core/src/main/java/hudson/model/UpdateCenter.java#L1062

If you can't reach the Jenkins update server, then you have problems anyway. In the worst case, if that host really is down, then the user would be informed, and asked if they need to make proxy changes. But that should be rare, and the same would happen anyway for people in countries where Google can end up being blocked.

Just wondering, as somebody was asking about the connection check URL here:
https://github.com/jenkinsci/backend-update-center2/pull/40#issuecomment-183517346

[timja]

rtyler:

I have no idea if this helps at all, but seganw you might be to hit our mirrors directly for your update-center.json.

A list of the mirrors can be found here and from each mirror listed you should be able to navigate to updates/ and then select either the latest update-center.json or the LTS version (stable/update-center.json)

[timja]

[Originally duplicated by: JENKINS-47734]