kfogel@collab.net wrote:
>Andy Helten <andy.helten@dot21rts.com> writes:
>
>
>>>Some random-but-not-completely-random ideas:
>>>
>>> 1. Turn off http-compression in ~/.subversion/servers
>>>
>>>
>>>
>>Assuming I did this correctly (set 'http-compression = no' in the
>>'[global]' section), this made no difference -- it failed exactly as
>>before in exactly the same place.
>>
>>
>
>You also made sure "[global]" itself was uncommented, right?
>
>
Yes, I uncommented [global].
>
>
>>> 2. I can't remember, did you try svn:// access with svnserve instead?
>>>
>>>
>>>
>>I did not try this before. I just tried it and it worked fine. This
>>is useful in that it seems to point the finger to the HTTPS
>>functionality, however, I would rather not use the svn:// access
>>method because I don't want to create system accounts for those
>>accessing this repository.
>>
>>
>
>??
>
>Using svn:// access should have nothing to do with creating system
>accounts for repository users.
>
>
Hmmm. This would be great if it is possible... please elaborate.
Obviously I want security (hence the usage of HTTPS), so how does one
provide security with svn:// access? The original route I took was using
svn+ssh://, but according to "The Book", this requires system accounts
(from the "SSH authentication and authorization" section):
-----
svnserve's built-in authentication can be very handy, because it avoids
the need to create real system accounts. On the other hand, some
administrators already have well-established SSH authentication
frameworks in place. In these situations, all of the project's users
already have system accounts and the ability to “SSH into” the server
machine.
.
[snip]
.
What's happening here is that the Subversion client is invoking a local
ssh process, connecting to host.example.com, authenticating as the user
harry, then spawning a private svnserve process on the remote machine,
running as the user harry. ..
-----
All of this implies (to me anyway), that user 'harry' must have a system
account. Am I missing something?
Thanks,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 30 00:28:44 2004