help-guix
[Top][All Lists]
Advanced

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

Re: udev-rules for my FST-01 gnuk security token


From: Chris Marusich
Subject: Re: udev-rules for my FST-01 gnuk security token
Date: Wed, 25 Jul 2018 20:54:04 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Pierre Neidhardt <address@hidden> writes:

> Thanks for this walkthrough, Chris, very useful!

I'm glad you liked it!  I enjoy sharing what I know, although often I
feel like it isn't enough.  :-)

> I guess we should document this a bit more, what do you think?

I'm sympathetic, but I don't think we need to add documentation.  Here's
why.

This behavior is not specific to the udev service.  Because we use Guix
heavily in GuixSD for as many aspects of system configuration as
possible, lots of services are configured to point to store items.  It's
the natural place to store (immutable) configuration.

It was just particularly confusing in this case because of the spurious
rules.d directories in the system profile. But I think the description
of the udev service is clear in our manual ((guix) Base Services).  It
says that the udev service is extended by using the udev-rule procedure,
or via packages that deposit udev rules at the expected output path.  I
can't think of a way to make it better.

Because GuixSD is a declarative system, it isn't necessary to modify
system files in-place.  In other distros, which are not declarative,
it's normal to mutate system files to shape the system to your needs.
With that in mind, hopefully it is less surprising that the services
GuixSD uses rely on (immutable) files in the store.

> If /run/current/system/profile/lib/udev/rules.d is not used, couldn't
>we remove
> it to avoid confusion?

I'd like to, but unfortunately it isn't quite so simple.  The rules.d
directory is present there because eudev is in the system profile.  The
reason eudev is there is probably to provide tools like udevadm.  It
might be possible to devise a clever way to arrange for the rules.d
directory to be left out of the system profile without breaking the way
that the udev service also collects rules from its extensions, but I'm
not sure it's worth the effort here.

If someone knows otherwise, I'd love to know.

> Then mention the
>
> # cat /proc/251/environ | tr '\000' '\n'
> ...
> UDEV_CONFIG_FILE=/gnu/store/...f32r-udev.conf
> EUDEV_RULES_DIRECTORY=/gnu/store/...cx44-udev-rules/lib/udev/rules.d
>
> trick somewhere to help users find the rules directory.

This specific trick can be used in a lot of situations.  I don't think
it should be called out for this specific case in our manual, but I
think it might be good content for a troubleshooting guide or a FAQ or
something.  We do need more of that sort of stuff.

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]