legacy CLI.jar remoting is broken

[matonb]

@jhoblitt
I'm trying to use jenkins_security_realm to configure the Active Directory plugin but I'm not getting very far...

I've tweaked puppet master config to include the additional cache path and added the retries gem (puppetserver restarted).

Puppet agent on the test node fail with:

Error: Could not find a suitable provider for jenkins_security_realm

Just to see, I added the retries gem to the node, I then got this error

Error: Failed to apply catalog: Execution of '/bin/java -jar /usr/lib/jenkins/jenkins-cli.jar -s http://localhost:8080 groovy /usr/lib/jenkins/puppet_helper.groovy get_security_realm' returned 5: ERROR: This command is requesting the deprecated -remoting mode. See https://jenkins.io/redirect/cli-command-requires-channel

Puppet code:

    jenkins_security_realm { 'hudson.plugins.active_directory.ActiveDirectorySecurityRealm':
      ensure    => 'present',
      #String domain, String site, String bindName, String bindPassword, String server
      arguments => [
<blah>
      ],
      require   => Jenkins::Plugin['active-directory'],
    }

[matonb]

Bit more info:

server CentOS 7.4
puppetserver-2.8.0-1.el7.noarch

/opt/puppetlabs/bin/puppetserver gem list

*** LOCAL GEMS ***

fast_gettext (1.1.0)
gettext (3.2.2)
gettext-setup (0.26)
hocon (1.1.3)
jar-dependencies (0.2.6)
jruby-openssl (0.9.16 java)
json (1.8.0 java)
locale (2.1.2)
rake (10.1.0)
rdoc (4.1.2)
retries (0.0.5)
semantic_puppet (0.1.3)
text (1.3.1)

node is CentOS 7.4
jenkins-2.73.3-1.1.noarch
puppet-agent-1.10.9-1.el7.x86_64

/opt/puppetlabs/puppet/bin/gem list

*** LOCAL GEMS ***

bigdecimal (1.2.4)
deep_merge (1.0.1)
facter (3.6.8)
fast_gettext (1.1.0)
gettext (3.2.2)
gettext-setup (0.20)
hiera (3.3.2)
hocon (1.2.5)
io-console (0.4.3)
json (1.8.1)
locale (2.1.2)
minitest (4.7.5)
net-ssh (4.1.0)
psych (2.0.5)
puppet (4.10.9)
rake (10.1.0)
rdoc (4.1.0)
retries (0.0.5)
semantic_puppet (0.1.2)
stomp (1.3.3)
test-unit (2.1.9.0)
text (1.3.1)

[matonb]

Tinkering a bit more, adding the -remoting option to the command seems to succeed

/bin/java -jar /usr/lib/jenkins/jenkins-cli.jar -remoting -s http://localhost:8080 groovy /usr/lib/jenkins/puppet_helper.groovy get_security_realm
{
    "setSecurityRealm": {
        "hudson.security.SecurityRealm$None": [
            
        ]
    }
}

[jhoblitt]

@matonb The recently introduced semantics with respect to remoting are a bit wacky and need to be revisited. I've had to hack it up for $day_job's production env.

[matonb]

@jhoblitt That's fair enough always a PITA when API's change

[matonb]

@jhoblitt
I tried to shoe-horn the -remoting option in to the command line, ran in to a couple of issues there.
branch here

Any ideas on the following issues ?

First off it can't find the cli_remoting_free fact,

2017-11-15 08:26:42 +0000 Facter (debug): custom fact "jenkins_cli_remoting_free" was not found.
2017-11-15 08:26:42 +0000 Puppet (debug): cli_remoting_free: false
2017-11-15 08:26:42 +0000 Puppet (debug): command:           ["groovy", "/usr/lib/jenkins/puppet_helper.groovy", "get_security_realm"]

So I forced it by removing the cli_remoting_free test, it then barfed with this error (no idea where to start with this one):

Error: /Stage[main]/Profiles::Jenkins/Jenkins_security_realm[hudson.plugins.active_directory.ActiveDirectorySecurityRealm]: Could not evaluate: Execution of '/bin/java -jar /usr/lib/jenkins/jenkins-cli.jar -remoting -s http://localhost:8080 groovy /usr/lib/jenkins/puppet_helper.groovy set_jenkins_instance' returned 1: ERROR: Unexpected exception occurred while performing groovy command.
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.io.File#<init>.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
	[class java.lang.String]
	[class java.net.URI]

[matonb]

btw, I'm only checking for groovy in this test case based on point 2 in this post

[nmaludy]

Looks like Jenkins finally removed this functionality and throws an error if you try to use it:

Error: Could not prefetch jenkins_credentials provider 'cli': Execution of '/bin/java -jar /usr/lib/jenkins/jenkins-cli.jar -s http://localhost:8080 -logger WARNING groovy /usr/lib/jenkins/puppet_helper.groovy credentials_list_json' returned 5: ERROR: This command is requesting the -remoting mode which is no longer supported. See https://jenkins.io/redirect/cli-command-requires-channel

I'm trying to get jenkins_credentails type working with no luck.

[witjoh]

@nmaludy
works for me with LTS but latest. I have in my profile in /facts.d/jenkins_profile.yaml following facts defined:
jenkins_cli_username: jenkins_user jenkins_cli_remoting_free: true jenkins_cli_ssh_keyfile: /var/lib/jenkins/.ssh/id_rsa_cli jenkins_ssh_private_key: /var/lib/jenkins/.ssh/id_rsa_cli
if using ldap, that user must exist over there.
hth

[nmaludy]

@witjoh i'm running 2.176.2 and seeing the error above, even without authentication enabled.

Some googleing led me here: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/cli/CLICommand.java#L324

You can see the CLI is throwing that exception in the latest master branch.

Checking the commit logs for that file: https://github.com/jenkinsci/jenkins/commits/master/core/src/main/java/hudson/cli/CLICommand.java

It appears that they change the behavior back in January 2019.

[witjoh]

@nmaludy 2.176.2 beaks everything with me, so still on 2.176.1.
if you need more info, chack back on monday afternoon.

[ekohl]

The legacy remoting has been removed from recent versions. In #984 I'm dropping the code.