Greetings, I''ve been reading through the Xen API wiki page and it''s associated PDF, as well as checking out libvirt for a solution to remotely manage xend daemons. Unless I missed something, it seems both the Xen API and libvirt only make xml-rpc calls to a local xend daemon. Is this true or am I way off base? If the Xen API & libvirt can only connect to a local xend daemon, are there any alternatives short of providing your own transport (i.e. ssh/telnet to invoke the command locally) ? Any suggestions would be appreciated. Thanks, John A. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Aug 02, 2006 at 04:28:37PM -0700, John Anderson wrote:> I''ve been reading through the Xen API wiki page and it''s associated PDF, > as well as checking out libvirt for a solution to remotely manage xend > daemons. Unless I missed something, it seems both the Xen API and > libvirt only make xml-rpc calls to a local xend daemon. Is this true or > am I way off base?It''s a bit more complex, first libvirt does not (yet) make xml-rpc calls it currently does more ad-hoc HTTP based calls when talking to xend. Second libvirt interract with Xen in more ways than just with xend.> If the Xen API & libvirt can only connect to a local xend daemon, are > there any alternatives short of providing your own transport (i.e. > ssh/telnet to invoke the command locally) ?I think libvirt 0.1.3 should be able to connect to remote xend daemons using the HTTP protocol. It will be limited to xend based accesses and there is unfortunately no authentication. Security wise opening the HTTP port is a big no-no in my opinion, anybody getting access to the network one way or another would instantly get control over every domain running. Using SSH or other secure authenticated transport to then connect to the local service sounds way saner, that''s why I didn''t really pushed or tested the remote access. But passing an URL pointing to the remote service when opening the libvirt connection may work, though as said I don''t really recommend this. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. Thanks! John A. -----Original Message----- From: Daniel Veillard [mailto:veillard@redhat.com] Sent: Thursday, August 03, 2006 1:46 AM To: John Anderson Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen API/libvirt & Remote On Wed, Aug 02, 2006 at 04:28:37PM -0700, John Anderson wrote:> I''ve been reading through the Xen API wiki page and it''s associatedPDF,> as well as checking out libvirt for a solution to remotely manage xend > daemons. Unless I missed something, it seems both the Xen API and > libvirt only make xml-rpc calls to a local xend daemon. Is this trueor> am I way off base?It''s a bit more complex, first libvirt does not (yet) make xml-rpc calls it currently does more ad-hoc HTTP based calls when talking to xend. Second libvirt interract with Xen in more ways than just with xend.> If the Xen API & libvirt can only connect to a local xend daemon, are > there any alternatives short of providing your own transport (i.e. > ssh/telnet to invoke the command locally) ?I think libvirt 0.1.3 should be able to connect to remote xend daemons using the HTTP protocol. It will be limited to xend based accesses and there is unfortunately no authentication. Security wise opening the HTTP port is a big no-no in my opinion, anybody getting access to the network one way or another would instantly get control over every domain running. Using SSH or other secure authenticated transport to then connect to the local service sounds way saner, that''s why I didn''t really pushed or tested the remote access. But passing an URL pointing to the remote service when opening the libvirt connection may work, though as said I don''t really recommend this. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
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@redhat.com] Sent: Friday, August 04, 2006 6:47 AM To: John Anderson Cc: xen-devel@lists.xensource.com 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@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Aug 04, 2006 at 11:09:44AM -0700, John Anderson wrote:> 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.I''m still wondering honnestly. There is so many way to do remote access (custom protocol, XML-RPC, SOAP,CORBA, ...) and I would expect each ''customer'' to have his own type of deployed framework already, so I''m not sure adding one kind of remote access capability would hit the 80/20 sweet spot. It would also make things more complex (need for a daemon etc. though there is already one for the proxy mode). I would also expect each deployment to have it''s own preferred authentication method which may vary greatly depending on how and why they use virtualization (LDAP, SSH, etc...). Basically the matrix of capabilities explodes and unless going though a very versatile (plugin again) interface, hardcoding one may not be usable to most users. Maybe when we have more deployment and more use case feedback then it should be considered more seriously, in the meantime explaining how things could be done is probably the best approach. Feedback welcome :-) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi John, Sorry for the delay in replying. On Wed, Aug 02, 2006 at 04:28:37PM -0700, John Anderson wrote:> I''ve been reading through the Xen API wiki page and it''s associated PDF, > as well as checking out libvirt for a solution to remotely manage xend > daemons. Unless I missed something, it seems both the Xen API and libvirt > only make xml-rpc calls to a local xend daemon. Is this true or am I way > off base? > > If the Xen API & libvirt can only connect to a local xend daemon, are > there any alternatives short of providing your own transport (i.e. > ssh/telnet to invoke the command locally) ?As you''ve discussed with Daniel Veillard already, the reason we don''t open a port by default at the moment is that there''s no authentication in the protocol. If you''re in a secure environment, you could use XML-RPC/HTTP, with a small patch to Xend. Alternatively there is now XML-RPC/SSH support too, so you can set up SSH keys and use that as your authentication layer. I can dig more information out if you''re interested. The plan for the future is to improve this aspect of the Xen API significantly. I posted new C bindings to the Xen-API mailing list today, and these show how you would be able to manage Xend remotely using libcurl. I intend for all our bindings to work remotely, and over a number of transports, and securely. If you''re interested in this work, you could join the Xen-API mailing list, or simply wait until Xen 3.0.3 is released, at which point we''re going to start dropping this work into Xen unstable so that it can be released with Xen 3.0.4. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel