Project

General

Profile

HowTo configure Redmine for advanced git integration » History » Revision 3

Revision 2 (Felix Schäfer, 2010-07-13 12:55) → Revision 3/25 (Felix Schäfer, 2010-07-14 00:23)

h1. HowTo configure Redmine for advanced git integration 

 {{>TOC}} 

 h2. Scope 

 This HowTo explains how to serve git repositories on apache through the http-based "git-smart-http protocol":http://progit.org/2010/03/04/smart-http.html introduced in git 1.6.6. The git-smart-http offers various advantages over ssh or git-based access: you can use redmine access control as-is, no need for extra ssh keys or whatnot, you can secure it through SSL as needed, and there's generally less problems with firewalls and https/https ports than exist with ssh and git ports. git-smart-http also doesn't have some of the drawbacks of its "dumb" predecessor, as it doesn't require any complex DAV setup. 

 This HowTo is mainly written from memory and was conducted on a setup which was already serving [[Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl|svn repositories integrated with redmine]], so it might be possible that I forgot some things or take them for granted. This is a wiki page, feel free to correct or amend anything you find lacking :-) 

 h2. Prerequisites 

 * Apache with mod_perl (access control) 
 * git (version at least 1.6.6) 
 * A way to serve git-smart-http 
 ** mod_cgi (or mod_cgid) if you want to use the stock "git-http-backend":http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html 
 ** a rack server if you want to use "grack":http://github.com/schacon/grack (basically a rack wrapper around the right git commands) 

 You should already have a rack server to run redmine, and that's why I chose grack as the backend and which I will describe in this tutorial. Using the stock git-http-backend should be quite straightforward though. 

 h2. Install grack 

 h3. Get My rack server of choice is "passenger":http://modrails.com/ and it is already configured on my system. As this is not within the sources scope of this HowTo, please refer to the "passenger documentation":http://modrails.com/documentation.html or to the passenger installation guide from your distribution. 

 Fetch grack from its "github repository":http://github.com/schacon/grack, I checked out mine to @/var/www/git.myhost.com@: 

 <pre><code class="bash">git http://github.com/schacon/grack.git /var/www/git.myhost.com</code></pre> 

 h3. Configuration 

 Edit the @config.ru@ file and adapt it to your local configuration. @project_root@ must contain the path to the directory containing your git repositories, @git_path@ must obviously contain the path to the git, mine looks like this (on gentoo): 

 <pre><code class="ruby">$LOAD_PATH.unshift File.expand_path(File.dirname(__FILE__) + '/lib') 

 use Rack::ShowExceptions 

 require 'lib/git_http' 

 config = { 
   :project_root => "/var/git/git.myhost.com", 
   :git_path => '/usr/libexec/git-core/git', 
   :upload_pack => true, 
   :receive_pack => true, 
 } 

 run GitHttp::App.new(config)</code></pre> 

 h3. Integrate with Apache 

 You could obviously use any rack server you like at this point, but the access control mechanism @Redmine.pm@ is written for apache with mod_perl, so you will at least need to reverse proxy your rack server through apache. My rack server of choice is "passenger":http://modrails.com/ (solid performance, apache module, mostly simple configuration) and it is already configured on my system. As passenger installation and configuration is not within the scope of this HowTo, please refer to the "passenger documentation":http://modrails.com/documentation.html or to the passenger installation guide from your distribution. 

 There's a little more work to do here to get passenger to work with this, you will need to create the directories @public@ and @tmp@ in the grack directory. Please also be aware that in the standard configuration, passenger will run the grack application with the same user and group owning the @config.ru@ file. This user must have read- and write-access as needed to the git repositories! 

 The last step is to configure an apache vhost to serve the application: 

 <pre><code class="apache"><VirtualHost yo.ur.i.p:80> 
     ServerName git.myhost.com 

     ServerAdmin root@myhost.com 
     DocumentRoot "/var/www/git.myhost.com/public" 

     <Directory "/var/www/git.myhost.com/public"> 
         Options None 
         AllowOverride None 
         Order allow,deny 
         Allow from all 
     </Directory> 
 </VirtualHost></code></pre> 

 At this point, if you have a repository in @/var/git/git.myhost.com/myrepo@, you should be able to access it through @http://git.myhost.com/myrepo@, for example @git ls-remote http://git.myhost.com/myrepo@ should show you some information about the repository. 

 h2. Access control 

 You now have a working git server, albeit with no access control. Currently, the shipped perl module for access control @Redmine.pm@ (in @extra/svn/@ in your redmine directory) does not support access control for the git-smart-http protocol, the patch in #4905 aims to implement that. 

 h3. Applying the patch 

 Download the latest (or better: correct) version of the patch from #4905 to your redmine directory. In the redmine directory, apply the patch: @patch -p1 < the-patch-file.patch@ should work (if it tells you stuff about being unable to apply a hunk, the patch is incompatible with your @Redmine.pm@ version, if it says other stuff, try @patch -p0 < the-patch-file.patch@, if it still borks, ask for advice on #4905). 

 You will possibly still need to edit the file from here, because the current version of the patch only works for repositories served from @http://git.myhost.com/git/myrepo@ though the above example uses @http://git.myhost.com/myrepo@. Search around line 280 for the following line: 

 <pre><code class="perl">my $is_read_only = $uri !~ /^\/git\/.*\/[^\/]*git\-receive\-pack$/o;</code></pre> 

 Change the first part of the Regex @\/git@ to whatever sub-URI your repositories reside under (make sure to escape your @/@s!), in my case they are under @/@ so I deleted that part entirely: 

 <pre><code class="perl">my $is_read_only = $uri !~ /^\/.*\/[^\/]*git\-receive\-pack$/o;</code></pre> 

 h3. Configuring Apache 

 You now have to make Apache aware of your new authentication module (if you already had done this step for subversion integration, you can go to the @Location@ directives directly). Copy or link @Redmine.pm@ (from your @extra/svn/@ directory) to @/usr/lib/perl5/Apache/Redmine.pm@ or wherever your distribution puts its apache perl modules (e.g. gentoo puts them in @/usr/lib64/perl5/vendor_perl/5.8.8/Apache/@). 

 Having done that, reload apache to make sure everything in the patching phase went well (if not, remove the link or the file create in the step just before and restart apache to get apache back up, try to find the error in your Redmine.pm file). Now edit your vhost configuration to look somewhat like (same as above but with more stuff): 

 <pre><code class="apache"><VirtualHost yo.ur.i.p:80> 
     ServerName git.myhost.com 

     ServerAdmin root@myhost.com 
     DocumentRoot "/var/www/git.myhost.com/public" 

     PerlLoadModule Apache::Redmine 

     <Directory "/var/www/git.myhost.com/public"> 
         Options None 
         AllowOverride None 
         Order allow,deny 
         Allow from all 
     </Directory> 

     <Location "/"> 
         AuthType Basic 
         AuthName "Redmine git repositories" 
         Require valid-user 

         PerlAccessHandler Apache::Authn::Redmine::access_handler 
         PerlAuthenHandler Apache::Authn::Redmine::authen_handler 

         ## for mysql 
         RedmineDSN "DBI:mysql:database=databasename;host=my.db.server" 
         ## for postgres 
         # RedmineDSN "DBI:Pg:dbname=databasename;host=my.db.server" 
         ## for SQLite3 
         # RedmineDSN "DBI:SQLite:dbname=database.db" 

         RedmineDbUser "redmine" 
         RedmineDbPass "password" 
         RedmineGitSmartHttp yes 
     </Location> 
 </VirtualHost></code></pre> 

 Reload your apache, and everything should be good and well :-) 

 h2. Known issues 

 Currently none…