On 10/19/06, Andrew Lentvorski <[EMAIL PROTECTED]> wrote:
Okay, Subversion junkies, here's your chance... I need to put together source control for a class I'm teaching. I used CVS with Solaris ACL's last year. I really don't want to do that again.
There are few fundamental things to keep in mind when implementing this to make things go smoother with little maintenance over time. 1. Keep file system access to the repository restricted. Keep it away from a NFS or other network file system share. This keep access control easier. There's no point in putting in access control if a student can copy the repository backend to some other place and pull out the files in version control. 2. Deal with authentication and access control separately. 3. Use a real authentication mechanism. Although subversion can use it's own user, password list, don't use that. Tie authentication into an existing system already in place, (unix logins or windows logins) 4. Use apache and stay away from svnserve, ssh+svn, other access methods if possible. Using apache to access the repository is slower than svnserve or ssh+svn, but using apache brings a lot more to the table that losing speed might be work it (YMMV). 1) Individual authenticated access (per student)
Students should not be able to look at one another's work. This probably means one repository per student. https with login would probably be good (as long as student's can change their own passwords). ssh is okay, but probably not optimal as most of the students are on Windows boxes and ssh is not so hot there.
SVN over http(s) can be setup to use PAM for authentication. It's fairly straight forward to setup authentication against Windows Domain logins (or any other login for that matter, eg, solaris login on that box) using mod_auth_pam. If you need specific example of how to do it, there is some info in the subversion book and mailing lists. (or contact me off-list and I can send you detailed instructions & setup files for apache & subversion that might help). Once authentication is setup, deal with access control separately using "AuthzSVNAccessFile somefile.conf". Using this method you can control read & write access to every repository and every directory specifically. For eg, this access control file could look like, [myclassprojects:/] instructor = rw [myclassprojects:/student1] student1 = rw [myclassprojects:/student2] student2 = rw etc. This allows "instructor" to have access to everything in repository myclassprojects, whereas student1 and student2 are restricted to their own directories only. 2) The instructor needs to be able to check out and modify the files of
any student
This was a *nightmare* on CVS. I would like to be able to use the same mechanism as the students but with a different login/password.
See above. Going behind the scenes and hitting the filesystem directly almost
always results in permission problems. I really want to avoid that.
Using apache and using pam to authenticate allows you to avoid that. However, you do need to make the actual repository owned by apache once after creating the repository. After that don't touch the repository backend directly and use only http(s).
4) Should use the FS repository Sorry, this is already likely to have too many dependencies. I refuse to manage a database on top of everything else.
You get to pick it when you create the repository. Although fsfs is default I think. 5) Low maintenance to manage
Once I start this running, I don't want to have to touch it again. As nightmarish as CVS with ACL's was, once I got it going, I didn't have to do one iota of extra work.
Once everything is setup, all you have to do is keep your access control file updated as users & repositories come & go. There usually is no need to touch the authentication mechanism after setup. HTH. -V -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
