After upgrading from OoD-2.0.32 to OoD-3.0.3 our portal doesn’t accept logons through a CNAME.
We have four servers running OoD which are all reachable through a shared CNAME (round-robin DNS). This worked well with OoD-2.0.32. After the upgrade users get: HTTP ERROR 403: Access Denied
We temporarily worked around this by setting (in /etc/httpd/conf.d/ood-portal.conf) SetEnv OOD_ALLOWED_HOSTS "<FQDN CNAME>,<FQDN A-record>"
This config is automatically generated at every boot through the ood-portal-generator, where the <FQDN A-record> is a variable for every host. This means that the work-around will be overwritten after a reboot, so we would like to configure this somewhere in de YAML-files. Could anyone help us achieve this?
Can you supply the servername and proxy_server configurations from your ood_portal.yml? This should have just worked and we’d like to investigate further. As for a workaround, you might be able to supply something in pun_custom_env (nginx_stage.yml — Open OnDemand 3.0.3 documentation):
servername is set to ‘null’, proxy_server is not set
servername: null
#proxy_server: null
Setting a fixed value would be problematic since our servers are all running from the same image, so they have identical yaml-files but different servernames, which would have to be dynamically configured during generation-time. Is there a variable for FQDN or hostname I can use in the yaml-file (i.e. derived from /etc/hostname of the hostname command)?
This in nginx_stage.yml should be a workaround for you as the FQDN CNAME is static and well known before the image is created (or booted). This workaround should work until we fix the system upstream.
We should be populating OOD_ALLOWED_HOSTS correctly for you and obviously we’re not.
Do you use ServerAlias anywhere - we have support for that although I’m finding now it’s not documented.
If you have servername: null how does apache route the request (I’m guessing the requests/users use FQDN CNAME?) to the right configuration?
FQDN CNAME is indeed fixed, but we want the servers also to be accessible on their individual name.
We have login[01-04].domain and a shared CNAME login.domain. We could of course configure all 5 names on all servers and that might work. But it’s ‘wrong’.
No, we don’t use ServerAlias. At least it’s not in our ood_portal.yml. How should we use it to get OoD to work on both the shared name and the individual name.
I suppose the use of servername: null results in a default vhost config:
<VirtualHost *:80>
and
<VirtualHost *:443>
Which is fine at this moment, since this is the only website running on these hosts. Of course it would be better to explicitly naming the vhost with all desired names.
