Opened at 2009-02-26T15:00:53Z
Closed at 2010-05-21T00:57:54Z
#645 closed defect (fixed)
connecting to sftp frontend using sshfs fails from linux client
Reported by: | azazel | Owned by: | azazel |
---|---|---|---|
Priority: | major | Milestone: | 1.7.0 |
Component: | code-frontend | Version: | 1.3.0 |
Keywords: | test sftp reliability sshfs | Cc: | rheimbuch@… |
Launchpad Bug: |
Description
Strange error, i've tried 3 linux clients, and to specify two commandline variations:
sshfs -C -p 8022 server: local_dir
and
sshfs -C -p 8022 server:/ local_dir
boh fail in setting up the mount with errors like:
server:.: Operation not permitted
on the client and tracebacks like this on the server:
2009-02-26 15:37:57+0100 [SSHChannel session (0) on SSHService ssh-connection on SSHServerTransport,0,88.1 49.141.217] GETATTRS . 1 2009-02-26 15:37:57+0100 [SSHChannel session (0) on SSHService ssh-connection on SSHServerTransport,0,88.1 49.141.217] Unhandled Error
Traceback (most recent call last):
File "/home/azazel/wip/tahoe/darcs/tahoe/Twisted-8.2.0-py2.5-linux-i686.egg/twisted/conch/ssh/se
ssion.py", line 105, in dataReceived
self.client.transport.write(data)
File "/home/azazel/wip/tahoe/darcs/tahoe/Twisted-8.2.0-py2.5-linux-i686.egg/twisted/conch/ssh/se
ssion.py", line 156, in write
self.proto.dataReceived(data)
File "/home/azazel/wip/tahoe/darcs/tahoe/Twisted-8.2.0-py2.5-linux-i686.egg/twisted/conch/ssh/fi
letransfer.py", line 53, in dataReceived
f(data)
File "/home/azazel/wip/tahoe/darcs/tahoe/Twisted-8.2.0-py2.5-linux-i686.egg/twisted/conch/ssh/fi
letransfer.py", line 321, in packet_STAT
d = defer.maybeDeferred(self.client.getAttrs, path, followLinks)
--- <exception caught here> ---
File "/home/azazel/wip/tahoe/darcs/tahoe/Twisted-8.2.0-py2.5-linux-i686.egg/twisted/internet/def
er.py", line 106, in maybeDeferred
result = f(*args, kw)
File "/home/azazel/wip/tahoe/lib/python2.5/site-packages/allmydata_tahoe-1.3.0_r3745-py2.5.egg/a
llmydata/frontends/sftpd.py", line 305, in getAttrs
d = self._get_node_and_metadata_for_path(self._convert_sftp_path(path))
File "/home/azazel/wip/tahoe/lib/python2.5/site-packages/allmydata_tahoe-1.3.0_r3745-py2.5.egg/a
llmydata/frontends/sftpd.py", line 317, in _convert_sftp_path
assert pathstring[0] == "/"
exceptions.AssertionError?:
The same sshfs command does work when connecting to the allmydata's production sftp service.
Attachments (4)
Change History (22)
comment:1 Changed at 2009-02-26T15:31:50Z by azazel
Changed at 2009-02-26T15:32:37Z by azazel
comment:2 Changed at 2009-02-27T00:33:26Z by warner
Well, I don't think that will hurt anything, so if it makes sshfs connect correctly, I'll apply it.
As for tests, wow, I haven't really thought about that yet. Well, Twisted has an SSH client implementation too (we're using the server code here), so maybe it'd be possible to exercise some of the code that way. These tests would have to be skipped gracefully if conch or pycrypto were unavailable.
comment:3 Changed at 2009-02-27T00:45:25Z by warner
- Milestone changed from undecided to 1.3.1
- Resolution set to fixed
- Status changed from new to closed
Applied, in 3035dfb8ed70ae4b. Thanks!
comment:4 Changed at 2009-03-05T22:10:17Z by rheimbuch
- Cc rheimbuch@… added
- Resolution fixed deleted
- Status changed from closed to reopened
Path 3035dfb8ed70ae4b causes the contents of the 'root' directory to be displayed in all sub-directories. Example:
sftp> ls / /foobar /test-dir sftp> ls /foobar /foobar/foobar /foobar/test-dir sftp> ls /foobar/foobar /foobar/foobar/foobar /foobar/foobar/test-dir sftp>
I get this behavior in both the sftp command line and sshfs.Reverting the patch seems to fix the it, but breaks sshfs compatability. The problem seems to be with the returning an empty path array when the path == "."
comment:5 Changed at 2009-03-05T23:26:59Z by azazel
I don't get the same behavior, here is mine:
sftp> ls / /documenti /personale /test sftp> ls /test /test/Archives /test/Latest sftp> version SFTP protocol version 3 azazel@lizard:~$ dpkg -S sftp openssh-client: /usr/bin/sftp azazel@lizard:~$ dpkg -l openssh-client Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-======================-======================-=========== ii openssh-client 1:4.6p1-2
Please add details of your environment to this ticket, so that i can reproduce it, maybe.
comment:6 Changed at 2009-03-06T19:16:19Z by rheimbuch
Just to clarify: I get the correct behavior using the 1.3.0 release. I get recursive display of the root directory when I build the trunk with changeset 3035dfb8ed70ae4b.
The original run was on a Ubuntu Hardy LTS server:
rheimbuch@swoop:~$ uname -a Linux swoop 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008 x86_64 GNU/Linux rheimbuch@swoop:~$ dpkg -l openssh-client Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-======================-======================-============================================================ ii openssh-client 1:4.7p1-8ubuntu1.2 secure shell client, an rlogin/rsh/rcp replacement
To reproduce I repeated on my laptop with OSX 10.5.6 with fresh installs of the 1.3.0 release and the trunk with changeset 3035dfb8ed70ae4b. v1.3.0 works correctly through sftp. The trunk build has the broken behavior:
ryan-heimbuchs-macbook41:Volumes ryan$ cd ryan-heimbuchs-macbook41:~ ryan$ sftp -oPort=8022 test2@localhost Connecting to localhost... test2@localhost's password: sftp> ls test1 test2 sftp> ls test1 test1/test1 test1/test2 sftp> ls test2 test2/test1 test2/test2 sftp> exit ryan-heimbuchs-macbook41:~ ryan$ ssh -V OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006 ryan-heimbuchs-macbook41:~ ryan$ which ssh /usr/bin/ssh ryan-heimbuchs-macbook41:~ ryan$ Projects/tahoe/trunk/bin/tahoe -V allmydata-tahoe: 1.3.0-r3759, foolscap: 0.3.2, pycryptopp: 0.5.12, zfec: 1.4.4, Twisted: 8.2.0, Nevow: 0.9.32, zope.interface: 3.3.0, python: 2.5.1, platform: Darwin-9.6.0-i386-32bit, simplejson: 2.0.9, argparse: 0.8.0, pyOpenSSL: 0.6, pyutil: 1.3.30, zbase32: 1.1.1, setuptools: 0.6c12dev
comment:7 Changed at 2009-03-07T04:32:43Z by zooko
Could we test this code without going all the way through the SSH interface, just by invoking the appropriate Python methods of the server? Going through SSH would be fine, too, but we do need tests for this.
comment:8 Changed at 2009-03-09T00:21:35Z by warner
I suppose the first step would be to build up a catalog of how ssh clients behave. I wrote the convert_sftp_path method empirically, watching what a few clients I had available to me did. With the required inputs defined, then yeah, a non-round-trip test which creates an sftpd.SFTPHandler instance and invokes methods like openFile would be a good test. (it would still need to be skipped gracefully if conch were not available).
comment:9 Changed at 2009-04-07T16:42:23Z by zooko
Oh, hey, this is a regression from 1.3.0? Should we revert 3035dfb8ed70ae4b before 1.4.0 release?
comment:10 Changed at 2009-04-10T16:40:25Z by zooko
- Milestone changed from 1.4.0 to 1.4.1
So my understanding of this issue is that Alberto's patch makes it start working for Alberto's use case but stop working for Ryan's use case, and that there are no unit tests. I'm going to revert this patch for Tahoe-1.4.0 release on the principle that Alberto's use case didn't work in Tahoe-1.3.0 but Ryan's did, and a regression is worse than "it still doesn't work".
The next step should be for someone (Alberto?) to write unit tests.
Moving this ticket to Milestone 1.4.1 and planning to revert the patch within the next 24 hours or so.
comment:11 Changed at 2009-12-13T05:32:44Z by zooko
- Milestone changed from 1.6.0 to eventually
- Owner set to azazel
- Status changed from reopened to new
azazel: the next step on this would be for you to write a unit test. I would be willing to show you how to do so.
comment:12 Changed at 2010-01-15T02:46:45Z by davidsarah
- Keywords test sftp added
comment:13 Changed at 2010-01-15T02:47:06Z by davidsarah
- Keywords reliability added
comment:14 Changed at 2010-02-06T22:22:38Z by davidsarah
- Milestone changed from eventually to 1.7.0
- Priority changed from minor to major
From the patch:
if pathstring == "" or ".":
This is clearly wrong, since "." is truthy. It was probably supposed to be
if pathstring == "" or pathstring == ".":
However, I'm confused as to why sshfs worked when the path was always set to [].
Changed at 2010-02-07T01:39:35Z by davidsarah
Corrected potential fix for sftpd path handling (ticket #645)
Changed at 2010-02-07T01:40:16Z by davidsarah
Corrected potential fix for sftpd path handling (ticket #645) as unified diff
Changed at 2010-02-07T03:36:24Z by davidsarah
Assertions for size attribute, to track down the bug described in http://allmydata.org/pipermail/tahoe-dev/2010-February/003831.html
comment:15 Changed at 2010-03-12T04:08:09Z by davidsarah
- Owner changed from azazel to davidsarah
- Status changed from new to assigned
comment:16 Changed at 2010-05-12T06:06:29Z by davidsarah
This is intended to be fixed by the new SFTP implementation in #1037.
comment:17 Changed at 2010-05-16T16:14:17Z by davidsarah
- Owner changed from davidsarah to azazel
- Status changed from assigned to new
azazel: please check out the ticket1037 branch using
darcs get --lazy http://allmydata.org/source/tahoe-lafs/ticket1037 tahoe-sftp
and try this again.
comment:18 Changed at 2010-05-21T00:57:54Z by davidsarah
- Keywords sshfs added
- Resolution set to fixed
- Status changed from new to closed
This bug has essentially been obsoleted by the new SFTP implementation. bj0 has been testing with sshfs on Linux, and josipl with sshfs on OS X; neither have seen the bugs mentioned here.
I'm sorry for the ugly formatting of my last post, i 've clicked submit instead of preview. Attached there's a patch that fix this bug. I'm not a test expert so if anyone can suggest an idea about how implement a test for this please do it.