11:36 p.m.
Hi guys,
Created the windows libvirt 0.8.7 installer using Matthias's updated scripting:
http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-0.exe
Does someone have time to test and confirm it's ok, before we point to it from
the website?
Arnaud, this version of the installer adds the virsh bin directory to the system PATH
variable. So I'm thinking don't need to copy the libvirt dll's around, when
using
your C# bindings.
If you've have time to test that, it would be great. Could then update the web page
with that info. :)
Regards and best wishes,
Justin Clift
10:51 p.m.
2011/1/8 Justin Clift <jclift(a)redhat.com>:
Hi guys,
Created the windows libvirt 0.8.7 installer using Matthias's updated scripting:
http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-0.exe
Does someone have time to test and confirm it's ok, before we point to it from
the website?
Arnaud, this version of the installer adds the virsh bin directory to the system PATH
variable. So I'm thinking don't need to copy the libvirt dll's around, when
using
your C# bindings.
If you've have time to test that, it would be great. Could then update the web page
with that info. :)
Regards and best wishes,
Justin Clift
The readme suggests (at least to me) that the TLS certs for libvirt's
TLS transport and the ESX driver using HTTPS are the same:
"TLS certificates are needed prior to connecting to either
QEMU instances with TLS, or connecting to VMware
ESX/vSphere."
Yes, the ESX driver (actually libcurl) needs to know the cacert.pem
for the key that signed the HTTPS certificate in order to verify the
server's certificate. That's what you can disable using the
no_verify=1 query parameter. But HTTPS doesn't do mutual verification
as libvirt's TLS transport does. There is no clientcert/key.pem
involved in HTTPS.
The ESX driver could tell libcurl to add libvirt's cacert.pem to the
certificate pool that libcurl uses to verify the HTTPS certificate.
Currently it doesn't do this and libcurl just uses the common
certificate pool provided by the OS. A while ago I tested this
(generating and using a certificate set independent from libvirt ones
for ESX) and it worked on Ubuntu. I didn't test this on Windows yet,
but I've added this to my todo list now.
Another thing is that the installer adds the bin directory to the path
unconditionally. I'd suggest to ask to let the user choose this, for
example like the msysGit InnoSetup-based installer does.
The rest looks good :)
Matthias
11:01 p.m.
On Mon, Jan 10, 2011 at 03:51:42PM +0100, Matthias Bolte wrote:
2011/1/8 Justin Clift <jclift(a)redhat.com>:
> Hi guys,
>
> Created the windows libvirt 0.8.7 installer using Matthias's updated scripting:
>
> http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-0.exe
>
> Does someone have time to test and confirm it's ok, before we point to it from
> the website?
>
> Arnaud, this version of the installer adds the virsh bin directory to the system
PATH
> variable. So I'm thinking don't need to copy the libvirt dll's around,
when using
> your C# bindings.
>
> If you've have time to test that, it would be great. Could then update the web
page
> with that info. :)
>
> Regards and best wishes,
>
> Justin Clift
The readme suggests (at least to me) that the TLS certs for libvirt's
TLS transport and the ESX driver using HTTPS are the same:
"TLS certificates are needed prior to connecting to either
QEMU instances with TLS, or connecting to VMware
ESX/vSphere."
Yes, the ESX driver (actually libcurl) needs to know the cacert.pem
for the key that signed the HTTPS certificate in order to verify the
server's certificate. That's what you can disable using the
no_verify=1 query parameter. But HTTPS doesn't do mutual verification
as libvirt's TLS transport does. There is no clientcert/key.pem
involved in HTTPS.
Actually HTTPS as a generic protcool *can* do mutual authentication
requiring a client certificate - the Fedora build system uses this
capability. Whether libcurl implements support for this, and whether
VMWare ESX server requests it, are the actual questions to ask :-)
Daniel
6:14 a.m.
On 11/01/2011, at 1:51 AM, Matthias Bolte wrote:
The readme suggests (at least to me) that the TLS certs for
libvirt's
TLS transport and the ESX driver using HTTPS are the same:
"TLS certificates are needed prior to connecting to either
QEMU instances with TLS, or connecting to VMware
ESX/vSphere."
Yes, the ESX driver (actually libcurl) needs to know the cacert.pem
for the key that signed the HTTPS certificate in order to verify the
server's certificate. That's what you can disable using the
no_verify=1 query parameter. But HTTPS doesn't do mutual verification
as libvirt's TLS transport does. There is no clientcert/key.pem
involved in HTTPS.
Thanks. I hadn't realised it operated differently from the er... "plain"
TLS
approach I'm more familiar with.
You up for writing better replacement text for the TLS bit, so it clarifies
things properly?
With the VBox warning now gone from virsh, I reckon we're ok to update
the text and push a new installer. (more than 200 downloads of the 0.8.6
one already, so people are definitely trying this stuff out)
The ESX driver could tell libcurl to add libvirt's cacert.pem to
the
certificate pool that libcurl uses to verify the HTTPS certificate.
Currently it doesn't do this and libcurl just uses the common
certificate pool provided by the OS. A while ago I tested this
(generating and using a certificate set independent from libvirt ones
for ESX) and it worked on Ubuntu. I didn't test this on Windows yet,
but I've added this to my todo list now.
Another thing is that the installer adds the bin directory to the path
unconditionally. I'd suggest to ask to let the user choose this, for
example like the msysGit InnoSetup-based installer does.
Ahhh, that's not a bad idea. I'd put it in the section where it installs
it automatically if the user installs the virsh component. Making it
optional sounds like a better approach.
The rest looks good :)
Cool. :)
Any idea how we'd go about including the C# bindings too?
I'm thinking it'll be something like:
a) Pull down the C# bindings source
b) Compile it on the same box after the compile_libvirt-0.x.x.sh script is run
c) Adjust the gather_libvirt.sh script to get the bits the C# bindings compile
d) Update the installer appropriately (give a C# bindings option in the installer, etc)
2:20 a.m.
On 11/01/2011, at 1:51 AM, Matthias Bolte wrote:
The readme suggests (at least to me) that the TLS certs for
libvirt's
TLS transport and the ESX driver using HTTPS are the same:
"TLS certificates are needed prior to connecting to either
QEMU instances with TLS, or connecting to VMware
ESX/vSphere."
Yes, the ESX driver (actually libcurl) needs to know the cacert.pem
for the key that signed the HTTPS certificate in order to verify the
server's certificate. That's what you can disable using the
no_verify=1 query parameter. But HTTPS doesn't do mutual verification
as libvirt's TLS transport does. There is no clientcert/key.pem
involved in HTTPS.
Just chucked a new revision of the 0.8.7 installer on the web:
http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe
This one clarifies the TLS usage a bit, pretty much pointing people
to the ESX page on the main website for ESX details.
It also makes the update of the system path optional. The way the
option is constructed leaves a bit to be desired, but is functional.
I would have preferred a checkbox that was separate from the other
components, but it didn't seem possible without spending a substantial
amount of time learning inner NSIS bits. (ugh)
Submitted an update for the Windows page to point to it, so if/when
that gets ACK'd it'll be available to more people. Will send an announce
email to the various mailing lists too.
Another thing is that the installer adds the bin directory to the
path
unconditionally. I'd suggest to ask to let the user choose this, for
example like the msysGit InnoSetup-based installer does.
InnoSetup (http://www.jrsoftware.org/isinfo.php for anyone interested)
looks more capable than NSIS, and seems to still be actively updated.
NSIS's seems to have pretty much died. I'm still thinking WiX or something
would be the better option for the longer term though.
+ Justin
5034
days inactive
5044
days old
4 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Justin Clift -
Matthias Bolte