[tahoe-dev] Debian packages?

[bertagaz at ptitcanardnoir.org]

On Wed, Apr 20, 2011 at 07:06:55AM -0400, Greg Troxel wrote:
> 
> bertagaz at ptitcanardnoir.org writes:
> 
> > One of the feedback might be to make tahoe ran like a system service
> > (started by an initscript), and be a bit more compliant regarding the
> > FHS, i.e having its configuration in /etc/tahoe/, storage in
> > /var/lib/tahoe/, etc... So far it seems the only change in tahoe that
> > might help is having a configurable storedir.
> 
> That makes sense, but a few points:
> 
>   Re: FHS: there are other conventions on BSD (hier(7)) and I'm sure
>   other rules in other places.  It's certainly fair to adjust tahoe
>   while packaging for FHS on Debian, but I wanted to caution that this
>   should lead to configuration options that Debian can use, not "fixing"
>   tahoe to be FHS-compliant.  It sounds very much like that's what you
>   meant.

It is :)

>   Tahoe's code installation and tahoe's node directories are decoupled.
>   I think you're only talking about the node directory.

Right.

>   There can be multiple nodes on a single machine.  They might be
>   running under different uids.  A user running a storage node  on a
>   multi-user machine should probably have the storage used count towards
>   that uid's quotas/accounting.

Yes, system service should support both hosting several nodes, and
different UIDs. This is probably longer term features, and maybe it should
be considered non bloking regarding releasing a Debian package without
this one first. This will require some more thoughts and code to have
something working. It may happen in tahoe's sources like in the misc/ or
contrib/ folder if upstream is interested though, and maybe that makes
sense.

>   I'm not sure what you mean by configurable storedir.  Do you mean
>   splitting storage and node config?   People have been talking about
>   that.  There could be a storage_dir= key added in the config file
>   pretty easily.

Sorry I didn't have the source code opened while writing the mail, so I
might have done a mistake in the variable name that would need some
flexibility.

I found storedir was used in the Client class to start the StorageServer.
Some little modifications in init_storage might be sufficient to set this
with a storage_dir key or not.

But you get my point. :)

>   People often put nodes on removable disks.  The node directory has the
>   identity of the node, and it can be brought up on another machine.
>   So there is merit in keeping node config and node storage together.
>   But, people may want to do it differently.

This storage_dir config key might (and should) as well be handled to
default to the current way tahoe uses this variable, and be only activated
if configured. Splitting a node storage and conf can be optional, but
that brings some more of this flexibility which can be useful for
packaging, and not just in Debian.

>   In packaging tahoe for NetBSD/pkgsrc, the only thing that's bothering
>   me (that's a packaging issue) is starting up the node at boot.  I am
>   thinking of a variable that's a list of pairs, sort of like
>   (semantically):
> 
>     (('tahoes "/n1/TAHOES/foo-n1-pubgrid")
>      ('gdt "/home/gdt/.tahoe-pubgrid))
> 
>   A nit is that users should perhaps be able to configure a node to be
>   permanent and have the startup process do it for them, but editing
>   /etc/rc.conf once privileged doesn't seem hard.

I'm thinking quite the same way to go, in Debian that could be handled by
debconf ideally.

bert.