Comparison of your fix vs. my hack below. I suspect that blindly clearing out the buffer of any line noise before sending anything to the remote end will work better but I have no logic or solid arguments to back up that assertion.
============================================= matt@xena:~/data/fossil/junk$ fsl info project-name: Fossil repository: /home/matt/fossils/fossil.fossil local-root: /home/matt/data/fossil/ project-code: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 checkout: 4473a27f3b6e049e3c162e440e0e4c87daf9570c 2012-11-11 22:42:50 UTC parent: 8c7faee6c5fac25b8456e96070ce068400d1d7e1 2012-11-11 17:59:42 UTC tags: trunk comment: Further attempts to help the "ssh" sync protocol move past noisy motd comments and other extraneous login text, synchronize with the remote end, and start exchanging messages successfully. (user: drh) matt@xena:~/data/fossil/junk$ rm -f fossil*;(cd ..;make) && ../fossil clone ssh://matt@xena//home/matt/fossils/fossil.fossil fossil.fossil make: Nothing to be done for `all'. ssh matt@xena Pseudo-terminal will not be allocated because stdin is not a terminal. ../fossil: ssh connection failed: [test1] ============================================= matt@xena:~/data/fossil/junk$ rm -f fossil*;(cd ..;make > make.log) && ../fossil clone ssh://matt@xena//home/matt/fossils/fossil.fossil fossil.fossil ssh matt@xena Pseudo-terminal will not be allocated because stdin is not a terminal. Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 5004225 13950 1751 5238 Sent: 71 2 0 0 Received: 5032480 9827 1742 3132 Sent: 57 93 0 0 Received: 5012028 9872 1137 3806 Sent: 57 1 0 0 Received: 4422156 3069 367 1169 Total network traffic: 1035 bytes sent, 19471761 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 server-id: 3e5f8ed7b0eed8a144fa4b07b4b34cc6c374d20c admin-user: matt (password is "40faae") On Sun, Nov 11, 2012 at 6:09 PM, Richard Hipp <d...@sqlite.org> wrote: > > > On Sun, Nov 11, 2012 at 7:10 PM, Matt Welland <estifo...@gmail.com> wrote: > >> >> On Sun, Nov 11, 2012 at 3:44 PM, Richard Hipp <d...@sqlite.org> wrote: >> >>> >>> >>> On Sun, Nov 11, 2012 at 5:11 PM, Matt Welland <estifo...@gmail.com>wrote: >>> >>>> I'll top-post an answer to this one as this thread has wandered and >>>> gotten very long, so who knows who is still following :) >>>> >>>> I made a simple tweak to the ssh code that gets ssh working for me on >>>> Ubuntu and may solve some of the login shell related problems that have >>>> been reported with respect to ssh: >>>> >>>> >>>> http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26&v2=61f9ddf1e2c8bbb0 >>>> >>> >>> Not exactly the same patch, but something quite similar has been checked >>> in at http://www.fossil-scm.org/fossil/info/4473a27f3b - please try it >>> out and let me know if it clears any outstanding problems, or if I missed >>> some obvious benefit of Matt's patch in my refactoring. >>> >> >> It seems not to work in my situation with the sending of test1. I'm not >> sure why. >> > > The trunk changes works here. And I don't see how it is materially > different from your patch. Am I overlooking something? > > >> >> ============= I get the following ================ >> fossil/junk$ ../fossil clone ssh://matt@xena//home/matt/fossils/fossil.fossil >> fossil.fossil >> >> ssh matt@xena >> Pseudo-terminal will not be allocated because stdin is not a terminal. >> ../fossil: ssh connection failed: [test1] >> >> >> >> >>> >>> >>> >>>> >>>> Joerg iasked if this will make it into a future release. Can Richard or >>>> one of the developers take a look at the change and comment? >>>> >>>> Note that unfortunately this does not fix the issues I'm having with >>>> fsecure ssh but I hope it gets us one step closer. >>>> >>>> Thanks, >>>> >>>> Matt >>>> -=- >>>> >>>> >>>> >>>> On Sun, Nov 11, 2012 at 1:53 PM, j. v. d. hoff < >>>> veedeeh...@googlemail.com> wrote: >>>> >>>>> On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland <estifo...@gmail.com> >>>>> wrote: >>>>> >>>>> On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff >>>>>> <veedeeh...@googlemail.com>**wrote: >>>>>> >>>>>> On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland < >>>>>>> estifo...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> sshfs is cool but in a corporate environment it can't always be >>>>>>> used. For >>>>>>> >>>>>>>> example fuse is not installed for end users on the servers I have >>>>>>>> access >>>>>>>> to. >>>>>>>> >>>>>>>> I would also be very wary of sshfs and multi-user access. Sqlite3 >>>>>>>> locking >>>>>>>> on NFS doesn't always work well, I imagine that locking issues on >>>>>>>> sshfs >>>>>>>> >>>>>>>> >>>>>>> it doesn't? in which way? and are the mentioned problems restricted >>>>>>> to NFS >>>>>>> or other file systems (zfs, qfs, ...) as well? >>>>>>> do you mean that a 'central' repository could be harmed if two users >>>>>>> try >>>>>>> to push at the same time (and would corruption propagate to the >>>>>>> users' >>>>>>> "local" repositories later on)? I do hope not so... >>>>>>> >>>>>> >>>>>> >>>>>> I should have qualified that with the detail that historically NFS >>>>>> locking >>>>>> has been reported as an issue by others but I myself have not seen >>>>>> it. What >>>>>> I have seen in using sqlite3 and fossil very heavily on NFS is users >>>>>> using >>>>>> kill -9 right off the bat rather than first trying with just kill. >>>>>> The lock >>>>>> gets stuck "set" and only dumping the sqlite db to text and >>>>>> recreating it >>>>>> seems to clear the lock (not sure but maybe sometimes copying to a >>>>>> new file >>>>>> and moving back will clear the lock). >>>>>> >>>>>> I've seen a corrupted db once or maybe twice but never been clear >>>>>> that it >>>>>> was caused by concurrent access on NFS or not. Thankfully it is >>>>>> fossil and >>>>>> recovery is a "cp" away. >>>>>> >>>>>> Quite some time ago I did limited testing of concurrent access to an >>>>>> sqlite3 db on AFS and GFS and it seemed to work fine. The AFS test >>>>>> was very >>>>>> slow but that could well be due to my being clueless on how to >>>>>> correctly >>>>>> tune AFS itself. >>>>>> >>>>>> When you say zfs do you mean using the NFS export functionality of >>>>>> zfs? >>>>>> >>>>> yes >>>>> >>>>> I've never tested that and it would be very interesting to know how >>>>>> well it >>>>>> works. >>>>>> >>>>> >>>>> not yet possible here, but we'll probably migrate to zfs in the not >>>>> too far future. >>>>> >>>>> >>>>> >>>>>> My personal opinion is that fossil works great over NFS but would >>>>>> caution >>>>>> anyone trying it to test thoroughly before trusting it. >>>>>> >>>>>> >>>>>> >>>>>>> could well be worse. >>>>>>> >>>>>>>> >>>>>>>> sshfs is an excellent work-around for an expert user but not a >>>>>>>> replacement >>>>>>>> for the feature of ssh transport. >>>>>>>> >>>>>>>> >>>>>>> yes I would love to see a stable solution not suffering from >>>>>>> interference >>>>>>> of terminal output (there are people out there loving the good old >>>>>>> `fortune' as part of their login script...). >>>>>>> >>>>>>> btw: why could fossil not simply(?) filter a reasonable amount of >>>>>>> terminal >>>>>>> output for the occurrence of a sufficiently strong magic pattern >>>>>>> indicating >>>>>>> that the "noise" has passed by and fossil can go to work? right now >>>>>>> putting >>>>>>> `echo " "' (sending a single blank) suffices to let the transfer >>>>>>> fail. my >>>>>>> understanding is that fossil _does_ send something like `echo test' >>>>>>> (is >>>>>>> this true). all unexpected output to tty from the login scripts >>>>>>> would come >>>>>>> _before_ that so why not test for receiving the expected text >>>>>>> ('test' just >>>>>>> being not unique/strong enough) at the end of whatever is send (up >>>>>>> to a >>>>>>> reasonable length)? is this a stupid idea? >>>>>>> >>>>>> >>>>>> >>>>>> I thought of trying that some time ago but never got around to it. >>>>>> Inspired >>>>>> by your comment I gave a similar approach a quick try and for the >>>>>> first >>>>>> time I saw ssh work on my home linux box!!! >>>>>> >>>>>> All I did was read and discard any junk on the line before sending >>>>>> the echo >>>>>> test: >>>>>> >>>>>> http://www.kiatoa.com/cgi-bin/**fossils/fossil/fdiff?v1=** >>>>>> 935bc0a983135b26&v2=**61f9ddf1e2c8bbb0<http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26&v2=61f9ddf1e2c8bbb0> >>>>>> >>>>>> ===========without========== >>>>>> rm: cannot remove `*': No such file or directory >>>>>> make: Nothing to be done for `all'. >>>>>> ssh matt@xena >>>>>> Pseudo-terminal will not be allocated because stdin is not a terminal. >>>>>> ../fossil: ssh connection failed: [Welcome to Ubuntu 12.04.1 LTS >>>>>> (GNU/Linux >>>>>> 3.2.0-32-generic-pae i686) >>>>>> >>>>>> * Documentation: https://help.ubuntu.com/ >>>>>> >>>>>> 0 packages can be updated. >>>>>> 0 updates are security updates. >>>>>> >>>>>> test] >>>>>> >>>>>> ==============with============**=== >>>>>> fossil/junk$ rm *;(cd ..;make) && ../fossil clone >>>>>> ssh://matt@xena//home/matt/**fossils/fossil.fossil >>>>>> fossil.fossil >>>>>> make: Nothing to be done for `all'. >>>>>> ssh matt@xena >>>>>> Pseudo-terminal will not be allocated because stdin is not a terminal. >>>>>> Bytes Cards Artifacts Deltas >>>>>> Sent: 53 1 0 0 >>>>>> Received: 5004225 13950 1751 5238 >>>>>> Sent: 71 2 0 0 >>>>>> Received: 5032480 9827 1742 3132 >>>>>> Sent: 57 93 0 0 >>>>>> Received: 5012028 9872 1137 3806 >>>>>> Sent: 57 1 0 0 >>>>>> Received: 4388872 3053 360 1168 >>>>>> Total network traffic: 1037 bytes sent, 19438477 bytes received >>>>>> Rebuilding repository meta-data... >>>>>> 100.0% complete... >>>>>> project-id: CE59BB9F186226D80E49D1FA2DB29F**935CCA0333 >>>>>> server-id: 3029a8494152737798f2768c799192**1f2342a84b >>>>>> admin-user: matt (password is "7db8e5") >>>>>> >>>>>> >>>>>> >>>>> great. that's essentially what I had in mind (but your approach of >>>>> sending two commands while flushing >>>>> the first response completely probably is better, AFAICS). will >>>>> something like this make it into a future release? >>>>> >>>>> joerg >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Nov 11, 2012 at 2:01 AM, Ramon Ribó <ram...@compassis.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> > Sshfs didn't fix the problems that I was having with fossil+ssh, >>>>>>>>> or at >>>>>>>>> least >>>>>>>>> > only did so partially. >>>>>>>>> >>>>>>>>> Why not? In what sshfs failed to give you the equivalent >>>>>>>>> functionality >>>>>>>>> than a remote access to a fossil database through ssh? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2012/11/11 Timothy Beyer <bey...@fastmail.net> >>>>>>>>> >>>>>>>>> At Sat, 10 Nov 2012 22:31:57 +0100, >>>>>>>>> >>>>>>>>>> j. van den hoff wrote: >>>>>>>>>> > >>>>>>>>>> > thanks for responding. >>>>>>>>>> > I managed to solve my problem in the meantime (see my previous >>>>>>>>>> mail in >>>>>>>>>> > this thread), but I'll make a memo of sshfs and have a look at >>>>>>>>>> it. >>>>>>>>>> > >>>>>>>>>> > joerg >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Sshfs didn't fix the problems that I was having with fossil+ssh, >>>>>>>>>> or at >>>>>>>>>> least only did so partially. Though, the problems that I was >>>>>>>>>> having >>>>>>>>>> with >>>>>>>>>> ssh were different. >>>>>>>>>> >>>>>>>>>> What I'd recommend doing is tunneling http or https through ssh, >>>>>>>>>> and >>>>>>>>>> host >>>>>>>>>> all of your fossil repositories on the host computer on your web >>>>>>>>>> server >>>>>>>>>> of >>>>>>>>>> choice via cgi. I do that with lighttpd, and it works flawlessly. >>>>>>>>>> >>>>>>>>>> Tim >>>>>>>>>> ______________________________****_________________ >>>>>>>>>> fossil-users mailing list >>>>>>>>>> fossil-users@lists.fossil-scm.****org <fossil-users@lists.fossil- >>>>>>>>>> **scm.org <fossil-users@lists.fossil-scm.org>> >>>>>>>>>> http://lists.fossil-scm.org:****8080/cgi-bin/mailman/listinfo/** >>>>>>>>>> ** >>>>>>>>>> fossil-users<http://lists.**fossil-scm.org:8080/cgi-bin/** >>>>>>>>>> mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> ______________________________****_________________ >>>>>>>>> fossil-users mailing list >>>>>>>>> fossil-users@lists.fossil-scm.****org <fossil-users@lists.fossil-* >>>>>>>>> *scm.org <fossil-users@lists.fossil-scm.org>> >>>>>>>>> http://lists.fossil-scm.org:****8080/cgi-bin/mailman/listinfo/**** >>>>>>>>> fossil-users<http://lists.**fossil-scm.org:8080/cgi-bin/** >>>>>>>>> mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> -- >>>>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>>>>>> ______________________________****_________________ >>>>>>> fossil-users mailing list >>>>>>> fossil-users@lists.fossil-scm.****org <fossil-users@lists.fossil-** >>>>>>> scm.org <fossil-users@lists.fossil-scm.org>> >>>>>>> http://lists.fossil-scm.org:****8080/cgi-bin/mailman/listinfo/** >>>>>>> **fossil-users<http://lists.**fossil-scm.org:8080/cgi-bin/** >>>>>>> mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>>> > >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>>>> ______________________________**_________________ >>>>> fossil-users mailing list >>>>> fossil-users@lists.fossil-scm.**org<fossil-users@lists.fossil-scm.org> >>>>> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/** >>>>> fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> fossil-users mailing list >>>> fossil-users@lists.fossil-scm.org >>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>> >>>> >>> >>> >>> -- >>> D. Richard Hipp >>> d...@sqlite.org >>> >>> _______________________________________________ >>> fossil-users mailing list >>> fossil-users@lists.fossil-scm.org >>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>> >>> >> >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> >> > > > -- > D. Richard Hipp > d...@sqlite.org > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users