[Engine-devel] SPICE IP override

[Andrew Cathrow]

----- 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?

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