1:37 p.m.
Hello,
I'm using DebOps to set up a GitLab runner with libvirt and
vagrant-libvirt in order to test applications in a GitLab pipeline.
Exactly the same way DebOps use it to test Ansible roles.
With the default configuration of roles, I'm able to start VMs through
vagrant if I adjust sudo configuration for gitlab-runner user. I don't
want to use sudo and I saw that tests under DebOps don't use it.
I'm not yet very familiar with debops.libvirtd but I'm sure there is
something to tweak in order to use libvirt without sudo privileges.
Thanks for your help.
--
Nicolas Quiniou-Briand
Jabber/XMPP : nqb(a)azyx.fr
1:53 p.m.
On Jun 27, Nicolas Quiniou-Briand wrote:
With the default configuration of roles, I'm able to start VMs
through
vagrant if I adjust sudo configuration for gitlab-runner user. I don't want
to use sudo and I saw that tests under DebOps don't use it.
I'm not yet very familiar with debops.libvirtd but I'm sure there is
something to tweak in order to use libvirt without sudo privileges.
To access the libvirt system instance your user needs to be in 'libvirt' and
IIRC 'kvm' UNIX system groups. The gitlab-runner UNIX account should be
automatically added to these by the 'debops.gitlab_runner' role. The
'vagrant-libvirt' plugin will then try and connect to the libvirt system
instance via the qemu:///system URI.
To check if you can access libvirt from your user account, you can run:
virsh -c qemu:///system sysinfo
If you get a dump of host information without errors, you should be OK. It
might be a good idea to set the qemu:///system connection as the default in
your user's libvirt configuration file.
Cheers,
Maciej
3:58 p.m.
Hello Maciej,
On 2019-06-27 1:53 p.m., Maciej Delmanowski wrote:
To access the libvirt system instance your user needs to be in
'libvirt' and
IIRC 'kvm' UNIX system groups. The gitlab-runner UNIX account should be
automatically added to these by the 'debops.gitlab_runner' role.
Yes, it is.
The 'vagrant-libvirt' plugin will then try and connect to the
libvirt system
instance via the qemu:///system URI.
To check if you can access libvirt from your user account, you can run:
virsh -c qemu:///system sysinfo
It failed:
```
gitlab-runner@ci:~$ id
uid=998(gitlab-runner) gid=995(gitlab-runner)
groups=995(gitlab-runner),112(kvm),1001(libvirtd)
gitlab-runner@ci:~$ virsh -c qemu:///system sysinfo
** (process:13177): CRITICAL **: polkit_unix_process_set_property:
assertion 'val != -1' failed
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: Debian (debian)
Password:
```
Running with sudo will ask a password.
If I use:
```
sudo virsh -c qemu:///system sysinfo
```
with my "ansible admin" user (also a libvirtd__admins), it works.
I try to use a Polkit rule [0] with the `libvirtd` group without success.
According to [1], if I create following file under
/etc/polkit-1/localauthority/50-local.d/gitlab-runner.pkla:
```
[Allow gitlab-runner libvirt management permissions]
Identity=unix-user:gitlab-runner
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes
```
then restart `polkit` and `libvirtd`, I'm able to run `virsh -c
qemu:///system sysinfo` as gitlab-runner user without password.
Maciej, I supposed you don't use Polkit on your CI infrastructure.
1. Which configuration do you use ?
2. According to [1], I supposed libvirtd comes with PolKit support in
Debian Stretch. IMO, we should adapt debops.libvirtd defaults to have a
ready to use setup with a gitlab-runner.
Thanks for your answer.
[0]
https://major.io/2015/04/11/run-virsh-and-access-libvirt-as-a-regular-user/
[1] https://libvirt.org/auth.html#ACL_server_polkit
--
Nicolas Quiniou-Briand
Jabber/XMPP : nqb(a)azyx.fr
7:37 p.m.
On Jun 27, Nicolas Quiniou-Briand wrote:
>To check if you can access libvirt from your user account, you can
run:
>
> virsh -c qemu:///system sysinfo
It failed:
```
gitlab-runner@ci:~$ id
uid=998(gitlab-runner) gid=995(gitlab-runner)
groups=995(gitlab-runner),112(kvm),1001(libvirtd)
gitlab-runner@ci:~$ virsh -c qemu:///system sysinfo
** (process:13177): CRITICAL **: polkit_unix_process_set_property: assertion
'val != -1' failed
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: Debian (debian)
Password:
```
Did you configure libvirt service with debops.libvirtd? By default the
'auth_unix_rw' in the /etc/libvirt/libvirtd.conf config file is disabled which
should result in 'none', which should disable PolicyKit. Unless the default
changed in Stretch, I haven't checked, or polkit is enabled with PolicyKit is
present on the host.
Running with sudo will ask a password.
That's correct, since gitlab-runner user does not get any special sudo
configuration apart from running chmod on image files to allow creation of
vagrant boxes.
I try to use a Polkit rule [0] with the `libvirtd` group without
success.
This rule is written in JavaScript, which is supported in polkit1. Debian
Stretch still uses polkit 0.105 which uses the older syntax. I was hesitant
about supporting PolicyKit in DebOps before because I hoped that Debian would
switch to the newer version that uses JavaScript rules, but since it will not
happen for at least 2 years (Buster comes with 0.105 version as well), I think
that we can just commit to the old version.
According to [1], if I create following file under
/etc/polkit-1/localauthority/50-local.d/gitlab-runner.pkla:
```
[Allow gitlab-runner libvirt management permissions]
Identity=unix-user:gitlab-runner
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes
```
then restart `polkit` and `libvirtd`, I'm able to run `virsh -c
qemu:///system sysinfo` as gitlab-runner user without password.
Hmm, do you have to restart libvirtd service as well? Can you check if only
a restart (or better yet reload) of polkit service works?
Maciej, I supposed you don't use Polkit on your CI
infrastructure.
No my GitLab Runner host I only see these packages:
#v+
drybjed:root@node07 /var/local/drybjed/ # dpkg -l | grep polkit
ii libpolkit-agent-1-0:amd64 0.105-18+deb9u1 amd64
PolicyKit Authentication Agent API
ii libpolkit-backend-1-0:amd64 0.105-18+deb9u1 amd64
PolicyKit backend API
ii libpolkit-gobject-1-0:amd64 0.105-18+deb9u1 amd64
PolicyKit Authorization API
drybjed:root@node07 /var/local/drybjed/ # dpkg -l | grep policykit
ii policykit-1 0.105-18+deb9u1 amd64
framework for managing administrative policies and privileges
#v-
It would be interesting to reproduce your issue first. Can you tell me more
about your environment? Is that Debian Stretch? Can you check the parameters
'auth_unix_rw' and 'auth_unix_ro' in /etc/libvirt/libvirtd.conf to see if
they
are active and their value?
1. Which configuration do you use ?
I'm using the defaults set up by DebOps, with roles ifupdown, libvirtd,
libvirtd_qemu, gitlab_runner. Not much changes via the inventory. It would be
interesting to find what are the differences between your environment and
mine.
2. According to [1], I supposed libvirtd comes with PolKit support in
Debian
Stretch. IMO, we should adapt debops.libvirtd defaults to have a ready to
use setup with a gitlab-runner.
Sure, it might be useful to expand the 'debops.libvirtd' a bit to handle more
authentication schemes. Adding PolicyKit support first sounds like a good
idea, although I think that the specific configuration file should be added by
the 'debops.gitlab_runner' role so that it is active when GitLab Runner is set
up on that host.
Cheers,
Maciej
10:51 a.m.
Hello Maciej,
On 2019-06-27 7:37 p.m., Maciej Delmanowski wrote:
Did you configure libvirt service with debops.libvirtd?
Yes.
Hmm, do you have to restart libvirtd service as well? Can you check
if only
a restart (or better yet reload) of polkit service works?
Job type reload is not applicable for unit polkit.service. Only a
restart of PolKit is necessary.
It would be interesting to reproduce your issue first. Can you tell
me more
about your environment? Is that Debian Stretch? Can you check the parameters
'auth_unix_rw' and 'auth_unix_ro' in /etc/libvirt/libvirtd.conf to see if
they
are active and their value?
Debian Stretch on a VPS, hosted by OVH, provisionned by cloud-init
package. I have exactly same PolKit packages as your node07 on my host.
#v+
$ grep ^#auth /etc/libvirt/libvirtd.conf
#auth_unix_ro = "none"
#auth_unix_rw = "none"
#auth_tcp = "sasl"
#auth_tls = "none"
#v-
Libvirt packages:
#v+
$ dpkg -l | grep libvirt
ii libsys-virt-perl 3.0.0-1
amd64 Perl module providing an extension for the
libvirt library
ii libvirt-clients 3.0.0-4+deb9u4
amd64 Programs for the libvirt library
ii libvirt-daemon 3.0.0-4+deb9u4
amd64 Virtualization daemon
ii libvirt-daemon-system 3.0.0-4+deb9u4
amd64 Libvirt daemon configuration files
ii libvirt-dev 3.0.0-4+deb9u4
amd64 development files for the libvirt library
ii libvirt0 3.0.0-4+deb9u4
amd64 library for interfacing with different
virtualization systems
ii python-libvirt 3.0.0-2
amd64 libvirt Python bindings
ii python3-libvirt 3.0.0-2
amd64 libvirt Python 3 bindings
ii ruby-fog-libvirt 0.3.0-1
all Module for the 'fog' gem to support libvirt
ii ruby-libvirt 0.7.0-1
amd64 Ruby bindings for libvirt
ii vagrant-libvirt 0.0.37-1
all Vagrant plugin that adds an Libvirt provider
to Vagrant
#v-
It would be interesting to find what are the differences between
your
environment and mine.
On my side, my host is part of [debops_service_libvirtd] and I only set
`libvirtd__admins` in inventory. Host was bootstrap with bootstrap
playbook and I use common playbook to configure it.
Sure, it might be useful to expand the 'debops.libvirtd' a
bit to handle more
authentication schemes. Adding PolicyKit support first sounds like a good
idea, although I think that the specific configuration file should be added by
the 'debops.gitlab_runner' role so that it is active when GitLab Runner is set
up on that host.
I agree.
--
Nicolas Quiniou-Briand
Jabber/XMPP : nqb(a)azyx.fr
11:04 a.m.
Hello Maciej,
I tried to reproduce the issue with Vagrant environment provided by
DebOps without success: it works like you mentioned without the need to
configure a PolKit rule. Sorry for this wrong warning.
--
Nicolas Quiniou-Briand
Jabber/XMPP : nqb(a)azyx.fr
11:29 a.m.
I was able to fix my issue without a Polkit rule. Simply add my users to
`libvirt` group in place of `libvirtd` group did the trick.
I found the root cause.
I previously did an installation of libvirt by hand on this host. During
my installation, I created a group called "libvirtd".
After, I started to manage this server with DebOps without removing this
old group. This morning, I noticed that my gitlab-runner and
`libvirtd__admins` are members of `libvirtd` group in place of `libvirt`
group (without a 'd' at end)
My ansible_local facts:
#v+
"libvirtd": {
"deployment_mode": "libvirt",
"hw_virt": true,
"installed": true,
"unix_sock_group": "libvirtd"
#v-
`libvirtd.fact` on host contains:
#v+
for group in unix_groups:
if group.gr_name == 'libvirt':
output['unix_sock_group'] = 'libvirt'
elif group.gr_name == 'libvirtd':
output['unix_sock_group'] = 'libvirtd'
#v-
This mean that `libvirtd` group will always take precedence over
`libvirt` group if both are present. I'm not sure this is an expected
behavior.
However, if you are member of `libvirtd` in place of `libvirt`, virsh
fallback to Polkit authentication according to
/usr/share/doc/libvirt-daemon/README.Debian.gz:
Access Control
==============
Access to the libvirt managing tasks is controlled by PolicyKit. To ease
configuration membership in the "libvirt" group is sufficient. If you want to
manage VMs as non-root you need to add a user to that group.
--
Nicolas Quiniou-Briand
Jabber/XMPP : nqb(a)azyx.fr
11:38 a.m.
Am 02.07.19 um 11:29 schrieb Nicolas Quiniou-Briand:
`libvirtd.fact` on host contains:
#v+
for group in unix_groups:
if group.gr_name == 'libvirt':
output['unix_sock_group'] = 'libvirt'
elif group.gr_name == 'libvirtd':
output['unix_sock_group'] = 'libvirtd'
#v-
This mean that `libvirtd` group will always take precedence over
`libvirt` group if both are present. I'm not sure this is an expected
behavior.
Not quite correct, but even worse: It depends on the order of groups in
"unix_groups": The one occurring later takes precedence. If
"unix_groups" is a dict, the behavior is unpredictable, since the order
of elements in a dict is (intentionally) unpredictable.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel(a)crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
2008
days inactive
2013
days old
7 comments
3 participants
participants (3)
-
Hartmut Goebel -
Maciej Delmanowski -
Nicolas Quiniou-Briand