Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Duplicate
-
None
-
Docker
Description
I am trying to setup a Dockerfile for our Jenkins server. Here is my dockerfile: https://github.com/mtscout6/jenkins-docker/blob/master/jenkins-server/Dockerfile
The problem I have is that the latest Docker plugin relies on ssh-slaves 1.8 and ssh-credentials 1.9. The jenkins war file is currently housing ssh-slaves 1.7 and ssh-credentials 1.8, when I tried adding those plugins to the war file they are replaced, but now I get a SHA-256 digest error. I'm sure this is because the checksum is now invalid as found in the META-INF/MANIFEST.MF file.
I tried using the jar -uf command to update those plugins, also to no avail. What do I need to do to update these plugins so my docker container is ready to run right out of the gate?
Here is the docker log output when running the docker container for the image defined by the above docker file: https://gist.github.com/mtscout6/a31298e1dcc5acf5863c.
Thanks,
Matt Smith
Attachments
Issue Links
- is related to
-
JENKINS-24986 Offer an alternate location to store plugins and groovy hook scripts
-
- Open
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link | This issue is related to JENKINS-24986 [ JENKINS-24986 ] |
I do not see this as an issue with any of the listed components... nothing to do with the docker plugin. nothing to do with the credentials plugin. nothing to do with the ssh-credentials plugin. This is a side effect of the code signing in core and there is a known solution
| Resolution | Not A Defect [ 7 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
The problem is that the $JENKINS_HOME directory is being provided via a docker container volume, the goal here is not to rely on what that data volume may or may not provide.
| Resolution | Not A Defect [ 7 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
Unassigning incorrectly associated plugin components. Unassigning myself from this issue
| Component/s | core [ 15593 ] | |
| Component/s | ssh-slaves [ 15578 ] | |
| Component/s | ssh-credentials [ 17424 ] | |
| Component/s | docker-plugin [ 18724 ] | |
| Assignee | stephenconnolly [ stephenconnolly ] |
The problem is that the $JENKINS_HOME directory is being provided via a docker container volume, the goal here is not to rely on what that data volume may or may not provide.
Appears to be a duplicate of JENKINS-24986 then, which proposes an additional location that is not extracted from the war, and not in JENKINS_HOME.
| Resolution | Duplicate [ 3 ] | |
| Status | Reopened [ 4 ] | Resolved [ 5 ] |
Why not just delete the signatures from the WAR file, or resign with your own key? Then you will not get a checksum mismatch. The signature is not really checked by anything that I know of anyway.
Are these the right files to delete to "unsign" it?
zip -d /usr/share/jenkins/jenkins.war META-INF/JENKINS.SF
zip -d /usr/share/jenkins/jenkins.war META-INF/JENKINS.RSA
That did not appear to work, but I may have the wrong files.
Yes, those, plus the file entries (with Name and SHA-256-Digest) in META-INF/MANIFEST.MF.
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Workflow | JNJira [ 159062 ] | JNJira + In-Review [ 208131 ] |
just pre-populate the $JENKINS_HOME/plugins directory with (rename .hpi to .jpi) each plugin's .jpi files and create a .jpi.pinned file beside it.
That way you don't need to resign the jenkins.war file after modification, because you will not be modifying it.