make the FUSE interface be a supported, first-class feature #1353

New issue

Open

opened 2011-02-03 05:59:55 +00:00 by zooko · 13 comments

zooko commented

2011-02-03 05:59:55 +00:00

In v1.7.0, released on 2010-06-18, we added a fully supported SFTP server (see The Parade Of Release Notes). However, there remains a widespread perception that Tahoe-LAFS doesn't have FUSE integration or doesn't have real, well-supported FUSE integration, or that we have several alternative FUSE interfaces, none of which completely works.

Examples:

To close this ticket you have to do the things on the following list. (You may also need to add to this list or to move some of the things on this list to separate tickets as appropriate.)

~~remove the old, unsupported FUSE implementations from source:trunk/contrib/fuse~~ (DONE)
consider rescuing source:trunk/contrib/fuse/runtests.py , configuring it to test the current, supported SFTP-based FUSE plugin, program a buildbot to run that test
document how to install Tahoe-LAFS as a FUSE plugin (can the install process be automated somehow?)
add to The FAQ a question: "Can I access Tahoe-LAFS through FUSE?" with an appropriate answer
document somewhere a clear, non-weasel-wordy answer to the question of whether the reader should use the SFTP-based FUSE plugin or the PyFilesystem-based FUSE plugin. (For one thing, the former is supported by the Tahoe-LAFS team, which means it was developed by a brilliant coder -- David-Sarah -- under full test driven development, and is subject to our practices intended to promote security, stability, and backward-compatibility.)
? document somewhere what are the important differences between the WUI, CLI, and FUSE interfaces

In v1.7.0, released on 2010-06-18, we added a fully supported SFTP server (see [The Parade Of Release Notes](http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc)). However, there remains a widespread perception that Tahoe-LAFS doesn't have FUSE integration or doesn't have *real*, well-supported FUSE integration, or that we have several alternative FUSE interfaces, none of which completely works. Examples: * <http://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006031.html> # (see the end of the letter) * <http://tahoe-lafs.org/pipermail/tahoe-dev/2011-January/005987.html> * <http://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006052.html> To close this ticket you have to do the things on the following list. (You may also need to add to this list or to move some of the things on this list to separate tickets as appropriate.) * ~~remove the old, unsupported FUSE implementations from source:trunk/contrib/fuse~~ (DONE) * consider rescuing source:trunk/contrib/fuse/runtests.py , configuring it to test the current, supported SFTP-based FUSE plugin, program a buildbot to run that test * document how to install Tahoe-LAFS as a FUSE plugin (can the install process be automated somehow?) * add to [The FAQ](wiki/FAQ) a question: "Can I access Tahoe-LAFS through FUSE?" with an appropriate answer * document somewhere a clear, non-weasel-wordy answer to the question of whether the reader should use the SFTP-based FUSE plugin or the PyFilesystem-based FUSE plugin. (For one thing, the former is supported by the Tahoe-LAFS team, which means it was developed by a brilliant coder -- David-Sarah -- under full test driven development, and is subject to our practices intended to promote security, stability, and backward-compatibility.) * ? document somewhere what are the important differences between the WUI, CLI, and FUSE interfaces

zooko added the

labels 2011-02-03 05:59:55 +00:00

zooko added this to the undecided milestone 2011-02-03 05:59:55 +00:00

gdt commented

2011-02-03 15:39:58 +00:00

Owner

The SFTP interface is cool, and I think should stay, but saying our fuse answer is to use it seems kludgy, and extended attributes and caching will be harder.

We need a way for someone to use the CLI to do

tahoe mount [ALIAS:][PATH] [system-path]

or perhaps just alias:, and require an alias for a sub-path. Note that there is no sftp login, no ssh credentials, just reading the cap out of the .tahoe directory. Perhaps system-path defaults to ~/TAHOE/ALIAS. the FUSE module should then allow requests only from the same uid that did the mount, and maybe root, and have an option to allow anyone who could access the original directory to do things - I'm not sure but one has to translate system access control to tahoe access control. Perhaps this is a whole separate program, but it seems core, and I think if it worked well many people would be using it.

This will then point out that having files be chmod +x would be sensible, which leads to tahoe storing attributes.

The really hard part is dealing with immutable files and the illusion of writing to them. Maybe they're just read-only and one has to write/rename which is what should happen anyway.

The SFTP interface is cool, and I think should stay, but saying our fuse answer is to use it seems kludgy, and extended attributes and caching will be harder. We need a way for someone to use the CLI to do ``` tahoe mount [ALIAS:][PATH] [system-path] ``` or perhaps just alias:, and require an alias for a sub-path. Note that there is no sftp login, no ssh credentials, just reading the cap out of the .tahoe directory. Perhaps system-path defaults to ~/TAHOE/ALIAS. the FUSE module should then allow requests only from the same uid that did the mount, and maybe root, and have an option to allow anyone who could access the original directory to do things - I'm not sure but one has to translate system access control to tahoe access control. Perhaps this is a whole separate program, but it seems core, and I think if it worked well many people would be using it. This will then point out that having files be chmod +x would be sensible, which leads to tahoe storing attributes. The really hard part is dealing with immutable files and the illusion of writing to them. Maybe they're just read-only and one has to write/rename which is what should happen anyway.

slush commented

2011-02-03 18:00:47 +00:00

Owner

I vote for tighter integration/support for PyFilesystem. It can give us almost instant support for FUSE and Windows virtual disk, both with nice unit tests. I know PyFS is quite young project, but it works and we don't need reinvent the wheel. And as a contributor of PyFS I will be more motivated to improve Tahoe-LAFS support if it become more used ;).

I vote for tighter integration/support for [PyFilesystem](wiki/PyFilesystem). It can give us almost instant support for FUSE and Windows virtual disk, both with nice unit tests. I know PyFS is quite young project, but it works and we don't need reinvent the wheel. And as a contributor of PyFS I will be more motivated to improve Tahoe-LAFS support if it become more used ;).

daira commented

2011-02-04 03:08:04 +00:00

Replying to gdt:

The SFTP interface is cool, and I think should stay, but saying our fuse answer is to use it seems kludgy, and extended attributes and caching will be harder.

(I don't agree about SFTP+sshfs being "kludgy", but I'll answer that separately. Extended attributes are indeed harder, but note that sshfs already does some caching.)

We need a way for someone to use the CLI to do
tahoe mount ALIAS:PATH system-path
or perhaps just alias:, and require an alias for a sub-path. Note that there is no sftp login, no ssh credentials, just reading the cap out of the .tahoe directory.

We can do that with sshfs. Allow logging in with username 'uri', and password the root URI to be used.

Then make the above tahoe mount command resolve ALIAS:PATH to an URI, and execute:

sshfs uri@GATEWAY -p SFTP_PORT -o password_stdin

passing the URI on stdin.

Perhaps system-path defaults to ~/TAHOE/ALIAS.

I don't think there should be any default for the mount point, but that's a detail.

the FUSE module should then allow requests only from the same uid that did the mount, and maybe root, and have an option to allow anyone who could access the original directory to do things - I'm not sure but one has to translate system access control to tahoe access control.

Why? The user who invokes tahoe mount can put the mount point somewhere that only they can access, if that's what they want. (It might not be what they want, and I don't see any reason to restrict them from putting the mount point anywhere that the OS allows them to.)

This will then point out that having files be chmod +x would be sensible, which leads to tahoe storing attributes.

That seems like a completely separate issue.

The really hard part is dealing with immutable files and the illusion of writing to them. Maybe they're just read-only and one has to write/rename which is what should happen anyway.

The SFTP interface already deals with this; writing to a path that resolves to an immutable file will replace the entry in the parent directory (and is possible only when that directory is writeable).

Replying to [gdt](/tahoe-lafs/trac/issues/1353#issuecomment-383664): > The SFTP interface is cool, and I think should stay, but saying our fuse answer is to use it seems kludgy, and extended attributes and caching will be harder. (I don't agree about SFTP+sshfs being "kludgy", but I'll answer that separately. Extended attributes are indeed harder, but note that sshfs already does some caching.) > We need a way for someone to use the CLI to do > ``` > tahoe mount ALIAS:PATH system-path > ``` > or perhaps just alias:, and require an alias for a sub-path. Note that there is no sftp login, no ssh credentials, just reading the cap out of the .tahoe directory. We can do that with sshfs. Allow logging in with username 'uri', and password the root URI to be used. Then make the above `tahoe mount` command resolve `ALIAS:PATH` to an URI, and execute: ``` sshfs uri@GATEWAY -p SFTP_PORT -o password_stdin ``` passing the URI on stdin. > Perhaps system-path defaults to ~/TAHOE/ALIAS. I don't think there should be any default for the mount point, but that's a detail. > the FUSE module should then allow requests only from the same uid that did the mount, and maybe root, and have an option to allow anyone who could access the original directory to do things - I'm not sure but one has to translate system access control to tahoe access control. Why? The user who invokes `tahoe mount` can put the mount point somewhere that only they can access, if that's what they want. (It might not be what they want, and I don't see any reason to restrict them from putting the mount point anywhere that the OS allows them to.) > This will then point out that having files be chmod +x would be sensible, which leads to tahoe storing attributes. That seems like a completely separate issue. > The really hard part is dealing with immutable files and the illusion of writing to them. Maybe they're just read-only and one has to write/rename which is what should happen anyway. The SFTP interface already deals with this; writing to a path that resolves to an immutable file will replace the entry in the parent directory (and is possible only when that directory is writeable).

zooko commented

2011-02-04 03:18:27 +00:00

Author

Okay so there is clearly a lot of work and open issues here. Thank you very much, gdt, for getting into details and clarifying things for me.

Let's open some separate tickets to track the parts of this that could be completed separately.

I suspect that the first, most urgent task is to document the current state of affairs, with the SFTP server, the PyFilesystem integration, and the three (all broken ??) native implementations. I imagine this doc would take the form of a file in source:trunk/docs/frontends/FUSE.rst, and an addition to wiki/FAQ, and perhaps an announcement explaining where we were, where we are, and where we are going, that we could send to tahoe-dev and perhaps to tahoe-announce.

By the way, while I strongly approve of this ticket in principle, I am not planning to spend a lot of my time actually writing the docs and code and tests. I have other priorities for Tahoe-LAFS and I don't personally use the FUSE interface.

Okay so there is clearly a lot of work and open issues here. Thank you very much, gdt, for getting into details and clarifying things for me. Let's open some separate tickets to track the parts of this that could be completed separately. I suspect that the first, most urgent task is to document the current state of affairs, with the SFTP server, the PyFilesystem integration, and the three (all broken ??) native implementations. I imagine this doc would take the form of a file in source:trunk/docs/frontends/FUSE.rst, and an addition to [wiki/FAQ](wiki/FAQ), and perhaps an announcement explaining where we were, where we are, and where we are going, that we could send to tahoe-dev and perhaps to tahoe-announce. By the way, while I strongly approve of this ticket in principle, I am not planning to spend a lot of my time actually writing the docs and code and tests. I have other priorities for Tahoe-LAFS and I don't personally use the FUSE interface.

daira commented

2011-02-05 04:05:04 +00:00

Replying to slush:

I vote for tighter integration/support for PyFilesystem. It can give us almost instant support for FUSE and Windows virtual disk, both with nice unit tests. I know PyFS is quite young project, but it works and we don't need reinvent the wheel. And as a contributor of PyFS I will be more motivated to improve Tahoe-LAFS support if it become more used ;).

Hmm, I might be missing something, but I don't see support for Windows virtual disks in the documentation. There is fs.expose.fuse, which depends on FUSE, but there's no Windows equivalent of that.

(You can create a Python object representing a Tahoe filesystem on Windows, of course, but a filesystem that can only be accessed via Python is not what users want.)

Replying to [slush](/tahoe-lafs/trac/issues/1353#issuecomment-383665): > I vote for tighter integration/support for [PyFilesystem](wiki/PyFilesystem). It can give us almost instant support for FUSE and Windows virtual disk, both with nice unit tests. I know PyFS is quite young project, but it works and we don't need reinvent the wheel. And as a contributor of PyFS I will be more motivated to improve Tahoe-LAFS support if it become more used ;). Hmm, I might be missing something, but I don't see support for Windows virtual disks in the documentation. There is `fs.expose.fuse`, which depends on FUSE, but there's no Windows equivalent of that. (You can create a Python object representing a Tahoe filesystem on Windows, of course, but a filesystem that can only be accessed via Python is not what users want.)

daira commented

2011-02-05 04:16:45 +00:00

Replying to [davidsarah]comment:5:

Replying to slush:

I vote for tighter integration/support for PyFilesystem. It can give us almost instant support for FUSE and Windows virtual disk, both with nice unit tests. I know PyFS is quite young project, but it works and we don't need reinvent the wheel. And as a contributor of PyFS I will be more motivated to improve Tahoe-LAFS support if it become more used ;).

Hmm, I might be missing something, but I don't see support for Windows virtual disks in the documentation. There is fs.expose.fuse, which depends on FUSE, but there's no Windows equivalent of that.

Oh, I missed fs.expose.dokan (because it is not documented at http://packages.python.org/fs/expose.html).

OTOH, the way that the interface to dokan here maps from POSIX-style open flags to fopen-style flags, loses information and is definitely not going to be sufficient for many applications. (That is, the "TODO: I'm sure this misses some important semantics." comment in that code is absolutely correct.)

Replying to [davidsarah]comment:5: > Replying to [slush](/tahoe-lafs/trac/issues/1353#issuecomment-383665): > > I vote for tighter integration/support for [PyFilesystem](wiki/PyFilesystem). It can give us almost instant support for FUSE and Windows virtual disk, both with nice unit tests. I know PyFS is quite young project, but it works and we don't need reinvent the wheel. And as a contributor of PyFS I will be more motivated to improve Tahoe-LAFS support if it become more used ;). > > Hmm, I might be missing something, but I don't see support for Windows virtual disks in the documentation. There is `fs.expose.fuse`, which depends on FUSE, but there's no Windows equivalent of that. Oh, I missed [fs.expose.dokan](http://code.google.com/p/pyfilesystem/source/browse/trunk/fs/expose/dokan) (because it is not documented at <http://packages.python.org/fs/expose.html>). OTOH, the way that the interface to dokan [here](http://code.google.com/p/pyfilesystem/source/browse/trunk/fs/expose/dokan/*init*.py#295) maps from POSIX-style open flags to fopen-style flags, loses information and is definitely not going to be sufficient for many applications. (That is, the "TODO: I'm sure this misses some important semantics." comment in that code is absolutely correct.)

gdt commented

2011-02-23 01:12:14 +00:00

Owner

So, I'd like there to be a FS-independent check program, and one would say

check --repair foo

and that would do a system call which would get passed to the FUSE implementation, and that would translate to how tahoe does things. Someone using the FUSE module for some other massively distributed filesystem could use the same command, and it would be translated differently. Perhaps on regular disks it would result in reading all the blocks to make sure they are there, and something similar could happen on coda and nfs. Perhaps check/repair and lease renewal should be combined, and perhaps not.

My other concern is that it doesn't currently seem possible to do the equivalent of "tahoe mount tahoe: ~/TAHOE" with sftp - I've only reduced it to a command that I then have to paste in a password. But I realize this is a small matter of programming to remedy, and much easier than a whole FUSE implementation.

My use of the word kludgy was unhelpful, and I'd like to apologize for it. What I was trying to express is that to integrate tahoe into a VFS interface (so that it appears as a native filesystem) requires mapping the POSIX-ish VFS API to tahoe semantics. The sftp interface does a lot of that, and it's particularly cool how the mutable/immutable divide is bridged. Once you move from sftp client to VFS and think of VFS-based access being the dominant paradigm, then you start thinking "how do I do check" and "how do I get caps". The answer seems likely to include a giant subroutine of "POSIX semantics are inadequate for distributed filesystems based on capabilities, so the VFS interface needs to be extended". Already we've seen a proposal to use extended attributes for this, but perhaps new system calls are needed. Once there are extensions, if there is a FUSE implementation, it needs to speak the new system calls and implement them via the WAPI or by being part of the tahoe process. With sftp, one would also need to extend the sftp/sftpd interface to support the new semantics. So, I'd like there to be a FS-independent check program, and one would say ``` check --repair foo ``` and that would do a system call which would get passed to the FUSE implementation, and that would translate to how tahoe does things. Someone using the FUSE module for some other massively distributed filesystem could use the same command, and it would be translated differently. Perhaps on regular disks it would result in reading all the blocks to make sure they are there, and something similar could happen on coda and nfs. Perhaps check/repair and lease renewal should be combined, and perhaps not. My other concern is that it doesn't currently seem possible to do the equivalent of "tahoe mount tahoe: ~/TAHOE" with sftp - I've only reduced it to a command that I then have to paste in a password. But I realize this is a small matter of programming to remedy, and much easier than a whole FUSE implementation.

gdt commented

2011-05-25 22:46:50 +00:00

Owner

Ticket #1411 is about making pubkey auth work in the sftp interface, which would make automatic mounting easier for those who live in the ssh agent world.

Ticket #1410 is about having the sftp server not listen on global interfaces by default.

Ticket #1411 is about making pubkey auth work in the sftp interface, which would make automatic mounting easier for those who live in the ssh agent world. Ticket #1410 is about having the sftp server not listen on global interfaces by default.

ClashTheBunny commented

2011-10-25 06:22:07 +00:00

Owner

I added a document to the wiki called pyFilesystem. It explains a quick pyFilesystem/(dokan|fuse) setup. Don't know if that helps this bug since it is just a quick and poorly formatted document, but it would be fairly easy to include it in Tahoe as a gdt said above with a tahoe mount ALIAS:PATH system-path and where the ALIAS:PATH and the system-path are just read in and replace the URI and the mountPoint variables. Also, with lot's of warnings of dragons and such.

I added a document to the wiki called pyFilesystem. It explains a quick pyFilesystem/(dokan|fuse) setup. Don't know if that helps this bug since it is just a quick and poorly formatted document, but it would be fairly easy to include it in Tahoe as a gdt said above with a `tahoe mount ALIAS:PATH system-path` and where the `ALIAS:PATH` and the `system-path` are just read in and replace the `URI` and the `mountPoint` variables. Also, with lot's of warnings of dragons and such.

daira commented

2011-10-25 13:06:03 +00:00

#36 was closed in favour of this ticket.

zooko commented

2012-01-23 05:48:31 +00:00

Author

Added a FAQ: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ#Q23_FUSE

Added a FAQ: <https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ#Q23_FUSE>

daira commented

2013-03-05 16:38:26 +00:00

Ticket #1356 is about being able to log in to SFTP and FTP with an arbitrary cap URI as root directory, as suggested in comment:3. It has a patch but needs tests.

Ticket #1357 is about using that to implement tahoe mount.

Ticket #1356 is about being able to log in to SFTP and FTP with an arbitrary cap URI as root directory, as suggested in comment:3. It has a patch but needs tests. Ticket #1357 is about using that to implement `tahoe mount`.