On Sun, Aug 16, 2015 at 5:21 AM, Thorsten Schöning
<tschoening_at_am-soft.de> wrote:
> Guten Tag Nico Kadel-Garcia,
> am Samstag, 15. August 2015 um 18:14 schrieben Sie:
>
>> Why don't you just use svn+ssh, and stay out of using HTTPS at all?
>
> I've considered that and in fact some of our customers already use SSH
> inbound to our private server and access via svnserve and it works for
> some, but not very well for others. All that SSH settings and key
> stuff and dealing with company proxys and saving things user specific
> in case of different admins and some use terminal servers with generic
> users and some not and such is something I would like to avoid in the
> future. I primary want transport security and there are some other
> reasons to use mod_dav_svn as well:
Cool. I'm glad you thought about it: rejecting something for good
reasons is the sign of a good admin. The lack of good key
administration tools for svn+ssh is one of my problems with it.
> * I want a read only mirror independently of our private server, which
> is sufficient for most customers
But you need an *authenticated* mirror, right? As opposed to a public mirror?
> * Some customers want write access, though
> * I don't want to give various people access to our internal network
> just to retrieve updates anymore
> * I always liked the idea of browsing the repo using a browser and
> WebSVN e.g. is not maintained anymore, so I try other ways
ViewVC is my friend for pure visual web access, it's packaged for most
distributions and is well maintained.
> svnserve using SASL looks like a better option to get transport
> security for me, but doesn't provide the master-slave setup like
> mod_dav_svn does. At least not that I know of...
Ahh. Hmm. I'm not sure why it couldn't, if you can propagate the
configurations for access among the different masters and slaves, and
simply designate the slave servers with the svnserve *daemon's* user
account having only read access to the relevant repositories.
Received on 2015-08-16 14:58:21 CEST