Message ID | cover.1604429058.git.simon@simonsouth.net |
---|---|
Headers | show |
Here's an updated version of the patch that - Fixes the "importing module from host" warning by removing an unnecessary import of (guix gexp) in transmission-daemon-computed-settings-file; and - Moves the execution of getpwnam in transmission-daemon-activation from the host side to the build side, where it belongs. Everything else is unchanged. For convenience, here's my original cover letter: This patch adds a service type for Transmission Daemon, the headless variant of the Transmission BitTorrent client (https://transmissionbt.com/). Running the client as a service this way makes it possible to share files over BitTorrent continuously without requiring a user be logged in. I've tried to make this as complete as possible but am especially interested in geting feedback as this is my first attempt at creating a service definition. A few things to point out: - I've placed the code in a new "(gnu services file-sharing)" module and the documentation in a new "File-Sharing Services" section of the manual, only because these names seemed the most natural to me. ("Peer-to-peer" would be too broad a categorization, I think, while "BitTorrent" too narrow.) - The module exports two procedures, "transmission-password-hash" and "transmission-random-salt", that together are my solution to the problem of assigning a value to the daemon's "rpc-password" configuration setting. Transmission clients seem to expect the user to supply a password in plaintext in their "settings.json" file. At startup, the client generates a random, eight-character salt value; hashes it and the password together; and writes the result back to the settings file, after which the password remains obscured. This obviously violates the functional nature of Guix, as we don't expect services to be rewriting their own configuration files and the use of a random salt value makes the process non-repeatable anyway. I've documented in the manual how a user can use these two procedures to create a suitable value for "rpc-password" that remains stable across system reconfigurations, but perhaps you know of a better (or more conventional) approach. - I've added a custom "stop" procedure to the Shepherd service that gives the daemon time to shut down before eventually killing its process. This is necessary since the daemon performs some housekeeping and sends a final update to BitTorrent trackers before it exits, which can take several seconds or more; without this code, restarting the service usually fails as the new daemon process finds the old one is still running and attached to the port used for peer connections. Again, the approach I've used to handle this seems reasonable to me but perhaps you know of something better. -- Simon South simon@simonsouth.net Simon South (1): services: Add transmission-daemon service. doc/guix.texi | 799 +++++++++++++++++++++++++++++++++ gnu/local.mk | 1 + gnu/services/file-sharing.scm | 803 ++++++++++++++++++++++++++++++++++ 3 files changed, 1603 insertions(+) create mode 100644 gnu/services/file-sharing.scm
Here's a new version of this patch that incorporates feedback[0] from Ludovic: - transmission-password-hash now signals an error in a more conventional manner, by raise'ing a &formatted-message condition, and uses Guile-GCrypt's "sha1" shorthand procedure along with string->utf8 for a more compact implementation. - A missing pair of parentheses in transmission-daemon-shepherd-service has been restored. - User-facing strings have been wrapped with "G_" and the file added to po/packages/POTFILES.in to permit internationalization. (I've done this for every string, not just the one in transmission-password-hash.) I've also added a small test suite that exercises the password-related procedures exported by the service module, using values captured from transmission-daemon itself. I've placed the file in tests/services, though it's not clear this is the right location; tests/networking.scm also pertains to a service, for instance. I can re-submit with the file relocated if need be. Finally, despite my earlier bravado[1] I've held off adding any system tests, only because I now realize getting the system test suite running on the machines I have available is going to be a project in and of itself. I do intend to add these at a later date. [0] https://lists.gnu.org/archive/html/guix-patches/2020-11/msg00551.html [1] https://lists.gnu.org/archive/html/guix-patches/2020-11/msg00557.html For convenience, here's my original cover letter: This patch adds a service type for Transmission Daemon, the headless variant of the Transmission BitTorrent client (https://transmissionbt.com/). Running the client as a service this way makes it possible to share files over BitTorrent continuously without requiring a user be logged in. I've tried to make this as complete as possible but am especially interested in geting feedback as this is my first attempt at creating a service definition. A few things to point out: - I've placed the code in a new "(gnu services file-sharing)" module and the documentation in a new "File-Sharing Services" section of the manual, only because these names seemed the most natural to me. ("Peer-to-peer" would be too broad a categorization, I think, while "BitTorrent" too narrow.) - The module exports two procedures, "transmission-password-hash" and "transmission-random-salt", that together are my solution to the problem of assigning a value to the daemon's "rpc-password" configuration setting. Transmission clients seem to expect the user to supply a password in plaintext in their "settings.json" file. At startup, the client generates a random, eight-character salt value; hashes it and the password together; and writes the result back to the settings file, after which the password remains obscured. This obviously violates the functional nature of Guix, as we don't expect services to be rewriting their own configuration files and the use of a random salt value makes the process non-repeatable anyway. I've documented in the manual how a user can use these two procedures to create a suitable value for "rpc-password" that remains stable across system reconfigurations, but perhaps you know of a better (or more conventional) approach. - I've added a custom "stop" procedure to the Shepherd service that gives the daemon time to shut down before eventually killing its process. This is necessary since the daemon performs some housekeeping and sends a final update to BitTorrent trackers before it exits, which can take several seconds or more; without this code, restarting the service usually fails as the new daemon process finds the old one is still running and attached to the port used for peer connections. Again, the approach I've used to handle this seems reasonable to me but perhaps you know of something better. -- Simon South simon@simonsouth.net Simon South (1): services: Add transmission-daemon service. Makefile.am | 1 + doc/guix.texi | 799 +++++++++++++++++++++++++++++++ gnu/local.mk | 1 + gnu/services/file-sharing.scm | 804 ++++++++++++++++++++++++++++++++ po/packages/POTFILES.in | 1 + tests/services/file-sharing.scm | 59 +++ 6 files changed, 1665 insertions(+) create mode 100644 gnu/services/file-sharing.scm create mode 100644 tests/services/file-sharing.scm -- 2.29.2