Redmine Git Hosting Plugin (v0.6.2)

A ChiliProject / Redmine plugin which makes configuring your own Git hosting easy.

This plugin allows straightforward management of Gitolite and associated public keys, the Git daemon, and integrates code from Scott Schacon's "grack" utility to provide Git Smart HTTP access. Git repositories are automatically created when the repository is created in Redmine. There is also an option to automatically create a Git repository for a project, when the project is created. Caching functionality is also implemented to speed page-load times for viewing Git repositories.

Release Notes are available off the wiki: https://github.com/jbox-web/redmine_git_hosting/wiki/Release-Notes.

Compatibility

As the time of this writing, it should be compatible with the following versions:

• Redmine: This plugin should work with Redmine branches 1.1-Stable through 2.3.1 (latest stable), including sub-versions.

• ChiliProject: This plugin should work with ChiliProject 2.0.0 through 3.3.x. It has been successfully used with at least 2.0.x, 2.5.x, 2.7.x, and 3.0.x, and 3.3.x releases.

• Gitolite: This plugin is compatible with most versions of Gitolite including versions 3.x. Tested with the last version of Gitolite : v3.5.1-4-g2f48a3e

• Ruby: This plugin is compatible with Ruby 1.8.7, 1.9.3 and 2.0

There is a known issue with Gitolite 3 and HTTP access (https://github.com/gitlabhq/gitlabhq/issues/1495)

The trick is to add these lines at the bottom of the file /<git user home dir>/bin/lib/Gitolite/Hooks/Update.pm in the DATA section :

__DATA__
#!/usr/bin/perl

BEGIN {
    exit 0 if exists $ENV{GL_BYPASS_UPDATE_HOOK};
}

You must do this every time you update Gitolite.

Required gems

In order to use this plugin you must have the following gems installed:

• lockfile

• inifile

• net-ssh

• backports

Configuration Strategy

This plugin allows Redmine to communicate with Gitolite via sudo. You must configure your sudoers file to allow your Redmine user to run commands as Git user, and your Git user to run commands as the Redmine user. Add these two lines to your sudoers file (run visudo to edit this file) :

redmine        ALL=(git)      NOPASSWD:ALL
git            ALL=(redmine)  NOPASSWD:ALL

This assumes redmine is your Redmine user, and git is your Git user (the user Gitolite is installed under). This will allow redmine to execute commands as git without prompting for a password and git to execute commands as redmine without prompting for a password. No other access (e.g. no root access, permissions to run commands as other users) are granted by these lines. These lines are only there to facilitate communication between the Redmine user and the Git user, no other users, keeping the system secure.

Also, the requiretty sudo setting can prevent the plugin from working correctly. Several users have reported this problem on CentOS. Check the Defaults directive in the sudoers file to see if this setting has been set. You address the problem by either removing requiretty from the Defaults directive, or by adding the following lines below the original Defaults directive to remove this requirement for only the two necessary users :

Defaults:git      !requiretty
Defaults:redmine  !requiretty

Again, this assumes redmine is your Redmine user, and git is the user Gitolite is installed under.

This plugin is compatible with running multiple Redmine installations on the same server, each with the same or different Gitolite users/repositories. The later configuration (multiple Redmine installations, each with a different Gitolite installation) is particularly useful for a web-hosting scenario with independent developers.

Step-By-Step configuration instructions

(1) Install Gitolite. If possible, use Gitolite version >= 2.0.3, so that the plugin will be able to recover from a variety of failures that mess up administrative access to the Gitolite repository (the plugin will utilize gl-admin-push to fixup admin access in these circumstances). Note that the plugin will work with earlier versions of Gitolite; however, it will not be able to recover from as many faults (it will attempt to use gl-setup which doesn't work quite as well).

It is important that this key not have a passphrase set. Further, it is very important that this ssh key be unique and not used for anything other than administrative access, i.e. should not be used by any user as their access key.

(2) If you want to enable anonymous access to your repositories via the git:// protocol you will need to install the git-daemon. The details of this are beyond the scope of the tutorial as well (and again there are lots of available guides out there). This step is optional -- if you don't want to enable anonymous access you can skip it.

(3) Run visudo (you will need root permissions to run this) and set the necessary lines in your sudoers file, listed above. Assuming Redmine is run as redmine and Gitolite is installed as git, you need to add this to your sudoers file:

redmine        ALL=(git)      NOPASSWD:ALL
git            ALL=(redmine)  NOPASSWD:ALL

If you have the requiretty set in the Defaults directive of your sudoers file (it is there by default in CentOS) either remove it or add the following lines below the original directive:

Defaults:git     !requiretty
Defaults:redmine !requiretty

Note: with at least some versions of Ubuntu, you must place any additions to the sudoers file at the end, otherwise the line starting with "admin ..." ends up negating these additions -- probably to your great frustration.

(4) Clone the redmine_git_hosting plugin into the vendor/plugins subdirectory of your Redmine/ChiliProject root directory:

cd REDMINE_ROOT/vendor/plugins
git clone https://github.com/jbox-web/redmine_git_hosting.git
cd ../..

If you use Redmine 2.x, you can find the plugin folder directly under the REDMINE_ROOT. If it is not existent, create it with

cd REDMINE_ROOT && mkdir plugins

You can then clone the repository in there.

(5) Run the rake db:migrate_plugins task to update the database. You will need to do this once for every rails environment you have configured (e.g. production, development, testing). For the production environment, run the following:

RAILS_ENV=production rake redmine:plugins:migrate

Note that you should perform a migrate_plugins operation whenever you update the plugin.

(6) Make a decision about whether or not you want the plugin to be able to modify scripts in the scripts directory on the fly. If you elect to prevent the plugin from modifying the scripts directory, you will be unable to modify certain settings from the plugin settings page (as discussed in the "Executable Scripts" section, below). You have three options:

• Script Directory Writeable: The simplest configuration is to allow the scripts directory to be written by the plugin. Consider this the default configuration. In this case, scripts will be regenerated "on-the-fly" by the plugin when certain settings change. For this option, execute the following task (assuming that Redmine is executing as redmine):

  rake redmine_git_hosting:install_scripts RAILS_ENV=production WEB_USER=redmine

• Script Directory Read-Only: Alternatively, you can choose to make the scripts directory read-only. You might choose this option if you wish to keep scripts in the default directory (i.e. RAILS_ROOT/vendor/plugins/redmine_git_hosting/bin), but do not want to make this directory writeable by the user running Redmine. Be forewarned that you will not be able to change some of the settings on the settings page if scripts directory is not writeable by the user running Redmine.

  rake redmine_git_hosting:install_scripts RAILS_ENV=production WEB_USER=redmine READ_ONLY=true

• SELinux Configuration: A final option is appropriate if you wish to utilize SELinux to protect your installation. Although more details are given in the "SELinux" section, below, the simplest SELinux configuration involves executing the following command (which will also installs the scripts read-only, making some settings unchangeable) :

  rake selinux:install RAILS_ENV=production WEB_USER=redmine

Note that your selected rake task must assign the user running Redmine (e.g. "redmine") as the owner of the new scripts directory.

(7) Unless you want to access your repositories exclusively via Smart HTTP, users will need to set apublic key to connect via SSH. To do this, open a browser, login to ChiliProject/Redmine and follow the "My Account" link in the upper right-hand corner of the page. The right-hand column contains controls for adding your public key(s).

Keys should be unique, that is, the keys you set in ChiliProject / Redmine should not already exist in the Gitolite repo. In particular, do not re-use the key you set as the Gitolite admin key.

(8) The plugin is now configured, but you may now want to set some additional settings on the Administration => Plugins => Redmine Git Hosting Plugin page.

Configuration variables

• The gitSciptDir variable indicates which directory will hold customized scripts. When relative, this variable indicates a directory relative to the root of the plugin. The default value of ' ' (empty), means that scripts will be written to 'REDMINE_ROOT/vendor/plugins/redmine_git_hosting/bin'. This default location should be sufficient for most installations.

  An absolute path can be utilized to place scripts anywhere in the filesystem. For instance, if you would prefer for the scripts to be placed in the /tmp directory to mimic the behavior of prior versions of plugin, you can set gitScriptDir to the same directory as gitTemporaryDir (i.e. '/tmp/redmine_git_hosting/' by default). Note that the script directory must be executable (thereby preventing scripts from being placed in the /tmp directory some systems).

  If non-empty, the gitScriptDir path should end in a path separator, e.g. '/'.

• The gitUser is the user under which Gitolite is installed. This plugin can handle hosts with more than one Gitolite repository (each with a different value for gitUser).

• The httpServer variable should be set to the hostname which will be used to access your Redmine site, e.g. www.my-own-personal-git-host-server.com. This variable may optionally include a port using the ':portnum' syntax, i.e. www.my-own-person-git-host-server.com:8000. Unlike earlier versions of this plugin, this variable should not include the path to your Redmine root.

• The sshServerLocalPort variable should be set to the port which will be used to access the Gitolite repositories via ssh. In most configurations, the sshServerLocalPort variable will be the standard SSH port '22'.

If you followed the above directions you will not need to modify the gitoliteIdentityFile or gitoliteIdentityPublicKeyFile variables -- these specify the path to the private/public key files for accessing the Gitolite admin repository. Further, although you can change the following three variables, their default values provide for a very reasonable installation:

• The gitConfigFile parameter specifies the Gitolite configuration file used by Redmine for Redmine-managed repositories. This file (or path) is relative to the Gitolite conf/ directory. The default value of "gitolite.conf" is sufficient for most configurations. If you choose to change this parameter, you will need to place a corresponding "include" statement in "gitolite.conf". Note that gitConfigHasAdminKey may be set to false for a non-standard "gitolite.conf" file. When this parameter is false, the plugin will assume that the administrative key is in the main "gitolite.conf" file; when true, the plugin will attempt to maintain the administrative key in the Redmine-managed Gitolite config file.

• The gitRepositoryBasePath is the path relative to the Git user root where the repositories are located. This should always be non-empty and should end in a file separator, e.g. '/'. Since Gitolite always uses repositories/ as the default place for repositories you probably shouldn't have to change this.

• The gitRedmineSubdir is an optional subdirectory under the gitRepositoryBasePath which can be used for all plugin-managed repositories. Its default value is the empty string (no special subdirectory). If you choose to set it, make sure that the resulting path ends in a file separator, e.g. '/'.

• The gitRepositoryHierarchy variable is a boolean value which denotes whether or not the plugin-managed repositories are placed into a hierarchy that mirrors the project hierarchy. Its value is either 'true' (default) or 'false'.

• Finally for versions of Redmine with more than one repository per project (i.e. Redmine 1.4+), the gitRepositoryIdentUnique variable determines both whether or not repository identifiers must be unique across all projects and, if not, the format of repository paths. In particular, when gitRepositoryIdentUnique is 'true', repository identifiers must be unique across all projects (and cannot match the identifiers of projects either). Path names are identical to those of pre-1.4 versions of this plugin. If, on the other hand, the gitRepositoryidentUnique is set to 'false', then repository identifiers do not have to be unique across projects (although they still cannot have the same value as project identifiers). In this case, all repositories with non-blank identifiers (i.e. non-default repositories) have the project identifier appended to their path.

As an example of the significance of the previous three variables, suppose that project-3 is a child of project-2 which is a child of project-1. Assume gitRepositoryBasePath == "repository/" and gitRedmineSubdir == "projects". When gitRepositoryHierarchy is 'true', project-3.git will be stored in repository/projects/project-1/project-2/project-3.git, which will further be reflected in the ssh access URL of repository/projects/project-1/project-2/project-3.git. In contrast, when gitRepositoryHierarchy is 'false', project-3.git will be stored directly under repository/projects -- regardless of the number and identity of any parents that it might have.

In Redmine 1.4+, if gitRepositoryIdentUnique is set to 'false', then secondary repositories for project-3 will additionally have paths of the form repository/projects/project-1/project-2/project-3/repo-1.git (when gitRepositoryHierarchy is 'true'). Note that the top of the settings page (Administration => Plugins => Redmine Git Hosting Plugin configuration page) provides information about how your chosen configuration affects the storage locations and URLs for accessing projects.

• The Lock Wait Time represents the amount of time that the plugin will wait in attempting to acquire its internal synchronization lock before giving up. You probably will not need to change this value.

• The Temporary Directory parameter points at a temporary directory for locks and Gitolite administrative configurations. This path should end in a path separator, e.g. '/'. For a system in which multiple redmine sites point at the same Gitolite repository (i.e. share a single git user), it is very important that all of said sites share the same temporary directory (so that locking works properly). You should probably just leave this parameter with its default value.

• Automatically Initialize Git Repositories For New Projects can be enabled to automatically create a new git repository every time you create a new project. You won't have to create the project, and then create the repository -- this will be done all it one step. However, if you have both git and svn (or hg, or cvs etc.) repositories, this may cause problems so it is disabled by default.

• The Default Git Daemon Mode, Default Smart HTTP Mode, and Default Notify CIA Mode settings denote the default settings for these parameters on new repositories.

• Delete Git Repository When Project Is Deleted can be enabled to let this plugin control repository deletion as well as repository creation. By default, this feature is disabled and when a repository is deleted in ChiliProject / Redmine, it is not deleted in Gitolite. This is a safety feature to prevent the accidental loss of data. If this feature is enabled, the safety is turned off and the repository files will be deleted when the Project/Repository is deleted in ChiliProject/Redmine. Note, however, that even when this feature is enabled, deleted repositories are placed into a "recycle_bin" for a configurable amount of time (defaulting to 24 hours) and can be recovered by recreating the project in Redmine with the same Identifier. Details are placed in the log.

• The Git Recycle Bin Base Path is the path relative to the Git user root where deleted repositories are placed. This path should end in a path separator, e.g. '/'. Deleted repositories are kept here for up to gitRecycleExpireTime hours (configurable, defaults to 24.0 hours).

• Show Checkout URLs can be disabled to hide the git URL bar in the repository tab. It is enabled by default.

See below in the "Caching" section of this README for more information on caching and how the caching variables should be configured.

Resynchronization of Gitolite configuration

Whenever a Redmine fetch_changesets() operation is executed (i.e. http://REDMINE_ROOT/sys/fetch_changesets?key=xxx), this plugin will check the Gitolite keydir and configuration file for consistency. It will correct any errors that it finds. Further, regular execution of a fetch_changesets operation will make sure that repositories placed in the recycle_bin (during delete operations) will be expired and removed. Since there still seem to be some phantom synchronization problems, it is recommended that you execute fetch_changesets() regularly (every 15 to 30 minutes).

Two rake tasks can additionally be used for resynchronization (although these are redundant with executing fetch_changesets() through other means).

(1) To fixup the gitolite configuration file, fix errors, and delete expired files in the recycle_bin, execute:

rake redmine_git_hosting:update_repositories RAILS_ENV=production

(2) To perform all the above operations while at the same time fetching changesets for all repositories, execute:

rake redmine_git_hosting:fetch_changesets RAILS_ENV=production

**Note that it is very important that these commands be run as redmine ** (The same is true of any fetch_changesets() operation initiated through the command line or from the cron daemon).

Interaction with non-Redmine Gitolite users

This plugin respects Gitolite repositories that are managed outside of Redmine or managed by both Redmine and non-Redmine users:

• When performing a fetch_changesets() operation, this plugin will delete and reestablish all keys that are of the form "redmine_", since it considers these to be under its exclusive control. A special token, called "redmine_dummy_key", is used as a placeholder when no access is granted for a given repository.
• Keys other than "redmine_*" are left untouched and can be in projects by themselves or mixed in with projects managed by redmine.
• When a Redmine-managed project is deleted (with the Delete Git Repository When Project Is Deleted option enabled), its corresponding git repository will not be deleted/recycled if there are non-Redmine keys in the gitolite.conf file.

A Note About PATH variables

One major source of issues with this plugin is that Redmine needs to be able to run both sudo and git commands. Specifically, these programs need to be in one of the directories specified by the PATH variable, in your Rails environment. This requirement has been known to cause problems, particularly when installing on FreeBSD.

To address this problem in the Apache + Passenger configuration, one possible solution is to do the following:

(1) Create a new file: /usr/local/bin/ruby18env, with the following code, modifying the PATH shown below to include all relevant directories:

#!/bin/sh
export PATH="/usr/local/lib/ruby/gems/1.8/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
[path_to_your_ruby_executable, e.g. /usr/local/bin/ruby18] $*

(2) Make this file executable:

chmod 755 /usr/local/bin/ruby18env

(3) In your httpd.conf file, replace (or add) your PassengerRuby directive with:

PassengerRuby /usr/local/bin/ruby18env

Note that this may be an issue for configurations other than Apache + Passenger, but as this is one of the most common configurations, instructions for that are provided above.

Thanks to user Tronix117 for helping to track down this issue and provide a solution for Apache + Passenger.

Placement and Modification of Executable Scripts

You may place the executable scripts anywhere in the filesystem. The default location of the scripts is set with gitScriptDir. The default value 'REDMINE_ROOT/vendor/plugins/redmine_git_hosting/bin' is a good location, especially if you have multiple simultaneous Redmine installations on the same host, since scripts are customized to each installation. Thus, we recommend that you consider keeping the default placement. In this location, some maintainers may not wish to allow the plugin to re-write the scripts during execution -- hence the options to make scripts read-only, as described in step (8) of the installation instructions, above. Further, when SELinux is installed, the scripts are not writeable by default (because of SELinux tags), since changing them could be construed to be a security hole.

When the script directory is not writeable by the user running Redmine, you also cannot alter five of the settings on the settings page (since their alteration would require the regeneration of scripts). These values are: gitScriptDir, gitUser, gitoliteIdentifyFile, gitoliteIdentityPublicKeyFile and sshServerLocalPort. The settings page will make the fact that you cannot alter these values clear by marking that as [Cannot change in current configuration].

In that case, the simplest way to change these values is to

(1) remove the old scripts

(2) alter the parameters on the settings page (after refreshing the settings page)

(3) then reinstalling scripts as discussed in step (8) of the installation instructions.

Scripts can be removed with:

rake redmine_git_hosting:remove_scripts RAILS_ENV=production

Deployment Credentials

This plugin provides deployment credentials on a per-repository basis. These credentials are combinations of a public key and access permissions (R or RW+) which are attached directly to a repository rather than by attaching users to repositories. Deployment credentials may be added to a repository through the repository settings interface. They may be added by anyone who is a manager for the project or by the administrator.

Public keys used in this way are called "deploy keys". They are owned by the user who created them and may be edited on the user's public_key page (which is under "my account" for individual users). Since keys have unique names (per creator), they may be reused in multiple deployment credentials (in multiple repositories), simply by selecting them from the pulldown menu on the "deployment credentials create" dialog box.

One typical use-case would be for all deploy keys to be owned by the administrator and attached selectively to various repositories. Note that the "deployment credentials create" dialog is actually a convenience dialog in that it allows the simultaneous creation of both a deploy key and deployment credential in a single step, even suggesting a name for the deployment credential, with the eye to deployments that have a separate deploy key for each repository. Reusing a deploy key in another credential is a simple matter of selecting the key from a drop-down menu.

Post-Receive URLs

This plugin supports the inclusion of GitHub-style Post-Receive URLs. Once added, a post-receive URL will be notified when new changes are pushed to the repository. Two versions of this functionality are available :

(1) either a GitHub-style POST operation will include json-encoded information about the updated branch

(2) or an empty GET request will be issued to the given URL

Post-Receive URLs may be added from the repository settings page.

Automatic Mirror Updates

This plugin can automatically push updates to repository mirrors when new changes are pushed to the repository. Mirrors must grant access to the public key defined in the gitolite_admin_id_rsa.pub public key file, which is displayed for convenience in the repository settings tab.

You have the ability to selectively push branches to the mirror (using the git-push refspec mechanism) rather than mirroring all branches and tags. To utilize this feature, simply select a mirror update mode of "Force Update Remote" or "Fast Forward (unforced)" instead of the default "Complete Mirroring" in the mirror create/edit dialog. More options will then become available.

Notification to CIA.vc

This plugin can notify CIA.vc when changes are pushed to the repository. The project identifier on CIA.vc must match the project identifier specified in ChiliProject/Redmine exactly.

Smart HTTP Functionality

Smart HTTP is an efficient way of communicating with the Git server over HTTP/HTTPS available in Git client version 1.6.6 and newer. A more detailed description of what Smart HTTP is all about can be found at : http://progit.org/2010/03/04/smart-http.html

This plugin allows you to automatically enable Smart HTTP access to your repositories. It is highly recommended that you enable Smart HTTP access only via HTTPS -- without encryption this is very insecure. If you want to enable (insecure) access via unencrypted HTTP, go to the repository settings tab and select "HTTPS and HTTP" under the "Git Smart HTTP" tab.

Where a password is required, this is your Redmine user password.

Once Smart HTTP is enabled no further configuration is necessary. You will be able to clone/push from/to the HTTP[S] URL specified in the URL bar in the Project/Repository tab.

Also note that you will need to ensure that Basic Auth headers are being passed properly to Rails for this to work properly. In Apache with mod_fcgid this may mean you need to add "Passheader Authorization" into the virtual host configuration file.

Further, if you are proxying requests through a third-party (such as Nginx), you need to make sure that you pass the protocol information onto Redmine so that it can distinguish between HTTP and HTTPS. One way to do this is to use the X-Forwarded-Proto header (which should be set to 'https' when https is in use from the client to the proxy).

Using the Git Daemon

In order to export repositories via the Git daemon (i.e. with URLs of the form 'git://'), you must first install this daemon and give it access to the Gitolite repositories (outside the scope of this README). Once you do so, then control of which repositories are exported depends on two things :

(1) the setting of the public flag for the project

(2) the setting of the GitDaemon parameter in the project's repository settings.

A repository will be exported via the Git daemon only if its corresponding project is public and its GitDaemon flag is enabled. This plugin handles such repositories by including a special "daemon" key in the gitolite.conf file. Presence of this key, in turn, causes Gitolite to insert a git-daemon-export-ok flag at the top-level of the corresponding repository. This flag is interpreted by the Git daemon as a sign to export the repository.

Note that the act of changing a project from public to private will set the GitDaemon flag to false automatically (to prevent accidental export of the project via the Git daemon later).

Caching Options

This plugin includes code for caching output of the Git command, which is called to display the details of the Git repository. Redmine/ChiliProject by default calls Git directly every time this information is needed. This can result in relatively long page load times.

This plugin caches the output of Git commands to dramatically improve page load times, roughly a 10x speed increase.

There are three configurable caching parameters in the plugins settings page : Max Cache Elements, Max Cache Element Size and Max Cache Time.

• The Max Cache Elements is the maximum number of Git commands for which to cache the output.

• The Max Cache Element Size is the maximum size of the Git output to cache. Anything above this size won't be cached, and Git will be called directly every time this command is run.

• The Max Cache Time is the maximum amount of time the Git command will be cached. No matter what, the output of Git commands for a given repository are cleared when new commits are pushed to the server and the post-receive hook is called.

This caching functionality only works in Redmine 1.2.x+ and ChiliProject v2.x+ -- while this plugin is compatible with ChiliProject 1.x the caching functionality is not.

Important note : If using mysql for your database, you must make sure that the max_allowed_packet size is set (in, e.g., /etc/my.cnf) to be at least as large as the value you specify for Max Cache Element Size above. If you do not do this, you are likely to get very strange failures of the web server. Such a setting must be placed in the [mysqld] parameter section of this file, for instance :

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
max_allowed_packet=32M

The above example should allow Max Cache Element Size == 32M.

SELinux Configuration for Redmine

This plugin can be configured to run with SELinux. We have included a rakefile in tasks/selinux.rake to assist with installing with SELinux. You should start by migrating as described above. Then, you can execute one of the SELinux rake tasks (from the Redmine root). For instance, the simplest option installs a SELinux configuration for both Redmine and the redmine_git_hosting plugin :

rake selinux:install RAILS_ENV=production

This will generate the redmine_git_hosting binaries in ./bin, install a SELinux policy for these binaries (called redmine_git.pp), then install a complete context for Redmine as follows :

(1) Most of Redmine will be marked with "public_content_rw_t"

(2) The dispatch files in Rails.root/public/dispatch.* will be marked with "httpd_sys_script_exec_t"

(3) The redmine_git_hosting binaries in Rails.root/vendor/plugins/redmine_git_hosting/bin will be labeled with "httpd_redmine_git_script_exec_t", which has been crafted to allow the sudo behavior required by these binaries.

Note that this rake file has additional options. For instance, you can specify multiple Redmine roots with regular expressions (not globbed expressions!) as follows (notice the use of double quotes) :

rake selinux:install RAILS_ENV=production ROOT_PATTERN="/source/.*/redmine"

These additional options are documented in the selinux.rake file. Under normal operation, you will get one SELinux complaint about /bin/touch in your log each time that you visit the plugin settings page.

Once this plugin is placed under SELinux control, five of the redmine_git_hosting settings can not be modified from the settings page. They are : 'gitScriptDir', 'gitUser', 'gitoliteIdentityFile', and 'gitoliteIdentityPublicKeyFile'. The plugin settings page will make this clear. One way to modify these options is to remove the old scripts, refresh the setting page, change options, then reinstall scripts. Specifically, you can remove scripts with :

rake selinux:redmine_git_hosting:remove_scripts RAILS_ENV=production

Scripts and SELinux policy/tags can be reinstalled with :

rake selinux:redmine_git_hosting:install RAILS_ENV=production

One final comment : The SELinux policy exists in binary form as selinux/redmine_git.pp. Should this policy need to be rebuilt, an additional rake task exists which will build the policy from selinux/redmine_git.te :

rake selinux:redmine_git_hosting:build_policy RAILS_ENV=productinon

This task can be followed by the selinux:install task.

The rakefile and SELinux configuration has been primarily tested on Redhat Enterprise Linux version 6.x with Apache and fcgi. Other configurations may require slight tweaking.

Copyright & License

This plugin is based largely on the Gitosis plugin by Jan Schulz-Hofen for http://plan.io. Several updates/fixes were provided by Github users : untoldwind, tingar and ericpaulbishop. These updates were merged together and expanded upon by Eric Bishop to create this more comprehensive Git Hosting plugin.

Copyright (c) 2013 Nicolas Rodriguez (nrodriguez@jbox-web.com) MIT License.

Copyright (c) 2011 John Kubiatowicz (kubitron@cs.berkeley.edu) MIT License.

Copyright (c) 2010-2011 Eric Bishop (ericpaulbishop@gmail.com) MIT License.

Copyright (c) 2009-2010 Jan Schulz-Hofen, ROCKET RENTALS GmbH (http://www.rocket-rentals.de). MIT License.