From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PpNzM-0004M6-6L for garchives@archives.gentoo.org; Tue, 15 Feb 2011 16:42:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 76C6AE09B7; Tue, 15 Feb 2011 16:42:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 0D1FCE09B7 for ; Tue, 15 Feb 2011 16:42:13 +0000 (UTC) Received: from pelican.gentoo.org (unknown [66.219.59.40]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id A462E1B4255 for ; Tue, 15 Feb 2011 16:42:13 +0000 (UTC) Received: from localhost.localdomain (localhost [127.0.0.1]) by pelican.gentoo.org (Postfix) with ESMTP id 0C7E980075 for ; Tue, 15 Feb 2011 16:42:13 +0000 (UTC) From: "Christian Ruppert" To: gentoo-commits@lists.gentoo.org Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Christian Ruppert" Message-ID: Subject: [gentoo-commits] proj/gitolite-gentoo:upstream commit in: doc/, conf/ X-VCS-Repository: proj/gitolite-gentoo X-VCS-Files: conf/example.gitolite.rc doc/gitolite.rc.mkd X-VCS-Directories: doc/ conf/ X-VCS-Committer: idl0r X-VCS-Committer-Name: Christian Ruppert X-VCS-Revision: ffcbc526379c7dab889262595fb1ff6bec3a725b Date: Tue, 15 Feb 2011 16:42:13 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 88ba8478e0da73bd862bc48b006f9c5a commit: ffcbc526379c7dab889262595fb1ff6bec3a725b Author: Sitaram Chamarty atc tcs com> AuthorDate: Fri Dec 31 13:33:48 2010 +0000 Commit: Christian Ruppert gentoo org> CommitDate: Fri Dec 31 13:33:48 2010 +0000 URL: http://git.overlays.gentoo.org/gitweb/?p=3Dproj/gitolite-gent= oo.git;a=3Dcommit;h=3Dffcbc526 rc file stripped down, variables categorised, documentation lifted out the old file was getting too unwieldy... --- conf/example.gitolite.rc | 326 ++++++----------------------------------= ----- doc/gitolite.rc.mkd | 325 ++++++++++++++++++++++++++++++++++++++++= +++++ 2 files changed, 369 insertions(+), 282 deletions(-) diff --git a/conf/example.gitolite.rc b/conf/example.gitolite.rc index e4ac0c0..8f8653a 100644 --- a/conf/example.gitolite.rc +++ b/conf/example.gitolite.rc @@ -1,313 +1,75 @@ -# paths and configuration variables for gitolite +# configuration variables for gitolite =20 -# please read comments before editing +# PLEASE READ THE DOCUMENTATION BEFORE EDITING OR ASKING QUESTIONS =20 # this file is meant to be pulled into a perl program using "do" or "req= uire". - # You do NOT need to know perl to edit the paths; it should be fairly # self-explanatory and easy to maintain perl syntax :-) =20 -# -------------------------------------- -# Do not change the next two lines unless you know what you're doing -# $GL_PACKAGE_CONF =3D ""; -# $GL_PACKAGE_HOOKS =3D ""; - -# -------------------------------------- -# MIRRORING SUPPORT - -# $GL_SLAVE_MODE =3D 0; -# $ENV{GL_SLAVES} =3D 'gitolite@server2 gitolite@server3'; -# PLEASE USE SINGLE QUOTES ABOVE, NOT DOUBLE QUOTES - -# see doc/mirroring.mkd for details - -# -------------------------------------- - -# this is where the repos go. If you provide a relative path (not start= ing -# with "/"), it's relative to your $HOME. You may want to put in someth= ing -# like "/bigdisk" or whatever if your $HOME is too small for the repos, = for -# example - -$REPO_BASE=3D"repositories"; - -# the default umask for repositories is 0077; change this if you run stu= ff -# like gitweb and find it can't read the repos. Please note the syntax;= the -# leading 0 is required - -$REPO_UMASK =3D 0077; # gets you 'rwx------' -# $REPO_UMASK =3D 0027; # gets you 'rwxr-x---' -# $REPO_UMASK =3D 0022; # gets you 'rwxr-xr-x' - -# part of the setup of gitweb is a variable called $projects_list (pleas= e see -# gitweb documentation for more on this). Set this to the same value: - -$PROJECTS_LIST =3D $ENV{HOME} . "/projects.list"; - -# giving access to @all users (as in "R =3D @all") in the config norma= lly does -# *not* include the special users "gitweb" and "daemon". If you want @a= ll to -# include these two users, set this variable: - -# $GL_ALL_INCLUDES_SPECIAL =3D 0; - -# -------------------------------------- - -# I see no reason anyone may want to change the gitolite admin directory= , but -# feel free to do so. However, please note that it *must* be an *absolu= te* -# path (i.e., starting with a "/" character) - -# gitolite admin directory, files, etc - +# ----------------------------------------------------------------------= -------- +# VARIABLES THAT SHOULD NOT BE TOUCHED AT ALL. EVER. +# ----------------------------------------------------------------------= -------- $GL_ADMINDIR=3D$ENV{HOME} . "/.gitolite"; - -# -------------------------------------- - -# templates for location of the log files and format of their names - -# I prefer this template (note the %y and %m placeholders) -# it produces files like `~/.gitolite/logs/gitolite-2009-09.log` - -$GL_LOGT=3D"$GL_ADMINDIR/logs/gitolite-%y-%m.log"; - -# other choices are below, or you can make your own -- but PLEASE MAKE S= URE -# the directory exists and is writable; gitolite won't do that for you (= unless -# it is the default, which is "$GL_ADMINDIR/logs") - -# $GL_LOGT=3D"$GL_ADMINDIR/logs/gitolite-%y-%m-%d.log"; -# $GL_LOGT=3D"$GL_ADMINDIR/logs/gitolite-%y.log"; - -# -------------------------------------- - -# location of the performance log files - -# uncomment and set this variable if you want performance logging -# -# perf log files are different from access log files; they store differe= nt -# information, are not meant to be as long-lived, and so on - -# $GL_PERFLOGT=3D"$GL_ADMINDIR/logs/perf-gitolite-%y-%m.log"; - -# -------------------------------------- - -# Please DO NOT change these three paths - $GL_CONF=3D"$GL_ADMINDIR/conf/gitolite.conf"; $GL_KEYDIR=3D"$GL_ADMINDIR/keydir"; $GL_CONF_COMPILED=3D"$GL_ADMINDIR/conf/gitolite.conf-compiled.pm"; +# DO NOT CHANGE THE NEXT TWO LINES UNLESS YOU REALLY KNOW WHAT YOU'RE DO= ING. +# These variables are set automatically by the install method you choose= . +# $GL_PACKAGE_CONF =3D ""; +# $GL_PACKAGE_HOOKS =3D ""; =20 -# -------------------------------------- - -# if git on your server is on a standard path (that is -# ssh git@server git --version -# works), leave this setting as is. Otherwise, choose one of the -# alternatives, or write your own - -$GIT_PATH=3D""; -# $GIT_PATH=3D"/opt/bin/"; - -# -------------------------------------- - -# ---------------------------------------------------------------------- -# BIG CONFIG SETTINGS - -# Please read doc/big-config.mkd for details +# ----------------------------------------------------------------------= -------- +# most often used/changed variables +# ----------------------------------------------------------------------= -------- +$GL_WILDREPOS =3D 0; +$PROJECTS_LIST =3D $ENV{HOME} . "/projects.list"; +$REPO_UMASK =3D 0077; =20 +# ----------------------------------------------------------------------= -------- +# variables with an efficiency impact +# ----------------------------------------------------------------------= -------- $GL_BIG_CONFIG =3D 0; $GL_NO_DAEMON_NO_GITWEB =3D 0; -$GL_NO_CREATE_REPOS =3D 0; -$GL_NO_SETUP_AUTHKEYS =3D 0; - -# ---------------------------------------------------------------------- -# SECURITY SENSITIVE SETTINGS -# -# Settings below this point may have security implications. That -# usually means that I have not thought hard enough about all the -# possible ways to crack security if these settings are enabled. - -# Please see details on each setting for specifics, if any. -# ---------------------------------------------------------------------- - - - -# -------------------------------------- -# ALLOW REPO ADMIN TO SET GITCONFIG KEYS -# -# Gitolite allows you to set git repo options using the "config" keyword= ; see -# conf/example.conf for details and syntax. -# -# However, if you are in an installation where the repo admin does not (= and -# should not) have shell access to the server, then allowing him to set -# arbitrary repo config options *may* be a security risk -- some config -# settings may allow executing arbitrary commands. -# -# You have 3 choices. By default $GL_GITCONFIG_KEYS is left empty, whic= h -# completely disables this feature (meaning you cannot set git configs f= rom -# the repo config). =20 +# ----------------------------------------------------------------------= -------- +# VARIABLES WITH A SECURITY IMPACT +# ----------------------------------------------------------------------= -------- +$GIT_PATH=3D""; $GL_GITCONFIG_KEYS =3D ""; - -# The second choice is to give it a space separated list of settings you -# consider safe. (These are actually treated as a set of regular expres= sion -# patterns, and any one of them must match). For example: -# $GL_GITCONFIG_KEYS =3D "core\.logAllRefUpdates core\..*compression"; -# allows repo admins to set one of those 3 config keys (yes, that second -# pattern matches two settings from "man git-config", if you look) -# -# The third choice (which you may have guessed already if you're familia= r with -# regular expressions) is to allow anything and everything: -# $GL_GITCONFIG_KEYS =3D ".*"; - -# NOTE that due to some quoting and interpolation issues I have not been= able -# to look at, a literal "." needs to be specified in this string as \\. = (two -# backslashes and a dot). So this is how you'd allow any keys in the "f= oo" -# category: -# $GL_GITCONFIG_KEYS =3D "foo\\..*"; - -# -------------------------------------- -# ALLOW GITCONFIG KEYS EVEN FOR WILD REPOS -# -# This is an efficiency issue more than a security issue, since this req= uires -# trawling through all of $REPO_BASE looking for stuff :) - # $GL_GITCONFIG_WILD =3D 0; - -# -------------------------------------- -# EXTERNAL COMMAND HELPER -- HTPASSWD - -# security note: runs an external command (htpasswd) with specific argum= ents, -# including a user-chosen "password". - -# if you want to enable the "htpasswd" command, give this the absolute p= ath to -# whatever file apache (etc) expect to find the passwords in. - +$GL_NO_CREATE_REPOS =3D 0; +$GL_NO_SETUP_AUTHKEYS =3D 0; +# $GL_WILDREPOS_DEFPERMS =3D 'R @all'; $HTPASSWD_FILE =3D ""; - -# Look in doc/3 ("easier to link gitweb authorisation with gitolite" sec= tion) -# for more details on using this feature. - -# -------------------------------------- -# EXTERNAL COMMAND HELPER -- RSYNC - -# security note: runs an external command (rsync) with specific argument= s, all -# presumably filled in correctly by the client-side rsync. - -# base path of all the files that are accessible via rsync. Must be an -# absolute path. Leave it undefined or set to the empty string to disab= le the -# rsync helper. - $RSYNC_BASE =3D ""; - -# $RSYNC_BASE =3D "/home/git/up-down"; -# $RSYNC_BASE =3D "/tmp/up-down"; - -# -------------------------------------- -# EXTERNAL COMMAND HELPER -- SVNSERVE - -# security note: runs an external command (svnserve) with specific argum= ents, -# as specified below. %u is substituted with the username. - -# This setting allows launching svnserve when requested by the ssh clien= t. -# This allows using the same SSH setup (hostname/username/public key) fo= r both -# SVN and git access. Leave it undefined or set to the empty string to d= isable -# svnserve access. - $SVNSERVE =3D ""; -# $SVNSERVE =3D "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=3D%u"; - -# -------------------------------------- -# ALLOW REPO CONFIG TO USE WILDCARDS - -# security note: this used to in a separate "wildrepos" branch. You can -# create repositories based on wild cards, give "ownership" to the speci= fic -# user who created it, allow him/her to hand out R and RW permissions to= other -# users to collaborate, etc. This is powerful stuff, and I've made it a= s -# secure as I can, but it hasn't had the kind of rigorous line-by-line -# analysis that the old "master" branch had. - -# This has now been rolled into master, with all the functionality gated= by -# this variable. Set this to 1 if you want to enable the wildrepos feat= ures. -# Please see doc/wildcard-repositories.mkd for details. - -$GL_WILDREPOS =3D 0; - -# -------------------------------------- -# DEFAULT WILDCARD PERMISSIONS - -# If set, this value will be used as the default user-level permission r= ule of -# new wildcard repositories. The user can change this value with the set= perms command -# as desired after repository creation; it is only a default. Note that = @all can be -# used here but is special; no other groups can be used in user-level pe= rmissions. - -# $GL_WILDREPOS_DEFPERMS =3D 'R @all'; - -# -------------------------------------- -# WILDREPOS PERMS CATEGORIES - -# Originally, we only allowed "R" and "RW" in the setperms command. Now= we -# allow the admin to define other categories as she wishes (example: MAN= AGERS, -# TESTERS, etc). - -# This variable is a space-sep list of the allowed categories. - -# PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd fo= r -# caveats and warnings. This is a VERY powerful feature and if you're n= ot -# careful you could mess up the ACLs nicely. - -# this is the internal default if you don't set it (like if you didn't u= pdate -# your ~/.gitolite.rc with new variables when you upgraded gitolite): -$GL_WILDREPOS_PERM_CATS =3D "READERS WRITERS"; - -# you can use your own categories in addition to the standard ones; I su= ggest -# you include READERS and WRITERS for backward compat though: -# $GL_WILDREPOS_PERM_CATS =3D "READERS WRITERS MANAGERS"; -# $GL_WILDREPOS_PERM_CATS =3D "READERS WRITERS MANAGERS TESTERS"; - -# -------------------------------------- -# HOOK CHAINING - -# by default, the update hook in every repo chains to "update.secondary"= . -# Similarly, the post-update hook in the admin repo chains to -# "post-update.secondary". If you're fine with the defaults, there's no= need -# to do anything here. However, if you want to use different names or p= aths, -# change these variables - # $UPDATE_CHAINS_TO =3D "hooks/update.secondary"; # $ADMIN_POST_UPDATE_CHAINS_TO =3D "hooks/post-update.secondary"; - -# -------------------------------------- -# ADMIN DEFINED COMMANDS - -# WARNING: Use this feature only if (a) you really really know what you'= re -# doing or (b) you really don't care too much about security. Please re= ad -# doc/admin-defined-commands.mkd for details. - # $GL_ADC_PATH =3D ""; +# $GL_GET_MEMBERSHIPS_PGM =3D "/usr/local/bin/expand-ldap-user-to-groups= " =20 -# -------------------------------------- -# SITE-SPECIFIC INFORMATION - -# Some installations would like to give their users customised informati= on -# (like a link to their own websites, for example) so that each end user= does -# not have to grok all the gitolite documentation. - -# If this variable is defined, the "info" command will print it at the e= nd of -# the listing. +# ----------------------------------------------------------------------= -------- +# less used/changed variables +# ----------------------------------------------------------------------= -------- +# $GL_ALL_INCLUDES_SPECIAL =3D 0; +# $GL_SLAVE_MODE =3D 0; +# $ENV{GL_SLAVES} =3D 'gitolite@server2 gitolite@server3'; +# PLEASE USE SINGLE QUOTES ABOVE, NOT DOUBLE QUOTES +$GL_WILDREPOS_PERM_CATS =3D "READERS WRITERS"; =20 -# $GL_SITE_INFO =3D ""; +# ----------------------------------------------------------------------= -------- +# rarely changed variables +# ----------------------------------------------------------------------= -------- +$GL_LOGT=3D"$GL_ADMINDIR/logs/gitolite-%y-%m.log"; +# $GL_PERFLOGT=3D"$GL_ADMINDIR/logs/perf-gitolite-%y-%m.log"; # $GL_SITE_INFO =3D "XYZ.COM DEVELOPERS: PLEASE SEE http://xyz.com/gitol= ite/help first"; =20 -# -------------------------------------- -# USERGROUP HANDLING - -# Some sites would like to store group membership outside gitolite, beca= use -# they already have it in (usually) their LDAP server, and it doesn't ma= ke -# sense to be forced to duplicate this information. - -# Set the following variable to the name of a script that, given a usern= ame as -# argument, will return a list of groups that she is a member of. - -# $GL_GET_MEMBERSHIPS_PGM =3D "/usr/local/bin/expand-ldap-user-to-groups= " +# ----------------------------------------------------------------------= -------- +# variables that should NOT be changed after the install step completes +# ----------------------------------------------------------------------= -------- +$REPO_BASE=3D"repositories"; =20 -# -------------------------------------- +# ----------------------------------------------------------------------= -------- # per perl rules, this should be the last line in such a file: 1; =20 diff --git a/doc/gitolite.rc.mkd b/doc/gitolite.rc.mkd new file mode 100644 index 0000000..ecf5758 --- /dev/null +++ b/doc/gitolite.rc.mkd @@ -0,0 +1,325 @@ +# configuration variables for gitolite + +This is the documentation for the contents of the "rc" file +(`$HOME/.gitolite.rc`) on the server. Until now this documentation was +inline, within the rc file itself, but it has grown too large, too unwie= ldy, +and too difficult to grok for people new to gitolite. + +The documentation follows approximately the same order as the sample var= iables +in the (now reorganised) example "rc" file. + +In this document: + + * variables = that should not be touched at all + * most often used/chan= ged variables + * variables with an = efficiency impact + * variables with a secu= rity impact + * less used/changed variable= s + * rarely changed variables + +[Note: in perl, there is no actual boolean. The undefined value, the nu= mber +'0', and the empty string, are all 'false'. Everything else is 'true'. = It is +thus common to use just 0/1 for false/true]. + + + +### variables that should not be touched at all + +The first section does not need too much elaboration. Let's just say ba= d +things happen if you change them. + + + +### most often used/changed variables + + * `$GL_WILDREPOS`, boolean, default 0 + + Setting this variable lets your users create repositories based on w= ild + cards, hand out R and RW permissions to other users to collaborate, = etc. + + See [doc/wildcard-repositories.mkd][wild] for lots of info on this. + + * `$PROJECTS_LIST`, filename, default `~/projects.list` + + This is for gitweb users only. Gitweb setup has a variable called + `$projects_list` (please see gitweb docs for more on this). Set thi= s to + the same value as that one. + + * `$REPO_UMASK`, octal, default `0077` + + The default UMASK that gitolite uses makes all the repos and their + contents have `rwx------` permissions. People who want to run gitwe= b + realise that this will not do. The correct way to deal with this is= to + change this variable to `0027` (which gets you `rwxr-x---`), then ad= d the + apache or httpd user running the webserver as a member of the 'gitol= ite' + group. + + Please note the syntax; the leading 0 is required. If you change it + *after* the install is complete, you'll have to do some chmod's also= to + adjust permissions of files and directories that have already been + created. + + + +### variables with an efficiency impact + + * `$GL_BIG_CONFIG`, boolean, default 0 + + This is the most common setting for efficiency in handling large rep= o/user + groups. This is a very powerful setting; please read + [doc/big-config.mkd][bc] for all the details you might need. + + There are 3 other settings related to big configs. They are changed= only + in rare cases, however, so are described later. + + * `$GL_NO_DAEMON_NO_GITWEB`, boolean, default 0 + + If you have *lots* of repos, and you're *not* using gitweb or daemon= , you + should probably set this on for efficiency. Despite the name, it al= so + blocks repo config settings. Please read [doc/big-config.mkd][bc] f= or + more details. + + + +### variables with a security impact + +**IMPORTANT NOTE** + +This section describes variables that, if not carefully used, can cause +security issues. It also includes variables which I personally do not u= se and +do not have the ability to test thoroughly + +Using non-default value for these variables voids the security reward in= the +README. This does *not* mean they are less important or that I will ign= ore +problems; it just means *my* ability to catch problems may be limited by= my +test suite, my actual production use, my time, and sometimes (LDAP comes= to +mind) even my skill or resources available to me, and that therefore I d= epend +on feedback from my users to find or fix issues. + + * `$GIT_PATH`, string, default empty + + If git on your server is on a standard path (that is `ssh git@server= git + --version` works), leave this setting as is. Otherwise, find out wh= ere it + is and use that value here, for example `GIT_PATH=3D"/opt/bin/";` + + * `$GL_GITCONFIG_KEYS`, string, default empty + + This setting allows the repo admin to define acceptable gitconfig ke= ys. + + Gitolite allows you to set git repo options using the "config" keywo= rd; + see conf/example.conf for details and syntax. + + However, if you are in an installation where the repo admin does not= (and + should not) have shell access to the server, then allowing him to se= t + arbitrary repo config options *may* be a security risk -- some confi= g + settings allow executing arbitrary commands! + + You have 3 choices. By default `$GL_GITCONFIG_KEYS` is left empty, = which + completely disables this feature (meaning you cannot set git configs= via + the repo config). + + The second choice is to give it a space separated list of settings y= ou + consider safe. (These are actually treated as a set of perl regular + expression patterns, and any one of them must match). For example: + `$GL_GITCONFIG_KEYS =3D "core\\.logAllRefUpdates core\\..*compressio= n";` + allows repo admins to set one of those 3 config keys (yes, that seco= nd + pattern matches two settings from "man git-config", if you look). + + The third choice (which you may have guessed already if you're famil= iar + with regular expressions) is to allow anything and everything: + `$GL_GITCONFIG_KEYS =3D ".*";` + + NOTE that due to some quoting and interpolation issues I have not be= en + able to look at, a literal "." needs to be specified in this string = as + `\\.` (two backslashes and a dot). So this is how you'd allow any k= eys in + the "foo" category: `$GL_GITCONFIG_KEYS =3D "foo\\..*";` + + * `$GL_GITCONFIG_WILD`, boolean, default 0 + + This setting allows gitconfig keys even for wild repos. This is an + efficiency issue more than a security issue, since this requires tra= wling + through all of `$REPO_BASE` looking for stuff :) + + * `$GL_NO_CREATE_REPOS`, boolean, default 0 + + DO NOT CHANGE THIS unless you have other means to create repos and + correctly populate them with the required hooks. No hooks, no acces= s + control; you have been warned! + + * `$GL_NO_SETUP_AUTHKEYS`, boolean, default 0 + + DO NOT CHANGE THIS unless you have other means to setup the authkeys= file + (`~/.ssh/authorized_keys`). In an extreme case, if you switch this = on + without also fixing up the authkeys file, users who you think you de= leted + may still have access. All in all, please be careful, as with any c= hange + that affects ssh. + + * `$GL_WILDREPOS_DEFPERMS`, string, default undef + + This sets default wildcard permissions for newly created wildcard re= pos. + + If set, this value will be used as the default user-level permission= rule + of new wildcard repositories. The user can change this value with th= e + setperms command as desired after repository creation; it is only a + default. + + Example: `$GL_WILDREPOS_DEFPERMS =3D 'R @all';` + + * `$HTPASSWD_FILE`, string, default empty + + Gitolite can help users run the htpasswd command in a secure manner = (since + gitolite has already identified them by an ssh key). If you want to + enable this, give the variable the absolute path to whatever file ap= ache + (etc) expect to find the passwords in. + + Look in [doc/3-faq-tips-etc.mkd][faq] ("easier to link gitweb + authorisation with gitolite" section) for more details on using this + feature. + + * `$RSYNC_BASE`, string, default empty + + Gitolite can be used to allow fine grained control of the rsync comm= and. + + This setting enables the rsync external command helper, by specifyin= g the + base path of all the files that are accessible via rsync. It must b= e an + absolute path, like `$RSYNC_BASE =3D "/home/git/up-down";`. Leave i= t + undefined or set to the empty string to disable the rsync helper. + + When enabled, it runs rsync with specific arguments, all presumably = filled + in correctly by the client-side rsync. However, I am not an expert o= n how + rsync may be abused, so if it breaks, you get to keep both pieces! + + * `$SVNSERVE`, string, default empty + + Gitolite can also be used to gate access (though not at a fine grain= ed + level) to SVN if needed, passing authentication information on to + `svnserve`. This setting allows launching svnserve when requested b= y the + ssh client. This allows using the same SSH setup for both SVN and g= it + access. Leave it undefined or set to the empty string to disable svn= serve + access. + + The setting will look something like (where the %u is substituted wi= th the + username): + + $SVNSERVE =3D "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=3D= %u"; + + * hook chaining + + * `$UPDATE_CHAINS_TO`, string, default "hooks/update.secondary" + * `$ADMIN_POST_UPDATE_CHAINS_TO`, string, default + "hooks/post-update.secondary" + + By default, the update hook in every repo chains to "update.secondar= y". + Similarly, the post-update hook in the admin repo chains to + "post-update.secondary". If you're fine with the defaults, there's = no + need to do anything here. However, if you want to use different nam= es or + paths, change these variables. + + * `$GL_ADC_PATH`, string, default undef + + This setting enables admin defined commands. + + **WARNING**: Use this feature only if (a) you really know what you'r= e + doing and (b) you really, **really**, know what you're doing! Pleas= e read + [doc/admin-defined-commands.mkd][adc] for details. This is an extre= mely + powerful and flexible feature, and naturally anything that flexible = can be + a security risk! + + * `$GL_GET_MEMBERSHIPS_PGM`, string, default undef + + Some sites would like to store group membership outside gitolite, be= cause + they already have it in (usually) their LDAP server, and it doesn't = make + sense to be forced to duplicate this information. + + Set the following variable to the name of a script that, given a use= rname + as argument, will return a list of groups that she is a member of. = See + [doc/big-config.mkd][bc] for more details. + + Example: `$GL_GET_MEMBERSHIPS_PGM =3D "/usr/local/bin/expand-ldap-us= er-to-groups"` + + + +### less used/changed variables + + * `$GL_ALL_INCLUDES_SPECIAL`, boolean, default undef + + Giving access to @all users (as in `R =3D @all`) in the config nor= mally + does *not* include the special users "gitweb" and "daemon". If you = want + @all to include these two users, set this variable. + + * mirroring setup + + These two variables enable mirroring support; see + [doc/mirroring.mkd][mirr] for details. The two variables are + `$GL_SLAVE_MODE`, (boolean, default undef), and `$ENV{GL_SLAVES}`, + (environment variable, string, default undef) + + Note on the second variable above: you must use single quotes to giv= e it + its value, not double quotes, (like `$ENV{GL_SLAVES} =3D 'gitolite@s= erver2 + gitolite@server3';`). Also note that this is an environment variabl= e, not + a regular perl variable, so mind the syntax if you're not a perl guy= :-) + + * `$GL_WILDREPOS_PERM_CATS`, string, default "READERS WRITERS" + + Originally, we only allowed "R" and "RW" in the setperms command. N= ow we + allow the admin to define other categories as she wishes (example: + MANAGERS, TESTERS, etc). + + This variable is a space-separated list of the allowed categories. + + PLEASE, *PLEASE*, read the section in + [doc/wildcard-repositories.mkd][wild] for caveats and warnings. Thi= s is a + VERY powerful feature and if you're not careful you could mess up th= e ACLs + nicely. + + This is the internal default if you don't set it (like if you didn't + update your ~/.gitolite.rc with new variables when you upgraded gito= lite): + + $GL_WILDREPOS_PERM_CATS =3D "READERS WRITERS"; + + You can use your own categories in addition to the standard ones; I + suggest you include READERS and WRITERS for backward compatbility th= ough: + + $GL_WILDREPOS_PERM_CATS =3D "READERS WRITERS MANAGERS TESTERS"; + + + +### rarely changed variables + + * `$GL_LOGT`, string, default `$GL_ADMINDIR/logs/gitolite-%y-%m.log` + + This is the template for location of the log files and format of the= ir + names. + + The default produces files like `~/.gitolite/logs/gitolite-2009-09.l= og`. + If you make up your own templates, **PLEASE MAKE SURE** the director= y + exists and is writable; gitolite won't do that for you unless it is = the + default, ("$GL_ADMINDIR/logs") + + * `$GL_PERFLOGT`, string, default undef + + This gives the location of the performance log files. Uncomment and= set + this variable if you want performance logging. Performance log file= s are + kept separate from access log files because they store different, us= ually + much shorter term, information. + + * `$GL_SITE_INFO`, string, default undef + + Some installations would like to give their users customised informa= tion + (like a link to their own websites, for example) so that users have = a + quick way to find some links or information. + + If this variable is defined, the "info" command will print it at the= end + of the listing. + + * `$REPO_BASE`, string, default "repositories" + + This is where all the repos go. If it's not an absolute path, it is + considered to be relative to $HOME. Changing it after the install h= as + completed is doable, but tricky if you don't know how gitolite works= . + +[wild]: http://github.com/sitaramc/gitolite/blob/pu/doc/wildcard-reposit= ories.mkd +[bc]: http://github.com/sitaramc/gitolite/blob/pu/doc/big-config.mkd +[faq]: http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mk= d +[adc]: http://github.com/sitaramc/gitolite/blob/pu/doc/admin-defined-com= mands.mkd +[mirr]: http://github.com/sitaramc/gitolite/blob/pu/doc/mirroring.mkd