-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Powered by SuggestiMate -
Jenkins 2.189
java -jar jenkins-cli.jar -s http://localhost:8080/ install-plugin http://updates.jenkins-ci.org/latest/job-dsl.hpi
reports
Installing a plugin from http://updates.jenkins-ci.org/latest/job-dsl.hpi
but fails to install the plugin
java -jar jenkins-cli.jar -s http://localhost:8080/ list-plugins
doesn't list it, neither does the GUI
curl -X POST -d '<jenkins><install plugin="job-dsl@1.34" /></jenkins>' --header 'Content-Type: text/xml' http://localhost:8080/pluginManager/installNecessaryPlugins
does install the plugin
[JENKINS-29065] CLI install plugin jobs-dsl fails
nothing...
Jun 25, 2015 8:13:36 AM INFO org.eclipse.jetty.util.log.JavaUtilLog info
Started SelectChannelConnector@0.0.0.0:8080
Jun 25, 2015 8:13:36 AM INFO winstone.Logger logInternal
Winstone Servlet Engine v2.0 running: controlPort=disabled
Jun 25, 2015 8:13:36 AM INFO jenkins.InitReactorRunner$1 onAttained
Started initialization
Jun 25, 2015 8:13:54 AM INFO jenkins.InitReactorRunner$1 onAttained
Listed all plugins
Jun 25, 2015 8:13:54 AM INFO jenkins.InitReactorRunner$1 onAttained
Prepared all plugins
Jun 25, 2015 8:13:54 AM INFO jenkins.InitReactorRunner$1 onAttained
Started all plugins
Jun 25, 2015 8:14:00 AM INFO jenkins.InitReactorRunner$1 onAttained
Augmented all extensions
Jun 25, 2015 8:14:02 AM INFO jenkins.InitReactorRunner$1 onAttained
Loaded all jobs
Jun 25, 2015 8:14:02 AM INFO hudson.model.AsyncPeriodicWork$1 run
Started Download metadata
Jun 25, 2015 8:14:03 AM INFO org.jenkinsci.main.modules.sshd.SSHD start
Started SSHD at port 49789
Jun 25, 2015 8:14:03 AM INFO jenkins.InitReactorRunner$1 onAttained
Completed initialization
Jun 25, 2015 8:14:03 AM INFO hudson.WebAppMain$3 run
Jenkins is fully up and running
Jun 25, 2015 8:14:08 AM INFO hudson.model.UpdateSite updateData
Obtained the latest update center data file for UpdateSource default
Jun 25, 2015 8:14:08 AM INFO hudson.model.DownloadService$Downloadable load
Obtained the updated data file for hudson.tasks.Maven.MavenInstaller
Jun 25, 2015 8:14:09 AM INFO hudson.model.DownloadService$Downloadable load
Obtained the updated data file for hudson.tasks.Ant.AntInstaller
Jun 25, 2015 8:14:11 AM INFO hudson.model.DownloadService$Downloadable load
Obtained the updated data file for hudson.tools.JDKInstaller
Jun 25, 2015 8:14:11 AM INFO hudson.model.AsyncPeriodicWork$1 run
Finished Download metadata. 8,162 ms
Jun 25, 2015 8:20:07 AM INFO hudson.TcpSlaveAgentListener$ConnectionHandler run
Accepted connection #1 from /172.17.42.1:35739
Jun 25, 2015 8:27:59 AM INFO hudson.TcpSlaveAgentListener$ConnectionHandler run
Accepted connection #2 from /172.17.42.1:35743
Jun 25, 2015 8:29:11 AM INFO hudson.TcpSlaveAgentListener$ConnectionHandler run
Accepted connection #3 from /172.17.42.1:35748
The Job DSL plugin is build by the gradle-jpi-plugin, so there may be subtle difference compared to plugins build by the maven-hpi-plugin. See JENKINS-28408 for an example.
I tried to reproduce the problem on a fresh Jenkins 1.565 (the minimum version supported by the Job DSL plugin) and 1.609.1 and got this:
$ cat /var/lib/jenkins/plugins/job-dsl.jpi <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://updates.jenkins-ci.org/download/plugins/job-dsl/1.34/job-dsl.hpi">here</a>.</p> <hr> <address>Apache/2.2.14 (Ubuntu) Server at updates.jenkins-ci.org Port 443</address> </body></html>
So Jenkins saves the response from the redirect page instead of following the redirect.
It's not a job-dsl-plugin specific problem:
$ java -jar jenkins-cli.jar -s http://localhost:8080/ install-plugin http://updates.jenkins-ci.org/latest/envinject.hpi Installing a plugin from http://updates.jenkins-ci.org/latest/envinject.hpi $ cat /var/lib/jenkins/plugins/envinject.jpi <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://updates.jenkins-ci.org/download/plugins/envinject/1.91.3/envinject.hpi">here</a>.</p> <hr> <address>Apache/2.2.14 (Ubuntu) Server at updates.jenkins-ci.org Port 443</address> </body></html>
The response from updates.jenkins-ci.org seems to be correct, so it's not an INFRA problem:
$ curl -sv http://updates.jenkins-ci.org/latest/envinject.hpi * Hostname was NOT found in DNS cache * Trying 199.193.196.24... * Connected to updates.jenkins-ci.org (199.193.196.24) port 80 (#0) > GET /latest/envinject.hpi HTTP/1.1 > User-Agent: curl/7.35.0 > Host: updates.jenkins-ci.org > Accept: */* > < HTTP/1.1 302 Found < Date: Wed, 01 Jul 2015 13:45:16 GMT * Server Apache/2.2.14 (Ubuntu) is not blacklisted < Server: Apache/2.2.14 (Ubuntu) < Location: https://updates.jenkins-ci.org/download/plugins/envinject/1.91.3/envinject.hpi < Vary: Accept-Encoding < Content-Length: 351 < Connection: close < Content-Type: text/html; charset=iso-8859-1 < Set-Cookie: SERVERID=Local; path=/ < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://updates.jenkins-ci.org/download/plugins/envinject/1.91.3/envinject.hpi">here</a>.</p> <hr> <address>Apache/2.2.14 (Ubuntu) Server at updates.jenkins-ci.org Port 443</address> </body></html> * Closing connection 0
So maybe it's a problem with the UrlConnection used in FilePath, see https://github.com/jenkinsci/jenkins/blob/jenkins-1.609.1/core/src/main/java/hudson/FilePath.java#L868
If the standard JDK HttpUrlConnection is used, it should follow redirects by default (http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#setFollowRedirects%28boolean%29). Since I have no other plugins installed, it can't be a plugin messing around with this.
For the record, I'm using OpenJDK7:
$ java -version java version "1.7.0_79" OpenJDK Runtime Environment (IcedTea 2.5.5) (7u79-2.5.5-0ubuntu0.14.04.2) OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
Oh, and installing the plugin by specifying the short name works as expected:
$ java -jar jenkins-cli.jar -s http://localhost:8080/ install-plugin job-dsl Installing job-dsl from update center $ java -jar jenkins-cli.jar -s http://localhost:8080/ safe-restart $ ll /var/lib/jenkins/plugins | grep job-dsl drwxr-xr-x 4 jenkins jenkins 4096 Jul 1 14:04 job-dsl/ -rw-r--r-- 1 jenkins jenkins 8564801 Jul 1 14:04 job-dsl.jpi
not for me unfortunately
java -jar /home/mediaplayout/Downloads/jenkins-cli.jar -s http://localhost:8080/ install-plugin job-dsl
Installing job-dsl from update center
Jul 03, 2015 1:33:28 PM hudson.remoting.SynchronousCommandTransport$ReaderThread run
SEVERE: I/O error in channel CLI connection to http://localhost:8080/
java.io.IOException: Unexpected termination of the channel
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:299)
at hudson.remoting.ObjectInputStreamEx.<init>(ObjectInputStreamEx.java:40)
at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
But that's a different problem. It's a communication problem between the CLI client and the Jenkins server. You should open another issue for that problem.
Bump? This breaks automation, including the jenkins chef cookbook. A working CLI seems pretty important, no?
conslo That link is a different issue (the original report, not the later comments). Bundled plugins cannot be uninstalled, period. You delete them, they come back on restart. And bundled plugins cannot be updated via CLI due to JENKINS-29726.
danielbeck sorry, the issue I linked isn't actually related, you're correct, I seemed to have changed "uninstalled" into "installed" with some temporary dyslexia.
However the chef cookbook for jenkins does use the jenkins-cli to install plugins, and thus, does not work because of this bug (I'll open an issue on the cookbook later).
I expect this to have been an infra issue due to the http -> https redirect (which isn't supported by Jenkins). Accessing http://updates.jenkins-ci.org/latest/job-dsl.hpi redirects me to plain http, so should work.
danielbeck Maybe this could be reopen. Or maybe this is related to https://issues.jenkins-ci.org/browse/JENKINS-44361 ? The issue with the HTTP / HTTPS redirect is corrupting the file when downloading using the CLI.
If I use wget https://updates.jenkins.io/download/plugins/groovy/2.2/groovy.hpi and then do a sha1sum groovy.jpi I can see the right sha 85af4e8de47e981d3bf22adaf0c7f5747b991d83.
If I use the Jenkins CLI to install from https://updates.jenkins.io, it succeeds:
java -jar jenkins-cli.jar -logger FINE -s http://cje.example.com:8081 -auth admin:admin install-plugin https://updates.jenkins.io/download/plugins/groovy/2.2/groovy.hpi Jul 19, 2019 2:34:09 PM org.apache.sshd.common.util.security.SecurityUtils register FINE: register(BC) not registered - enabled=true, supported=false Jul 19, 2019 2:34:09 PM org.apache.sshd.common.util.security.AbstractSecurityProviderRegistrar getOrCreateProvider INFO: getOrCreateProvider(EdDSA) created instance of net.i2p.crypto.eddsa.EdDSASecurityProvider Jul 19, 2019 2:34:09 PM hudson.cli.CLI _main FINE: using connection mode HTTP Jul 19, 2019 2:34:09 PM hudson.cli.CLI plainHttpConnection FINE: Trying to connect to http://allan.oss.com:8081/ via plain protocol over HTTP Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: establishing download side Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: established download side Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: establishing upload side Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: established upload side Installing a plugin from https://updates.jenkins.io/download/plugins/groovy/2.2/groovy.hpi
but the sha of the $JENKINS_HOME/plugins/groovy.hpi is wrong 7c5e3f4ae6540474cf24bd4cb3ece2d31e701965. The file contains the HTTP response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://mirrors.jenkins-ci.org/plugins/groovy/2.2/groovy.hpi">here</a>.</p> </body></html>
This will break Jenkins startup on the next restart.
If I use the Jenkins CLI to install from http://updates.jenkins.io, it succeeds:
java -jar jenkins-cli.jar -logger FINE -s http://cje.example.com:8081 -auth admin:admin install-plugin https://updates.jenkins.io/download/plugins/groovy/2.2/groovy.hpi Jul 19, 2019 2:34:09 PM org.apache.sshd.common.util.security.SecurityUtils register FINE: register(BC) not registered - enabled=true, supported=false Jul 19, 2019 2:34:09 PM org.apache.sshd.common.util.security.AbstractSecurityProviderRegistrar getOrCreateProvider INFO: getOrCreateProvider(EdDSA) created instance of net.i2p.crypto.eddsa.EdDSASecurityProvider Jul 19, 2019 2:34:09 PM hudson.cli.CLI _main FINE: using connection mode HTTP Jul 19, 2019 2:34:09 PM hudson.cli.CLI plainHttpConnection FINE: Trying to connect to http://allan.oss.com:8081/ via plain protocol over HTTP Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: establishing download side Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: established download side Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: establishing upload side Jul 19, 2019 2:34:09 PM hudson.cli.FullDuplexHttpStream <init> FINE: established upload side Installing a plugin from https://updates.jenkins.io/download/plugins/groovy/2.2/groovy.hpi
And the sha of the $JENKINS_HOME/plugins/groovy.hpi is correct 85af4e8de47e981d3bf22adaf0c7f5747b991d83*
Note that it works for the update site at jenkins-updates.cloudbees.com/ whether you use http or https
As of https://github.com/jenkinsci/jenkins/pull/4123 the silent corruption is replaced by an error (and no bogus file except for a *.tmp):
Installing a plugin from https://updates.jenkins.io/download/plugins/groovy/2.2/groovy.hpi ERROR: Unexpected exception occurred while performing install-plugin command. java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:225) at java.util.zip.ZipFile.<init>(ZipFile.java:155) at java.util.jar.JarFile.<init>(JarFile.java:166) at java.util.jar.JarFile.<init>(JarFile.java:130) at hudson.cli.InstallPluginCommand.moveToFinalLocation(InstallPluginCommand.java:176) at hudson.cli.InstallPluginCommand.run(InstallPluginCommand.java:110) at …
Making it follow redirects would be a nice enhancement.
Not sure I would consider this “fixed”, exactly—Jenkins still does not follow redirects—but the behavior is certainly better than before.
The part where Jenkins comes up with failures to load (potentially many) plugins is fixed; so seems reasonable to me to close this. What's left is the lack of supporting HTTP redirects, which can be filed in a new issue if desired.
Anything interesting in the Jenkins log?