[tahoe-dev] Warning or error when running Tahoe as root

Sat Aug 11 03:39:06 UTC 2012

On Thu, Aug 2, 2012 at 11:05 PM, Two Spirit <twospirit6905 at gmail.com> wrote:
> If I understand the question correctly, I was trying to make a file system
> "mountable" by multiple hosts usable by all users while I was running the
> setup as root on one of the servers -- not make a file system used by and
> for the root user where root was the only user on the system.

This use case makes sense.  I hope I can clarify a bit:

When you say "setup" it's slightly ambiguous, because there are three
distinct stages: installing the software, configuring it, and then
using it.

In python land "setup.py" is the conventional name for an *installer*.
 If you installed from source, you probably used this, but if you use
a debian package or some other packaging system, you won't come across
setup.

Installation stage:
*If* you want to install the software "system wide" for all users to
run, you probably need to run the install step as root. (Note:
Sometimes on multi-user unix systems, the system is configured to
allow non-root users to install system-wide software for all users.  I
like this approach.  On debian there is a "staff" or "source" or
"admin" group which has write access to /usr/local, so I add my user
account to that group and then I can install without root
permissions.)

Configuration stage:
This is when you run "tahoe create-node".  You should do this with the
*same* user account that will run the node.  On my laptop, this is my
normal user, but when I setup online storage servers I typically
create a "tahoe" account and run tahoe as that user.

Usage stage:
The commandline tools are network clients to the node, and they can
run as any user which can connect to that node.  The simple setup is
one node per user, but it's also possible to have a single node (say
running under a "tahoe" user), and multiple other user accounts
connect to that.

Bonus usage:

It sounds like you want to mount a filesystem and access the storage
with any normal linux tool.  Others have done this by setting up sshfs
(a fuse filesystem) to connect to a Tahoe node's sftp interface.  I
haven't done this and don't know the details.  Of course, fuse
requires mounting which requires some configuration as root, either to
run the mount command or to configure /etc/fstab to allow non-root
users to mount with specific configurations.

Keep in mind that there is an "impedence" mismatch between linux
filesystems (and fuse) and Tahoe.  For example.  For example one kind
of Tahoe file requires the gateway node to rewrite the entire file
whenever it is modified, whereas a linux program may open a file, seek
to the middle and write a single byte, then flush the file.  So, sshfs
on tahoe should hopefully be *functionally* correct, but it might have
poor performance for some applications (see below).

> I wanted the
> back end to be transparent to the end user (assumed I would have ability to
> set standard unix file permissions) -- even have the user's home directories
> within the Tahoe setup(Now I think that won't be possible).

The sshfs approach should be "semi-transparent", but I wouldn't
recommend putting user home directories on it.   I would recommend
something like mounting it on /mount/tahoe-storage, and then doing
explicit cp to and from that area.

For example, firefox probably updates various sqlite database in the
users home directory every time they save a bookmark or cache a new
page, and those updates might be expensive on an sshfs mounted Tahoe.

> Before I got a
> better understanding of Tahoe,  I was thinking back then that Tahoe was
> offering a user experience similar to something like gmailfs, but in storage
> space managed by me instead of commercial Google.

I'm not familiar with gmailfs, but I can guess that *any* network
filesystem has to make a decision about when and how to transfer the
data across the network.

The advantage of Tahoe's approach is that once an operation completes
successfully (ie: tahoe cp a myalias:backups/a), then you have a good
guarantee that the data is reliably stored across many servers.

An alternative is to cache local modifications and occasionally sync
them.  This is what dropbox does for example.

A fuse interface makes the same decision.  Imagine a fuse interface
which uses the dropbox approach.  You run firefox, add a bookmark, and
quit.  In a sync-later approach, the fuse filesystem may tell firefox:
"Sure, you've written the bookmarks file, all is well."  Then before
it has a chance to actually upload the data, there's a crash or
network outage.  Now you've lost data and the next time you open
firefox, that bookmark will be gone (or worse, all your bookmarks are
corrupted).

> I went and mounted my
> gmail space as diskspace using the standard mount and posix type interface.

I'm curious: Have you tried mounting your home directory there and
then running firefox?  Actually a safer test is to mount gmailfs on
/some/non-home/path/, then tell firefox that's where you're home is.
(Either firefox has that option, or in bash you can do:

$ HOME=/some/non-home/path firefox

I predict that firefox is either responsive, but your data is not very
reliable, *or* firefox occasionally "sticks" on some operations
because it's blocked on gmailfs syncing.

If it *is* responsive, try doing something like saving a bookmark then
immediately disconnecting your network (or in the other order).

Whatever you discover, it could help the Tahoe-LAFS project by testing
the comparison.

>
> While still a newbie(meaning I haven't read all the docs yet or up to speed
> yet), I get a feel that Tahoe is more of a user app for managing storage
> space remotely using torrent/peer to peer technologies focusing on the
> "Least Authority" portion. I personally don't like to call it a file system,
> but more of a p2p storage management interface.

Yes, I understand that confusion.  For many people, "filesystem" means
something you tell your kernel to mount.  For other people, it could
mean anything with some analog of file and directories (gfs, nfs,
maybe even s3, etc...) for which there may not be a kernel/fuse
interface.

> Now learning it is more
> userspace, I see that it is a good solution for utilizing the extra
> diskspace on the corporate desktop workstations across routed networks as a
> secure storage medium -- similar to the commercial version of Vembu's
> Storgrid.  While I think tahoe has done a great job on ease of installation
> and not trusting the remote colos, I'm thinking that tahoe has only solved a
> portion of my needs, and looking at possible solution in combination with
> possibly drbd(still debating which is going to perform better for my
> different small to large configurations -- a network RAID1 between server
> hosts at the block device level or a torrent like replication between hosts
> at the file level) and or gfs2 (being evaluated now).
>

I recommend you try the sshfs configuration with Tahoe, because it
sounds like you want the standard fs interface.  I'm also curious how
that stacks up to the alternatives you mentioned in terms of
usability.

nejucomo

>
> On Thu, Aug 2, 2012 at 8:13 PM, David-Sarah Hopwood
> <david-sarah at jacaranda.org> wrote:
>>
>> On 02/08/12 19:39, markus reichelt wrote:
>> > * David-Sarah Hopwood <david-sarah at jacaranda.org> wrote:
>> >
>> >> There's an argument for saying that this shouldn't just be a
>> >> warning; it should be an error, because running as root once may
>> >> already do things that need to be undone (e.g.  creating files
>> >> owned by root, as in the case that motivated the ticket).
>> >
>> > Maybe I missed it but which install type was it all about? A
>> > system-wide install or a mere user-install?
>>
>> The OP (Two Spirit) didn't say. But it shouldn't matter, since
>> 'tahoe' should not run as or create files as root by default, whether
>> or not it is a system install.
>>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>