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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list