Re: [fossil-users] SSH client updates.
On Fri, Jul 12, 2013 at 3:15 AM, Matt Welland estifo...@gmail.com wrote: My vote is to go with the new behaviour only. More options usually means more pain - albeit after getting though any transition troubles. +1 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
On 2013-07-12 01:49, Andy Bradford wrote: Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200: I would prefer to not have that option. test-http is for testing a new transport method. If you give someone read acces to your ssh repo then test-http circumvents that. In fact test-htp makes you while connected setup user I agree with you on this sentiment. Does this also mean, however, that you would prefer to remove the original clone behavior entirely? Right now, the original behavior is preserved by default: fossil clone ssh://amb@remote//tmp/test.fossil test.fossil Will invoke a remote shell via SSH, go through the echo/reply probes, and then finally launch ``fossil test-http /tmp/test.fossil''. Should this option be removed entirely? Should it be changed instead to go through the same echo/reply probes, but then finally call ``fossil http /tmp/test.fossil'' instead? Or should the default behavior be replaced with simply issuing a remote ``fossil http /tmp/test.fossil'' as I now do using the -h http option? My vote would be to remove the original behavior, and replace it with simply running a remote ``fossil http /tmp/test.fossil'' and not worry about shell issues. But, that does introduce one difference in behavior on clones---because the ``fossil http'' command outputs a Connection: close header in the response, each interaction during the clone will invoke a new SSH command. This isn't necessarily a problem for people who are using SSH keys, but you will be prompted for a password each time if you aren't using a key. This may not be so bad, however, because I believe autosync already behaves this way, so really, it's only the cloning operation that would change in behavior. Perhaps a poll is in order. Thanks for the feedback. Andy -- TAI64 timestamp: 400051df44b5 I prefer the new way and do remove the old way -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200: I would prefer to not have that option. test-http is for testing a new transport method. If you give someone read acces to your ssh repo then test-http circumvents that. In fact test-htp makes you while connected setup user I agree with you on this sentiment. Does this also mean, however, that you would prefer to remove the original clone behavior entirely? Right now, the original behavior is preserved by default: fossil clone ssh://amb@remote//tmp/test.fossil test.fossil Will invoke a remote shell via SSH, go through the echo/reply probes, and then finally launch ``fossil test-http /tmp/test.fossil''. Should this option be removed entirely? Should it be changed instead to go through the same echo/reply probes, but then finally call ``fossil http /tmp/test.fossil'' instead? Or should the default behavior be replaced with simply issuing a remote ``fossil http /tmp/test.fossil'' as I now do using the -h http option? My vote would be to remove the original behavior, and replace it with simply running a remote ``fossil http /tmp/test.fossil'' and not worry about shell issues. But, that does introduce one difference in behavior on clones---because the ``fossil http'' command outputs a Connection: close header in the response, each interaction during the clone will invoke a new SSH command. This isn't necessarily a problem for people who are using SSH keys, but you will be prompted for a password each time if you aren't using a key. This may not be so bad, however, because I believe autosync already behaves this way, so really, it's only the cloning operation that would change in behavior. Perhaps a poll is in order. Thanks for the feedback. Andy -- TAI64 timestamp: 400051df44b5 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
My vote is to go with the new behaviour only. More options usually means more pain - albeit after getting though any transition troubles. I am biased in this. The old method seemed brittle. However I haven't yet tested your new code. Hopefully I'll get a chance to do that next week some time. On Thu, Jul 11, 2013 at 4:49 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200: I would prefer to not have that option. test-http is for testing a new transport method. If you give someone read acces to your ssh repo then test-http circumvents that. In fact test-htp makes you while connected setup user I agree with you on this sentiment. Does this also mean, however, that you would prefer to remove the original clone behavior entirely? Right now, the original behavior is preserved by default: fossil clone ssh://amb@remote//tmp/test.fossil test.fossil Will invoke a remote shell via SSH, go through the echo/reply probes, and then finally launch ``fossil test-http /tmp/test.fossil''. Should this option be removed entirely? Should it be changed instead to go through the same echo/reply probes, but then finally call ``fossil http /tmp/test.fossil'' instead? Or should the default behavior be replaced with simply issuing a remote ``fossil http /tmp/test.fossil'' as I now do using the -h http option? My vote would be to remove the original behavior, and replace it with simply running a remote ``fossil http /tmp/test.fossil'' and not worry about shell issues. But, that does introduce one difference in behavior on clones---because the ``fossil http'' command outputs a Connection: close header in the response, each interaction during the clone will invoke a new SSH command. This isn't necessarily a problem for people who are using SSH keys, but you will be prompted for a password each time if you aren't using a key. This may not be so bad, however, because I believe autosync already behaves this way, so really, it's only the cloning operation that would change in behavior. Perhaps a poll is in order. Thanks for the feedback. Andy -- TAI64 timestamp: 400051df44b5 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
On Wed, Jul 10, 2013 at 9:51 AM, Andy Bradford amb-fos...@bradfords.orgwrote: ... Is there value in keeping this old method? I personally don't see any, but then I don't have the background to know why it was done this way. If i'm not sorely mistaken, the current approach was done because it was quick and easy to add. ssh was added relatively late in Fossil's development (and i've never used it - the CGI interface gives me everything i need), and almost certainly piggybacked on as much connection-related code as it could. Removing it would simplify the code, but perhaps break unforseen things. For now, I think it would be alright to leave it in as the default behavior just to be safe, despite the fact that it introduces multiple code paths. i would have thought that it leads to fewer code paths (no ssh-specific server component, for example). ... The changes are still against version-1.26 (I used it as BASIS when I branched). I did a test merge against trunk and there were no conflicts. I'm not certain the changes are implemented in the best way, but they do work and they also allow for more restricted control using SSH keys. Very little has changed in the trunk since then, so i wouldn't expect any conflicts. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
On 2013-07-10 21:31, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. On linux (arch) it works. Now if i lower my credentials i'm not allowed to write! I had no problem typing the password. even if i botch my first one! fossil clone ssh://renez@arch:22/src/fossil/myclone.fossil?fossil=bin/fssh new2.fsl ssh -e none -T renez@arch renez@arch's password: Permission denied, please try again. renez@arch's password: Round-trips: 6 Artifacts sent: 0 received: 21510 Clone finished with 1592 bytes sent, 28967314 bytes received Killed by signal 2. Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 admin-user: renez (password is 4b8994) Is nobody allowed to clone on your repo? -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
On Wed, Jul 10, 2013 at 10:32:26PM +0200, Rene wrote: On 2013-07-10 21:31, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. On linux (arch) it works. Now if i lower my credentials i'm not allowed to write! I had no problem typing the password. even if i botch my first one! fossil clone ssh://renez@arch:22/src/fossil/myclone.fossil?fossil=bin/fssh new2.fsl ssh -e none -T renez@arch renez@arch's password: Permission denied, please try again. renez@arch's password: Round-trips: 6 Artifacts sent: 0 received: 21510 Clone finished with 1592 bytes sent, 28967314 bytes received Killed by signal 2. Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 admin-user: renez (password is 4b8994) Cloning the repo work with orignal fossil using http:// protocol, so nobody can clone it.. Here some experiments: - try 1: normal fossil, clone throught http: - me@myserver(~/test) $ fossil clone http://10.0.0.1/repo/common common1.fossil Round-trips: 12 Artifacts sent: 0 received: 3120 Clone finished with 2888 bytes sent, 75949538 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 6e3c63) - try 2: normal fossil, clone throught ssh: - me@myserver(~/test) $ fossil clone ssh://me@10.0.0.1//fossil/common.fossil common2.fossil ssh -e none -T me@10.0.0.1 me@10.0.0.1's password: Round-trips: 12 Artifacts sent: 0 received: 3157 Clone finished with 2994 bytes sent, 75953950 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 4ff602) - try 3: patched fossil, clone throught ssh: - (Notice on output that it ask password on same line as sync status output, but we can see that artifact received and sent are 0) $ fossil2 clone ssh://me@10.0.0.1//fossil/common.fossil common3.fossil ssh -e none -T me@10.0.0.1 fossil http /fossil/common.fossil me@10.0.0.1's password: nt: 0 received: 0 Now, if I list my 3 cloned repos: (common3.fossil have the journal file and is a lot smaller that it should be..) me@myserver(~/test) $ ls -ltrh total 336800 -rw-r--r-- 1 me me 79.7M Jul 10 17:11 common.fossil -rw-r--r-- 1 me me 79.7M Jul 10 17:13 common2.fossil -rw-r--r-- 1 me me 14.5K Jul 10 17:13 common3.fossil-journal -rw-r--r-- 1 me me 4.7M Jul 10 17:13 common3.fossil -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
On Wed, Jul 10, 2013 at 05:24:29PM -0400, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 10:32:26PM +0200, Rene wrote: On 2013-07-10 21:31, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. On linux (arch) it works. Now if i lower my credentials i'm not allowed to write! I had no problem typing the password. even if i botch my first one! fossil clone ssh://renez@arch:22/src/fossil/myclone.fossil?fossil=bin/fssh new2.fsl ssh -e none -T renez@arch renez@arch's password: Permission denied, please try again. renez@arch's password: Round-trips: 6 Artifacts sent: 0 received: 21510 Clone finished with 1592 bytes sent, 28967314 bytes received Killed by signal 2. Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 admin-user: renez (password is 4b8994) Cloning the repo work with orignal fossil using http:// protocol, so nobody can clone it.. Here some experiments: - try 1: normal fossil, clone throught http: - me@myserver(~/test) $ fossil clone http://10.0.0.1/repo/common common1.fossil Round-trips: 12 Artifacts sent: 0 received: 3120 Clone finished with 2888 bytes sent, 75949538 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 6e3c63) - try 2: normal fossil, clone throught ssh: - me@myserver(~/test) $ fossil clone ssh://me@10.0.0.1//fossil/common.fossil common2.fossil ssh -e none -T me@10.0.0.1 me@10.0.0.1's password: Round-trips: 12 Artifacts sent: 0 received: 3157 Clone finished with 2994 bytes sent, 75953950 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 4ff602) - try 3: patched fossil, clone throught ssh: - (Notice on output that it ask password on same line as sync status output, but we can see that artifact received and sent are 0) $ fossil2 clone ssh://me@10.0.0.1//fossil/common.fossil common3.fossil ssh -e none -T me@10.0.0.1 fossil http /fossil/common.fossil me@10.0.0.1's password: nt: 0 received: 0 Now, if I list my 3 cloned repos: (common3.fossil have the journal file and is a lot smaller that it should be..) me@myserver(~/test) $ ls -ltrh total 336800 -rw-r--r-- 1 me me 79.7M Jul 10 17:11 common.fossil -rw-r--r-- 1 me me 79.7M Jul 10 17:13 common2.fossil -rw-r--r-- 1 me me 14.5K Jul 10 17:13 common3.fossil-journal -rw-r--r-- 1 me me 4.7M Jul 10 17:13 common3.fossil -- Martin G. Sorry, *my* mistake.. I didn't notice the new version of the patch on latest Andy Bradford email. My test was made with the previous patch. Work fine now.. sorry for the noise.. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
Thus said Martin Gagnon on Wed, 10 Jul 2013 17:50:40 -0400: Sorry, *my* mistake.. I didn't notice the new version of the patch on latest Andy Bradford email. My test was made with the previous patch. Not a problem. I should probably setup a fossil clone that can be accessed, rather than sending patches (I'll get there eventually). I was about to respond mentioning that your output was consistent with the first version of the patch. Looks like you got it figured out. Andy -- TAI64 timestamp: 400051ddf557 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH client updates.
Thus said Martin Gagnon on Wed, 10 Jul 2013 17:50:40 -0400: Work fine now.. sorry for the noise.. Speaking of noise, time to add a little more (because my original email wasn't quite long enough). The new options that I've added are not yet fully documented in the usage/help (not having settled on how to access the changes in client). At the moment, you can specify which type of HTTP access to use (test-http vs http): fossil clone -h http ssh://amb@remote//tmp/test.fossil test.fossil Or if you prefer the old method (this option may be redundant): fossil clone -h test-http ssh://amb@remote//tmp/test.fossil test.fossil Path to fossil can be made explicit: fossil clone -f /opt/bin/fossil -h http ssh://amb@remote//tmp/test.fossil test.fossil Of course, if force command SSH keys are in use, it doesn't really matter what is specified because that will be controlled by the remote SSH account, in which case you might want to explicitly set the ssh command (in the even that the SSH key is different from your default SSH key): fossil clone -s 'ssh -e none -T -i /home/amb/.ssh/fossil' ssh://amb@remote//tmp/test.fossil test.fossil I wasn't certain if this was the right location to do this; can a repository specific SSH command be configured prior to cloning the repository? All of these options are also exposed in sync/push/pull (in the event that it needs to be changed). Andy -- TAI64 timestamp: 400051ddf842 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users