Bug #17597

Test suite: libvirt vs. AppArmor in buster

Added by CyrilBrulebois 2020-04-06 15:35:36 . Updated 2020-04-17 23:51:46 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Trying to run the test suite on a newly installed buster system (with AppArmor enabled), I’ve adjusted the TEMPLATE.qemu file as instructed (to include /home/kibi/TT as my Tails Toaster directory), but I’m seeing strange failures:

Apr 06 16:55:43 hamburg libvirtd[1239]: Child quit during startup handshake: I/O error
Apr 06 16:55:43 hamburg libvirtd[1239]: internal error: Process exited prior to exec: libvirt:  error : unable to set AppArmor profile 'libvirt-203552d5-819c-41f3-800e-2c8ef2545404' for '/usr/bin/qemu-system-x86_64': No such file or directory

but all the mentioned files seem around just fine:

kibi@hamburg:~/work/clients/tails/release/release-checkout$ ls -l /etc/apparmor.d/libvirt
total 16
-rw-r--r-- 1 root root 316 Apr  6 16:55 libvirt-203552d5-819c-41f3-800e-2c8ef2545404
-rw-r--r-- 1 root root 506 Apr  6 16:55 libvirt-203552d5-819c-41f3-800e-2c8ef2545404.files
-rw-r--r-- 1 root root 342 Dec  5 00:22 TEMPLATE.lxc
-rw-r--r-- 1 root root 215 Apr  6 16:45 TEMPLATE.qemu

kibi@hamburg:~/work/clients/tails/release/release-checkout$ ls -l /usr/bin/qemu-system-x86_64
-rwxr-xr-x 1 root root 14204992 Mar 20 12:40 /usr/bin/qemu-system-x86_64

Until this is figured out, instead of disabling AppArmor entirely, one can disable it in libvirtd only, by setting this in /etc/libvirt/qemu.conf and restarting the libvirtd service:

security_driver = "none"

In passing, it would be nice to add some details in test/setup.mdwn:

AppArmor tweaks
---------------

If you have AppArmor enabled:

* You need to add the `/tmp/TailsToaster/** rwk,` line
  to `/etc/apparmor.d/libvirt/TEMPLATE.qemu`, in the
  `profile LIBVIRT_TEMPLATE` section; then delete
  `/etc/apparmor.d/libvirt/libvirt-*` and retry.
  On Debian Stretch, if you use a custom `TMPDIR` to run the test suite,
  replace `/tmp/TailsToaster` with the value of that `$TMPDIR`.

That is:

  • what does “retry” mean? I’ve tried rebooting entirely just to be sure.
  • and I suppose the “On Debian Stretch” part can go away now that we can run the test suite on Buster+?

Subtasks


History

#1 Updated by intrigeri 2020-04-15 15:44:44

I’ll look at the main part of this bug report ASAP. To start with I triaged the 2 “In passing” bits:

> * what does “retry” mean? I’ve tried rebooting entirely just to be sure.

commit:f35c615501eaa64352511553006b3187935a2e62 ← better?

> * and I suppose the “On Debian Stretch” part can go away now that we can run the test suite on Buster+?

The rest of this doc, for now, says we support running the test suite on Stretch. I’d prefer a transition period longer than 2 weeks, to give folks a little bit more time to upgrade, before we remove Stretch-specific bits of that doc :)

#2 Updated by CyrilBrulebois 2020-04-17 23:51:46

intrigeri wrote:
> I’ll look at the main part of this bug report ASAP. To start with I triaged the 2 “In passing” bits:
>
> > * what does “retry” mean? I’ve tried rebooting entirely just to be sure.
>
> commit:f35c615501eaa64352511553006b3187935a2e62 ← better?

Sure! I wasn’t sure whether some services should be restarted… it’s even better if only the test suite needs to be restarted.

> > * and I suppose the “On Debian Stretch” part can go away now that we can run the test suite on Buster+?
>
> The rest of this doc, for now, says we support running the test suite on Stretch. I’d prefer a transition period longer than 2 weeks, to give folks a little bit more time to upgrade, before we remove Stretch-specific bits of that doc :)

OK, fine! I suppose I’m getting a little too used to flag days. I wonder why that is. ;)