On Thu, Mar 05, 2009 at 09:58:46AM +0100, Daniel Veillard wrote:
On Wed, Mar 04, 2009 at 11:03:17AM +0100, Chris Lalancette wrote:
> > These are all just minor auth credentials/acl config tasks that the admin
> > has to deal with for normal remote usage already, so I don't see that they
> > present a particular problem for migration
>
> Yes, they are certainly all solvable from the admin's point-of-view, so they
are
> not show stoppers. The thing is that I think admins will have a difficult time
> discovering what the problems are when migration doesn't work for them. There
> are just so many combinations that it's very easy for the admin to get one of
> them wrong, and then it may be difficult to figure out exactly what they need to
> do to get it working. On the other hand, having a dedicated channel makes it
> relatively easy; if the admin is having problems, then the answer is going to be
> "open port XYZ on the destination", and that will usually solve the
problem.
From my POV, I think getting the auth fixed is a matter of installing
proper files on a machine and of the responsability of the sysadmins
basically and purely within their realm. On the other hand opening a new
port is a decision involving network admins and security, it's not the
same scope within a company with strict policies.
I would really stay with the existing RPC model and avoid the
requirement of adding a new open port, from a pure sysadmin "upgrade"
perspective this can turn into a nightmare,
We've discussed this further on IRC and decided that if we need to get a
better authentication system for migration, then we should extend the
server RPC auth call to return a choice of multiple auth schemes. So,
for example, we could allow normal virsh cients to run SASL/TLS, and for
migration to run a one-time-key. The REMOTE_AUTH_LIST rpc command already
allows for this
struct remote_auth_list_ret {
remote_auth_type types<REMOTE_AUTH_TYPE_LIST_MAX>;
};
we currently just always return a 1 element list. We can easily add more
auth options to the list without breaking existing clients too.
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 :|