Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've recently acquired a dedicated server, and need to move several repositories to it from a source control hosting service. Having not much experience in server administration however I have no clue how to effectively organize it. What I seek --

  1. svn.host.com, hg.host.com, git.host.com subdomains that will be roots to the different repos, via SSH keys
  2. easy creation of new repositories
  3. authentication using the server unix user list, but with permissions on a per-project basis, also optional read-only public access for some of the repos

Unfortunately any search term I try on Google directs me to commercial hosted solutions, and not guides on how to roll up my own. I need something like a stripped down hosted solution but without the need of having users be able to create their own repos.

Any suggestions, tutorials or scripted solutions on where to start research? A open source solution for an administrative interface for handling that (or at least for some would be perfect...

share|improve this question

5 Answers 5

RhodeCode is an open source repository browser/management tool with a built in push/pull server, LDAP/AD, permissions system and full text search.

You can see it live here: http://demo.rhodecode.org/

share|improve this answer

SCM-Manager might be perfect for your needs:

The easiest way to share and manage your Git, Mercurial and Subversion repositories over http.

  • Very easy installation
  • No need to hack configuration files, SCM-Manager is completely configureable from its Web-Interface
  • No Apache and no database installation is required
  • Central user, group and permission management
  • Out of the box support for Git, Mercurial and Subversion
  • Full RESTFul Web Service API (JSON and XML)
  • Rich User Interface
  • Simple Plugin API
  • Useful plugins available ( f.e. Ldap-, ActiveDirectory-, PAM-Authentication)
share|improve this answer

When you want to use SSH, then you basically have to restrict the keys by editing the authorized_keys file on the server. For Mercurial, the main ways to do this is:

  • You can use the contrib/hg-ssh script to restrict the commands people can execute when logged in with SSH. The file contains a header to explain how to use it, but you basically add

    $ command="hg-ssh path/to/repo"
    

    infront of the key in the authorized_keys file. That restricts the key so that it can only be used for push and pull to the indicated repository.

  • You can also use the third-party mercurial-server tool if you want something like gitois. This let's you manage users and their access rights by editing files in a special admin repository.

See the Mercurial wiki for some other similar tools for SSH.

For HTTP, there are

  • The built-in hgweb (Fast)CGI or WSGI script that comes with Mercurial. That handles pushes and pulls, but does not allow the creation of new repositories — log into the server for that.

  • The third-party RhodeCode project. This gives you a Bitbucket-like web front-end for Mercurial where you can configure users and their access rights. It supports LDAP authentication, so you can hook it into your existing Unix user database.

See the page on publishing repositories for more information.

share|improve this answer

I only use Git, so I wil try at least to help you with that:

If you do not see any trouble administrating your repos via the command line, gitosis should do the trick pretty nicely.

If you do really need a web interface, you could take a look at repo.or.cz (http://repo.or.cz/w/girocco.git) or gitorious (http://gitorious.org/gitorious). Repo.or.cz is uglier, but it is way easier to install (gitorious is open-source, but it is also the software powering gitorious.org - they do not have much incentive to write nice instructions)

Here is a more comprehensive list of options: https://git.wiki.kernel.org/index.php/GitHosting

Anyone of those options will give you easy creation of new repositories.

Now, one word of caution: you should never, EVER, use the unix server user list for repository permissions. It is easy enough to mess with, and results are easily catastrophic (gitosis uses a simple file configuration, and ssh keys. Should do the trick for you).

Another thing, I don't see why you need to have subversion, HG and Git repositories. Most projects use only one of those options. Care to elaborate why?

share|improve this answer
    
I have several projects, held in several repositories. Many commiters are not especially tech-savy and hence hg and git would be a problem for them, so I keep svn for the more open projects. Personally I use HG as my SCM of choice. I also guest host a couple of projects for my friends and some of them use git as their SCM of choice. No way to please everyone as it seems :) –  Kornel Kisielewicz Apr 27 '11 at 21:17
1  
Also, could you elaborate more on the dangers of using unix user list for repo permissions? –  Kornel Kisielewicz Apr 27 '11 at 21:18
3  
Why using unix user list for repositories is a Bad Thing: loss of granularity, loss of portability. If you need to change the repos to another server, you will have to move the entire unix user list. If you want to delegate admin permissions, you have to give root permissions. Now, on gitosis, if you want to change the server, you just have to clone the repo. If you want to delegate admin permissions, you just have to add the user to the gitosis-admin group. –  just_testing May 2 '11 at 14:42
    
just_testing, agreed, valid points :) –  Kornel Kisielewicz May 2 '11 at 22:12

SVN can be done with Apache WebDAV, in a vhost, using unix authentication and subversion's own user-level ACLs. I know nothing about mercurial or git, but I would hope they could be hooked into DAV as well.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.