[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Testing for FUSE in ci tests



Antonio Terceiro <terceiro@debian.org> writes:
> On Thu, Jul 10, 2014 at 11:06:59PM -0700, Nikolaus Rath wrote:
>> On Thu, 17 Apr 2014 15:15:00 -0300, Antonio Terceiro wrote:
>> > On Wed, Apr 16, 2014 at 06:49:41PM -0700, Nikolaus Rath wrote:
>> >> Currently the S3QL CI tests fail because the test runner does not have
>> >> permission to access the /dev/fuse device
>> >> (http://ci.debian.net/data/unstable-amd64/packages/s/s3ql/2014-04-10.log).
>> >> 
>> >> Nothing wrong with that, but the test already goes out of its way to
>> >> determine if it ought to be able to use FUSE, or if the test should be
>> >> skipped. It checks:
>> >> 
>> >> - Is there a fusermount executable?
>> >> - Is there a /dev/fuse device?
>> >> - Are we root, or is the fusermount executable setuid root?
>> >> - Can we execute fusermount -V without getting an error?
>> >> 
>> >> It seems all these preconditions are fulfilled, yet fuse access is
>> >> not allowed.
>> >> 
>> >> Does someone know a test that will (even more) reliably determine if
>> >> fuse is available or not?
>> >
>> > I guess a more precise description of what exactly the ci.debian.net
>> > test runner is would help figuring this out. So current ci.debian.net
>> > runs test suites on schroot sessions with the following configuration:
>> [...]
>> 
>> This looks perfectly normal, /dev is just bind mounted to the schroot
>> session.
>> 
>> Is it possible that the /dev/fuse on the host system has non-default
>> permissions? On current testing and unstable, /dev/fuse is 666 by
>> default.
>
> /dev/fuse is 600 on the host, but I never did anything explicitly about
> it.

Ah, ok. Then I can check for that and have the fuse test at least be
skipped rather than failing.

> $ ls -l /dev/fuse
> crw------T 1 root root 10, 229 May  2 15:12 /dev/fuse
> $ dpkg-query --show udev
> udev  175-7.2
>
> I understand that fuse-utils is reponsible for setting the proper
> permissions for /dev/fuse, and it is indeed not installed on the host.

But fuse-utils is required by the package being tested. Shouldn't that
cause its installation prior to the test run and fix up the permissions?

> I could make debci depend on fuse-utils, but maybe the tests that
> depend on devices in /dev/ should be marked as requiring kernel-level
> isolation instead (we should get to the point of running on actual
> vm's at some point)?

I don't see why using /dev/fuse should require kernel-level
isolation.. but you are probably right for most other stuff in /dev.

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«


Reply to: