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] Xen API/libvirt & Remote

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: RE: [Xen-devel] Xen API/libvirt & Remote
From: "John Anderson" <johnha@xxxxxxxxxx>
Date: Fri, 4 Aug 2006 11:09:44 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 04 Aug 2006 11:10:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aca3zHSrq5cPcyqYTlCF2HKSRl711gAHbZTw
Thread-topic: [Xen-devel] Xen API/libvirt & Remote
I suppose I can.

Basically I wanted a fencing mechanism for RedHat Cluster's fenced. Most
of what I read uses a script to ssh with key exchange authentication to
the Xen Dom0 and destroy the DomU.  I didn't want to do that because you
need root permissions in order to destroy a DomU and my company has a
strict policy that sshd doesn't allow root logins.

To that end I wrote a small server daemon (xenfenced) using gSOAP
[http://gsoap2.sourceforge.net/] that listens for soap connections and
runs on the Xen Dom0.  Then I wrote a small gSOAP client that sits at
/sbin/fence_xen.   When invoked the client parses the options from
stdin, and makes a soap call to xenfenced on the appropriate Xen Dom0(s)
as listed in the tags in /etc/cluster/cluster.conf.  Xenfenced then uses
libvirt to see if the requested domain exists within that hypervisor and
if it does the domain is destroyed.

Xenfenced uses SSL certificates to authenticate clients and fence_xen
uses SSL certficates to authenticate the server, so any connections
originating from/to clients/servers whose certificate is not my signed
by my root CA will fail the SSL handshake.

Here is a link to the (pretty cheesy) proof of concept code.  It works
though.  http://chesty.homedns.org:4572/fence_xen/

It should compile with gSOAP > 2.7 & libvirt > 0.0.6.

I'm guessing that in the future, libvirt will handle the network
transport & authentication tasks I'm using gSOAP for currently.  When
that happens it would be nice to have an SSL certificate authentication
mechanism.

John A.


-----Original Message-----
From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx] 
Sent: Friday, August 04, 2006 6:47 AM
To: John Anderson
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Xen API/libvirt & Remote

On Thu, Aug 03, 2006 at 10:14:05AM -0700, John Anderson wrote:
> Authentication would have been my next question had I discovered that
> remote access was possible and widely used, but since there is no
> authentication mechanism, I agree that opening the http port is a bad
> thing.
> 
> I think I've found a solution.  I've wrapped the libvirt calls I need
> with gSOAP using SSL certificate authentication.   It seems to be
> working for me and secure.

Could you elaborate a little on how you implemented this ? Did it 
involve changes to libvirt or xend code to support it ? If its a 
solution which other people would benefit from I'd like to see if
we could incorporate any neccessary changes in libvirt, or at least
document it as one of the deployment scenarios.

Regards,
Dan. 
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392
2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/
-=|
|=-               Projects: http://freshmeat.net/~danielpb/
-=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
-=| 

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

<Prev in Thread] Current Thread [Next in Thread>