On Sun, Nov 11, 2012 at 8:25 PM, Matt Welland <estifo...@gmail.com> wrote:
> 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. > Both versions send two "echo" commands to the remote side, ignore the return from the first echo and check the return from the second. The only difference that I see between your patch and mine (unless I'm missing something) is that I'm sending different "echo" text. What do you see that is different from this? > > ============================================= > 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 > > -- 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
