From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: udev-rules for my FST-01 gnuk security token Date: Wed, 25 Jul 2018 20:54:04 -0700 Message-ID: <878t5ytzxf.fsf@gmail.com> References: <87pnzjiugu.fsf@gmail.com> <87h8knucjh.fsf@gmail.com> <87o9evehdz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fiXLy-0007Hh-Nm for help-guix@gnu.org; Wed, 25 Jul 2018 23:54:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fiXLv-000845-Qd for help-guix@gnu.org; Wed, 25 Jul 2018 23:54:14 -0400 Received: from mail-pl0-x234.google.com ([2607:f8b0:400e:c01::234]:36493) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fiXLv-00083j-JX for help-guix@gnu.org; Wed, 25 Jul 2018 23:54:11 -0400 Received: by mail-pl0-x234.google.com with SMTP id e11-v6so186806plb.3 for ; Wed, 25 Jul 2018 20:54:11 -0700 (PDT) In-Reply-To: <87o9evehdz.fsf@gmail.com> (Pierre Neidhardt's message of "Wed, 25 Jul 2018 12:31:20 +0200") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Pierre Neidhardt Cc: help-guix@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pierre Neidhardt 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=3D/gnu/store/...f32r-udev.conf > EUDEV_RULES_DIRECTORY=3D/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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAltZRdwACgkQ3UCaFdgi Rp04aQ/+NlDz0Fr/j3Hr1YnmxSQapuuR5QgyWjc4F0a/zUR4o8ae7qAq+MG7jx7y v1NRirFKQjn9BhQJc6m77xsdCn6sA3sUhrvFL8JWSxTHtFdCAEr8rcLcofOhJytn 4laQCoxoiAdmE+wPqSZheUNqGCiSXYP7D5b3SAZr4hqnCPkaNGczaW5yFypnYcG6 MBAtTmXb8DcJi8V8x6LL/DTbAqkhP/eSGzhvAt6V7IXlKU/tL5AV8Oob/QP+TgBt 3kehSIe3Kxi0TDZKh+sT/u0hMaMl0BdkEmrbsfbr1JbDgzN0FRlA/odvcBoqIoRR IjhXNIUy/nIwE0CRHU2w8+ucLGmZSZoiRy3HtbqZQCp0UEF+MH4YSskx1yNa958W rDk6yHihjp8B12NWqgLKS8cXGCzjaWX0myfTYuEVFYkr7N+J7Uz1k+0qRDFDldRk NCtGkb1uWUtDoVLjr9Gpg8rMIcVUPb8ZTWYrunokN80EQYwoBBTwmB32tRUrHShm K2VSRdfgcotFlNq8RtPzQwqXB6pknF4Eqw8+WGAiZeeaoymQchGttsuliZBZJOZb MQydRlDoK2iphGx86at9fGjmIGIokqmwU4aTOiOzkWTiyGLuVgawoYZ6yQYE7c24 bzf0Hx5etmfYvxhdkeRk7dO+bInj0IM0pxrhjQS+TmvTJQiDJCM= =Ngqc -----END PGP SIGNATURE----- --=-=-=--