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 <[email protected]> wrote:
>
>
> On Sun, Nov 11, 2012 at 7:10 PM, Matt Welland <[email protected]> wrote:
>
>>
>> On Sun, Nov 11, 2012 at 3:44 PM, Richard Hipp <[email protected]> wrote:
>>
>>>
>>>
>>> On Sun, Nov 11, 2012 at 5:11 PM, Matt Welland <[email protected]>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 <
>>>> [email protected]> wrote:
>>>>
>>>>> On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland <[email protected]>
>>>>> wrote:
>>>>>
>>>>> On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff
>>>>>> <[email protected]>**wrote:
>>>>>>
>>>>>> On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland <
>>>>>>> [email protected]>
>>>>>>> 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ó <[email protected]>
>>>>>>>> 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 <[email protected]>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>> [email protected].****org <[email protected]
>>>>>>>>>> **scm.org <[email protected]>>
>>>>>>>>>> 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
>>>>>>>>> [email protected].****org <[email protected]*
>>>>>>>>> *scm.org <[email protected]>>
>>>>>>>>> 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
>>>>>>> [email protected].****org <[email protected]**
>>>>>>> scm.org <[email protected]>>
>>>>>>> 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
>>>>> [email protected].**org<[email protected]>
>>>>> 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
>>>> [email protected]
>>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>>
>>>>
>>>
>>>
>>> --
>>> D. Richard Hipp
>>> [email protected]
>>>
>>> _______________________________________________
>>> fossil-users mailing list
>>> [email protected]
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>>
>>
>> _______________________________________________
>> fossil-users mailing list
>> [email protected]
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>
>
> --
> D. Richard Hipp
> [email protected]
>
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
