Azure DevOps EPROTO Error

SonarQube
1

We are working on upgrading our installation of SonarQube to Version 9.9.

Using Version 5.* of the Prepare Analysis on SonarQube task in Azure DevOps Server 2020 we get the following errors:

##[debug]e71dba46-4e0d-4cf1-9c43-01f1452e5d21=https://<internal url>/sonarqube
##[debug]e71dba46-4e0d-4cf1-9c43-01f1452e5d21 auth param apitoken = undefined
##[debug]e71dba46-4e0d-4cf1-9c43-01f1452e5d21 auth param username = ***
##[debug]e71dba46-4e0d-4cf1-9c43-01f1452e5d21 auth param password = undefined
##[debug]organization=undefined
##[debug]scannerMode=CLI
##[debug]configMode=file
##[debug]configFile=D:\azagent\_work\300\s\sonar-project.properties
##[debug][SQ] API GET: '/api/server/version' with query "undefined"
##[debug][SQ] API GET '/api/server/version' failed, error was: {"errno":"EPROTO","code":"EPROTO","syscall":"write"}
##[debug]task result: Failed
##[error][SQ] API GET '/api/server/version' failed, error was: {"errno":"EPROTO","code":"EPROTO","syscall":"write"}
##[debug]Processed: ##vso[task.issue type=error;][SQ] API GET '/api/server/version' failed, error was: {"errno":"EPROTO","code":"EPROTO","syscall":"write"}
##[debug]Processed: ##vso[task.complete result=Failed;][SQ] API GET '/api/server/version' failed, error was: {"errno":"EPROTO","code":"EPROTO","syscall":"write"}

Our Sonarqube instance is running on a Debian VM under Docker using Nginx in front of it for SSL termination and to serve is under /sonarqube.
The SSL Cert used on Nginx is created/signed by our internal CA instead of being self signed.

It seems to be directly related to the SSL Nginx is presenting because using the same configuration running the web server on HTTP works fine, but our security office definately wont let that fly, even if it’s internal use only.

Any thoughts? I have not seen many posts calling out the EPROTO error and a fix…

2

After some messing around it looks like this is related to the version of Node used in the Sonar tasks on DevOps. It looks like the Prepare Analysis task explicitly looks for node10:

2023-03-06T16:43:35.5126641Z ##[section]Starting: Prepare analysis on SonarQube
2023-03-06T16:43:35.5563800Z ==============================================================================
2023-03-06T16:43:35.5564381Z Task         : Prepare Analysis Configuration
2023-03-06T16:43:35.5564877Z Description  : Prepare SonarQube analysis configuration
2023-03-06T16:43:35.5565266Z Version      : 5.11.1
2023-03-06T16:43:35.5565631Z Author       : sonarsource
2023-03-06T16:43:35.5566257Z Help         : Version: 5.11.1. [More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html)
2023-03-06T16:43:35.5566949Z ==============================================================================
2023-03-06T16:43:35.7941921Z ##[error]This step requires a node version that does not exist in the agent filesystem. Path: D:\azagent\externals\node10\bin\node.exe
2023-03-06T16:43:35.7962301Z ##[section]Finishing: Prepare analysis on SonarQube

And testing Node10 against our newer installation of SonarQube, it seems to have the TLS problem. I am using the request package to call the same version API of our SonarQube install:

D:\nodeHttp>d:\azagent\externals\node10\bin\node.exe -v
v10.23.0

D:\nodeHttp>d:\azagent\externals\node10\bin\node.exe request.js
{ Error: write EPROTO 5224:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:c:\ws\deps\openssl\openssl\ssl\record\rec_layer_s3.c:1544:SSL alert number 70

    at WriteWrap.afterWrite [as oncomplete] (net.js:789:14) errno: 'EPROTO', code: 'EPROTO', syscall: 'write' }
5

Hi @Brandon_Etheredge

This node version is dependent on the agent running all the tasks itself. Unless otherwise a fix can be implemented on ours, I would suggest to contact the azure devops community directly, on microsoft’s side, and let us know (as you said, we didn’t had to deal with this so far it seems).

Thank you.
Mickaël

7

I think I just forced the server to allow TLSv1.2 connections instead of dealing with older versions of Node.
It looks like the maintainers of the agent code are prepared to make the jump to a newer version of Node.

Edit:
It does look like newer versions of the agents do use Node 10 instead of Node 6 for their internals… but I think that was still having the TLS issue so I just kept to TLSv1.2

1 Like
9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.