The Isenkram
system provide a practical and easy way to figure out which
packages support the hardware in a given machine. The command line
tool isenkram-lookup and the tasksel options provide a
convenient way to list and install packages relevant for the current
hardware during system installation, both user space packages and
firmware packages. The GUI background daemon on the other hand provide
a pop-up proposing to install packages when a new dongle is inserted
while using the computer. For example, if you plug in a smart card
reader, the system will ask if you want to install pcscd if
that package isn't already installed, and if you plug in a USB video
camera the system will ask if you want to install cheese if
cheese is currently missing. This already work just fine.
But Isenkram depend on a database mapping from hardware IDs to
package names. When I started no such database existed in Debian, so
I made my own data set and included it with the isenkram package and
made isenkram fetch the latest version of this database from git using
http. This way the isenkram users would get updated package proposals
as soon as I learned more about hardware related packages.
The hardware is identified using modalias strings. The modalias
design is from the Linux kernel where most hardware descriptors are
made available as a strings that can be matched using filename style
globbing. It handle USB, PCI, DMI and a lot of other hardware related
identifiers.
The downside to the Isenkram specific database is that there is no
information about relevant distribution / Debian version, making
isenkram propose obsolete packages too. But along came AppStream, a
cross distribution mechanism to store and collect metadata about
software packages. When I heard about the proposal, I contacted the
people involved and suggested to add a hardware matching rule using
modalias strings in the specification, to be able to use AppStream for
mapping hardware to packages. This idea was accepted and AppStream is
now a great way for a package to announce the hardware it support in a
distribution neutral way. I wrote
a
recipe on how to add such meta-information in a blog post last
December. If you have a hardware related package in Debian, please
announce the relevant hardware IDs using AppStream.
In Debian, almost all packages that can talk to a LEGO Mindestorms
RCX or NXT unit, announce this support using AppStream. The effect is
that when you insert such LEGO robot controller into your Debian
machine, Isenkram will propose to install the packages needed to get
it working. The intention is that this should allow the local user to
start programming his robot controller right away without having to
guess what packages to use or which permissions to fix.
But when I sat down with my son the other day to program our NXT
unit using his Debian Stretch computer, I discovered something
annoying. The local console user (ie my son) did not get access to
the USB device for programming the unit. This used to work, but no
longer in Jessie and Stretch. After some investigation and asking
around on #debian-devel, I discovered that this was because udev had
changed the mechanism used to grant access to local devices. The
ConsoleKit mechanism from /lib/udev/rules.d/70-udev-acl.rules
no longer applied, because LDAP users no longer was added to the
plugdev group during login. Michael Biebl told me that this method
was obsolete and the new method used ACLs instead. This was good
news, as the plugdev mechanism is a mess when using a remote user
directory like LDAP. Using ACLs would make sure a user lost device
access when she logged out, even if the user left behind a background
process which would retain the plugdev membership with the ConsoleKit
setup. Armed with this knowledge I moved on to fix the access problem
for the LEGO Mindstorms related packages.
The new system uses a udev tag, 'uaccess'. It can either be
applied directly for a device, or is applied in
/lib/udev/rules.d/70-uaccess.rules for classes of devices. As the
LEGO Mindstorms udev rules did not have a class, I decided to add the
tag directly in the udev rules files included in the packages. Here
is one example. For the nqc C compiler for the RCX, the
/lib/udev/rules.d/60-nqc.rules file now look like this:
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0694", ATTR{idProduct}=="0001", \
SYMLINK+="rcx-%k", TAG+="uaccess"
The key part is the 'TAG+="uaccess"' at the end. I suspect all
packages using plugdev in their /lib/udev/rules.d/ files should be
changed to use this tag (either directly or indirectly via
70-uaccess.rules). Perhaps a lintian check should be created
to detect this?
I've been unable to find good documentation on the uaccess feature.
It is unclear to me if the uaccess tag is an internal implementation
detail like the udev-acl tag used by
/lib/udev/rules.d/70-udev-acl.rules. If it is, I guess the
indirect method is the preferred way. Michael
asked for more
documentation from the systemd project and I hope it will make
this clearer. For now I use the generic classes when they exist and
is already handled by 70-uaccess.rules, and add the tag
directly if no such class exist.
To learn more about the isenkram system, please check out
my
blog posts tagged isenkram.
To help out making life for LEGO constructors in Debian easier,
please join us on our IRC channel
#debian-lego and join
the Debian
LEGO team in the Alioth project we created yesterday. A mailing
list is not yet created, but we are working on it. :)
As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
