We are working to integrate a NICE DCV Desktop application with our OOD portal for our users. We have the DCV server ready and we can launch sessions via OOD and connect with authentication to the session created using this URL format:
We are trying to use reverse proxy with OOD just like we do with apps like CodeServer (which uses this format: https://#{OOD_url}/rnode/node01/22320/?folder=/home/validuser), but we are getting an error related with the internal reverse proxy.
We are trying to see if we need to configure anything else, but we are a bit lost. The idea is to have this type of URL to connect to the app’s session:
I would suggest you try to curl 10.3.3.7:8443 from the same machine that OnDemand is installed on. This will replicate what apache is attempting to do.
From the error message above - it was able to make a TCP connection to that URL, but the HTTP response got mangled or malformed somehow or the server disconnected abruptly.
In any case - using curl from the same machine OnDemand is installed on to the same machine that’s running the application should help you debug.
@laura-olivera99 is a colleague of mine who’s also working with me on the Open OnDemand projects — I’m bringing her into the Discourse .
Regarding the question Laura posted earlier: we followed your suggestion to test the connection with curl from the OOD server to the compute node’s port, and found something interesting. We’re basing our NICE DCV integration on the AWS example project ondemand-dcv, where they define a custom connection template (adding dcv.rb alongside basic.rb, vnc.rb, and vnc_container.rb). This makes it straightforward to configure and launch DCV-based interactive sessions.
As for the connection method, the AWS example provides two options: using an Application Load Balancer (ALB), or relying on OOD’s built-in reverse proxy. For our project, we wanted to use the reverse proxy approach — similar to what we do for other apps like RStudio (via /rnode) or Jupyter (via /node). However, we weren’t able to get it working with the DCV server.
When we tried the curl tests you recommended, we noticed that while HTTP requests failed, HTTPS requests succeeded. After digging a bit, we realized NICE DCV only listens over HTTPS. That got me looking more closely into how the reverse proxy works at a lower level. Reviewing the logs and the Lua handlers under /opt/ood/mod_ood_proxy/lib/, I saw that all reverse proxy connections from OOD to the compute nodes use HTTP — which made sense, considering a conversation we had here about securing traffic between OOD and the nodes.
To resolve this, I added a new Apache config snippet in /etc/httpd/conf.d/ood-custom-dcv.conf, instead of modifying the main ood-portal.conf (since that one is regenerated and shouldn’t be edited manually). The custom file defines a new <LocationMatch "^/dcv/(?<host>[^/]+)/(?<port>\d+)(?<uri>/.*|)"> block, which redirects requests to a new Lua script: /opt/ood/mod_ood_proxy/lib/dcv_proxy.lua. That script sets up and manages the HTTPS connection to the DCV server.
With this configuration in place, we now have NICE DCV sessions running and accessible directly through our Open OnDemand portal.
Glad to hear you worked it all out! That said - you can add these lines to the actual ood-portal.conf through the custom_vhost_directives configuration.
.