[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2045: Make the paths of the different folders configurable

[Tahoe-LAFS]

#2045: Make the paths of the different folders configurable
-------------------------+-------------------------------------------------
     Reporter:  meskio   |      Owner:  leif
         Type:           |     Status:  new
  enhancement            |  Milestone:  undecided
     Priority:  normal   |    Version:  1.10.0
    Component:  code-    |   Keywords:  FHS unix daemon twistd review-
  nodeadmin              |  needed multiuser-gateway
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 (sorry to be coming late to the party here)

 My current opinion: I'm happy to make it easier to be FHS-compliant, I
 absolutely want Tahoe in Debian, I'm +0 on enabling system-wide installs,
 I'm -1 on adding a bunch of `--blahdir=` options, and I'm -0 on extending
 tahoe.cfg to express the necessary directory paths.

 I guess I'd assumed that getting Tahoe into debian would just mean making
 `/usr/bin/tahoe` work, enabling users to create their own nodes (in
 `~/.tahoe`) and use them independently. I can see how that's not an ideal
 assumption: there are almost-reasonable ways to share access to a system-
 wide node among multiple users. Currently the main problem is that they'll
 all be forced to use the same grid, convergence secret, and encoding
 parameters. In the future, as we start building
 [wiki:Summit2Day1#AgentGatewaysplit Agents] and control panels and stuff,
 this will get more challenging. But right now I can see it working well
 enough.

 One option would be to merely change the Tahoe codebase to put the
 locations of all these directories into a single source file. The Debian
 /FHS-compliant version could patch this file to look in the appropriate
 places for that platform. The trunk version could stick with the existing
 NODEDIR-relative approach. That might be easiest for everybody, although
 it would mean a non-upstreamable patch for the debian folks.

 Another would be to have tahoe.cfg settings for these directories, and do
 something in the debian world to populate it appropriately for the FHS.
 Maybe ship a separate create-node script that puts everything into
 tahoe.cfg? Maybe add a `tahoe create-node --fhs` and have the debian
 postinst script run that if /etc/tahoe doesn't already exist?

 I guess one critical question is: to what extent is it appropriate to
 automatically create a node at install time? Tahoe nodes are useless
 without a specific grid to connect to, so the answer is probably "no, it's
 not appropriate". Which means really the package needs to point admins at
 the right tool to create this system-wide shared node some time *after*
 installation. How do we want them to do this? I like writing the docs
 first, before tests and code.. what instructions could we feel comfortable
 giving sysadmins to create their system-wide node, and how would it differ
 from what users would use to create a personal node?

 That said, how technically difficult would it be to use `tahoe.cfg` to
 drive this? Suppose we define BASEDIR as the thing that holds tahoe.cfg,
 and therefore put it in /etc/tahoe or something. Until we fix #1159 we
 also need the .tac file in there, but that's config-like and static, so
 that's fine. We read the config file before doing anything else. Logs are
 easy enough to write elsewhere. There are some FURLs that are generated on
 each node startup, but tahoe.cfg can instruct the node to use other
 directories for them (/var/lib ?) first. So probably doable.

 Or, should we go even narrower and just add a `tahoe --fhs` global option?
 One boolean that the node knows should change the configuration of all
 these paths to something that matches FHS? I'm less confident about that,
 because then running multiple nodes on a single box becomes really hard
 (you need to coordinate the various subdirs of /etc/tahoe ,
 /var/lib/something, etc).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2045#comment:53>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage