Skip to Content
Technical Articles

Jenkins Configuration- Windows as Master and Linux as Slave

Jenkins fundamental architecture is ‘Master+Slave’ which is distributed in nature.

Master is designed for co-ordination and handling tasks such as scheduling jobs, monitoring slave nodes, dispatching builds to slave nodes, recording and representing the build result and executing build jobs directly.

Slave is designed to perform the work. Agent can run on different operating systems such as Windows and Linux and doesn’t require Jenkins installation on it.

Following document provides details to setup Master Slave configuration in Jenkins. Windows is configured as Master and Linux as Slave node.

Steps to be executed on Master server/Windows

Install Jenkins on Master server

Since the agent node is setup on Linux, it will be launched through ssh.

Secure Shell(ssh) is a network that provides authentication and encrypted data communications between two machines connecting over open network such as the internet.

ssh key authentication is needed to setup agent node.

Generate ssh key

ssh-keygen

‘id_rsa’ private and ‘id_rsa.pub’ public key will be created in the ‘.ssh’ directory

 

Steps to be executed on Slave server/Linux

Setup of slave node requires Java to be installed. Install Java from Oracle Website.

Installed java version can be checked by executing ‘java -version’

Set up environmental variables for the installed java

export JAVA_HOME=/usr/java/latest

export JRE_HOME=/usr/java/latest

Create a new user Jenkins and user group named Jenkins

sudo useradd jenkins -U -s /bin/bash

set password jenkins

Verify by checking in /etc/passwd and /etc/group files

Configure sudo privileges by configuring in /etc/sudousers

jenkins ALL=(ALL)        NOPASSWD: ALL

 

Command to copy ssh-id from Windows to LINUX

After the generation of ssh key, place the public key into the slave machine’s authorized_keys file by executing below command

C:\Users\admin\.ssh> ssh jenkins@<slave machine IP>”umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys || exit 1″ < “umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys || exit 1” < C:\Users\admin\.ssh\id_rsa.pub

After the copy of ssh-id to Slave machine > Try logging into the slave machine by executing following command in Jenkins master machine ssh ‘jenkins@<slave machine IP>’.

 

Setup of Credentials on Jenkins

On Jenkins dashboard click on the Credentials.

 

Click on Global

Click on Add Credentials

Kind: SSH Username with private Key

Username: Jenkins

Private Key: Enter directly and paste the id_rsa private key

Click on OK

 

Jenkins user with SSH key is created.

 

Setup of New Node in Jenkins

Click on Manage Nodes

 

Click on New Node

 

Enter Node name LINUX_DEMO, choose Permanent Agent and click OK

 

  • Description: Slave node
  • Remote root directory: /home/jenkins
  • Launch method: Launch slave agent via SSH
  • Host: IP address
  • Credentials- Jenkins
  • Host Key Verification Strategy – Known hosts file Verification strategy

Click on Save


 

Slave node LINUX_DEMO is created

 

Click on Log to see the connection status details

If all the above steps are executed successfully, connection to slave machine will be established.

Conclusion:

To test a cross-platform code base with a different operating system, you can configure different OS slaves and run the job against it. Also, a distributed architecture will reduce the load on the master server.

In this blog, we have learned how to setup master slave configuration for Jenkins on different operating systems.

 

1 Comment
You must be Logged on to comment or reply to a post.
  • Hello Apoorva,

    You should be careful with that sudoers configuration.

    If your Jenkins master is compromised, one can run arbitrary commands at that Linux node (a.k.a., “slave”), an you can then become “root” on the Linux node without having to know any password.

    If you use

    jenkins ALL=(ALL) ALL

    instead, then even if one gets into the Linux node using the master (or with the private key), it still needs to know the password for the user “jenkins”. The private key will not help becoming “root” ;-).

    Further restrictions are advisable (i.e., is it even required to allow the “jenkins” user to use sudo on the node?)

    Cheers!

    Isaías