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

Sat Oct 4 00:44:22 UTC 2014

#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 meskio):

 Replying to [comment:53 warner]:
 > 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.

 All the options on the `--blahdir=` options and the tahoe.cfg
 configuration are optional and backward compatible. You can not use them
 and everything will work as it is right now. I understand that adding
 options always complicate things and is not great.

 > 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?

 We want to support both posibilities in debian, to run it as a daemon and
 to run it as a user with all the configuration in `~/.tahoe` as it is
 right now. I think the daemon set up can be a requirement for other unixes
 around and not debian or gnu/linux specific. To hardcode a 'FHS' set up
 somewhere in tahoe or in debian won't help other unixes to daemonize
 tahoe.

 > 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?

 I don't care about install time. As a sysadmin, I care to be able to run
 tahoe from init when my system boots without hacking debian to fit in the
 tahoe model, but the other way around, to have tahoe fitting with the rest
 of the daemons in my system.

 > 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.

 We are putting all that we can in the tahoe.cfg, but things like logs
 start writting before tahoe.cfg is readed and we need to configure the
 logging without the tahoe.cfg. Or modify tahoe '''a lot''' to change the
 logging system.

 > 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).

 No, FHS is too specific of a bunch of linux distributions, and not general
 enough for other unixes to daemonize tahoe.

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