Thu 12 Nov 2009 09:45:09 PM UTC, comment #12:
Should I file a separate support request for enabling bzr+ssh again? It really does make a very significant difference and I don't want it to be forgotten.
|
Thu 12 Nov 2009 09:35:27 PM UTC, comment #11:
Thank you!
|
Thu 12 Nov 2009 09:28:26 PM UTC, comment #10:
I thought it was disabled, but it turns out it was enabled temporarily at a point but not disabled since then. This is the case now.
|
Thu 12 Nov 2009 08:41:27 PM UTC, comment #9:
I don't say bzr+ssh is supported, I say it is enabled. In fact, we've been using it, with disasterous results. We believe using bzr+ssh is the reason our repository was corrupted, not once but twice!
If you don't want to support bzr+ssh, I'd feel much safer if it was completely disabled, specially taking into account our mailing lists archives contain old mails referencing bzr+ssh URLs and advicing for their use.
Right now my only option is reminding every project member that bzr+ssh should not be used, and taking backups periodically (I take them every hour) just in case somebody used them by mistake.
|
Thu 12 Nov 2009 02:37:50 PM UTC, comment #8:
You say you want Savannah to support bzr+ssh. I answered: not now.
You say that Savannah supports both sftp and ssh. I don't think so, it only supports sftp.
|
Thu 12 Nov 2009 12:11:11 PM UTC, comment #7:
You're currently allowing both sftp: and bzr+ssh: at the same time.
I suggested that bzr+ssh: be disabled for safety reasons. You cited security reasons in favour of disabling it too.
It seems that we agree, so why are you closing this bug? :-)
|
Thu 12 Nov 2009 10:09:02 AM UTC, comment #6:
At Savannah we do not allow local shell access to make it harder for users to attempt to exploit vulnerabilities before fixes are applied.
Consequently we will not offer both sftp: and bzr+ssh: at the same time, as the combination of both would allow users to run arbitrary commands on the server through commit hooks, in effect getting local access.
At a point we may move to bzr+ssh completely, but this requires moving all the projects at once, and making sure they can create the directory layouts they need through our web interface. Currently, there is not enough incentive, or time, to do so. In particular it seems server-side commit hook'ing is supported, but there are few actual server-side commit hooks.
As for installing the recent 2.0, we'll wait until this is properly support in Debian stable, or possibly Debian backports.
So it is a bit more complicated than just installing a piece of software on our servers.
|
Wed 11 Nov 2009 11:37:06 PM UTC, comment #5:
It would really be far preferable to support bzr+ssh properly; it should just be a matter of installing an up-to-date version of bzr on the server.
bzr is really not at all network-efficient when using sftp, because it tends to have to lock the branch, download the entire pack file, change it, and upload the whole thing again; a trivial commit to grub (which triggered an automatic repack) just involved about 4MB of network transfer for me. bzr+ssh is much, much better for this kind of thing since it can send much more concise messages. The server doesn't usually have to stay religiously in step, but something in the bzr 2.0.x series would be good.
|
Tue 10 Nov 2009 10:24:27 AM UTC, comment #4:
Does this rule out the possibility of corruption? We consider it quite likely that bzr+ssh:// is the cause. Colin?
I'd like to recommend that bzr+ssh:// is entirely disabled untill it is clear that it doesn't corrupt data. We had repository corruption twice and had to reconstruct the whole repository from scratch both times. It's a terrible waste of time, sometimes loss of data. Taking this into account, I think the proposed measure would be reasonable.
|
Sat 07 Nov 2009 06:47:16 PM UTC, comment #3:
Note that Savannah offers sftp-based access to the bzr repository, but do not allow you to run a bzr smartserver of the remote side.
|
Sat 07 Nov 2009 03:32:46 PM UTC, comment #2:
We had some corruption issues with our repository (GRUB project). We're not sure what caused it yet, but we don't rule out the possibility that it could be related to our use of bzr+ssh://
If I understood correctly, bzr+ssh:// makes us use bzr in daemon mode in the server; this code is otherwise (sftp://) not used, resulting in very different code paths.
|
Sat 24 Oct 2009 05:38:45 PM UTC, comment #1:
I think these warnings are actually a client bug. https://bugs.launchpad.net/bzr/+bug/260335 says that it only happens with a bzr 1.5 client (the version in Debian stable, unfortunately) talking to a 1.6 or later server.
|
Sat 24 Oct 2009 03:30:41 PM UTC, original submission:
https://savannah.gnu.org/bzr/?group=grub encourages use of sftp:// protocol when branching off a Bazaar repository, but according to Colin Watson (CCed), bzr+ssh:// is a better option. From his email in grub-devel:
<quote>
I would also generally recommend using bzr+ssh:// rather than sftp://
URLs. sftp:// involves copying all the metadata back and forward for a
number of operations. bzr+ssh:// runs a smart server on the remote
system and interacts with that, which is generally much faster. If you
do this, you'll need to drop /srv/bzr from the URL as well, so:
bzr branch bzr+ssh://${username}@bzr.sv.gnu.org/grub/trunk
</quote>
However, it appears to generate some warnings. Perhaps the benefit does not apply untill server is upgraded to 1.2?
$ bzr branch bzr+ssh://robertmh@bzr.sv.gnu.org/grub/trunk
No handlers could be found for logger "bzr"
Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this)
No handlers could be found for logger "bzr"
Branched 1768 revision(s).
$
|