Make the paths of the different folders configurable

[meskio]

The objective is to be able to run Tahoe-LAFS as a daemon on a unix system. For that each part of the node needs to have a folder in its unix path instead of inside the node folder: configuration files goes to /etc, storage to /var/lib, log files to /var/log, ...

The proposed solution to that is to have a set of fields on tahoe.cfg to set where each folder should go, also adding a set of options to the tahoe command line tools.

The topic was discussed on the past on the mailing list: pipermail/tahoe-dev/2011-May/006324.html

[meskio]

I started an implementation at: ​https://github.com/meskio/tahoe-lafs/tree/meskio

Adding storedir and logdir to the configuration file, --pidfile to the start/stop cli and --logdir and --storedir to the create-* cli.

[amontero]

This puppet module already has initscripts: ​https://github.com/ctrlaltdel/puppet-tahoe

[daira]

Re: the --pidfile option, see also #1546 and #1533.

[bertagaz]

When the new Debian package (1.10-1) will be uploaded, this bug will be a blocker for it to migrate into testing.

With the iniscript feature implementd in this package, tahoe-lafs now becomes a real unix daemon, and as such should respect the FHS. Otherwise it will be considered as RC-buggy and won't be migrated in the next upcoming Debian stable.

Jessie's freeze is planned to happen on the 2014-11-15, hopefully far enough for this bug to be closed. Thanks to meskio preliminary work, that shouldn't be difficult.

[bertagaz]

I've reviewed meskios's patches regarding FHS compliance. They sound close to ready, tests adaptations are also included.

It might remain one issue: nodedir/tahoe.cfg (and probably some others, like private keys) should probably stand in /etc/tahoe-lafs/nodedir/ as they are configuration files.

I plan to merge meskio's branch in a feature branch of the debian package repo, and see how this last implementation is possible. This could land in Debian's experimental suite if people are willing to try it. That'd be a good candidate for a 1.11-1, now that git.debian.org is up again. :)

[meskio]

Thank you for your review of my patches bertagaz. I've being pretty busy to follow up with this, but I'll love to see it in tahoe.

I'm not sure if I understand the remain issue. Is it your proposal to be able to pass the path to the cfg file to the tahoe command?

How do you envision to run it from the /etc/init.d/ script? Something like 'tahoe start --cfg=/etc/tahoe-lafs/nodedir/tahoe.cfg /var/lib/tahoe-lafs/nodedir/'?

[daira]

I'm -1 on splitting out tahoe.cfg etc. from the nodedir, since I think that's too much of a divergence from the current behaviour, and would complicate the code and our support burden significantly.

[zooko]

Would everyone interested in this ticket (#2045) please also go read the entire discussion on #1310 carefully?

[bertagaz]

Thanks for the #1310 pointer. These two issues certainly share commons.

I've taken time to think and read more the code regarging this FHS issue.

Sure the way tahoe is made isn't really fiting to the proposed changes regarding configuration files.

But maybe that's because once they are removed from basedir, there's almost nothing left in there when meskio's patches have been applied. Well, appart three things i've seen, maybe more as I surely have missed some:

• tmp/: This one was fine to lay in basedir if this directory was under /var/
• tmpfile: Same as previous
• picklefile: Stats_gatherer data

So, another approach for tahoe-lafs to be FHS compliant in vendors would be to make basedir being a subdir of /etc/tahoe-lafs/ rather than /var/lib/tahoe-lafs/.

Then the two tmp contents should probably be in a subdir of /var/tmp/tahoe-lafs/. Regading the picklefile, a subdir of /var/lib/tahoe-lafs/ might be the right place.

In the end, this approach would require very little changes to add in meskio's patches, and not so much in Debian's packaging too.

Does it sound realistic? More interesting regarding support burden? Any other stuff that should get out of basedir once considered as a configuration directory?

[gdt]

FHS aspires to be universal, but I view it as Linux-centric; BSD has hier(7) which is similar but not quite the same. That argues for making paths configurable, so that people (packages) can just pass --foo-dir=/bar and do the locally-correct thing.

[amontero]

I +1 gdt's point about making them freely configurable and let each OS packagers decide. Command line seems the best/simplest option.

[daira]

End-users are not going to want to type options specifying paths on every tahoe command they use. Please can we have a bit more practical consideration of usability issues on this ticket and #1310?

[bertagaz]

End users won't have to do this, as in the proposition, they would still use the guenuine historical way of using tahoe-lafs: basedir and all content will reside in ${HOME}/.tahoe. This is already how meskio did it.

Still what we're trying to achieve is helping sysadmins to deploy tahoe-lafs instances system-wide, by having it better integrated in distributions, with other tools. Usualy it goes by respecting standards, like FHS and hier. +1 on gtd's and amontero's proposal btw.

What is proposed is to let sysadmins being able to manage easily nodes on their systems. Regarding the 'multitude' of options, as sysadmins they should know how to do that. Good documentation, maybe an tahoe create-node helper is certainly something to ship...

Still they would just have to use the full options on node creation, then the relevant directories will be found in the tahoe.cfg file.

[amontero]

As bertagaz clarified, adding "--foo-dir=/bar" options would be as a way of overriding the default/current behaviour of using ~/.tahoe, if nothing specified. As Daira already pointed out, doing it otherwise would be a serious usability regression. Overriding dirs on command line would bring best of both worlds. I'm not sure if/how adding the config option in the .cfg file fits.

[bertagaz]

I've worked a bit toward this and send 3 small patches to meskio who merged them in his repo (link in the first comment).

tempdir was already configurable in tahoe.cfg, so I've just made it so that it can be define at the command line during node creation.

I've also added an option to specify an alternative directory to place the picklefile, if one wants to puts this file in a different path from basedir. This is usefull when using the initscript provided in Debian, where a node basedir will lay in a subdir of /etc/tahoe-lafs/.

That would be great if some core dev could have a look and see if it is good enough to be merged. This is the last bits I think to have tahoe-LAFS following FHS.

[meskio]

I send a pull request with the changes: ​https://github.com/tahoe-lafs/tahoe-lafs/pull/79

[leif]

Replying to meskio:

I send a pull request with the changes: ​https://github.com/tahoe-lafs/tahoe-lafs/pull/79

A few notes:

• test_log_dir needs to be updated for the change from logdir to incident_dir
• the name incidents_dir (plural) might be better
• perhaps storedir should be storage_dir? I think whole words and underscores are preferable. s/tempdir/temp_dir/ too.
• as meskio and I discussed yesterday at 30c3, it does not seem like it would be trivial to make tahoe.cfg able to configure the path to twistd.log because that path is needed in scripts/startstop_node.py when the config file has not yet been read. A simple solution for properly debianizing tahoe is to just have the --logdir option passed on the commandline by the init script, perhaps configured in /etc/default/tahoe-lafs or something like that. (The pull request includes a --logdir commandline option, not to be confused with the incident_dir config option which was previously called logdir.)
• the --logdir option needs to be documented
• maybe the --logdir option should actually be --logfile (as the twistd option derived from it is) so that the log file doesn't have to be called twistd.log. That way it could log to something like /var/log/tahoe-lafs.log."

[bertagaz]

Replying to leif:

A few notes:

• test_log_dir needs to be updated for the change from logdir to incident_dir

Ack.

• the name incidents_dir (plural) might be better

Are there several directories to store a node incident logs?

• perhaps storedir should be storage_dir? I think whole words and underscores are preferable. s/tempdir/temp_dir/ too.

Ack, that makes sense.

• as meskio and I discussed yesterday at 30c3, it does not seem like it would be trivial to make tahoe.cfg able to configure the path to twistd.log because that path is needed in scripts/startstop_node.py when the config file has not yet been read. A simple solution for properly debianizing tahoe is to just have the --logdir option passed on the commandline by the init script, perhaps configured in /etc/default/tahoe-lafs or something like that. (The pull request includes a --logdir commandline option, not to be confused with the incident_dir config option which was previously called logdir.)

That is the conclusion meskio and I also ended on. I'm willing to implement this in the Debian initscript as soon as the patches are accepted.

• the --logdir option needs to be documented

Ack.

• maybe the --logdir option should actually be --logfile (as the twistd option derived from it is) so that the log file doesn't have to be called twistd.log. That way it could log to something like /var/log/tahoe-lafs.log."

In case sysadmins run a lot of nodes, this might be a bit confusing, or hard to dig in a one-log-file-rules-them-all. Having one logfile per node would probably be much more useable in this regard. That would also require more code change to maintain backward compatibility, as the twistd.log filename is appended to the logdir option at the moment. But I admit I'm unsure about this, maybe I missed something.

[meskio]

The --logdir parameter is also used by create-node to initialice the 'incident_dir' config field, if it's present incident_dir is configured as $logdir/incidents. If we rename --logdir to --logfile I think won't make sense this behaviour anymore, and I can remove it.

I agree with the rest of leid coments. I'll fix them soon.