Hello, I've got a CentOS box that i'm wanting to set up svnserve on. I've read much, and am confused. Does svnserve support data encryption and also restricting users from specific repositories?
I'm thinking of a single repo structure under /var/svn-repos and I've got two users user1 and user2, each should have access to their own projects in this case user1 can access project1 and user2 can access project2, but neither should be allowed to access the others.
My second issue is I don't want to have a access path like /var/svn-repos/project1
for instance. I've read the -r root option which I would set to:
-r /var/svn-repos
would settle this, but am not sure where to set that option so it's picked up.
Thanks. Dave.
On 7/15/2011 9:41 AM, David Mehler wrote:
Hello, I've got a CentOS box that i'm wanting to set up svnserve on. I've read much, and am confused. Does svnserve support data encryption and also restricting users from specific repositories?
I'm thinking of a single repo structure under /var/svn-repos and I've got two users user1 and user2, each should have access to their own projects in this case user1 can access project1 and user2 can access project2, but neither should be allowed to access the others.
My second issue is I don't want to have a access path like /var/svn-repos/project1
for instance. I've read the -r root option which I would set to:
-r /var/svn-repos
would settle this, but am not sure where to set that option so it's picked up.
I don't believe svnserve provides encryption, but it is not the only way to remotely access subversion repositories. You can also use http(s) with mod_dav_svn or svn+ssh which the clients understand natively. You can set up path-based authorization but that and authentication will depend on which access method(s) you use.
Details here: http://svnbook.red-bean.com/nightly/en/svn-book.html
It is somewhat painful to re-arrange repositories/contents after they grow large, so unless your projects share components it might be better to have separate repositories under the same root directory.
Hello,
Thanks, and apologies if this is a repeat message.
I'm not really wanting to do an apache setup for this project. What my structure will be like I think will be /var/svn and under that parent directory repos# where that equals a separate project.
I've read that svnserve can hook in to sasl for encryption and authentication, but not a lot of details on it. I'm starting to think my best method would be svn+ssh, any experiences with this method?
Thanks. Dave.
On 7/15/11, Les Mikesell lesmikesell@gmail.com wrote:
On 7/15/2011 9:41 AM, David Mehler wrote:
Hello, I've got a CentOS box that i'm wanting to set up svnserve on. I've read much, and am confused. Does svnserve support data encryption and also restricting users from specific repositories?
I'm thinking of a single repo structure under /var/svn-repos and I've got two users user1 and user2, each should have access to their own projects in this case user1 can access project1 and user2 can access project2, but neither should be allowed to access the others.
My second issue is I don't want to have a access path like /var/svn-repos/project1
for instance. I've read the -r root option which I would set to:
-r /var/svn-repos
would settle this, but am not sure where to set that option so it's picked up.
I don't believe svnserve provides encryption, but it is not the only way to remotely access subversion repositories. You can also use http(s) with mod_dav_svn or svn+ssh which the clients understand natively. You can set up path-based authorization but that and authentication will depend on which access method(s) you use.
Details here: http://svnbook.red-bean.com/nightly/en/svn-book.html
It is somewhat painful to re-arrange repositories/contents after they grow large, so unless your projects share components it might be better to have separate repositories under the same root directory.
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 7/15/2011 6:55 PM, David Mehler wrote:
Hello,
Thanks, and apologies if this is a repeat message.
I'm not really wanting to do an apache setup for this project.
You make it sound like that's a hard thing. It's basically a 'yum install httpd mod_dav_svn' and an edit to /etc/httpd/conf.d/subversion.conf.
What my structure will be like I think will be /var/svn and under that parent directory repos# where that equals a separate project.
That will work with any of the serving methods.
I've read that svnserve can hook in to sasl for encryption and authentication, but not a lot of details on it. I'm starting to think my best method would be svn+ssh, any experiences with this method?
I think the sasl encryption is limited to the password exchange. You should probably ask on the subversion list if encryption/security is important - there are some fanatics there. My experience is mostly behind firewalls where those details are less critical.
Hello, Thanks again for your reply.
I've done some more reading/googling and from what i'm seeing high security isn't doable with svnserve even with sasl, passwords from the client need to be stored on disk plain, this isn't desirable in my case.
Do you host a repository via apache? The problem I'm having is not it's ease of setup, I can do that, the issue is one of data visibility. I'm not wanting someone to be able to go to http://domain.com/svn/project1 and see trunk code. I know that I can use basic authentication to prevent this, but would rather the repo not be viewable at all to any anonymous users.
Thanks. Dave
On 7/15/11, Les Mikesell lesmikesell@gmail.com wrote:
On 7/15/2011 6:55 PM, David Mehler wrote:
Hello,
Thanks, and apologies if this is a repeat message.
I'm not really wanting to do an apache setup for this project.
You make it sound like that's a hard thing. It's basically a 'yum install httpd mod_dav_svn' and an edit to /etc/httpd/conf.d/subversion.conf.
What my structure will be like I think will be /var/svn and under that parent directory repos# where that equals a separate project.
That will work with any of the serving methods.
I've read that svnserve can hook in to sasl for encryption and authentication, but not a lot of details on it. I'm starting to think my best method would be svn+ssh, any experiences with this method?
I think the sasl encryption is limited to the password exchange. You should probably ask on the subversion list if encryption/security is important - there are some fanatics there. My experience is mostly behind firewalls where those details are less critical.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 7/16/11 1:35 PM, David Mehler wrote:
I've done some more reading/googling and from what i'm seeing high security isn't doable with svnserve even with sasl, passwords from the client need to be stored on disk plain, this isn't desirable in my case.
Yes, that's why there is the ssh+svn variation. But the client plain text password on disk is more of a linux issue. The windows and mac clients use OS facilities to keep the password encrypted and only accessible by that user.
Do you host a repository via apache? The problem I'm having is not it's ease of setup, I can do that, the issue is one of data visibility. I'm not wanting someone to be able to go to http://domain.com/svn/project1 and see trunk code. I know that I can use basic authentication to prevent this, but would rather the repo not be viewable at all to any anonymous users.
The repos where I use http do have anonymous read access (but behind a firewall). If I didn't want that I'd use basic auth with 'require valid-user' for the location - and probably force https use so the password exchange would be encrypted. Some other parts of the company use https with a client certificate requirement in addition to the password. I don't have access to that configuration but I don't think it would be difficult other than maintaining per-client certificates if you don't already have infrastructure for that.
-
David Mehler -
Les Mikesell