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?

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

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

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

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