[JENKINS-41745] Updating CLI documentation for non-Remoting modes #802
Conversation
content/doc/book/managing/cli.adoc
Outdated
| 23:21 <@danielbeck> it's probably better in general, but e.g. firewalls rules may require regular CLI use | ||
| 23:21 <@danielbeck> in any case, auth needs to use SSH keys | ||
| //// | ||
| Prior to Jenkins 2.54, use of the custom CLI client is not recommended for security reasons: |
There was a problem hiding this comment.
If merged into this week’s release, obviously.
| ==== | ||
| The `JENKINS_URL` environment variable is automatically set when Jenkins forks a process | ||
| during builds or Pipelines, allowing the use of the Jenkins CLI from inside a | ||
| project without explicit configuration of the Jenkins URL. |
There was a problem hiding this comment.
Deleting this tip since
- some of the commands relying on this trick, such as
set-build-result, will not work without Remoting mode - even if they do, you have to somehow pass a real user’s authentication along to a Jenkins build, which is inherently risky
|
|
||
| === Common Problems | ||
| ===== Common Problems with the Remoting-based client | ||
|
|
||
| There are a number of common problems that may be experienced when running the |
There was a problem hiding this comment.
This is far from an exhaustive list. In the links section of JENKINS-41745 I have tried to dig up various issues that I suspect are limited to Remoting mode.
|
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
content/doc/book/managing/cli.adoc
Outdated
| 23:21 <@danielbeck> it's probably better in general, but e.g. firewalls rules may require regular CLI use | ||
| 23:21 <@danielbeck> in any case, auth needs to use SSH keys | ||
| //// | ||
| Prior to Jenkins 2.54, use of the custom CLI client is not recommended for security reasons: |
There was a problem hiding this comment.
The phrasing "custom CLI client" is ambiguous IMHO. "I never downloaded a custom client, I used the one shipped with Jenkins!"
I suggest rephrasing to something more assertive too, like:
Using the CLI client
.jarwith versions older than Jenkins 2.54 is not recommended, as the older CLI client defaults to a transport mode (JNLP) with a history of security issues . As of 2.54, the CLI client.jaruses more a more secure default mode (HTTP,-http).
There was a problem hiding this comment.
Please do not conflate JNLP with the CLI protocol.
They are two different protocols, and JNLP4 should now be just as safe as SSH for launching a build agent.
The issue with the CLI is fundamentally exposing the remoting protocol with the serialisation vectors to persons other than the Jenkins Admin.
We need admins to launch agents either with JNLP4 or SSH and conflating with the CLI protocol may cause confusion and drive them to SSH as the only slave launch mechanism (which is bad)
There was a problem hiding this comment.
s/JNLP/remoting/ still works for me
There was a problem hiding this comment.
Right, it is the protocol, not the transport, which is the problem. Remoting protocol is insecure over either TCP or HTTP Duplex transport.
I will try to amend this text along the lines of what @rtyler suggests.
And clarifying surrounding text as suggested by @rtyler.
| ==== | ||
| === Client connection modes | ||
|
|
||
| There are three basic modes in which the 2.54+ client may be used, selectable by global option: |
There was a problem hiding this comment.
(version number here and elsewhere to be adjusted according to actual merge target)
|
Ready for merge I think. PR error looks unrelated: See INFRA-1139. |
|
@reviewbybees done |
|
I'm just going to interpret
from @rtyler as approval, otherwise I'd have to adjust my (approved) blog post. |
Presumes jenkinsci/jenkins#2795 is merged.
@reviewbybees