This (i.e. one instance, multiple users, set up) needs to be documented in the usage doc. This question has been running back and forth across my mind for a week.
j ---- - Think carefully. - Contra mundum - "Against the world" (St. Athanasius) - Credo ut intelliga - "I believe that I may know" (St. Augustin of Hippo) On Wed, Jan 13, 2010 at 12:26 PM, Brian Warner <[email protected]> wrote: > (just adding to what Zooko said..) > > Kyle Markley wrote: > > What are the recommended methods for setting up a tahoe node to be > > used by multiple users on a host, without using root? > > Yeah, don't run the tahoe node as root.. it has no need for that. We > actually have an unfinished ticket to make it complain if it is run as > root. > > > > How then do I best enable other users on the same machine to use the > > same tahoe node? (Is that even what I really want?) > > From a reliability point of view, there's not much value to running more > than one storage node per computer (or one per disk spindle, depending > upon how well the system tolerates disk failures). So if you're enabling > storage, I'd certainly stick to having just one node. Even if you aren't > providing storage, there's a (linear) performance hit to running > multiple nodes.. each will use separate memory, separate network > connections, etc. > > The main disadvantage to having multiple users sharing a node is > security. All users are vulnerable to anyone who can control the node > (probably you, in this case). With a few code changes, you could capture > their filecaps, read their documents, and modify them undetectably. If > you're the host admin, you have all those powers already, so it wouldn't > matter. > > > Alternately, what are the (dis)advantages of creating a dedicated user > > account to run the tahoe node? > > I'd create a separate account to run the node, if only to make it easier > to keep track of how much CPU and disk space it's using, and to limit > the damage to your own account in the unlikely case that some major bug > in Python or Tahoe allows an attacker to compromise the tahoe node > (buffer overflow or something). > > > Personally, I'd run a single node on my box, in a new dedicated account > (named "tahoe" or "tahoe-prodgrid" or something) and make it available > as a service for my other users. I might set it to listen on > web.port="tcp:3456:interface=127.0.0.1" to restrict its use to local > users and their CLI tools. And then I'd tell my users to set up and test > their CLI tools by doing the following: > > mkdir ~/.tahoe > mkdir ~/.tahoe/private > echo "http://127.0.0.1:3456/"; >~/.tahoe/node.url > tahoe create-alias tahoe: > echo "yay" |tahoe put - tahoe:yay.txt > tahoe get tahoe:yay.txt > > > cheers, > -Brian > > > _______________________________________________ > tahoe-dev mailing list > [email protected] > http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev >
_______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
