Re: [Savannah-hackers-public] Setting up bzr+ssh on Savannah.

[Karl Fogel]

Still waiting for answers on the question(s) quoted below.

Also, I have some upcoming responsiblities that will prevent me from
making much progress on this for the forseeable future.  If Robert
Collins is willing, Sylvain, would you be okay giving him the same
access to the Savannah machines that I have?  He's just as trustworthy,
and frankly he's better qualified to do this anyway.

No pressure, Robert.  If you can't take this on, we can ask around in
the Bazaar community.  But you'd be a logical choice, if you're willing.

-Karl

Karl Fogel <address@hidden> writes:
>Ping; any help on the questions below appreciated.  Thanks,
>-Karl
>
>Karl Fogel <address@hidden> writes:
>>Sylvain Beucler <address@hidden> writes:
>>>Also: Karl, you'll want to test the creation of new bzr repositories
>>>from the Savane interface in the new environment.
>>
>>Sure.  What is this interface?  I've never used it AFAIK.  (Is it a web
>>interface, or something else?)
>>
>>Current status: I'm testing bzr+ssh:// on vcs-noshell, and some things
>>work, but not everything works yet.  Details follow, ending with a
>>question:
>>
>>I've done the following:
>>
>>    * Tar'd up /srv/bzr on sftp, copied it over to vcs-noshell, and
>>      unpacked it into /srv/bzr there.  (I didn't worry about the small
>>      chance that a repository could have inconsistent state when I tar
>>      it up, since this is just for testing right now anyway.)
>>
>>    * Installed bazaar on vcs-noshell:
>>
>>      First I tried
>>
>>        # apt-get update
>>        # apt-get install bzr
>>
>>      But it turns out the latest bzr in lenny is 1.5 and that's what
>>      we're running already.  So as a temporary solution, I built bzr
>>      2.1.0 from source to run in-place (/root/kfogel/bzr-2.1.0/bzr).
>>      In the long run we'll need a better solution, of course.  At
>>      http://packages.debian.org/lenny-backports/bzr, the latest is
>>      1.16.1, which is a bit behind.  Shall I see if we can get 2.1.0
>>      backported?
>>
>>      Anyway, to get it to build from source I had to do the following:
>>
>>        # apt-get install python-pyrex
>>        # apt-get install python-paramiko
>>        # apt-get install bzrtools
>>        # apt-get install gcc
>>        # apt-get install python-dev
>>        # apt-get install libc6-dev
>>        # apt-get install zlibc
>>        # apt-get install zlib1g-dev
>>        # cd ~root/kfogel/bzr-2.1.0/
>>        # make   (equivalent to 'python setup.py build', I believe)
>>
>>    * I added this to /etc/membersh-conf.pl on vcs-noshell:
>>
>>        $use_bzr = 1;
>>        $bin_bzr = "/root/kfogel/bzr-2.1.0/bzr";
>>
>>    * Also on vcs-noshell, applied a patch to /usr/local/bin/sv_membersh
>>      to disable plugins and suppress writing of ~/.bzr.log.  See
>>      lists.gnu.org/archive/html/savannah-hackers-public/2010-03/msg00027.html
>>      for that patch.  I also tweaked $regexp_bzr at the top of that
>>      file:
>>
>>        our $regexp_bzr = '^(bzr|/root/kfogel/bzr-2.1.0/bzr) serve \
>>                           --inet --directory=/ --allow-writes$';
>>
>>On my client machine, I can do this:
>>
>>  $ BZR_REMOTE_PATH=/root/kfogel/bzr-2.1.0/bzr \
>>    bzr ls bzr+ssh://address@hidden/srv/bzr/emacs/trunk
>>
>>to get a listing of the Emacs bzr branches.  Note the hostname is "git"
>>for now, because bzr.sv.gnu.org doesn't point to vcs-noshell yet.
>>
>>However, I cannot do the same command with user "kfogel":
>>
>>  $ BZR_REMOTE_PATH=/root/kfogel/bzr-2.1.0/bzr \
>>    bzr ls bzr+ssh://address@hidden/srv/bzr/emacs/trunk
>>
>>nor with "kfogel" and the proper path:
>>
>>  $ BZR_REMOTE_PATH=/root/kfogel/bzr-2.1.0/bzr \
>>    bzr ls bzr+ssh://address@hidden/emacs/trunk
>>
>>...because both get this error:
>>
>>  Failed to exec '/root/kfogel/bzr-2.1.0/bzr --no-plugins serve  \
>>    --inet --directory=/srv/bzr --allow-writes':                 \
>>  Permission denied at /usr/local/bin/sv_membersh line 157.
>>  bzr: ERROR: Connection closed: Unexpected end of message.      \
>>  Please check connectivity and permissions, and report a bug if \
>>  problems persist.
>>
>>And that's what I'm debugging right now.  Some notes:
>>
>>In the first case (the successful one using "root"), we presumably never
>>even invoke /usr/local/bin/sv_membersh on the server, because "root" is
>>not affected by the restricted shell system.  Hence the need for
>>"/srv/bzr" in the original URL, since the "--directory=/srv/bzr" option
>>that /usr/local/bin/sv_membersh adds to 'bzr serve' never happens.
>>
>>Does that sound correct?
>>
>>In the second case, with user "kfogel", I'm not sure why the
>>custom-built bzr is failing to exec().  The file
>>/etc/ssh/authorized_keys/kfogel exists and has the expected content.
>>And I can log into the server and run the exact same 'bzr serve' command
>>on the command line (as root) just fine.
>>
>>Any ideas?
>>
>>-Karl