Ahh, cool stuff! I did not understand this capability first time though.
Thanks for the info.
--joe
Ryan Schmidt wrote:
>
> On Jun 13, 2007, at 12:37, Joseph Mocker wrote:
>
>> Benjamin Podszun wrote:
>>
>>> Joseph Mocker wrote:
>>>
>>>> What would be nice is an "ssh-agent" type of capability for
>>>> subversion. Where one could authenticate once for a session, and
>>>> the agent would keep track of the authentication/password. When
>>>> authentication is needed, subversion would query the agent first.
>>>
>>> Why don't you use svn+ssh then?
>>
>> Main reasons, per the "red-bean" subversion book:
>>
>> * Requires users to be in same system group, or use a shared ssh key.
>>
>> * Can lead to file permissions problems.
>>
>>
>> Coming from similar headaches with CVS, I didn't want to deal with
>> that again, svnserve seemed a good choice to not have to deal with that.
>>
>> Also, unless there is a trick I don't know about (which there
>> probably is), the svn+ssh URLs to the repository include full
>> pathnames to the location of the repository on the server. So if I
>> decide to move that location, I have to tell all my developers to
>> update their URLs. OTOH, svnserve abstracts that for you.
>
> The trick is described in the book:
>
> http://svnbook.red-bean.com/en/1.2/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks.fixedcmd
>
>
>> Controlling the invoked command
>>
>> Because we can specify the executed server-side command, it's easy to
>> name a specific svnserve binary to run and to pass it extra arguments:
>>
>> command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
>>
>> In this example, /path/to/svnserve might be a custom wrapper script
>> around svnserve which sets the umask (see the section called
>> “Supporting Multiple Repository Access Methods”). It also shows how
>> to anchor svnserve in a virtual root directory, just as one often
>> does when running svnserve as a daemon process. This might be done
>> either to restrict access to parts of the system, or simply to
>> relieve the user of having to type an absolute path in the svn+ssh://
>> URL.
>
>
> Joseph Mocker wrote:
>
>> I do use svn+ssh for one (private) repository for myself, but
>> currently for the group repository we're only using svnserve.
>>
>> Hmm, thinking about shared ssh keys, actually I could probably create
>> a single server account with the users keys added to
>> .ssh/authroized_keys file, and people would access svn via that
>> account. That would mitigate permissions issues, but then do changes
>> get logged as the original user, or the server account?
>
> The next paragraphs at the above book URL address that issue:
>
>> It's also possible to have multiple users share a single account.
>> Instead of creating a separate system account for each user, generate
>> a public/private keypair for each person. Then place each public key
>> into the authorized_users file, one per line, and use the
>> --tunnel-user option:
>>
>> command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com
>> command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com
>>
>> This example allows both Harry and Sally to connect to the same
>> account via public-key authentication. Each of them has a custom
>> command that will be executed; the --tunnel-user option tells
>> svnserve -t to assume that the named argument is the authenticated
>> user. Without --tunnel-user, it would appear as though all commits
>> were coming from the one shared system account.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 14 00:49:35 2007