Nodes via Headless WebStart: Unable to checkout git repository using credentials

[Jannis Achstetter]

Hi,

 

I'm facing an issue in a master/slave Jenkins setup. Version of master is 2.89.2, slaves are running Linux.

 

If a node is connected via the "Launch slave agent via SSH" method, everything is working as expected.

 

When I use the "Launch agent via Java Web Start" method and use this command to connect the node to the master:

                java -jar agent.jar -jnlpUrl https://MASTER/computer/SLAVENAME/slave-agent.jnlp -secret SECRET

the node is connected successfully to the master and jobs are being executed.

 

The problem arises when a second git repository is to be checked out during build with this step in our build pipelines:

                dir('keys') {

                                git url: 'g...@github.enterprise.com:ORG/REPO.git', credentialsId: 'MyCredentials'

                }

‘MyCredentials’ is a private SSH key with username and passphrase to decrypt the key, stored in the Jenkins master.

 

The build times out after waiting 10 minutes for the step to finish with no relevant info (stack trace + exit code for SIGTERM + no stdout + no stderr) in the build log. However, on the terminal where the agent.jar was started there is this output:

                May 02, 2018 2:25:05 PM hudson.remoting.jnlp.Main$CuiListener status

INFO: Connected

Enter passphrase for key '/var/lib/jenkins/workspace/PROJECTNAME':

 

So it seems that when using the WebStart-method, something is wrong with the stdin/stdout redirection. In the wiki (https://wiki.jenkins.io/display/JENKINS/Distributed+builds) it says: “execute the agent program like java -jar agent.jar, on the right computer, and have its stdin/stdout connect to your script's stdin/stdout”. I’m not sure if I’m doing something wrong because all examples for headless just run the java command as shown above.

 

Any ideas if this is valid bug, I’m doing something wrong or that scenario is currently just not supported?

 

Thanks!

 

Jannis Achstetter Technical Engineer Mobility Innovation & Technology Digitization Industry Business Schneider Electric Automation GmbH	D  +49 9391 606 - 2897 E  jannis.a...@schneider-electric.com	Schneiderplatz 1 97828 Marktheidenfeld Germany
http://www.schneider-electric.com/ww/en/
*Please consider the environment before printing this e-mail

 

Sitz der Gesellschaft: Marktheidenfeld | Amtsgericht Würzburg | HRB 10733 | USt-IdNr. DE261529553 Geschäftsführer: Thomas Martis, Ottmar Himmelsbach

 

 

[Mark Waite]

Since you're running `java -jar agent.jar -jnlpUrl https://MASTER/computer/SLAVENAME/slave-agent.jnlp -secret SECRET` from a command line, the ssh command invoked by command line git believes there is a controlling terminal and prompts on that controlling terminal for the passphrase.

You can probably prevent that prompt on Linux by adding `setsid` before that command to launch the JNLP agent.  The `setsid` command runs the program in a new session, detached from the controlling terminal.

The new command would be:

    setsid java -jar agent.jar -jnlpUrl https://MASTER/computer/SLAVENAME/slave-agent.jnlp -secret SECRET 

There is a Java property that attempts to force that behavior.  For compatibility purposes, that property defaults to false.  You should be able to set it to true with the additional argument:

-Dorg.jenkinsci.plugins.gitclient.USE_SETSID=true 

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/VI1PR04MB31506BC1A82F0403511F1DB2D2800%40VI1PR04MB3150.eurprd04.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[Jannis Achstetter]

Hi Mark,

 

Nailed it! Thanks for the fast response, using setsid solves the problem! I’d like to add this to the wiki but due to some ldap-server fallout, I’m currently unable to login.

 

About the Java property org.jenkinsci.plugins.gitclient.USE_SETSID you mentioned some “compatibility” issues that lead to this property not being set to true by default. Are there any problems to be expected using setsid?

 

Thanks,

                Jannis

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFpbJCQ5s_L8c6zZxwoSCJf11JcpvzDGvG4UGk7rYnPFQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

[Mark Waite]

The USE_SETSID defaults to false because I was unable to predict all the places where users might have depended on the existing behavior.

For example, I'm not sure what would happen to a JNLP agent that was started from a shell which had a running ssh-agent.  I've learned by sad experience that the combinations and configurations I test are a fraction of the combinations and configurations that are important to users.

I'm not aware of any specific cases where USE_SETSID=true would have an undesirable result, but I didn't want to risk incompatibility for a case that I believe is rare.  I believe that most Jenkins agents are not run from a controlling terminal.  I think it is uncommon to launch a long-running process like a Jenkins agent from a controlling terminal.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/VI1PR04MB3150B8EF045545525BC66F9AD2800%40VI1PR04MB3150.eurprd04.prod.outlook.com.

[Jannis Achstetter]

Perfect, thanks for the detailed explanation.

Sure, a developer in most cases cannot anticipate in which way the software will be used by the community/customers. That’s why a vibrant community is so important 😊

 

The reason why I have a controlling terminal is that the agent is being run inside a Docker container which is not spawned on request but keeps running and waits for jobs as other Jenkins nodes. Might not be the perfect or final solution but was the least painful way to migrate to Docker-based build slaves for now.

 

Nevertheless, setsid helped in that case and I can see where I want to go from there.

 

Thanks again!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEHsaFjYTL8KtV99%2BRUcpUpYVFRgKk7r9BNgFkboAd0eg%40mail.gmail.com.