Tahoe much like a web service should probably run in a semi protected environment as a non privileged user (aka nobody) in most instances. Not a knock to the OP, but I think this is a fairly standard Sys Admin task. While it may not be friendly to the newest of users, it isn't unfriendly.<div>
<br></div><div>Perhaps, a quick start guide targeted towards users less used to building environments of this sort would be the best bet. Though I thought it was already there.</div><div><br></div><div>The use case mentioned by the OP I don't think was a typical one.  The stages mentioned below may be a step in the right direction but I think a better idea of the most common use cases and clear instructions (documentation) are the best bet.</div>
<div><br></div><div>-- Justin <br><div><br><div class="gmail_quote">On Fri, Aug 10, 2012 at 8:39 PM, Nathan <span dir="ltr"><<a href="mailto:nejucomo@gmail.com" target="_blank">nejucomo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Aug 2, 2012 at 11:05 PM, Two Spirit <<a href="mailto:twospirit6905@gmail.com">twospirit6905@gmail.com</a>> wrote:<br>

> If I understand the question correctly, I was trying to make a file system<br>
> "mountable" by multiple hosts usable by all users while I was running the<br>
> setup as root on one of the servers -- not make a file system used by and<br>
> for the root user where root was the only user on the system.<br>
<br>
</div>This use case makes sense.  I hope I can clarify a bit:<br>
<br>
When you say "setup" it's slightly ambiguous, because there are three<br>
distinct stages: installing the software, configuring it, and then<br>
using it.<br>
<br>
In python land "setup.py" is the conventional name for an *installer*.<br>
 If you installed from source, you probably used this, but if you use<br>
a debian package or some other packaging system, you won't come across<br>
setup.<br>
<br>
Installation stage:<br>
*If* you want to install the software "system wide" for all users to<br>
run, you probably need to run the install step as root. (Note:<br>
Sometimes on multi-user unix systems, the system is configured to<br>
allow non-root users to install system-wide software for all users.  I<br>
like this approach.  On debian there is a "staff" or "source" or<br>
"admin" group which has write access to /usr/local, so I add my user<br>
account to that group and then I can install without root<br>
permissions.)<br>
<br>
Configuration stage:<br>
This is when you run "tahoe create-node".  You should do this with the<br>
*same* user account that will run the node.  On my laptop, this is my<br>
normal user, but when I setup online storage servers I typically<br>
create a "tahoe" account and run tahoe as that user.<br>
<br>
Usage stage:<br>
The commandline tools are network clients to the node, and they can<br>
run as any user which can connect to that node.  The simple setup is<br>
one node per user, but it's also possible to have a single node (say<br>
running under a "tahoe" user), and multiple other user accounts<br>
connect to that.<br>
<br>
<br>
Bonus usage:<br>
<br>
It sounds like you want to mount a filesystem and access the storage<br>
with any normal linux tool.  Others have done this by setting up sshfs<br>
(a fuse filesystem) to connect to a Tahoe node's sftp interface.  I<br>
haven't done this and don't know the details.  Of course, fuse<br>
requires mounting which requires some configuration as root, either to<br>
run the mount command or to configure /etc/fstab to allow non-root<br>
users to mount with specific configurations.<br>
<br>
Keep in mind that there is an "impedence" mismatch between linux<br>
filesystems (and fuse) and Tahoe.  For example.  For example one kind<br>
of Tahoe file requires the gateway node to rewrite the entire file<br>
whenever it is modified, whereas a linux program may open a file, seek<br>
to the middle and write a single byte, then flush the file.  So, sshfs<br>
on tahoe should hopefully be *functionally* correct, but it might have<br>
poor performance for some applications (see below).<br>
<div class="im"><br>
<br>
> I wanted the<br>
> back end to be transparent to the end user (assumed I would have ability to<br>
> set standard unix file permissions) -- even have the user's home directories<br>
> within the Tahoe setup(Now I think that won't be possible).<br>
<br>
</div>The sshfs approach should be "semi-transparent", but I wouldn't<br>
recommend putting user home directories on it.   I would recommend<br>
something like mounting it on /mount/tahoe-storage, and then doing<br>
explicit cp to and from that area.<br>
<br>
For example, firefox probably updates various sqlite database in the<br>
users home directory every time they save a bookmark or cache a new<br>
page, and those updates might be expensive on an sshfs mounted Tahoe.<br>
<div class="im"><br>
> Before I got a<br>
> better understanding of Tahoe,  I was thinking back then that Tahoe was<br>
> offering a user experience similar to something like gmailfs, but in storage<br>
> space managed by me instead of commercial Google.<br>
<br>
</div>I'm not familiar with gmailfs, but I can guess that *any* network<br>
filesystem has to make a decision about when and how to transfer the<br>
data across the network.<br>
<br>
The advantage of Tahoe's approach is that once an operation completes<br>
successfully (ie: tahoe cp a myalias:backups/a), then you have a good<br>
guarantee that the data is reliably stored across many servers.<br>
<br>
An alternative is to cache local modifications and occasionally sync<br>
them.  This is what dropbox does for example.<br>
<br>
A fuse interface makes the same decision.  Imagine a fuse interface<br>
which uses the dropbox approach.  You run firefox, add a bookmark, and<br>
quit.  In a sync-later approach, the fuse filesystem may tell firefox:<br>
"Sure, you've written the bookmarks file, all is well."  Then before<br>
it has a chance to actually upload the data, there's a crash or<br>
network outage.  Now you've lost data and the next time you open<br>
firefox, that bookmark will be gone (or worse, all your bookmarks are<br>
corrupted).<br>
<div class="im"><br>
<br>
> I went and mounted my<br>
> gmail space as diskspace using the standard mount and posix type interface.<br>
<br>
</div>I'm curious: Have you tried mounting your home directory there and<br>
then running firefox?  Actually a safer test is to mount gmailfs on<br>
/some/non-home/path/, then tell firefox that's where you're home is.<br>
(Either firefox has that option, or in bash you can do:<br>
<br>
$ HOME=/some/non-home/path firefox<br>
<br>
I predict that firefox is either responsive, but your data is not very<br>
reliable, *or* firefox occasionally "sticks" on some operations<br>
because it's blocked on gmailfs syncing.<br>
<br>
If it *is* responsive, try doing something like saving a bookmark then<br>
immediately disconnecting your network (or in the other order).<br>
<br>
Whatever you discover, it could help the Tahoe-LAFS project by testing<br>
the comparison.<br>
<div class="im"><br>
><br>
> While still a newbie(meaning I haven't read all the docs yet or up to speed<br>
> yet), I get a feel that Tahoe is more of a user app for managing storage<br>
> space remotely using torrent/peer to peer technologies focusing on the<br>
> "Least Authority" portion. I personally don't like to call it a file system,<br>
> but more of a p2p storage management interface.<br>
<br>
</div>Yes, I understand that confusion.  For many people, "filesystem" means<br>
something you tell your kernel to mount.  For other people, it could<br>
mean anything with some analog of file and directories (gfs, nfs,<br>
maybe even s3, etc...) for which there may not be a kernel/fuse<br>
<div class="im">interface.<br>
<br>
<br>
> Now learning it is more<br>
> userspace, I see that it is a good solution for utilizing the extra<br>
> diskspace on the corporate desktop workstations across routed networks as a<br>
> secure storage medium -- similar to the commercial version of Vembu's<br>
> Storgrid.  While I think tahoe has done a great job on ease of installation<br>
> and not trusting the remote colos, I'm thinking that tahoe has only solved a<br>
> portion of my needs, and looking at possible solution in combination with<br>
> possibly drbd(still debating which is going to perform better for my<br>
> different small to large configurations -- a network RAID1 between server<br>
> hosts at the block device level or a torrent like replication between hosts<br>
> at the file level) and or gfs2 (being evaluated now).<br>
><br>
<br>
</div>I recommend you try the sshfs configuration with Tahoe, because it<br>
sounds like you want the standard fs interface.  I'm also curious how<br>
that stacks up to the alternatives you mentioned in terms of<br>
usability.<br>
<br>
<br>
nejucomo<br>
<div class="im HOEnZb"><br>
<br>
><br>
> On Thu, Aug 2, 2012 at 8:13 PM, David-Sarah Hopwood<br>
> <<a href="mailto:david-sarah@jacaranda.org">david-sarah@jacaranda.org</a>> wrote:<br>
>><br>
>> On 02/08/12 19:39, markus reichelt wrote:<br>
>> > * David-Sarah Hopwood <<a href="mailto:david-sarah@jacaranda.org">david-sarah@jacaranda.org</a>> wrote:<br>
>> ><br>
>> >> There's an argument for saying that this shouldn't just be a<br>
>> >> warning; it should be an error, because running as root once may<br>
>> >> already do things that need to be undone (e.g.  creating files<br>
>> >> owned by root, as in the case that motivated the ticket).<br>
>> ><br>
>> > Maybe I missed it but which install type was it all about? A<br>
>> > system-wide install or a mere user-install?<br>
>><br>
>> The OP (Two Spirit) didn't say. But it shouldn't matter, since<br>
>> 'tahoe' should not run as or create files as root by default, whether<br>
>> or not it is a system install.<br>
>><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> tahoe-dev mailing list<br>
> <a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
> <a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
><br>
_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</div></div></blockquote></div><br></div></div>