JNLP1-connect protocol.
-On successful connection to the master the slave will receive a cookie from the master, which the slave stores.
+On successful connection to the master the agent will receive a cookie from the master, which the agent stores.
-If the slave needs to reconnect it will send the same cookie as part of the new connection request.
+If the agent needs to reconnect it will send the same cookie as part of the new connection request.
The master can use the cookie to determine if the incoming request is an initial connection request
or a reconnection and take appropriate action.
@@ -78,8 +78,8 @@ Check the bugtracker for more issues.
* The protocol is disabled by default in Jenkins
* **Not recommended** for use since the JNLP4-connect release
-This protocol aims to improve security of JNLP-based slaves.
-Both the master and the slave securely authenticate each other and then setup an encrypted channel.
+This protocol aims to improve security of JNLP-based agent.
+Both the master and the agent securely authenticate each other and then setup an encrypted channel.
The protocol does not support non-blocking IO.
For each connection a new thread is being created, and it leads to the performance degradation or
@@ -94,7 +94,7 @@ There is no plan to fix these issues, usage of `JNLP4-connect` is the recommende
* [JENKINS-37302](https://issues.jenkins-ci.org/browse/JENKINS-37302) -
JNLP3 challenge response generates invalid string encoding, the check may fail randomly.
* [JENKINS-33886](https://issues.jenkins-ci.org/browse/JENKINS-33886) -
-On some configurations only one JNLP3 slave per IP address can be connected.
+On some configurations only one JNLP3 agent per IP address can be connected.
* [JENKINS-34121](https://issues.jenkins-ci.org/browse/JENKINS-34121) -
JNLP3 cannot be used on IBM Java, which doesn't support AES/CTR/PKCS5Padding.
diff --git a/docs/remoting-3-compatibility.md b/docs/remoting-3-compatibility.md
index 554461499..6e9343d74 100644
--- a/docs/remoting-3-compatibility.md
+++ b/docs/remoting-3-compatibility.md
@@ -23,8 +23,8 @@ In Remoting 3 the required Java version is updated from Java 6 to Java 7.
In **Jenkins** project:
* Nothing changes, starting from 1.610 Java 6 is not supported in Jenkins,
- on both master and slaves/agents
-* In particular cases it was possible to run Jenkins slaves/agents on Java 6 with Remoting 2.x,
+ on both master and agents
+* In particular cases it was possible to run Jenkins agents on Java 6 with Remoting 2.x,
but this configuration was not officially supported
In other projects:
diff --git a/docs/tcpAgent.md b/docs/tcpAgent.md
index a1bbad8e2..004923ca1 100644
--- a/docs/tcpAgent.md
+++ b/docs/tcpAgent.md
@@ -96,7 +96,7 @@ This allows the Windows Service infrastructure to manage the process lifecycle.
To configure the agent this way, first launch the agent using one of the other mechanisms that doesn't run as headless.
In the agent GUI, select "File -> Install as a service".
-Additional descriptions of configuring this mechanism are located at [Installing Jenkins as a Windows service](https://wiki.jenkins.io/display/JENKINS/Installing+Jenkins+as+a+Windows+service) or [How to Install Several Windows Slaves as a Service?](https://support.cloudbees.com/hc/en-us/articles/217423827-How-to-Install-Several-Windows-Slaves-as-a-Service-)
+Additional descriptions of configuring this mechanism are located at [Installing Jenkins as a Windows service](https://wiki.jenkins.io/display/JENKINS/Installing+Jenkins+as+a+Windows+service) or [How to Install Several Windows Agents as a Service?](https://support.cloudbees.com/hc/en-us/articles/217423827-How-to-Install-Several-Windows-Slaves-as-a-Service-)
## Parameters
diff --git a/docs/workDir.md b/docs/workDir.md
index a98772114..6b7641194 100644
--- a/docs/workDir.md
+++ b/docs/workDir.md
@@ -10,7 +10,7 @@ all operations were managed by library users (e.g. Jenkins agent workspaces).
### Before Remoting 3.8 (Jenkins 2.68)
* There is no work directory management in Remoting itself
-* Logs are not being persisted to the disk unless `-slaveLog` option is specified
+* Logs are not being persisted to the disk unless `-agentLog` option is specified
* JAR Cache is being stored in `${user.home}/.jenkins` unless `-jarCache` option is specified
### After Remoting 3.8 (Jenkins 2.68)
diff --git a/src/main/java/org/jenkinsci/remoting/engine/HandshakeCiphers.java b/src/main/java/org/jenkinsci/remoting/engine/HandshakeCiphers.java
index a6d6a37e0..b120bc3bc 100644
--- a/src/main/java/org/jenkinsci/remoting/engine/HandshakeCiphers.java
+++ b/src/main/java/org/jenkinsci/remoting/engine/HandshakeCiphers.java
@@ -98,12 +98,12 @@ public String decrypt(String encrypted) throws IOException {
* Create a pair of AES symmetric key {@link Cipher}s that
* will be used during the handshake process.
*
- * The slave name and slave secret are used to create a + *
The agent name and agent secret are used to create a * {@link PBEKeySpec} and an {@link IvParameterSpec}which is then used to * create the ciphers. * - * @param salt The slave for which the handshake is taking place. - * @param secret The slave secret. + * @param salt The agent for which the handshake is taking place. + * @param secret The agent secret. */ public static HandshakeCiphers create(String salt, String secret) { try { diff --git a/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol1Handler.java b/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol1Handler.java index b606094a3..84a294713 100644 --- a/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol1Handler.java +++ b/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol1Handler.java @@ -43,11 +43,11 @@ /** * Implementation of the JNLP-connect protocol. * - * The slave sends the master the slave name it wants to register as and the - * computed HMAC of the slave name. If accepted the master will reply with a + * The agent sends the master the agent name it wants to register as and the + * computed HMAC of the agent name. If accepted the master will reply with a * confirmation response. * - * This was the first protocol supported by Jenkins. JNLP slaves will use this + * This was the first protocol supported by Jenkins. JNLP agents will use this * as a last resort when connecting to old versions of Jenkins masters. * * @since 3.0 diff --git a/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol2Handler.java b/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol2Handler.java index 8eeee1bcf..f23b26b75 100644 --- a/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol2Handler.java +++ b/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol2Handler.java @@ -47,10 +47,10 @@ * Implementation of the JNLP2-connect protocol. * * This is an extension of the JNLP1-connect protocol. On successful - * connection to the master the slave will receive a cookie from the master, - * which the slave stores. + * connection to the master the agent will receive a cookie from the master, + * which the agent stores. * - * If the slave needs to reconnect it will send the same cookie as part of + * If the agent needs to reconnect it will send the same cookie as part of * the new connection request. The master can use the cookie to determine if * the incoming request is an initial connection request or a reconnection * and take appropriate action. diff --git a/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java b/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java index d233ca575..841c5d6ee 100644 --- a/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java +++ b/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java @@ -59,29 +59,29 @@ * Implementation of the JNLP3-connect protocol. * *
This protocol aims to provide a basic level of security for JNLP based - * slaves. Both the master and the slave securely authenticate each other and + * agents. Both the master and the agent securely authenticate each other and * then setup an encrypted {@link Channel}. * - *
The slave secret is never exchanged, but instead used as a shared secret + *
The agent secret is never exchanged, but instead used as a shared secret * to generate matching symmetric key {@link javax.crypto.Cipher}s by both * sides which are used to perform a secure handshake. During the handshake - * both the slave and the master send each other challenge phrases which can - * only be decrypted with the matching cipher created with the slave secret. + * both the agent and the master send each other challenge phrases which can + * only be decrypted with the matching cipher created with the agent secret. * Once decrypted the SHA-256 hash of the challenge is computed and sent back * to authenticate. * *
Once the handshake is successful another pair of symmetric key ciphers - * are created by the slave using random keys. These are then shared with the + * are created by the agent using random keys. These are then shared with the * master. These ciphers are used to create an encrypted channel by both sides. * *
The following goes over the handshake in more detail: *
* {@code
* Client Master
- * handshake ciphers = createFrom(slave name, slave secret)
+ * handshake ciphers = createFrom(agent name, agent secret)
*
* | |
- * | initiate(slave name, encrypt(challenge), encrypt(cookie)) |
+ * | initiate(agent name, encrypt(challenge), encrypt(cookie)) |
* | -------------------------------------------------------------->>> |
* | |
* | encrypt(hash(challenge)) |
@@ -111,8 +111,8 @@
* }
*
*
- * The entire process assumes the slave secret has not been leaked - * beforehand and the slave obtains it in a secure manner. + *
The entire process assumes the agent secret has not been leaked + * beforehand and the agent obtains it in a secure manner. * *