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

Sat Aug 11 03:52:36 UTC 2012

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.

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.

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.

-- Justin

On Fri, Aug 10, 2012 at 8:39 PM, Nathan <nejucomo at gmail.com> wrote:

> 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
> >
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120810/0a1cee23/attachment.html>