© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
> I really appreciated the detailed bug description. However, some
> elements were missing on the MIR template rules and checks, like the
> output of lintian pedantic running as per
> https:/
> not exact, you state: "* The package installs no services, timers,
> or recurring jobs". However, nbd-client installs
> /lib/systemd/
> to /dev/null). I have then had to recheck and find the informations
> myself. Please try to follow the template thoughtfully next time so
> that the burden on the MIR team is lighter, and we can process MIR
> bugs quicker. :)
Sorry about missing that -- the vast majority of my testing had been
in the netboot scenario and in those cases that service isn't used
(because no instances are enabled; it's all handled by the initrd).
Hence I'd seen the systemd server units derived from init.d (more on
that below) but completely missed the instanced client unit.
> I see that we have a really trivial autopkgtests as of now (I read
> the discussion above about it too). I think this one covers the real
> basics of the packages but it’s not comprehensive enough. Since the
> package was introduced in main, the MIR rules have changed and now
> required better testing story than when it was promoted. This
> include autopkgtests too. If non trivial autopkgtests is not
> feasable, we have then to fallback to a manual test plan, that is
> documented, updated, and run with any upload of the package. This
> will though not prevent from reverse dependency regression, meaning
> that the test plan has to be run manually at regular intervals too.
> As you can see, autopkgtest is a way more future-proof looking in
> term of maintainance :)
Agreed. I've had a crack at enhancing the autopkgtests, and I'm
reasonably pleased with the results. Quoting Wouter:
> A proper DEP-8 test would at least set up nbd-server, connect an NBD
> device, write to it and read from it again.
In a branch up on salsa [1] I've now enhanced the existing regression
test (nbdtab-
test that checks operations on a file-system match between local
access and nbd access (I'd have liked to add this as a separate
autopkgtest but it turned out that isolation between tests is not as
simple as I'd thought; LP: #2058040).
> Additionally, the initramfs his that are shipped would preferably be
> tested too, which requires a netboot setup.
>
> This is not trivial to do in a DEP-8 context, and while I have a
> plan that could work, I have not yet had the time to implement this.
> If anyone is willing to help with this as a prerequisite to moving
> this to Ubuntu main, I'm happy to have a chat or something to
> discuss the details. This is absolutely something I really really
> really want to do, but the complexity of the problem is significant.
While this wasn't trivial, this wasn't as hard as I was expecting
either, but this is thanks in large part to my being familiar with the
sterling efforts of others in sbuild's autopkgtests. These use the new
debvm tools to construct and run VMs. What's most impressive is that
the use of unshare means we don't even need root, so this test can run
even on salsa's infrastructure without machine isolation! Anyway, the
result's in the initrd-boot test [1].
Back to Didier:
> - We do run nbd-client as a root process for each nbd device block
> found via a systemd service. However, I see this one has no systemd
> confinement set. It would be great to have as much restriction on
> the systemd unit itself to limit the attack surface.
We run nbd-client as root for each *enabled* nbd block device (the
instanced nbd@ service isn't run implicitly for each block device
found, even if they're defined in nbdtab), i.e. instances need to be
manually enabled by the administrator. But I do agree that it would be
nice to take advantage of systemd's confinement capabilities, both on
the client side and the server side.
I'll see what I can come up with, aided by the new autopkgtests and
propose what I've got so far upstream.
[1]: https:/