[bug#44435] [PATCH v2 0/1] services: Add Transmission Daemon

[Simon South <simon@simonsouth.net>]

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

-- 
2.29.2