[ovirt-users] get UI working throug ALIAS and real hostname

[Juan Hernández]

On 01/24/2017 03:49 PM, Doug Ingham wrote:
> On 24 January 2017 at 15:15, emanuel.santosvarina at mahle.com
> <mailto:emanuel.santosvarina at mahle.com> wrote:
> 
>     If I access the UI via "ALIAS" I get the Error-Page "The client is
>     not authorized to request an authorization. It's required to access
>     the system using FQDN.
> 
>     What can I do to get UI working through ALIAS and real hostname?
> 
> 
> The Hosted-Engine should be installed & configured with the correct FQDN
> to begin with. Changing it post install is currently unsupported & can
> cause a whole host of problems. There are a couple of documented cases
> where people have attempted to do so with varying success, but non have
> come out problem free.
> 
> I'm currently in the same situation after a company domain change and
> have decided that the risk of unforeseen issues & potential problems
> down the line, are far greater than the pain of redeploying & migrating
> to a new environment.
> 
> A really hacky hack, without interfering with the engine, would be to
> try & put a reverse proxy in front, but that'll require a load of
> dynamic rewriting filters to work.
> 
> 
> On 24 January 2017 at 11:41, Juan Hernández <jhernand at redhat.com
> <mailto:jhernand at redhat.com>> wrote:
> 
>     Create a 99-whatever-you-like.conf file in
>     /etc/ovirt-engine/engine.conf.d with the following content:
> 
>       SSO_ALTERNATE_ENGINE_FQDNS="thealias"
> 
>     Then restart the engine:
> 
>       systemctl restart ovirt-engine
> 
>     This setting is documented here:
> 
> 
>     https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-engine/ovirt-engine.conf.in#L363-L366
>     <https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-engine/ovirt-engine.conf.in#L363-L366>
> 
> 
> AFAIK, the SSL certificates will still need updating & I've read of
> people still having other issues due to differing FQDNs. Being able to
> update the HE's FQDN would be of big interest to me, but I've not yet
> seen one case where it didn't end with anomalies...
> 

Correct, if the FQDN of the engine changes it is a completely different
story. But in this case my understanding is that the objective is
accessing the engine using an alternative name, probably a DNS CNAME. In
that case changing the configuration as proposed should work.