`xnat_web_server.url` should include the exposed port

[paddyroddy]

Fixes #75. Would be nice to do this as a variable, but not sure how easy that would be to do. Essentially the same change as in UCL-MIRSG/UCLH-MPBE-SRR-XNAT#198.

[paddyroddy]

fatal: [xnat_web]: FAILED! => {"attempts": 10, "changed": false, "elapsed": 0, "msg": "Status code was -1 and not [200]: Request failed: <urlopen error [Errno 111] Connection refused>", "redirected": false, "status": -1, "url": "http://xnat.web.local:8000/"}

Hmm, not too sure I understand what you guys are doing with ports. Can anyone help @UCL-MIRSG/mirsg?

[p-j-smith]

I'm not sure adding the port is necessary? I think the url is already set with the port: https://github.com/UCL-MIRSG/ansible-collection-infra/blob/163a8ddc552b0131df71e9e44ae67b0f582a6d01/roles/xnat/templates/gradle.properties.j2#L9 Or is xnatUrl not where the issue is?

[paddyroddy]

I'm not sure adding the port is necessary? I think the url is already set with the port:

https://github.com/UCL-MIRSG/ansible-collection-infra/blob/163a8ddc552b0131df71e9e44ae67b0f582a6d01/roles/xnat/templates/gradle.properties.j2#L9

Or is xnatUrl not where the issue is?

The current set up doesn't work, unless the port is 80/443. You get kicked off when a redirect fails. @HChughtai may be able to give a better explanation.

[HChughtai]

I'm not sure adding the port is necessary? I think the url is already set with the port:

https://github.com/UCL-MIRSG/ansible-collection-infra/blob/163a8ddc552b0131df71e9e44ae67b0f582a6d01/roles/xnat/templates/gradle.properties.j2#L9

Or is xnatUrl not where the issue is?

This is the internal Tomcat port. What Paddy's referring to is this being set with just the url and not a port: https://github.com/UCL-MIRSG/ansible-collection-infra/blob/main/roles/xnat/templates/prefs-init.j2#L4

In normal cases that doesn't make a difference as it's http/80 or https/443 and the port and protocol are defaults. In testing and non standard set-ups that port could be something arbitary (e.g. 8080). In those cases, if teh site URL doesn't include the port, XNAT will redirect to the wrong location and hit an error.

[HChughtai]

Possibly setting xnat_web_server.url and including the port is sufficient - where it's not a default?

@paddyroddy - ah, that's what you tried. Clearly something else doesn't support that

[HChughtai]

With molecule testing is it similar to Docker where you need to expose ports? If so, I expect theres some test config to be done as well

[paddyroddy]

@p-j-smith in SRR we map 8080:80 https://github.com/UCL-MIRSG/UCLH-MPBE-SRR-XNAT/blob/83f6aa1de30c72ddacb7b0486229a3c6d4e873f8/docker-compose.yml#L117C9-L117C13 so 8080 is exposed, and that is what should be in site URL. By default, HTTP would look for 80 which is what the current set up is doing. In my case, 80 wouldn't work, so we need 8080 to be explicitly set for the URL. Does that make sense?

Are you using HTTP or HTTPS in your molecule tests?

[drmatthews]

Are you using HTTP or HTTPS in your molecule tests?

Just to chip in - HTTP. The published ports are here:

https://github.com/UCL-MIRSG/ansible-collection-infra/blob/163a8ddc552b0131df71e9e44ae67b0f582a6d01/playbooks/molecule/rocky9_xnat/molecule.yml#L73-L74

8080 is exposed but not published:

https://github.com/UCL-MIRSG/ansible-collection-infra/blob/163a8ddc552b0131df71e9e44ae67b0f582a6d01/playbooks/molecule/rocky9_xnat/molecule.yml#L68-L72

(There is an equivalent config for centos7 - https://github.com/UCL-MIRSG/ansible-collection-infra/blob/main/playbooks/molecule/centos7_xnat/molecule.yml)

[p-j-smith]

@paddyroddy I'm not sure but I think you might also need to expose port 8080 of the web container to other containers on the network

[paddyroddy]

@paddyroddy I'm not sure but I think you might also need to expose port 8080 of the web container to other containers on the network

I haven't had to in SRR

[p-j-smith]

I haven't had to in SRR

oh I meant you might need to do it for SRR - it's already done here as @drmatthews linked to

[paddyroddy]

I haven't had to in SRR

oh I meant you might need to do it for SRR - it's already done here as @drmatthews linked to

I don't follow. SRR is working.

[p-j-smith]

In normal cases that doesn't make a difference as it's http/80 or https/443 and the port and protocol are defaults. In testing and non standard set-ups that port could be something arbitary (e.g. 8080). In those cases, if teh site URL doesn't include the port, XNAT will redirect to the wrong location and hit an error.

wouldn't it be better to force users to connect via nginx (on port 80 or 443) rather than access 8080 directly?

[drmatthews]

@paddyroddy, question: why do you need to use 8080? Is it something to do with setting the xnat_web hostname to "localhost"?

[drmatthews]

I didn't phrase that very well. I'm wondering why the hostname for xnat_web is set to "localhost". But I assume 8080 because you can't bind to 80 on the Docker host, hence:

https://github.com/UCL-MIRSG/UCLH-MPBE-SRR-XNAT/blob/83f6aa1de30c72ddacb7b0486229a3c6d4e873f8/docker-compose.yml#L116-L117

My understanding: in SRR, externally XNAT is accessible via 8080. That port binds to 80 in the xnat_web container. In the container nginx is listening on 80 and reverse proxying to tomcat (which is on 8080 inside the container).

[HChughtai]

My understanding: in SRR, externally XNAT is accessible via 8080. That port binds to 80 in the xnat_web container. In the container nginx is listening on 80 and reverse proxying to tomcat (which is on 8080 inside the container).

This is only true in Paddy's dev setup (using localhost:8080 so it can't conflict with anything else running at localhost:80), on the production instance it's setup to use port 80 with the server's hostname. So it's a generalisation point if I understand correctly. It should be possible to run a web service on a non-standard port and have it function correctly.

[paddyroddy]

@paddyroddy, question: why do you need to use 8080? Is it something to do with setting the xnat_web hostname to "localhost"?

8080 was @HChughtai's idea

[paddyroddy]

@p-j-smith and I are on a huddle to discuss this as we speak

[paddyroddy]

I didn't realise that tomcat uses 8080. I was under the impression that >=8000 was unreserved

[HChughtai]

I didn't realise that tomcat uses 8080. I was under the impression that >=8000 was unreserved

Widely used, rather than reserved. It's also widely used as an alternative to 80 (which is why I used it) See https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers. It is also used by our Tomcat definition, but in a different scope to publishing it on your host

[p-j-smith]

@drmatthews I think the issue is that issue if the site URL is e.g. xnat.web.local, then XNAT will some times attempt to redirect to this URL. For example, after creating a project, XNAT attempts to return you to the homepage (xnat.web.local). However, outside of the docker network you connect to the web interface via e.g. localhost:8000, and the host xnat.web.local is not defined outside of the network (unless you add it to your local /etc/hosts).

One solution is to add a new variable xnat_site_url that you can set to be localhost:8000 you are running XNAT in docker and need to access it outside of the docker network (PR #79 does this but perhaps there is a better way?)

@paddyroddy's fix for SRR works there but not here because:

• the hostname for the web container is localhost
• the http port on the web container is published to port 8080 on localhost. This means that when xnat_web_server.url is used in other tasks that run on the web container (e.g. waiting for tomcat to start, localhost:8080 still makes sense - it is the tomcat port on the web container

Sorry that that is most likely not clear or helpful - might be easier to chat about it!

[paddyroddy]

(fixing in #79)