Description of problem: virt-install fails to authenticate via SASL Version-Release number of selected component (if applicable): rawhide as well as python-virtinst-0.400.0-5.fc10.noarch python-virtinst-0.400.0-1.fc9.noarch How reproducible: yes Steps to Reproduce: 1.set up sasl on host: 2.run virt-install remotely with qemu+tcp://host/system Actual results: fails Expected results: ask for libvirt user name and passwd Additional info: libvirtd host configuration: [root@NODE ~]# cat /etc/sasl2/libvirt.conf | grep -v ^# sasldb_path: /etc/libvirt/passwd.db mech_list: digest-md5 [root@NODE ~]# cat /etc/libvirt/libvirtd.conf | grep -v ^# | grep -v ^$ listen_tls = 0 listen_tcp = 1 virsh works: # virsh -c qemu+tcp://10.11.231.77/system list Please enter your authentication name:david Please enter your password: Id Name State ---------------------------------- virt-inst fails: $ LIBVIRT_DEBUG=1 virt-install --connect=qemu+tcp://dhcp231-77.rdu.redhat.com/system --hvm --name test --ram 512 --network bridge:breth1 -f /var/lib/libvirt/images/test.img -s 10 --cdrom /dev/cdrom DEBUG: libvirt.c: virInitialize (register drivers) DEBUG: libvirt.c: virRegisterDriver (registering Test as driver 0) DEBUG: libvirt.c: virRegisterNetworkDriver (registering Test as network driver 0) DEBUG: libvirt.c: virRegisterStorageDriver (registering Test as storage driver 0) DEBUG: libvirt.c: virRegisterDriver (registering Xen as driver 1) DEBUG: libvirt.c: virRegisterDriver (registering OPENVZ as driver 2) DEBUG: libvirt.c: virRegisterDriver (registering remote as driver 3) DEBUG: libvirt.c: virRegisterNetworkDriver (registering remote as network driver 1) DEBUG: libvirt.c: virRegisterStorageDriver (registering remote as storage driver 1) DEBUG: libvirt.c: virRegisterDeviceMonitor (registering remote as device driver 0) DEBUG: libvirt.c: virConnectOpen (name=qemu+tcp://dhcp231-77.rdu.redhat.com/system) DEBUG: libvirt.c: do_open (name "qemu+tcp://dhcp231-77.rdu.redhat.com/system" to URI components: scheme qemu+tcp opaque (null) authority (null) server dhcp231-77.rdu.redhat.com user (null) port 0 path /system ) DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...) DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 1 (Xen) ...) DEBUG: libvirt.c: do_open (driver 1 Xen returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 2 (OPENVZ) ...) DEBUG: libvirt.c: do_open (driver 2 OPENVZ returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 3 (remote) ...) DEBUG: remote_internal.c: doRemoteOpen (proceeding with name = qemu:///system) DEBUG: remote_internal.c: remoteAuthSASL (Client initialize SASL authentication) DEBUG: remote_internal.c: remoteAuthSASL (Client start negotiation mechlist 'DIGEST-MD5') DEBUG: libvirt.c: do_open (driver 3 remote returned ERROR) DEBUG: datatypes.c: virUnrefConnect (unref connection 0x11f7620 1) DEBUG: datatypes.c: virReleaseConnect (release connection 0x11f7620) ERROR Failed to start SASL negotiation: -4 (SASL(-4): no mechanism available: No worthy mechs found) Traceback (most recent call last): File "/usr/bin/virt-install", line 692, in <module> main() File "/usr/bin/virt-install", line 507, in main conn = cli.getConnection(options.connect) File "/usr/lib/python2.5/site-packages/virtinst/cli.py", line 127, in getConnection return libvirt.open(connect) File "/usr/lib64/python2.5/site-packages/libvirt.py", line 160, in open if ret is None:raise libvirtError('virConnectOpen() failed') libvirtError: Failed to start SASL negotiation: -4 (SASL(-4): no mechanism available: No worthy mechs found) No errors reported on the host even with libvirtd running in debug mode:
We aren't using libvirt's openAuth command in virt-install so we are limited to general user permissions. In a way this makes sense: we wouldn't want virt-install to inadvertently prompt a user if they are scripting tasks. Though I suppose the same argument could be made for virsh, so maybe we should support openAuth for virt-install. We could also tie it up with the --prompt flag so that users need to explicitly request interactivity. danpb, any thoughts?
We fundamentally need to be using openAuth if we are to support remote provisioning - there's simply no way around the fact that SASL needs to prompt for credentials in all except for Kerberos. As for scripting - we're not going to break any existing places using scripting by switching to use openAuth. If the connection didn't require auth, then using openAuth won't add any prompting. If the connection does require auth, then its already impossible to use virt-install. So, IMHO we should switch to openAuth and use the default callback impl as per virsh.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
We now use openAuth upstream for virt-* tools: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/5d6dc8af58b5 Moving to POST.
This is in rawhide now, moving to F11VirtTarget
python-virtinst-0.400.3-11.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/python-virtinst-0.400.3-11.fc11
python-virtinst-0.400.3-11.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update python-virtinst'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10356
python-virtinst-0.400.3-11.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.