[MINC-development] MINC and Subversion

[Jonathan HARLAP]

Andrew Janke wrote:
>> We use a simple SVN with apache setup - no SSL, just plain apache
>> authentication, and with a separately maintained set of accounts
>> (htpasswd) for write access. Not the most secure solution, but
>> hopefully enough for our purposes.
> 
> Thanks for the info.  So essentially you have two types of users,
> those who can see the svn repo and those who cant.. :)  a .htpasswd
> method with svn doesn't allow for more fine-grained control does it?
> (the LDAP thing is out as the BIC still uses NIS from what I know.
> IRIX and GNU/Linux still won't hold hands and play nice)

Now that I look it up, LDAP isn't necessary: apache_auth_pam would be 
happy to use the NIS accounts.

SSL server I said and meant it.  SSL client certs I think is way 
overkill and was just pointing out that you can do whatever you want. 
Users logging in to SVN via http using their NIS accounts will be 
sending their BIC account info in plaintext across the internet.  Not 
really a great idea, IMHO - thus SSL server to encrypt the communication 
channel such that the account info is sent securely.

As to how to handle internal and external users together: BIC accounts 
(NIS) for internal users and a separate htpasswd-type file for the 
external users should be fine.  You can load more than one auth module 
into apache, and if you use an auth block that's something like:

AuthType Basic
AuthName "secure area"
AuthPAM_FallThrough on
AuthUserFile /path/to/apache/passwd/passwords
AuthGroupFile /path/to/apache/passwd/groups

require group coders
require valid-user

Then it will try PAM (in our case, NIS) and if the user doesn't appear 
in NIS then it will fall through to the specified htpasswd-managed user 
and group files.

> 
>>> 1. keep on burying our heads and leave it in CVS
>>> 2. install SVN and lots of acronyms on feeble.
>>> 3. Use a third party.
>> I've used google code for a different project and quite like it - but
>> all repositories have to be world readable, which might not be what you
>> want. I suspect that the desire to keep certain repositories private
>> will mean that the do it yourself solution is still best.
> 
> Most interesting, care to hand out the address so that I can have a
> poke around to see what a small project would look like?
> 
> I suspect however than an external site will not really ever be
> completely sanctioned if only for political reasons.  ie: it would be
> nice if the SVN address of MINC still included bic.mni.mcgill.ca in it
> somewhere...
> 
> The option that does present itself here though is to have a local
> webDAV repo at the BIC that is only open to those with passwords (ala
> .htpasswd) and then use a post-commit hook to synch it to an external
> "read for all" repo on google code or the likes.  Might be messy
> though.
> 
> I should also point out that the only code that will migrate to this
> new svn thing (if it comes into being) will be code that is on
> packages (ie: stuff that is to be released). if things are not to be
> released then either we make another separate local repo or continue
> to use CVS for these projects.
> 
> This to my mind is a good way to separate what is and what isn't for
> publc consumption from the BIC.
> 

For private projects you could have a private repos and just don't allow 
the PAM fallthrough so only internals have access (or have a separate 
set of user/group files so internals and a different set of selected 
externals have access)

J