<div class="gmail_quote">On Sun, Sep 26, 2010 at 11:56 AM, Vincent Ladeuil <<a href="mailto:v.ladeuil%2Blp@free.fr">v.ladeuil+lp@free.fr</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">>>>>> Maritza Mendez <<a href="mailto:martitzam@gmail.com">martitzam@gmail.com</a>> writes: > On Sun, Sep 26, 2010 at 9:25 AM, Maritza Mendez <<a href="mailto:martitzam@gmail.com">martitzam@gmail.com</a>> wrote: >> If this bug has been reported, I failed to find it on Launchpad. </div>Very nice bug report, please, don't hesitate to file it on launchpad. Anyway, failing to find a duplicate is not a deadly sin ;) At worst, the community or the devs may finally realize it's a dupe but could point to it if the report is clearer or better explain the problem. <div class="im"> >> There have been numerous "TooManyConcurrentRequests" bugs filed, >> but most/all of them seem to be related to legitimate attempts to >> open an ssh connection. I have found a case in which there seems >> to be no legitimate reason to involve ssh. </div>Even if the reason is not legitimate, it's still possible that we shouldn't tracebak and create a new connection (I'm pretty sure we have related and valid use cases that we fail to handle (and we raise TooManyConcurrentRequests), http:/<a href="http://pad.lv/483661" target="_blank">pad.lv/483661</a> for example. There is also one use case I thought I reported but couldn't find anymore :-/ <snip/> <div class="im"> >> So it *appears* that either qconfig or explorer is triggering an >> illegitimate ssh connection request when the active GUI page is a >> checkout via bzr+ssh. </div>In fact, that's the opposite that is surprising: that we manage to resue the same connection instead of creating a new "illegitimate" one. Trying to use the same connection is "illegitimate", hence the exception. But *why* we are doing this, is unclear. <snip/> <div class="im"> > FYI, it does not matter if the checkout was set up exactly as > above or if I use authentication.conf to minimize typing. As it > turns out, I usually need to include the username in the transport > scheme anyway because I use several different "shared" accounts on > the server to grant access to different groups of branches. It's > a simple but effective way of controlling access to "restrcited" > repositories. </div>This sounds interesting, would you mind share your setup (if only in describing it a bit more) and tell us what is missing in the crontrib/ directory or if you used or modified something here ? Vincent </blockquote></div> Thanks for your support. A few quick notes: 1. The bug is now logged as <a href="https://bugs.launchpad.net/bzr-explorer/+bug/648294" target="_blank">https://bugs.launchpad.net/bzr-explorer/+bug/648294</a> 2. I appreciate the irony. (A month ago I suggested that tools in the bzr system should reuse ssh connections). I'm impressed that you remembered and more impressed that you pointed this out so gently. :) 3. Regarding access control, I didn't have to modify anything (although I admit to having thought about it). I have a box which I use to provide centralized storage for bzr branches for use by (at least) two teams, who are working on two different, but not necessarily disjoint sets of code. Suppose Team1 is working on Product1 and Product2. Team2 is working on Product1 and Product3. So both teams need to access branches related to Product1 and but only Team1 should see Product2 and only Team2 should see Product3. So I create three users on my central server: user1 who owns Product1 branches, user2 who owns Product2 brnaches and user3 who owns Product3 branches. Team1 is given passwords for user1 and user2. Team2 is given passwords for user1 and user3. Now the beauty of bzr+ssh is that each member (of Team1 or Team2) only needs to use a given password once -- to store her SSH public key in each account for which she has a password. After that, an ssh-agent takes care of the rest. This system is relatively each to maintain *unless* you need to revoke someone's access to a particular branch. To do that, you have to change the password of the "shared user" which owns that branch. And that inconveniences everyone who uses that "shared account" for any branch it owns. So this works for small setups but I would not try to use it in a large enterprise. Another thing to remember obviously is this setup does nothing to stop a developer from improperly disclosing her legitimately obtained branch to unauthorized people. But then that's always the case with all information. ~M