[JENKINS-34260] slave.jar missing -secret feature

[timja]

Currently the output of slave.jar --help gives me the following:

{{java -jar slave.jar [options...]
-auth user:pass : If your Jenkins is security-enabled, specify
a valid user name and password.
-connectTo HOST:PORT : make a TCP connection to the given host and
port, then start communication.
-cp (-classpath) PATH : add the given classpath elements to the
system classloader.
-jar-cache DIR : Cache directory that stores jar files sent
from the master
-jnlpCredentials USER:PASSWORD : HTTP BASIC AUTH header to pass in for making
HTTP requests.
-jnlpUrl URL : instead of talking to the master via
stdin/stdout, emulate a JNLP client by
making a TCP connection to the master.
Connection parameters are obtained by
parsing the JNLP file.
-noReconnect : Doesn't try to reconnect when a
communication fail, and exit instead
-proxyCredentials USER:PASSWORD : HTTP BASIC AUTH header to pass in for making
HTTP authenticated proxy requests.
-secret HEX_SECRET : Slave connection secret to use instead of
-jnlpCredentials.
-slaveLog FILE : create local slave error log
-tcp FILE : instead of talking to the master via
stdin/stdout, listens to a random local
port, write that port number to the given
file, then wait for the master to connect to
that port.
-text : encode communication with the master with
base64. Useful for running slave over 8-bit
unsafe protocol like telnet}}

It seems like there is a hidden "-secret" feature which allows the configuration of EC2 spot instances.

It would be nice if that feature would be available for the general public, as it seems to be a hidden feature without any documentation, but would make certain setups much easier.

---

Originally reported by lifeofguenter, imported from: slave.jar missing -secret feature

• status: Resolved
• priority: Minor
• resolution: Not A Defect
• resolved: 2016-04-15T09:31:17+00:00
• imported: 2022/01/10

[timja]

danielbeck:

-secret HEX_SECRET : Slave connection secret to use instead of -jnlpCredentials.

Hidden, this is not.

Also, it should be shown on the slave index page, i.e. https://jenkins/computer/thenameofthething/.

Additionally, it's just a different way of authenticating the slave to Jenkins so you don't need to store actual Jenkins user credentials. Not clear what magic functionality you expect here.

[timja]

lifeofguenter:

Thanks for the hint danielbeck, however I must be blind because I am not seeing it?

I also can not really find any official documentation on:

• jnlpCredentials
• auth

Some websites (stackoverflow) suggest using jnlpCredentials but not using the user password, but the user api key (which does not correlate with the help instructions), others suggest to use "-user" and "-pass" - e.g. no mention of "-auth".

I understand for a Jenkins veteran this must be all very simple and "basic knowledge", but for someone just starting out it is a little difficult to get information on how stuff is working correctly.

[timja]

danielbeck:

Is the slave configured to use the JNLP launcher? (possibly called "Java WebStart") If not, no support for secrets.

[timja]

lifeofguenter:

Where is this documented though? Not that I am not believing you, but I would like to learn more about it.

[timja]

danielbeck:

Let me filter and reorder the parameter documentation you quoted, maybe it makes sense then…

-jnlpUrl URL : instead of talking to the master via stdin/stdout, emulate a JNLP client by making a TCP connection to the master. Connection parameters are obtained by parsing the JNLP file.
-jnlpCredentials USER:PASSWORD : HTTP BASIC AUTH header to pass in for making HTTP requests.
-secret HEX_SECRET : Slave connection secret to use instead of -jnlpCredentials.

So unless you're using a launcher that "emulate[s] a JNLP client by making a TCP connection to the master", no need for jnlpCredentials/secret. Of course it's not impossible that a plugin may change this around a bit, but since you're not answering my question, I can't provide more specific advice.

[timja]

lifeofguenter:

Ah I think it makes more sense now (I guess). My Jenkins setup has "Jenkins’ own user database" & "Role-Based Strategy" activated, meaning there are no guest activities allowed. So I am running "normal" nodes/slaves as "dumb slave" + "launch slave agents on unix via ssh" - which works perfectly.

Per log I only see the following:
[04/14/16 12:25:27] [SSH] Starting slave process: cd "/var/lib/jenkins" && java -jar slave.jar

Which looks like it is not passing through any credentials, but it still works?

When using the EC2 Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Amazon+EC2+Plugin) and Spot Instances however, I need to start the slave.jar from within the node, there I get a 403 (and I'd be surprised if it just worked, or else any machine could propagate itself as a slave/node).

I am trying to figure out now which parameters I need to use, and as said I am too stupid to find a proper documentation except running java -jar slave.jar --help - which btw. is also not documented but a common way under unix/linux to get some kind of help.

Googleling on those options I am getting mixed information - so it would be great to know which option to use to authenticate the slave.jar, and if it is indeed true that the "password" must be replaced by a users api key.

[timja]

danielbeck:

Which looks like it is not passing through any credentials, but it still works?

Well, the connection has been established from the master, so it's assumed that's legitimate, and the default mode of operation is…

talking to the master via stdin/stdout

---

I need to start the slave.jar from within the node, there I get a 403 (and I'd be surprised if it just worked, or else any machine could propagate itself as a slave/node).

Seems like an oversight in the documentation for the plugin. Also, it should in theory show the secret, but…

JNLP: https://github.com/jenkinsci/jenkins/blob/944571f9b5242b1d1419cdfcd1a4a7d62bc33904/core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly#L69
EC2: https://github.com/jenkinsci/ec2-plugin/blob/a6d2c874daf999362d827430e419d38cefaa7c81/src/main/resources/hudson/plugins/ec2/EC2SpotComputerLauncher/main.jelly#L27...L36

FWIW the secret was only added as an alternative means to connect three years ago. Workarounds:

• Use jnlpCredentials.
• Figure out how to get the secret from the script console.

Resolving as not a defect, because it isn't. You should consider filing an improvement request for the EC2 Plugin.