[tahoe-dev] Debian packages?

[Greg Troxel]

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.

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

  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.

  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.

  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.

  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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110420/9ede5a77/attachment.pgp>