Re: RFC: DKMS - Dynamic Kernel Module Support
David Paleino wrote:
> On Fri, 12 Sep 2008 11:12:59 +0000, Tzafrir Cohen wrote:
>
>
>> Furthermore, m-a is part of the package management system, which is a
>> good thing.
Indeed, as reasoned below
>> [...]
>>
>> Building packages should be the norm. Having many files under /lib that
>> cannot be tracked by debsums is not something I like.
>>
>> [...]
>>
> The modules are meant to be handled by dkms, not dpkg. If you need a .deb, it
> might be a problem, then.
>
There are a couple reasons against this IMHO:
- Having files *vital* to the system not tracked by dpkg is
counter-productive. At the very least it thwarts the most basic and
obvious way of integrity protection. It does provide a fantastic
opportunity to leave cruft behind when uninstalling, too
- Where, for security reasons, the full build is unavailable (i.e.
removed from production servers), source-only DKMS would be completely
unusable. However, in a farm of identical servers (quite normal
nowadays), a sysadmin would only need to have one particular machine
equipped with the build system plus full DKMS. Modules would then be
distributed to the other servers via a private repository.
The second item above brings the same issue again. My vote goes for
using an approach similar to module-assistant here, and generate
"versioned" modules which can co-exist within a system. Moreover, the
generated modules would be installed normally, under
/lib/modules/${KVERS} and tracked by dpkg.
One idea which comes to mind (without further thinking) is to merge both
approaches: dkms could become a "subsystem" of module-assistant in Debian:
As presented above, installing kernel-headers and/or booting a kernel
for which modules are unavailable would trigger building the necessary
modules with DKMS, and module-assistant would be used to generate the
policy-conforming .deb. This package would then be installed
automatically, so that boot can continue.
When the rebuild is triggered by booting with a new kernel, dpkg is not
active and can be invoked to *register* the new modules, hence realizing
the accountability objective.
When triggered by dpkg installing a -headers package .... well, we'll
have to devise a solution for this. As said before in this thread, and
knowing nary a thing about dpkg's internals, it might just not be
possible to do this. However, solving this problem might, as hinted
before, provide us with a more elegant solution to other issues.
In any case, since updating -headers can never happen without human
intervention (save, maybe, for apt-cron), it is not unreasonable to
require the admin to manually install the packages immediately after.
Moreover, some script might be provided to automate this process: e.g.
drop a file in some /etc/dkms/pending.d/<module> file which said script
would use in order to install the just-generated modules.
AFAICS, the aforementioned solution covers all three use cases:
- Updating -headers, wanting to have modules installed immediately (so
as not to lengthen the boot period --- think the VoIP case pointed out
before). Just run the provided script (à la "update-grub")
- Updating -headers in the "master" machine, then being able to
replicate just the binary packages to other machines so that they are
available upon next boot, without the need for a working build
environment in those machines
- When the modules don't get installed before reboot, the built
packages can be looked for in some predetermined location. If
unavailable, the modules could be built and installed on the spot
(again, out of any dpkg loop)
I may perfectly well be leaving some use case out, but this could be a
starting point. My two cents.
J.L.
Reply to: