Version 5.103 (latest) can't connect to XCP-NG host anymore

[bufanda]

After updateing to 5.103 the container isn't connecting anymore to the XCP-NG Host.
The following Error message is printed

_watchEvents Error: socket hang up
    at connResetException (node:internal/errors:711:14)
    at TLSSocket.socketCloseListener (node:_http_client:461:25)
    at TLSSocket.emit (node:events:525:35)
    at TLSSocket.patchedEmit [as emit] (/home/node/xen-orchestra/@xen-orchestra/log/configure.js:135:17)
    at node:net:298:12
    at TCP.done (node:_tls_wrap:587:7)
    at TCP.callbackTrampoline (node:internal/async_hooks:132:17) {
  code: 'ECONNRESET',
  url: 'https://10.14.14.90/jsonrpc',
  call: {
    method: 'event.from',
    params: [ [Array], '00000000000018624678,00000000000018564034', 60.1 ]
  }
}

I have updated XCP-NG to the latest patches in Version 8.2.1.
The SSL Connection uses a self signed certificate

* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=10.14.14.90
*  start date: May 12 23:32:44 2020 GMT
*  expire date: May 10 23:32:44 2030 GMT
*  issuer: CN=10.14.14.90

[Ezka]

Hi @bufanda

Can't help much with the errors logs, but I think if between XCP-ng and your XOA docker you'r using a self-signed SSL connection you will need to add in the docker your self-signed root certificate.

Again, check by yourself but I think you need to append your pem file to /etc/ssl/certs/ca-certificates.crt in the docker, so mount your pem file at container startup, open a terminal in the docker and cat your_ca.pem >> /etc/ssl/certs/ca-certificates.crt

If you find something that work for you let me know, may be I'll manage a way to make the thing easier to configure.

[Michael Dombrowski]

Same problem with me: vatesfr/xen-orchestra#6475. Not related to TLS as far as I can tell.

Rolling back to the previous tag on dockerhub fixes things, but I've also rebuilt the image locally with various versions of XOA, back to 5.96.0 and none of them are working. So I'm suspecting some issue with this repo, or one of the dependencies it is pulling in.

[Ezka]

Thanks you for your return @MikeDombo,

indeed if an old docker image works and building the same version get the issue ... it's quite reasonable to think that a dependence is in cause. The 5.100 tag in my docker hub is 2 month old, but starting with the 5.103 I add some "optimization" steps to strip the dependencies and minimize the image footprint.

If you can make a test with the branch : tb-no_npm_optimisation a build of this image will remove any "alterations" from the sources repos and gives a better comparison with the working version 5.100.

[bufanda]

@MikeDombo Yeah that's also what I found. First I tried to inject the SSl Certs but then realized that Xen-Orchestra already has a switch built in on the UI to ignore invalid certs which I had enabled.

Then to exclude a general issue in Xen-Orchestra I spun up a fresh AlmaLinux 8 VM and installed Xen-Orchestra from Source without docker in between. Here I was able to connect to my Host.

After that I tried to rebuild also multiple images with various Xen-orchestra versions and the HEAD of this repo.

I will now try the branch @Ezka77 mentioned. I'll get to you.

[bufanda]

So I tried the branch you provided still had the same issue. I then took a closer look at node. The 5.103 Image on the hub uses node 19.0.0. I then check the 5.100 Image it uses Node 18.8. So I change the node image in the build step to '18-alpine3.16' and now it's working. Seems node 19 is the culprit here and breaks Xen-Orchestra.

Edit: I also tried it with the HEAD of this repo and it works with your clean up steps.

[bufanda]

I open PR #52

[Michael Dombrowski]

+1, verified using the older node 18 image works.

[Ezka]

Ah! nice catch, not the first time I bump the alpine version image and it bumps the node image too. I'll merged your fix asap, and push a working image on docker hub.