[JIRA] (JENKINS-61212) CLI, Agent -websockets DeploymentException: Handshake response not received

15 views
Skip to first unread message

fred.vogt@gmail.com (JIRA)

unread,
Feb 24, 2020, 11:08:02 PM2/24/20
to jenkinsc...@googlegroups.com
Fred Vogt updated an issue
 
Jenkins / Bug JENKINS-61212
CLI, Agent -websockets DeploymentException: Handshake response not received
Change By: Fred Vogt
Summary: CLI, Agent -websockets hangs, then DeploymentException: Handshake response not received
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

o.v.nenashev@gmail.com (JIRA)

unread,
Feb 25, 2020, 8:25:03 AM2/25/20
to jenkinsc...@googlegroups.com

o.v.nenashev@gmail.com (JIRA)

unread,
Feb 25, 2020, 8:25:03 AM2/25/20
to jenkinsc...@googlegroups.com

jglick@cloudbees.com (JIRA)

unread,
Feb 25, 2020, 8:45:02 AM2/25/20
to jenkinsc...@googlegroups.com

Probably something specific to your environment. First try using JDK 8 on both client and server (11 is in general poorly tested in Jenkins). Then check your service setup. You are using the built-in Winstone/Jetty servlet container? How is HTTPS being terminated—by Jetty’s built-in options (never before tested with WebSocket AFAIK), or using some sort of reverse proxy (which)?

o.v.nenashev@gmail.com (JIRA)

unread,
Feb 25, 2020, 8:47:03 AM2/25/20
to jenkinsc...@googlegroups.com

o.v.nenashev@gmail.com (JIRA)

unread,
Feb 25, 2020, 8:48:03 AM2/25/20
to jenkinsc...@googlegroups.com

o.v.nenashev@gmail.com (JIRA)

unread,
Feb 25, 2020, 8:48:04 AM2/25/20
to jenkinsc...@googlegroups.com

fred.vogt@gmail.com (JIRA)

unread,
Feb 25, 2020, 9:07:06 AM2/25/20
to jenkinsc...@googlegroups.com

Jesse Glick - thanks  for the prompt response.

You are probably right.  I'll do testing with different combinations of jdk-8 and without HTTPS today.

It will take me a bit of time to come up with the smallest reproducible setup and test with jdk-8.

server-*.pem is a self-signed cert with :

localhost
127.0.0.1
jenkins-server

google chrome likes it when imported (Mac/Linux)

The client / agent are connecting using a different container over a bridge network.

server:

# winstone args
--httpsPort=${HTTPS_PORT-8443} \
--httpsPrivateKey=/var/jenkins_home/tls/server-rsa.pem \
--httpsCertificate=/var/jenkins_home/tls/server-cert.pem} \
--extraLibFolder=/var/jenkins_home/extraLibs \
--accessLoggerClassName=winstone.accesslog.SimpleAccessLogger \
--simpleAccessLogger.format=combined \
--simpleAccessLogger.file=/var/jenkins_home/logs/access.log  \

client:

java \
  -Djavax.net.ssl.trustStore=/var/lib/jenkins/truststore.jks \
  -Djavax.net.ssl.trustStorePassword=jenkins \
  -Djava.util.logging.config.file=/var/lib/jenkins/debug-logging.properties  \
  -jar "../jenkins-cli.jar" \
  -s "https://jenkins-server:8443" \
  -webSocket \
  -logger FINE \
  -auth "$AGENT_AUTH" \
  <args>

jglick@cloudbees.com (JIRA)

unread,
Feb 25, 2020, 9:40:06 AM2/25/20
to jenkinsc...@googlegroups.com

Definitely I never tried to test against Winstone’s built-in --httpsPort, only against TLS termination done by reverse proxies (specifically Kubernetes ingress). In principle it ought to work to the extent that Jetty supports TLS + WebSocket.

Offhand I suspect that the system properties you are passing to the client are not sufficient for the Tyrus library to recognize the custom certificate. Do you get the same error if you simply omit those properties? If so, this may just be a matter of inadequate error logging.

Reply all
Reply to author
Forward
0 new messages