Add Jenkins 2.54 new cli options: -http, -ssh, -remoting to jenkins_script resource

[lmilbaum]

Cookbook version

4.2.1

Chef-client version

Chef Development Kit Version: 1.2.22
chef-client version: 12.18.31
delivery version: master (0b746cafed65a9ea1a79de3cc546e7922de9187c)
berks version: 5.6.1
kitchen version: 1.15.0

Platform Details

workstation - OS-X 10.12.4
target - Ubuntu 16.04 on EC2

Scenario:

I would like to execute my groovy scripts on Jenkins 2.54 as before. So, want to add the '-remoting' flag to the jenkins_script resource.

Steps to Reproduce:

Running jenkins_script resource

Expected Result:

Actual Result:

Works like a charm for Jenkins 2.53 and bellow
Works for Jenkins 2.54 when executing manually with the '-remoting' flag.
For Jenkins 2.54 with jenkins_script resource:

ec2-54-76-216-204.eu-west-1.compute.amazonaws.com �[0m ---- Begin output of "java" -jar "/var/chef/cache/jenkins-cli.jar" -s http://localhost:8080 groovy /tmp/groovy20170414-1437-11rb2yt ----
ec2-54-76-216-204.eu-west-1.compute.amazonaws.com �[0m STDOUT:
ec2-54-76-216-204.eu-west-1.compute.amazonaws.com �[0m STDERR: ERROR: This command is requesting the deprecated -remoting mode. See https://jenkins.io/redirect/cli-command-requires-channel
ec2-54-76-216-204.eu-west-1.compute.amazonaws.com �[0m ---- End output of "java" -jar "/var/chef/cache/jenkins-cli.jar" -s http://localhost:8080 groovy /tmp/groovy20170414-1437-11rb2yt ----
ec2-54-76-216-204.eu-west-1.compute.amazonaws.com �[0m Ran "java" -jar "/var/chef/cache/jenkins-cli.jar" -s http://localhost:8080 groovy /tmp/groovy20170414-1437-11rb2yt returned 5�[0m

[p0d0l]

Wanted to open similar issue. Same situation with jenkins cookbook 5.0.0 and CentOS (7.3) based environment (Masters and Slaves).

Here's some additional info about changes in Jenkins 2.54:
https://jenkins.io/blog/2017/04/11/new-cli/
https://gist.github.com/jglick/9721427da892a9b2f75dc5bc09f8e6b3

Here's my little research about problems that need to be addressed.

1. New 2.54 jenkins-cli.jar is not treating "-remoting" as a default anymore (http protocol is the default one now) so "-remoting" needs to be added i.e.:

java -jar "/var/chef/cache/jenkins-cli.jar" -remoting -s http://localhost:8080 groovy test

2. Simple switch to "-ssh -user <name_of_a_user>" or "-http -user <name_of_a_user>" will not work for some CLI commands like:

• groovy (plugin)
• install-plugin (core)
  as they still need "remoting"...it would be great to just switch to ssh, but right now it's not possible :( i.e.:

java -jar "/var/chef/cache/jenkins-cli.jar" -ssh -user "example_user" -s https://jenkins.example.com groovy test

ERROR: This command is requesting the deprecated -remoting mode. See https://jenkins.io/redirect/cli-command-requires-channel

I hope that Jenkins Community will fix/work out this "requesting the deprecated -remoting mode"

3. Jenkins Master needs to have enabled "CLI over remoting" when you try to use "remoting" channel protocol now.

I changed _helper.rb and _executor.rb libraries in my jenkins wrapper cookbook to support "protocol" (remoting/ssh/http) and "cli_user" (needed when ssh or http is used) - both as an option. Together with executor.rb attribute it works like before.

BTW The Jenkins Community is planning to drop jenkins-cli.jar as a whole. There will be REST-like CLI in its place. CLI is crucial in the orchestration perspective so probably there will be more changes required in the jenkins cookbook in the nearest future.

[kannan4k]

@p0d0l I've the same problem with jenkins-cli.
Could you please share the code to make it work?

[ghost]

@kannan4k Switch the jenkins-cli call to a REST API call

[kannan4k]

@lioraspark We were using key based auth to manage the jobs. I hope REST api will not be applicable in that case right?

[p0d0l]

@kannan4k p0d0l/jenkins@d18f599

[Dispader]

@p0d0l Have you submitted that commit as a Pull request? ('Cause it looks good here.)

[bflad]

For what its worth, this is affecting 2.46.2 users as well now.

[daften]

@p0d0l @Dispader I've ran into this issue and created a new branch. I've opened up a PR by using @p0d0l 's commit. If he opens one himself to work on this issue, I'll just close mine, but now you can use this PR with berks e.g. if you need it :)

[p0d0l]

Thx @daften. I'm perfectly fine with what you did there. I've added the review as 'approved' to #603

[iennae]

Hey folks, can you verify v 5.0.1 of the cookbook resolves your issue?

[daften]

v5.0.1 fixes it for me.
I'd keep this issue open though, since the PR is a temporary fix. The -remoting option, which is now default, will be removed from jenkins-cli at some point.

[p0d0l]

I switched to use v5.0.1 jenkins cookbook on my production together with removed 'workaround' from my wrapper cookbook - it works.

As to CLI commands that needed "remoting" (so ssh/http cannot be used):

ERROR: This command is requesting the deprecated -remoting mode. See https://jenkins.io/redirect/cli-command-requires-channel

I'm on Jenkins 2.58 and I no longer see such error for the "install-plugin" CLI command - it works. The CLI "groovy" command still has this error though.

[Dispader]

@p0d0l Agreed— the CLI "groovy" command is still failing here. It looks like other commands are working fine.

    ---- End output of "java" -jar "/home/appadm/chef/file_cache/jenkins-cli.jar" -s http://localhost:8080 -"remoting" groovy /tmp/groovy20170502-575-16uruff ----
    Ran "java" -jar "/home/appadm/chef/file_cache/jenkins-cli.jar" -s http://localhost:8080 -"remoting" groovy /tmp/groovy20170502-575-16uruff returned 255
    STDOUT:
    STDERR: No such command: -remoting

Bizarrely, I'm only seeing this under rhel. centos seems to be working here.

[StephenKing]

Calling jenkins_command[safe-restart] fails for me with java.security.GeneralSecurityException: Authentication failed. No private key accepted.. That worked before. See the full logs here. Possible that something is still a bit incorrect here?

[StephenKing]

Executing the command without -"remoting" works.

[Dispader]

@p0d0l And I don't know what's going down, but using war (rather than package for a Jenkins source) solved the --remoting problem with Groovy scripts here.

I'm good here.

[maati55]

Using v5.0.1 - Jenkins 2.46.2

I still have issue:

---- Begin output of "java" -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"remoting" -i "/tmp/kitchen/cache/jenkins-key" groovy /tmp/groovy20170503-6482-pp6obk ----
           STDOUT:
           STDERR: May 03, 2017 10:40:01 AM hudson.cli.CLI _main
           WARNING: null
           java.security.GeneralSecurityException: Authentication failed. No private key accepted.
           	at hudson.cli.CLI.authenticate(CLI.java:750)
           	at hudson.cli.CLI._main(CLI.java:590)
           	at hudson.cli.CLI.main(CLI.java:399)
           ---- End output of "java" -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"remoting" -i "/tmp/kitchen/cache/jenkins-key" groovy /tmp/groovy20170503-6482-pp6obk ----
           Ran "java" -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"remoting" -i "/tmp/kitchen/cache/jenkins-key" groovy /tmp/groovy20170503-6482-pp6obk returned 255

[lmilbaum]

Hitting a totally different error:
remote_file[/var/lib/jenkins/jenkins.war] cannot be downloaded from https://updates.jenkins.io/2.57/latest/jenkins.war: 404 "Not Found"

This error is related to issue: #590

My workaround was to add the next line to the jenkins wrapper cookbook (attributes file):
override['jenkins']['master']['source'] = "https://updates.jenkins.io/download/war/#{node['jenkins']['master']['version']}/jenkins.war"

[lmilbaum]

the new cookbook version (5.0.1) worked for me

[p0d0l]

I did some comparison of CLIs by manual triggering. Here are the results:

$ java -jar jenkins-cli-2.46.1.jar -version
Version: 2.46.1
$ java -jar jenkins-cli-2.46.2.jar -version
Version: 2.46.2
$ java -jar jenkins-cli-2.58.jar -version
Version: 2.58

Executions of those CLIs against the Jenkins Master on localhost - in this example request about the Jenkins Master version (Master is 2.58 but it's not relevant right now and output is very short if successful):

$ java -jar jenkins-cli-2.58.jar -s http://localhost:8080 -remoting -i "jenkins-key" version
2.58
$ java -jar jenkins-cli-2.46.2.jar -s http://localhost:8080 -remoting -i "jenkins-key" version
2.58
$ java -jar jenkins-cli-2.46.1.jar -s http://localhost:8080 -remoting -i "jenkins-key" version 2>&1 | head -2
[WARN] Failed to authenticate with your SSH keys. Proceeding as anonymous
No such command: -remoting

"head -2", beacuse there's a whole "help" output after those two lines.

So "-remoting" option is not understood and is read as CLI command + there's an additional SSH keys authentication failure.

Same against CLI in 2.46.1 but without "-remoting"

$ java -jar jenkins-cli-2.46.1.jar -s http://localhost:8080 -i "/var/chef/cache/jenkins-key" version
2.58

@Dispader In your example the error suggests as "-remoting" was read as a CLI command and not a jar option. Are you sure that jenkins-cli.jar was from 2.46.2 (aka LTS) or 2.54+ (aka latest-greatest)? Because before those versions, jenkins-cli.jar did not have protocols in its options (just assumed the "remoting" as a default). In such case "-remoting" is read as a CLI command. Jenkins Community does not provide different contents of rpm packages for RHEL and CeonOS. Are you sure you had the same version of jenkins-cli.jar for war and non-war installation back then, during your tests?

@StephenKing @Ali-karimkhani
It's strange behaviour as the LTS 2.46.2 and non-LTS versions 2.54+ have the same security fixes and "Non-Remoting-based CLI" fixes:
https://jenkins.io/changelog-stable/
https://jenkins.io/changelog/

Maybe manually triggered jenkins-cli.jar would be more descriptive about the error. You could try:

java -jar "/opt/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -remoting -i "/opt/kitchen/cache/jenkins-key" version
java -jar "/opt/kitchen/cache/jenkins-cli.jar" -version

@Ali-karimkhani do you have the same case as @StephenKing - when "remoting" is removed, it's working? Is it possible that your environment tirggered CLI comands with older jenkins-cli.jar?

@lioramilbaum the v5.0.1 had some fixes in repositories area (pkg.jenkins.io: rpms, debs) to distinguish "stable" (aka LTS) vs "current" (aka latest-greatest). From the "stable" repositories, all newest non-LTS packages were moved to a separate URL. Probably a similar thing needs to be align with the "war" type installation like:

• current:
  https://updates.jenkins.io/current/latest/
• stable:
  https://updates.jenkins.io/stable/latest/

So jenkins cookbook should probably distinguish jenkins-cli.jar version or possible options to pass and add "-remoting" (or not) to support both old-way and new-way and to enable smooth transition between. Without "-remoting" passed to CLI you could not use newest versions of Jenkins Master and with "-remoting" passed to CLI you cannot use older versions. In other words - jenkins cookbook <=5.0.0 works with <2.46.2 and <2.54 and jenkins cookbook 5.0.1 works with >=2.46.2 and >=2.54.

[p0d0l]

Well, to keep things simple and the story short - if you have Jenkins Master versions lower then 2.46.2 (LTS) and 2.54 (non-LTS) comment the:

executor['protocol'] = 'remoting'

in your executor.rb attributes. It will not pass such option as it's only passed if it's present... so no other changes for "distinguishing" versions is needed tbh.

[maati55]

@p0d0l
Here is result:

with -remoting

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -remoting -i "/tmp/kitchen/cache/jenkins-key" version
May 04, 2017 4:49:45 PM hudson.cli.CLI _main
WARNING: null
java.security.GeneralSecurityException: Authentication failed. No private key accepted.
	at hudson.cli.CLI.authenticate(CLI.java:750)
	at hudson.cli.CLI._main(CLI.java:590)
	at hudson.cli.CLI.main(CLI.java:399)

without

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080  -i "/tmp/kitchen/cache/jenkins-key" version
2.46.2

[ramc-n]

@p0d0l -remoting option doesnt seem to work fine for me as well.

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:80 -remoting -i "/tmp/kitchen/cache/jenkins-key" version
May 04, 2017 6:55:17 PM hudson.cli.CLI _main
WARNING: null
java.security.GeneralSecurityException: Authentication failed. No private key accepted.
	at hudson.cli.CLI.authenticate(CLI.java:750)
	at hudson.cli.CLI._main(CLI.java:590)
	at hudson.cli.CLI.main(CLI.java:399)

Using -http option however seems to work for version.

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:80 -"http" -i "/tmp/kitchen/cache/jenkins-key" version
2.46.2

However using -http option to install plugin isn't working as the URL passed is a local URL instead of HTTP URL.
The trick is to get the http URL passed as argument instead of local URL.
This is output from kitchen converge using -http executor:

       ---- Begin output of "java" -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:80 -"http" -i "/tmp/kitchen/cache/jenkins-key" install-plugin /tmp/kitchen/cache/ace-editor-1.1.plugin -name ace-editor  ----
       STDOUT: /tmp/kitchen/cache/ace-editor-1.1.plugin is neither a valid file, URL, nor a plugin artifact name in the update center
       STDERR: ERROR: Error occurred, see previous output.

If we manually run the command on the kitchen VM by passing a HTTP URL while using -http executor, it works fine:

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:80 -"http" -i "/tmp/kitchen/cache/jenkins-key" install-plugin http://updates.jenkins-ci.org/download/plugins/ace-editor/1.1/ace-editor.hpi -name ace-editor
Installing a plugin from http://updates.jenkins-ci.org/download/plugins/ace-editor/1.1/ace-editor.hpi

Do you know how we can enforce passing a HTTP URL while using -http executor?
I know that we can use source option, but is there a way that cookbook can automatically pass HTTP URL while using -http executor?

[ramc-n]

Using -ssh option and local URL also doesnt seem to work:

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:80 -"ssh" -user jenkins -i "/tmp/kitchen/cache/jenkins-key" install-plugin /tmp/kitchen/cache/ace-editor-1.1.plugin -name ace-editor
/tmp/kitchen/cache/ace-editor-1.1.plugin is neither a valid file, URL, nor a plugin artifact name in the update center

ERROR: Error occurred, see previous output.

However using -ssh and HTTP URL works fine:

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:80 -"ssh" -user jenkins -i "/tmp/kitchen/cache/jenkins-key" install-plugin http://updates.jenkins-ci.org/download/plugins/ace-editor/1.1/ace-editor.hpi -name ace-editor
Installing a plugin from http://updates.jenkins-ci.org/download/plugins/ace-editor/1.1/ace-editor.hpi

For me, it looks like using -http or -ssh rather than -remoting is looking promising, provided the cookbook uses HTTP URL rather than local URL.

[ramc-n]

In continuation of my earlier comment that -http and -ssh work better when provided with HTTP URL, the code here is downloading the URL to disk and passing the local URL to cli jar. (Due to cli jar unable to handle 302 re-directs)
https://github.com/chef-cookbooks/jenkins/blob/master/libraries/plugin.rb#L292-L318

Probably the new cli jar is able to handle the 302 re-directs and the code can pass the HTTP URL directly, instead of downloading it?

[maati55]

@p0d0l and @ramc-n

http works for me but, still have issue with groovy

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"http" -i "/tmp/kitchen/cache/jenkins-key" version
2.46.2

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"http" -i "/tmp/kitchen/cache/jenkins-key" install-plugin http://updates.jenkins-ci.org/download/plugins/ace-editor/1.1/ace-editor.hpi -name ace-editor
Installing a plugin from http://updates.jenkins-ci.org/download/plugins/ace-editor/1.1/ace-editor.hpi

Groovy test:

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"http" -i "/tmp/kitchen/cache/jenkins-key" groovy /tmp/groovy-list-plugin

ERROR: This command is requesting the deprecated -remoting mode. See https://jenkins.io/redirect/cli-command-requires-channel

Same when running with kitchen test:

Expected process to exit with [0], but received '5'
           ---- Begin output of "java" -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"http" -i "/tmp/kitchen/cache/jenkins-key" groovy /tmp/groovy20170505-6480-1u6ry1m ----
           STDOUT:
           STDERR: ERROR: This command is requesting the deprecated -remoting mode. See https://jenkins.io/redirect/cli-command-requires-channel

[dshvedchenko]

Hello, regarding to

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:80 -remoting -i "/tmp/kitchen/cache/jenkins-key" version
May 04, 2017 6:55:17 PM hudson.cli.CLI _main
WARNING: null
java.security.GeneralSecurityException: Authentication failed. No private key accepted.
	at hudson.cli.CLI.authenticate(CLI.java:750)
	at hudson.cli.CLI._main(CLI.java:590)
	at hudson.cli.CLI.main(CLI.java:399)

imho : code at regex in jenkins/libraries/_executor.rb requires change:

/^Authentication failed\. No private key accepted\.$/

to

/.*?Authentication failed\. No private key accepted\.$/

Please. review and merge if appropriate #607

[p0d0l]

@ramc-n @Ali-karimkhani

jenkinsci/jenkins#2795

The install-plugin command now supports a source of = to load a plugin *.hpi from standard input, since use of local file paths only worked in Remoting mode.

So:

• with remoting it can be localfile (path)
• with http/ssh it needs to be URL or localfile (but redirected to stdin):

java -jar jenkins-cli.jar install-plugin SOURCE ... [-deploy] [-name VAL] [-restart] [--username VAL] [--password VAL] [--password-file VAL]
Installs a plugin either from a file, an URL, or from update center. 
 SOURCE              : If this points to a local file (‘-remoting’ mode only),
                       that file will be installed. If this is an URL, Jenkins
                       downloads the URL and installs that as a plugin. If it
                       is the string ‘=’, the file will be read from standard
                       input of the command, and ‘-name’ must be specified.
                       Otherwise the name is assumed to be the short name of
                       the plugin in the existing update center (like
                       ‘findbugs’), and the plugin will be installed from the
                       update center.

So knowing that, all current possible options look like this (examples):

1. Local file by pointing a path (it's for remoting only now):

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -"remoting" -i "/tmp/kitchen/cache/jenkins-key install-plugin /tmp/kitchen/cache/gerrit-trigger-2.23.1.plugin
Installing a plugin from local file: /var/chef/cache/gerrit-trigger-2.23.1.plugin

2. Local file by stdin redirection (i.e. with ssh protocol):

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -ssh -user "example_chef_user" install-plugin = -name gerrit-trigger < /tmp/kitchen/cache/gerrit-trigger-2.23.1.plugin
Installing a plugin from standard input

3. Direct URL (i.e. with ssh protocol):

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -ssh -user "example_chef_user" install-plugin http://updates.jenkins-ci.org/download/plugins/gerrit-trigger/2.23.2/gerrit-trigger.hpi -name gerrit-trigger
Installing a plugin from http://updates.jenkins-ci.org/download/plugins/gerrit-trigger/2.23.2/gerrit-trigger.hpi

4. Directly from update center via short name (i.e. with ssh protocol):

java -jar "/tmp/kitchen/cache/jenkins-cli.jar" -s http://localhost:8080 -ssh -user "example_chef_user" install-plugin gerrit-trigger -name gerrit-plugin
Installing gerrit-trigger from update center

For me, the most interesting question here is, why does your "-remoting" don't work.
Could you please share your jenkins-cli.jar version by:

java -jar "/opt/kitchen/cache/jenkins-cli.jar" -version
md5sum /opt/kitchen/cache/jenkins-cli.jar

@ramc-n @Ali-karimkhani please be aware that "-http" CLI falls to anonymous user without the
-auth [ USER:SECRET | @FILE ]).
As we can see in your cases anonymous can install plugins (security risks). Also the "-i ssh-key" is not read then (it's read only during -ssh and -remoting). When you use jenkins-cli.jar in version 2.46.2 and not define the "-remoting" the jenkins-cli.jar falls to the "-http" and because your anonymous user can do a lot - it works for you. If you have 2.46.2 version of jenkins-cli.jar I think your "Authentication failed. No private key accepted" may be a result of the ssh-key that is not like it needs to be (does that private key matches the public key added for the user that is set to orchestrate/configure Jenkins CI?)

For me personally the best solution (taking in consideration current Jenkins CI changes) would be to use "-ssh" + "-user" instead of "-remoting" for all CLI commands except "groovy" (which still is not working without the "remoting"). This will be needed in the end as "remoting" is deprecated and planned to be removed.

[daften]

Agreed with switching to -ssh instead of -remoting!

[isuftin]

Because Jenkins does not start with SSHd enabled, how does anyone perform an initial run of the Jenkins cookbook with the executor protocol set to SSH? Because SSHd is not enabled, I am unable to add any plugins unless I manually go in, start the SSHd server and re-run the cookbook.

Anyone?

[dshvedchenko]

Maybe it is possible to enable SSHd by altering some config file on filesystem or by REST api somehow *Denys Shvedchenko* Software Engineer Cell: +380 (50) 911-0375 Skype: dshvedchenko Sphere.Software Website <https://sphereinc.com/> | Twitter <https://twitter.com/SphereSW> | LinkedIn <https://www.linkedin.com/company/sphere-consulting-inc?trk=biz-companies-cym> | Facebook <https://www.facebook.com/pages/Sphere-Consulting/117317111623107> |

…

On Mon, May 15, 2017 at 11:29 PM, Ivan Suftin ***@***.***> wrote: Because Jenkins does not start with SSHd enabled, how does anyone perform an initial run of the Jenkins cookbook with the executor protocol set to SSH? Because SSHd is not enabled, I am unable to add any plugins unless I manually go in, start the SSHd server and re-run the cookbook. Anyone? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#599 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABORwN9-6yXG-tc7FtRt15dcndMNqsauks5r6LW5gaJpZM4M9ly1> .

[isuftin]

Here's my solution for flipping SSHd on by defualt in my owi_jenkins cookbook. Got the idea from https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Hook+Script and the Jenkins Docker container Dockerfile and how they're doing automated setup. This still does not fix plugin installation, btw.

owi_jenkins::master :

include_recipe 'jenkins::master'

jenkins_home = node['jenkins']['master']['home']

directory File.join(jenkins_home, 'init.groovy.d') do
	user node['jenkins']['master']['user']
	group node['jenkins']['master']['group']
end

template File.join(jenkins_home, 'init.groovy.d', 'sshd_configure.groovy') do
	source 'sshd_configure.groovy.erb'
	user node['jenkins']['master']['user']
	group node['jenkins']['master']['group']
	variables(
		'port' => node['owi_jenkins']['ssh']['port']
	)
       notifies :restart, 'service[jenkins]', :delayed
end

sshd_configure.groovy.erb :

import jenkins.model.*

def instance = Jenkins.getInstance()
def sshd = instance.getDescriptor("org.jenkinsci.main.modules.sshd.SSHD")
def currentPort = sshd.getActualPort()
def expectedPort = <%= @port %>

if (currentPort != expectedPort) {
  sshd.setPort(expectedPort)
}

default.rb attributes:

# Enable/disable SSHd.
# If the port is 0, Jenkins will serve SSHd on a random port
# If the port is > 0, Jenkins will serve SSHd on that port specifically
# SIf the port is is -1 turns off SSHd.
default['owi_jenkins']['ssh']['port'] = 0

[ayk33]

I am getting the following error:

sudo java -jar "/tmp/packer-chef-solo/local-mode-cache/cache/jenkins-cli.jar" -s http://localhost:8080 -i "/tmp/packer-chef-solo/local-mode-cache/cache/jenkins-key" -"remoting" groovy /tmp/groovy20170619-2927-ib1j5n
Jun 19, 2017 9:30:10 PM hudson.cli.CLI _main
WARNING: null
java.security.GeneralSecurityException: Authentication failed. No private key accepted.
	at hudson.cli.CLI.authenticate(CLI.java:750)
	at hudson.cli.CLI._main(CLI.java:590)
	at hudson.cli.CLI.main(CLI.java:399)

It appears that its pointing at a valid ssh key. Any suggestions on how to troubleshoot this are welcome.

[iennae]

@ayk33 Please open a new issue. Adding this request for help to this thread may delay support. Thanks!

[espoelstra]

Hopefully this is a useful contribution back to this huge issue that I've ready through many times.

One of the things that you might run into if you have enabled SSH or HTTPS is that attempting to run a Groovy script using groovy_path instead of command <<-eos.gsub(/^\s+/, '') and a code block will pretty much fall on its face if you don't have the Remoting over CLI and other "deprecated"/"insecure" settings enabled.

Since I prefer to keep our Jenkins in line with recommendations, and managing huge blocks of Groovy inline in Chef can get unwieldy, especially if it is static code/text and doesn't require any variables. What we've moved towards doing is managing a file to the Chef cache directory using remote_file or cookbook_file or template and then using a dirty trick to pass the body of the file into command so that it will pass through the SSH protocol without tripping over the dumb Remoting warnings fromgroovy_path.

  cookbook_file File.join(Chef::Config[:file_cache_path], 'create_seed_job.groovy') do
    source 'createSeedJobs.groovy'
    notifies :execute, "jenkins_script[create_seed_job]", :immediately
  end

  jenkins_script 'create_seed_job' do
    command lazy { ::IO.read(::File.join(Chef::Config[:file_cache_path], 'create_seed_job.groovy')) }
  end

This basically allows the file to get created during the converge portion of the compile/converge process, and then the command lazy ensures it doesn't attempt to resolve the path to read the file until the converge reaches that step on the node where the file at that point should exist.

[github-daniel-stoian]

Here is how we switched from remoting to ssh auth:

A. Set executor protocol

• attributes/default.rb
  default['jenkins']['executor']['protocol'] = 'ssh'
  default['jenkins']['executor']['cli_user'] = 'user_name'

B. Set template config for sshd server (we manually enable ssh on a jenkins master and capture this generated xml from jenkins_home)

• templates/sshd_configure.xml.erb

<org.jenkinsci.main.modules.sshd.SSHD>
<%= @PORT %>
</org.jenkinsci.main.modules.sshd.SSHD>

C. Set config file for sshd server + restart

• recipes/master.rb

template "#{node['jenkins']['home']}/org.jenkinsci.main.modules.sshd.SSHD.xml" do
source 'sshd_configure.xml.erb'
owner 'jenkins'
group 'jenkins'
mode 00600
variables(
'port' => '53800'
)
notifies :restart, 'service[jenkins]'
end

execute 'wait-until-sshd-is-up' do
command 'while ! nc -z localhost 53800 ; do sleep 1 ; done'
end

Hope it helps.

[don-code]

Thanks @danielstoian - we hit this in the middle of a planned-downtime upgrade; having a workaround readily available saved us.

For reference, we had to change:

template "#{node['jenkins']['home']}/org.jenkinsci.main.modules.sshd.SSHD.xml" do

...to:

template "#{node['jenkins']['master']['home']}/org.jenkinsci.main.modules.sshd.SSHD.xml" do

...and also:

<org.jenkinsci.main.modules.sshd.SSHD>
<%= @port %>
</org.jenkinsci.main.modules.sshd.SSHD>

...to:

<?xml version='1.1' encoding='UTF-8'?>
<org.jenkinsci.main.modules.sshd.SSHD>
  <port>2302</port>
</org.jenkinsci.main.modules.sshd.SSHD>

In hopes that it helps someone else - our Jenkins install is behind a load balancer that only allows HTTP traffic, and the Jenkins CLI will automatically resolve the JENKINS_URL of the Jenkins install, which in this case is the DNS name of the load balancer. I ended up overriding that DNS on the Jenkins master to 127.0.0.1 in /etc/hosts.

[mromero-convoso]

Because Jenkins does not start with SSHd enabled, how does anyone perform an initial run of the Jenkins cookbook with the executor protocol set to SSH? Because SSHd is not enabled, I am unable to add any plugins unless I manually go in, start the SSHd server and re-run the cookbook.

Anyone?

I use this little guy before all of my Jenkins resources - I have the protocol set to 'ssh' by default, unless this block is executed:

port = node['jenkins']['ssh']['port']
ruby_block 'initialize' do
  block do
    node.override['jenkins']['executor']['protocol'] = 'http'
  end
  not_if "grep #{port} /var/lib/jenkins/org.jenkinsci.main.modules.sshd.SSHD.xml"
end