[libvirt-users] New wiki pages with libvirt SSH setup instructions
Hi all, Just added some new pages to the wiki, this time covering how to configure remote access to libvirt through SSH, not using root: http://wiki.libvirt.org/page/SSHSetup <--- entry page http://wiki.libvirt.org/page/SSHPolicyKitSetup This has details for several different Linux distributions: * RHEL 5 & 6 * Fedora 11-13 * Centos 5 & 6 * Ubuntu 10.04 Server & Desktop * openSUSE 11.2 onwards Does anyone have info they'd like to include for other distributions? :) Regards and best wishes, Justin Clift
Hello Justin, just to give you a feedback on link about SSHSetup. On 09/14/2010 05:52 PM, Justin Clift wrote:
Hi all,
Just added some new pages to the wiki, this time covering how to configure remote access to libvirt through SSH, not using root:
http://wiki.libvirt.org/page/SSHSetup <--- entry page http://wiki.libvirt.org/page/SSHPolicyKitSetup
This has details for several different Linux distributions:
* RHEL 5 & 6 * Fedora 11-13 * Centos 5 & 6 * Ubuntu 10.04 Server & Desktop * openSUSE 11.2 onwards
Does anyone have info they'd like to include for other distributions?
I was thinking about writing info for Slackware, because you've asked. But I came to realize the page is written in such general way, it's simply applicable to other distributions without any big troubles which should be worth of writing up. At least that's my opinion. Of course it doesn't mean there can't be pitfalls in other distributions. I'm also pleased to know it's possible to grant "regular" user management of libvirtd. I think; good job is in order. One thing though and that's access to virtual storage. Isn't there a problem with group libvirt not having ACL to manipulate images as they are created with root:root ownership? I'm aware of <permissions>...</permissions>, but so far I haven't been successful to make it work (= ownership stayed as root:root no matter what; version 0.8.4). Thanks and have a nice day, Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
:)
Regards and best wishes,
Justin Clift
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 09/22/2010 07:33 PM, Zdenek Styblik wrote:
I was thinking about writing info for Slackware, because you've asked. But I came to realize the page is written in such general way, it's simply applicable to other distributions without any big troubles which should be worth of writing up.
Hmmmm, how does Slackware do the access control for the libvirt management socket? Any idea if it's using PolicyKit, or if it's using groups? Asking because if it's using one of those two, then it's extremely easy to add a new "Slackware" head and point people to the right bit.
At least that's my opinion. Of course it doesn't mean there can't be pitfalls in other distributions.
Yeah. I'm kind of thinking that if we know how Slackware does it, we should probably mention it. That'll help people using things like (ie) Google, when they do keyword searches for "+Libvirt +Slackware +access". Without a mention of Slackware on the pages, search engines won't show it in the result list. :( Plus... having more distributions on there helps to show off how cross-distribution libvirt is. :)
I'm also pleased to know it's possible to grant "regular" user management of libvirtd.
I think; good job is in order.
Thanks. :)
One thing though and that's access to virtual storage. Isn't there a problem with group libvirt not having ACL to manipulate images as they are created with root:root ownership? I'm aware of <permissions>...</permissions>, but so far I haven't been successful to make it work (= ownership stayed as root:root no matter what; version 0.8.4).
Hmmm, interesting thought. It's not an area I've looked at from the perspective of access by non-root users. Yeah, I should investigate that to ensure there aren't any pitfalls there. Good thinking Zdenek. :) Regards and best wishes, Justin Clift
Good noon, On 09/22/2010 02:25 PM, Justin Clift wrote:
On 09/22/2010 07:33 PM, Zdenek Styblik wrote:
I was thinking about writing info for Slackware, because you've asked. But I came to realize the page is written in such general way, it's simply applicable to other distributions without any big troubles which should be worth of writing up.
Hmmmm, how does Slackware do the access control for the libvirt management socket?
Any idea if it's using PolicyKit, or if it's using groups?
I've managed to create ACL by groups and it's working. However, to my surprise, there is Slackware package for PolicyKit. Yet, I have never used it nor tested it (I could though?).
Asking because if it's using one of those two, then it's extremely easy to add a new "Slackware" head and point people to the right bit.
Probably both or it depends on whether PolicyKit is installed or not. (T.B.D.?) Group ACL works for sure.
At least that's my opinion. Of course it doesn't mean there can't be pitfalls in other distributions.
Yeah. I'm kind of thinking that if we know how Slackware does it, we should probably mention it.
That'll help people using things like (ie) Google, when they do keyword searches for "+Libvirt +Slackware +access". Without a mention of Slackware on the pages, search engines won't show it in the result list. :(
Plus... having more distributions on there helps to show off how cross-distribution libvirt is. :)
Indeed :) [...]
One thing though and that's access to virtual storage. Isn't there a problem with group libvirt not having ACL to manipulate images as they are created with root:root ownership? I'm aware of <permissions>...</permissions>, but so far I haven't been successful to make it work (= ownership stayed as root:root no matter what; version 0.8.4).
Hmmm, interesting thought. It's not an area I've looked at from the perspective of access by non-root users.
Yeah, I should investigate that to ensure there aren't any pitfalls there.
Good thinking Zdenek. :)
First things first. I've messed up version number - 0.8.3 (0.8.4 is virt-manager, now at 0.8.5). So now, it's tested with libvirt-0.8.4 for sure. This works. Non-root user - VM management, creating images, VNC. Now, here comes part which is hard to describe. qemu-kvm - running as libvirt - great! libvirtd - running as root - bad? I wanted to achieve something like that (= root-less qemu and libvirtd) with 0.8.3, but it didn't work because libvirt/virt-manager claimed ACL problem. I think it's time for re-test and eventual push into "production" of mine :) I'm not sure if this part made sense. Simply - it works as expected.
Regards and best wishes,
Justin Clift
Have a nice day, Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
On 09/23/2010 08:08 PM, Zdenek Styblik wrote: <snip>
I've managed to create ACL by groups and it's working. However, to my surprise, there is Slackware package for PolicyKit. Yet, I have never used it nor tested it (I could though?).
Interesting. :) Ubuntu also has PolicyKit compiled into the client libraries, even though by default the libvirt daemon (server side) doesn't use it for access control. Suspecting it may be in order to allow connection to servers using PolityKit for access control. When compiling the libvirt virsh client on MacOS X, there is no PolicyKit available. Which somehow translates into qemu+ssh:// connections to PolicyKit enabled servers not working. (even though qemu+tcp:// and qemu+tls:// does). Same thing happened on when I manually compiled virsh _without_ PolicyKit on Fedora 13. Couldn't then connect to a PolicyKit enabled libvirtd with qemu+ssh://. At some point, we should look at that. It just doesn't seem like how it's supposed to be. ;>
Asking because if it's using one of those two, then it's extremely easy to add a new "Slackware" head and point people to the right bit.
Probably both or it depends on whether PolicyKit is installed or not. (T.B.D.?) Group ACL works for sure.
Cool. We should document that as "group access configuration is known to work" (or something along those lines), for Slackware. Heh, don't suppose you have a wiki user account, and feel like doing the edit? (yes, I'm trying to encourage people to make updates directly. :>)
First things first. I've messed up version number - 0.8.3 (0.8.4 is virt-manager, now at 0.8.5). So now, it's tested with libvirt-0.8.4 for sure.
This works. Non-root user - VM management, creating images, VNC.
Now, here comes part which is hard to describe.
qemu-kvm - running as libvirt - great! libvirtd - running as root - bad?
I wanted to achieve something like that (= root-less qemu and libvirtd) with 0.8.3, but it didn't work because libvirt/virt-manager claimed ACL problem. I think it's time for re-test and eventual push into "production" of mine :)
Ahhh, yeah. I think I understand. It looks like you're trying to have a running virtualisation system, without it using root for anything. Sounds like a good idea, but not sure if it can be made to work that way yet. :> If you do get it working, definitely let me know.... we should write it up if so. :) Regards and best wishes, Justin Clift
On 10/04/2010 09:36 AM, Justin Clift wrote:
On 09/23/2010 08:08 PM, Zdenek Styblik wrote: <snip>
I've managed to create ACL by groups and it's working. However, to my surprise, there is Slackware package for PolicyKit. Yet, I have never used it nor tested it (I could though?).
Interesting. :)
Ubuntu also has PolicyKit compiled into the client libraries, even though by default the libvirt daemon (server side) doesn't use it for access control.
Suspecting it may be in order to allow connection to servers using PolityKit for access control. When compiling the libvirt virsh client on MacOS X, there is no PolicyKit available. Which somehow translates into qemu+ssh:// connections to PolicyKit enabled servers not working. (even though qemu+tcp:// and qemu+tls:// does). Same thing happened on when I manually compiled virsh _without_ PolicyKit on Fedora 13. Couldn't then connect to a PolicyKit enabled libvirtd with qemu+ssh://.
Well, client is on Debian (because of virt-manager package), server is Slackware. I don't know if this makes difference/help. However, I have compiled libvirt without PolicyKit present. That was more like a statement about existence of such package ;) As I've said, I can try it with PolicyKit too, however/probably inside another VM :P (and more like "one day") Hm, and thinking about it, they might be using libvirt without PolicyKit too, as it works; unless it's MacOS X specific issue.
Asking because if it's using one of those two, then it's extremely easy to add a new "Slackware" head and point people to the right bit.
Probably both or it depends on whether PolicyKit is installed or not. (T.B.D.?) Group ACL works for sure.
Cool. We should document that as "group access configuration is known to work" (or something along those lines), for Slackware.
Heh, don't suppose you have a wiki user account, and feel like doing the edit?
Nope, I don't have an wiki account, but that shouldn't be a problem, should it? :) However, I won't do unless Sunday.
(yes, I'm trying to encourage people to make updates directly. :>)
Good approach, imho. And sooner means better [real life experience] ;) [...]
I wanted to achieve something like that (= root-less qemu and libvirtd) with 0.8.3, but it didn't work because libvirt/virt-manager claimed ACL problem. I think it's time for re-test and eventual push into "production" of mine :)
Ahhh, yeah. I think I understand. It looks like you're trying to have a running virtualisation system, without it using root for anything.
Sounds like a good idea, but not sure if it can be made to work that way yet. :>
If you do get it working, definitely let me know.... we should write it up if so. :)
Regards and best wishes,
Justin Clift
Haha, I've soon realized it's probably impossible, since libvirtd needs access to many things eg. iptables, although ... may be some internal hacking with duck tape and % sudo; and it could work. I have achieved, in "production", to have qemu-kvm running as libvirt and images owned by libvirt user/group. It's also possible to use non-root user for VM management (hopefully, as I haven't fully tested this one in "production"). Not exactly perfect, but I'm happy within limits. Have a nice weekend, Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
On 10/04/2010 09:36 AM, Justin Clift wrote:
On 09/23/2010 08:08 PM, Zdenek Styblik wrote: [...]
Cool. We should document that as "group access configuration is known to work" (or something along those lines), for Slackware.
Heh, don't suppose you have a wiki user account, and feel like doing the edit?
(yes, I'm trying to encourage people to make updates directly. :>)
I know it took months to do, but: http://wiki.libvirt.org/page/SSHSetup#Slackware If anything else needs to be added (= get more chars there), let me know. I mean, it's just couple lines and the most of them is just C&P. Damn! :| [...] Have a nice day, Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
On 09/11/2010, at 9:14 PM, Zdenek Styblik wrote:
I know it took months to do, but:
http://wiki.libvirt.org/page/SSHSetup#Slackware
If anything else needs to be added (= get more chars there), let me know. I mean, it's just couple lines and the most of them is just C&P. Damn! :|
Thanks Zdenik, that's good work. :)
participants (2)
-
Justin Clift -
Zdenek Styblik