[tahoe-dev] debian package: initscript and FHS

[bertagaz at ptitcanardnoir.org]

On Mon, May 02, 2011 at 01:16:32PM -0400, Greg Troxel wrote:
> 
> bertagaz at ptitcanardnoir.org writes:
> 
> > - About the FHS issue, I was considering several options : having
> >  configuration options for the logs/, storage/ and tmp/ directories, but
> >  that would require to add a lot more options to the create-node command
> >  (although some auto-detection if running on Debian might configure it
> >  almost automatically), or having only one configuration option, like
> >  `debian_layout = true`, that would help tahoe to know  where its
> >  different parts resides on the system. Which way sounds best to you? Or
> >  did you already have some ideas/alternative ways about this?
> 
> I'm not sure I fully understand the issue and your proposed changes.
> Could you explain in depth which pieces of the current node directory
> that should be elsewhere (in a FHS-compliant world), and which pieces
> would remain?  Then, what does "remain" mean - is there anything left
> that looks like a node directory does now?  Also, what happens with
> multiple nodes on a single computer, operated by different uids?

Ok, sorry, first things first then. According to the FHS :

basedir/tmp should be /tmp/nodedir
basedir/logs should be /var/log/tahoe/node (something in /var/log)
basedir/storage should be /var/lib/node (in /var/lib anyway)


> As a concrete example, it might help to explain how this would all work
> for the following set of 9 nodes.  I realize that's a lot and most
> machines would have less, but I'd say the following isn't insane on a
> multi-user server.
> 
>   uid "tahoes": pubgrid storage node
>   uid "tahoes": foo introducer node
>   uid "tahoes": foo storage node
> 
>   uid "alice": pubgrid client node
>   uid "alice": foo client node
> 
>   uid "bob": foo client node
>   uid "bob": bob introducer node
>   uid "bob": bob storage node
>   uid "bob": bob client node

Rather than describing the whole layout, maybe a use case might answer :

On a typical server, admins might want to run tahoe nodes as service. For
example, one for their users, another with a bunch of friendly servers
admins for backups or anything, another private one in their vpn network,
enventually each on a different grid, some being hidden services, or not.
It sounds like a reasonable scenario.

In the current way tahoe works, they'll have to start all their tahoe
instances by hands each time the machine reboots (well, that's not quite
exact as you can use @reboot cronjobs, but still, quite inelegant).
They'll also have to configure their log processor (logcheck or whatever)
to know where each node log file will be. And so on...

Actually, tahoe is really well designed for users, but on a sysadmin point
of view it does not integrate that well in the system. I'm not telling the
first use case should be changed, but at least that the second should be
made easiest to support, that would probably help admins to adopt tahoe,
as it will require less efforts to set it up in their environnement.

In the example you gave, only the first part is concerned, the one with
the "tahoes" uid, which I guess is something like a tahoe setup ran by the
system. Others wouldn't change from their actual setup (i.e in
$HOME/.tahoe, started by users by hands,...).

bert.