Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Looking for technical support for RTC Jazz Build Engines

Questions
Tags
Users
Badges
Randall Beck
(22●4●13) May 20 '20, 11:49 a.m.

 Recently, our RTC Admin enabled TLS1.2 enforcement on our RTC Source Code servers. We have been using the instructions at this URL to reconfigure our RTC Jazz Build Engines to accept the TLS1.2 protocol.


This article helped with many of our JBEs, but a few are still unable to communicate with the RTC source code servers. Consequently, we require assistance on how to remediate the remaining JBEs.

The specific error we are not able to resolve are:
"Error logging in to repository ... Remote host closed connection during handshake."

We can provide more details as needed.

Thanks.


0 votes

3 answers
1,825 views
0 votes

3 answers

Permanent link
Davyd Norris
(3.0k●2●19) May 20 '20, 10:17 p.m.
Hi Randall,

The error sounds like the changes haven't been implemented correctly for those engines, especially since you've managed to get all but a few to work.

Are the ones that aren't working exactly the same as the others? If they are then I would look for small differences in the jbe.ini file, in the command line used to start them, or in the paths

0 votes

Permanent link
Randall Beck
(22●4●13) May 21 '20, 10:15 a.m.

  Hi Davyd,


Thank you for your response. Still not working, but I have made some forward progress in the past 24 hours. Here's what I have learned:
  1. When I added the TLS directive -Dcom.ibm.team.repository.transport.client.protocol=TLSv1.2 to buildsystem/buildengine/eclipse/jbe.ini I still see the handshake failure, and the JBE fails to start.
  2. If I remove that entry from jbe.ini, and add it to buildsystem/buildengine/eclipse/jbe.sh, the JBE starts up successfully, but when it picks up a job, it fails with the message: Remote host closed connection during handshake.
  3. If the Build Definition is of type "Ant - Jazz Build Engine", I can add the string -Dcom.ibm.team.repository.transport.client.protocol=TLSv1.2 to the "Java VM arguments" field on the "Ant" tab. This works, and picks up a build request successfully.
  4. Encouraged by my luck with an Ant Build Def, I was hoping there was a way to pass the TLS directive to  Build Definitions of type "Command Line", but I see no way to do that in either the "Jazz Source Control" or "Command Line" table.
In summary, here are the questions that linger:
  • Is there a way to send -Dcom.ibm.team.repository.transport.client.protocol=TLSv1.2 for a "Command Line" build definition?
  • What is different about the communication between the RTC Server and the JBE that allows the JBE to start successfully, but fails the build request? 
Thanks again.

--Randy

0 votes

Comments
Davyd Norris
May 21 '20, 9:51 p.m.
So a couple of things:
 - from the above it appears you're using the Build System on Linux machines. Are all the engines on Linux, or are they on different OS? Are the ones that are working on the same or different?
 - did you have to do both 2 and 3 above to get the engine to work? I would have thought both were required because you need to be able to connect first and then service the jobs
 - every connection you make back to the ELM server is going to have to use TLS 1.2, so that would mean if your command line was pushing a build progress update or something, it'll need it too. Maybe that's where the job fails?
 - do you have build engine logs at all?

Permanent link
Randall Beck
(22●4●13) edited
May 22 '20, 1:26 p.m.

 Hi Davyd,

To answer your questions:

> Are all the engines on Linux, or are they on different OS?

> Are the ones that are working on the same or different?

They are all 100% Linux systems, RHEL 7.8 to be precise. What's unique about the ones that are not working is that their Build   Definition is of type "Command Line".  The RTC Build Definitions that are working are all of type "Ant - Jazz Build Engine".  This means that the same JBE will work for any build def of type Ant, and will fail for any build def of type "Command Line".

 > did you have to do both 2 and 3 above to get the engine to work?

 > I would have thought both were required because you need to be

 > able to connect first and then service the jobs

Correct. Adding the TLS1.2 string to jbe.sh is necessary and sufficient for a successful build only if the build def is of type Ant.

 > every connection you make back to the ELM server is going to have to

 > use TLS 1.2, so that would mean if your command line was pushing a

 > build progress update or something, it'll need it too. Maybe that's where

 > the job fails?

Yes, that is precisely the problem. I have not found a way to pass the TLS1.2 string using any of the tabs on the Build Definition of type "Command Line". The build def of type "Ant" allows me to pass the TLS1.2 string on the Ant tab using the "Java VM arguments" field.

In summary, I need to tell Java from a "Command Line" build def that I want to use the TLS1.2 string. I have tried setting JAVA_OPTS, but that did not work

-Randy 

0 votes

Comments
Davyd Norris
May 22 '20, 9:28 p.m.
Do you have a command line you can share with us? The line itself and any script you're using? Obfuscate or sanitise if you have to.

What I want to see is where you're potentially communicating back to the ELM server from either the command line or the script.

The other thing to try is add the -verbose option to jbe.sh to get detailed logging

Randall Beck
May 26 '20, 5:48 p.m.

Hi Davyd,


Getting closer, but one question remains: 

How can I pass the Java TLS1.2 argument using a Command Line build definition?

These are the available fields:
  1. Command
  2. Arguments
  3. Working Directory
  4. Properties
  5. Environment variables
Thanks again for sticking with me.

--Randy
 

Davyd Norris
May 26 '20, 9:06 p.m.
This is something you will likely have to bake into your actual commands in the command line itself.

I also think there's a way to add the TLS info into the JBE running the Ant builds without having to add it into the vm arguments, but you've got that working now so we can leave it be for now.

If you can show us what is actually being executed in the command line then we may be able to spot the problem.

Another thing to try out is create a super simple command line that just returns a success or fail code and try running that. If that works then it's definitely the command line script that's being run.

Also turn on verbose reporting for the engine, and have a look at where it fails - you may find it's actually running the script but returning that error inside it somewhere

Randall Beck
May 27 '20, 9:57 a.m.

G'Day Davyd,


It's working now, and I cannot thank you enough for your guidance.  The solution was staring me in the face, but it took your most recent note to jar my mind.

The script that is called by the Command Line build definition is named "build.sh". The first thing this script does is checkout the source code from the SCM library.   What was missing from this script was the TLS1.2 directive, informing the extract process to use the TLS1.2 protocol. This explained why the JBE was able to start, but failed during the extract.

All needed to do was to modify "build.sh" by adding the TLS1.2 parameter. Once I did that, the build extracted the source code without issue.

Again, thanks so much for you help!

--Randy

Davyd Norris
May 27 '20, 8:45 p.m.

YAY!!! Awesome news mate. So glad you got it running

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: May 20 '20, 11:49 a.m.

Question was seen: 1,825 times

Last updated: May 27 '20, 8:45 p.m.

Confirmation Cancel Confirm