savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karl Fogel
Subject: Re: [Savannah-hackers-public] Setting up bzr+ssh on Savannah.
Date: Tue, 11 May 2010 09:53:47 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.93 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]