Project

General

Profile

Bug #11411

The build system should tell what filesystem permissions must be granted to the libvirt-qemu user

Added by intrigeri over 3 years ago. Updated 8 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Build system
Target version:
Start date:
05/11/2016
Due date:
% Done:

100%

Feature Branch:
feature/15342-cache-wiki
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

Call to virDomainCreateWithFlags failed: internal error: early end of file from monitor, possible problem: 2016-05-11T12:12:00.380129Z qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=9aaa2faa29f5edaf04deda5b7a3c0bd,bus=pci.2,addr=0x3: Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/intrigeri/tails/git/vagrant

To make QEMU start, I had to use setfacl to give the libvirt-qemu "x" access to the directory hierarchy up to, and including, vagrant. Then, to make provisioning work, I had to recursively give read access to .git, and to vagrant/provision/assets. And finally, for the build process to start, I had to recursively do o+rx on .git (because the build process is run as the vagrant user, whose uid doesn't match mine). And now I have a build running! :)

I think that one shouldn't have to go through this guessing+retrying process, just because they set strict permissions to the path to their Tails Git tree (not even mentioning using a strict umask), so something about this should be documented. We can go crazy and simply require some superset of what we really need, in order to simplify the doc (if we go into more details, I suspect it'll bitrot).

I don't know if that's a regressions vs. the previous Vagrant setup, so not setting target version. If it's a regression, it would be nice if it was fixed for 2.5 to the latest.

In passing: perhaps using a different synced folder provider (e.g. the rsync one) would simplify this a lot?


Related issues

Related to Tails - Bug #12081: Fresh vagrant-libvirt setup has broken synced folders Resolved 12/25/2016

Associated revisions

Revision 48598b8f (diff)
Added by intrigeri almost 3 years ago

Vagrant build doc: point to the ticket about missing permissions doc (refs: #11411).

Revision 32b1ac98 (diff)
Added by intrigeri 22 days ago

Build system: set the permissions that Vagrant needs inside the source tree (refs: #11411, #16607, #17289)

Revision 6684a825 (diff)
Added by intrigeri 22 days ago

Build system: abort early if the permissions on one of the parent directories are too strict (refs: #11411, #16607, #17289)

Revision f5c75d4e
Added by intrigeri 8 days ago

Merge branch 'feature/15342-cache-wiki' into stable (Closes: #15342, #17288, #16607, #17289, #11411)

History

#1 Updated by intrigeri over 3 years ago

(In passing: once this problem is addressed, maybe it would be nice to send an announce to tails-dev@ to encourage more people to do the switch. I'll happily convey my good feelings about the whole thing there :)

#2 Updated by intrigeri about 3 years ago

  • Related to Bug #12081: Fresh vagrant-libvirt setup has broken synced folders added

#3 Updated by intrigeri almost 3 years ago

intrigeri wrote:

To make QEMU start, I had to use setfacl to give the libvirt-qemu "x" access to the directory hierarchy up to, and including, vagrant. Then, to make provisioning work, I had to recursively give read access to .git, and to vagrant/provision/assets.

That's not enough anymore on my sid: after another round of debugging, I had to give libvirt-qemu "r" access to the vagrant directory (which now has this ACL: user:libvirt-qemu:r-x).

#4 Updated by intrigeri almost 3 years ago

As a temporary stopgap measure I've pointed to this ticket from the build doc. My commit shall be reverted once we have better documentation about this problem.

#5 Updated by intrigeri almost 3 years ago

When trying to build wip/11972-use-vagrant-in-jenkins I also had to give read access to libvirt-qemu on the root of my Git working copy.

#6 Updated by anonym over 2 years ago

#7 Updated by anonym over 2 years ago

  • Target version set to Tails_3.2

#8 Updated by intrigeri over 2 years ago

  • Parent task deleted (#7526)

(1.5 years later, let's close #7526 and handle this one separately.)

#9 Updated by intrigeri over 2 years ago

  • Target version deleted (Tails_3.2)

I can't recall anyone reporting problems with that recently, possibly because the setup doc now points to this very ticket. So my understanding is that the current situation is not nice, but the ugly workaround I put in place 6 months ago seems to work => dropping target version.

#10 Updated by intrigeri over 2 years ago

#11 Updated by intrigeri 22 days ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to intrigeri
  • Feature Branch set to feature/15342-cache-wiki

#12 Updated by intrigeri 22 days ago

  • Subject changed from Vagrant build doc should tell what filesystem permissions must be granted to the libvirt-qemu user to The build system should tell what filesystem permissions must be granted to the libvirt-qemu user
  • Type of work changed from Contributors documentation to Code

#13 Updated by intrigeri 21 days ago

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (intrigeri)
  • Target version set to Tails_4.2

#14 Updated by CyrilBrulebois 15 days ago

  • Target version changed from Tails_4.2 to Tails_4.3

#15 Updated by segfault 14 days ago

  • Assignee set to segfault

#16 Updated by intrigeri 8 days ago

  • Status changed from Needs Validation to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF