WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [RFC][PATCH] Secure XML-RPC for Xend

On Fri, Jun 09, 2006 at 09:57:24AM -0500, Anthony Liguori wrote:
> On Fri, 09 Jun 2006 09:54:44 +0100, Anil Madhavapeddy wrote:
> 
> > On Fri, Jun 09, 2006 at 04:41:48AM -0400, Daniel Veillard wrote:
> >> 
> >>    SSH authentication is really expensive especially when you compare to
> >> other cost in the XML-RPC. I would really like some persistency
> >> of the connection if possible, especially for operations like monitoring,
> >> it's okay to reopen from time to time, but without reuse it would just not
> >> work.
> > 
> > Yes, but the right place to do it is not in Xend.  The auth caching
> > can be set up outside of Xend much more robustly depending on your
> > version of OpenSSH.  If done in Xend, then it definitely needs to
> > use the wildcard support in ControlPath to avoid the authentication
> > race condition, and an OpenSSH version check.
> 
> I think Daniel is suggesting that we use HTTP Keep-Alive which I also
> think is a really good idea.  I think this will come in handy regardless
> of whether we use SSH.

  Activating Keep-Alive would be a really good idea in any case,
local or remote, direct auth or tunnelling ! IIRC the main question
was about activating it at the Python level, that's something we
discussed on IRC but never formally I guess :-)

> This makes my patch a lot nicer though.  I just would make sure the
> client uses Keep-Alive and then you get the same 1-time auth without
> any of the SSH trickery.

  Is that just client side ?

> I'm investigating this right now.  I seem to recall the HTTP server in
> python providing support for Keep-Alive...

  Okay, maybe I'm off base :-)

> > 
> > As Ian says, stunnel/SSL is probably easier from the client's point
> > of view (although I do like the easier SSH key management this patch
> > allows).
> 
> There doesn't have to be one solution.  The only real code that's needed
> here is xm serve which is not more than 100 lines.  The client code is
> more of an example.  I see no reason why we couldn't support all of these
> protocols (httpu, http, https, ssh).

  Agreed, those are layered features, they should not have to conflict.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel