[libvirt] Web Interface -> LibVirt Communication?
Hi, I want to write a web tool that lets me administer my cluster from one location (including operations that things like virt-manager don't provide) - what's the proper way of achieving this? Can i communicate over TCP with libvirt on each server (is this documented?) or should I be trying to get my web app to auth and run virsh commands over SSH? Thanks. Henri
On Wed, Jul 09, 2008 at 02:31:15PM +0100, Henri Cook wrote:
Hi,
I want to write a web tool that lets me administer my cluster from one location (including operations that things like virt-manager don't provide) - what's the proper way of achieving this? Can i communicate over TCP with libvirt on each server (is this documented?) or should I be trying to get my web app to auth and run virsh commands over SSH?
Libvirt provides full remote management in its APIs using secure TCP channels. There is a choice of - TLS + x509 certs - Kerberos - Digest-MD5 (username+password) - SSH tunnel + SSH agent All of these 4 options provide authentication and data encryption of the sesion. There is more info on the plus & minuses of these here: http://libvirt.org/remote.html http://libvirt.org/auth.html I don't recommend using virsh from your webapp - use one of the real APIs, either C, Python, Perl, OCaml or Java. You may also be interested in the oVirt project which is aiming to provide a large scale web based management UI http://ovirt.org/ Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Henri Cook schreef:
I want to write a web tool that lets me administer my cluster from one location (including operations that things like virt-manager don't provide) - what's the proper way of achieving this? Can i communicate over TCP with libvirt on each server (is this documented?) or should I be trying to get my web app to auth and run virsh commands over SSH?
I have implemented this using Avahi and created a webserver handler for Cherokee. http://repo.or.cz/w/handlervirt.git My demo is just taken offline for hardware migration purposes, but if you want to team up, let me know :) Stefan
This might not be the 'right way' but here is how I handled communication to each Xen instance my web interface is managing. I used the ssh style connect string.. even if it was a local instance.. here is a line ripped right from my code: server_list={"michael":['127.0.0.1',""], "tito":['192.168.101.5',""], "jermaine":['192.168.101.6',""} .. then later in my code... for server in server_list: server_list[server][1] = libvirt.open('xen+ssh://root@'+server_list[server][0]+'/') if server_list[server][1] == None: print 'Failed to open connection to the hypervisor' sys.exit(1) .. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works.
Hi,
I want to write a web tool that lets me administer my cluster from one location (including operations that things like virt-manager don't provide) - what's the proper way of achieving this? Can i communicate over TCP with libvirt on each server (is this documented?) or should I be trying to get my web app to auth and run virsh commands over SSH?
Thanks.
Michael March schreef:
.. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works.
The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box. A shared certificate is probably an option too, if the hostname is ignored. Stefan
Michael March schreef:
.. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works.
The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box.
A shared certificate is probably an option too, if the hostname is ignored.
Hmm.. I'm not sure what you exactly mean by "hostname voodoo".... Do you mean the checks the ssh client does the first time it connects to an unknown server?
Michael March schreef:
Michael March schreef:
.. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works.
The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box.
A shared certificate is probably an option too, if the hostname is ignored.
Hmm.. I'm not sure what you exactly mean by "hostname voodoo".... Do you mean the checks the ssh client does the first time it connects to an unknown server?
No I mean that the certificate is not valid if the hostname doesn't match. (It is possible to disable that in the connection string though) Stefan
Stefan de Konink wrote:
Michael March schreef:
Michael March schreef:
.. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works.
The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box.
A shared certificate is probably an option too, if the hostname is ignored.
Hmm.. I'm not sure what you exactly mean by "hostname voodoo".... Do you mean the checks the ssh client does the first time it connects to an unknown server?
No I mean that the certificate is not valid if the hostname doesn't match. (It is possible to disable that in the connection string though)
All I did was make sure I ssh'd as a 'real' user first.. using whatever hostname I was using for the ssh endpoint.. if that went well (making sure I didn't have to enter a password or ssh key pass-phrase) I was pretty certain the libvirt connection would work. However.. other messages on this thread are recommending against the ssh method.. I'm going to try the recommended Digest-MD5 method now too
Michael March schreef:
Stefan de Konink wrote:
Michael March schreef:
Michael March schreef:
.. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works.
The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box.
A shared certificate is probably an option too, if the hostname is ignored.
Hmm.. I'm not sure what you exactly mean by "hostname voodoo".... Do you mean the checks the ssh client does the first time it connects to an unknown server?
No I mean that the certificate is not valid if the hostname doesn't match. (It is possible to disable that in the connection string though)
All I did was make sure I ssh'd as a 'real' user first.. using whatever hostname I was using for the ssh endpoint.. if that went well (making sure I didn't have to enter a password or ssh key pass-phrase) I was pretty certain the libvirt connection would work.
However.. other messages on this thread are recommending against the ssh method.. I'm going to try the recommended Digest-MD5 method now too
I'm using the tls connection not ssh. Stefan
On Wed, Jul 09, 2008 at 06:57:11AM -0700, Michael March wrote:
This might not be the 'right way' but here is how I handled communication to each Xen instance my web interface is managing. I used the ssh style connect string.. even if it was a local instance.. here is a line ripped right from my code:
server_list={"michael":['127.0.0.1',""], "tito":['192.168.101.5',""], "jermaine":['192.168.101.6',""}
.. then later in my code...
for server in server_list: server_list[server][1] = libvirt.open('xen+ssh://root@'+server_list[server][0]+'/')
I wouldn't recommend using the SSH transport for serious management tools. If you want a simple username/password based auth scheme which is trivial to setup, then the Digest-MD5 scheme is best bet. The SSH tunnel capability is handy for ad-hoc sysadmin work, but it suffers from having a high initial connection overhead and poor diagnostics when things go wrong. Digest-MD5 is easy to setup, only requiring you to create a user on each managed node which your app will authenticate as: http://libvirt.org/auth.html#ACL_server_username Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Wed, Jul 09, 2008 at 06:57:11AM -0700, Michael March wrote:
This might not be the 'right way' but here is how I handled communication to each Xen instance my web interface is managing. I used the ssh style connect string.. even if it was a local instance.. here is a line ripped right from my code:
server_list={"michael":['127.0.0.1',""], "tito":['192.168.101.5',""], "jermaine":['192.168.101.6',""}
.. then later in my code...
for server in server_list: server_list[server][1] = libvirt.open('xen+ssh://root@'+server_list[server][0]+'/')
I wouldn't recommend using the SSH transport for serious management tools. If you want a simple username/password based auth scheme which is trivial to setup, then the Digest-MD5 scheme is best bet. The SSH tunnel capability is handy for ad-hoc sysadmin work, but it suffers from having a high initial connection overhead and poor diagnostics when things go wrong.
Digest-MD5 is easy to setup, only requiring you to create a user on each managed node which your app will authenticate as:
When I looked at this it *seemed* you had to embed the username and password someplace in your code or a config file... did I get the wrong impression?
On Wed, Jul 09, 2008 at 07:18:32AM -0700, Michael March wrote:
On Wed, Jul 09, 2008 at 06:57:11AM -0700, Michael March wrote:
This might not be the 'right way' but here is how I handled communication to each Xen instance my web interface is managing. I used the ssh style connect string.. even if it was a local instance.. here is a line ripped right from my code:
server_list={"michael":['127.0.0.1',""], "tito":['192.168.101.5',""], "jermaine":['192.168.101.6',""}
.. then later in my code...
for server in server_list: server_list[server][1] = libvirt.open('xen+ssh://root@'+server_list[server][0]+'/')
I wouldn't recommend using the SSH transport for serious management tools. If you want a simple username/password based auth scheme which is trivial to setup, then the Digest-MD5 scheme is best bet. The SSH tunnel capability is handy for ad-hoc sysadmin work, but it suffers from having a high initial connection overhead and poor diagnostics when things go wrong.
Digest-MD5 is easy to setup, only requiring you to create a user on each managed node which your app will authenticate as:
When I looked at this it *seemed* you had to embed the username and password someplace in your code or a config file... did I get the wrong impression?
That is correct - you'll need to store the password somewhere in your client app. I'd recommend keeping it in a file and then using UNIX file permissions to ensure only your app can read the file. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (4)
-
Daniel P. Berrange -
Henri Cook -
Michael March -
Stefan de Konink