[Engine-devel] SPICE IP override

[Yaniv Kaul]

On 11/15/2012 06:13 AM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Yaniv Kaul" <ykaul at redhat.com>
>> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
>> Sent: Wednesday, November 14, 2012 11:10:21 PM
>> Subject: Re: [Engine-devel] SPICE IP override
>>
>> On 11/11/2012 11:45 AM, Yaniv Kaul wrote:
>>> On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>>>> ----- Original Message -----
>>>>> From: "Michal Skrivanek"<michal.skrivanek at redhat.com>
>>>>> To:engine-devel at ovirt.org
>>>>> Sent: Tuesday, November 6, 2012 10:39:58 PM
>>>>> Subject: [Engine-devel] SPICE IP override
>>>>>
>>>>> Hi all,
>>>>> On behalf of Tomas - please check out the proposal for enhancing
>>>>> our
>>>>> SPICE integration to allow to return a custom IP/FQDN instead of
>>>>> the
>>>>> host IP address.
>>>>> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
>>>>> All comments are welcome...
>>>> My 2 cents,
>>>>
>>>> This works under the assumption that all the users are either
>>>> outside of the organization or inside.
>>>> But think of some of the following scenarios based on a topology
>>>> where users in the main office are inside the corporate network
>>>> while users on remote offices / WAN are on a detached different
>>>> network on the other side of the NAT / public firewall :
>>>>
>>>> With current 'per host override' proposal:
>>>> 1. Admin from the main office won't be able to access the VM
>>>> console
>>>> 2. No Mixed environment, meaning that you have to have designated
>>>> clusters for remote offices users vs main office users -
>>>> otherwise connectivity to the console is determined based on
>>>> scheduler decision, or may break by live migration.
>>>> 3. Based on #2, If I'm a user travelling between offices I'll have
>>>> to ask the admin to turn off my VM and move it to internal
>>>> cluster before I can reconnect
>>>>
>>>> My suggestion is to covert this to 'alternative' IP/FQDN sending
>>>> the spice client both internal fqdn/ip and the alternative. The
>>>> spice client should detect which is available of the two and
>>>> auto-connect.
>>>>
>>>> This requires enhancement of the spice client, but still solves
>>>> all the issues raised above (actually it solves about 90% of the
>>>> use cases I've heard about in the past).
>>>>
>>>> Another alternative is for the engine to 'guess' or 'elect' which
>>>> to use, alternative or main, based on the IP of the client -
>>>> meaning admin provides the client ranges for providing internal
>>>> host address vs alternative - but this is more complicated
>>>> compared for the previous suggestion
>>>>
>>>> Thoughts?
>>> Lets not re-invent the wheel. This problem has been pondered before
>>> and
>>> solved[1], for all scenarios:
>>> internal clients connecting to internal resources;
>>> internal clients connecting to external resources, without the need
>>> for
>>> any intermediate assistance
>>> external clients connecting to internal resources, with the need
>>> for
>>> intermediate assistance.
>>> VPN clients connecting to internal resources, with or without an
>>> internal IP.
>>>
>>> Any other solution you'll try to come up with will bring you back
>>> to
>>> this standard, well known (along with its faults) method.
>>>
>>> The browser client will use PAC to determine how to connect to the
>>> hosts
>>> and will deliver this to the client. It's also a good path towards
>>> real
>>> proxy support for Spice.
>>> (Regardless, we still need to deal with the Spice protocol's
>>> migration
>>> command of course).
>>>
>>>
>>> [1] http://en.wikipedia.org/wiki/Proxy_auto-config
>> so instead of a spice proxy fqdn field, we should just allow user to
>> specify a pac file which resides under something like
>> /etc/ovirt/engine/pac...?
> Doesn't this presume that the user allows a single site to set his proxy settings, which seems rather insecure?

The PAC is retrieved via HTTPS, so it's supposedly secure.
In a corporate environment you have your company's PAC anyway.
Y.

>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>