047790140a
THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO
NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade
means should be fine, though.
Originally, we only allowed "R" and "RW" as categories of users supplied
to the `setperms` command. These map respectively to "READERS" and
"WRITERS" in the access rules.
Now:
- we prefer READERS instead of R and WRITERS instead of RW
- we allow the admin to define other categories as she wishes
(example: MANAGERS, TESTERS, etc). These do not have abbreviations,
however, so they must be supplied in full.
PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for
more info. This is a VERY powerful feature and if you're not careful
you could mess up the ACLs nicely.
Backward compat note: you can continue to use the "R" and "RW"
categories when running the "setperms" command, and gitolite will
internally convert them to READERS and WRITERS categories.
----
implementation notes:
- new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of
the allowed categories in a gl-perms file; defaults to "R RW" if not
specified
- wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if
"R $user", $r = '@all' if "R @all", and similarly with $w and "RW".
Instead it returns $c and a new hash that effectively gives the same
info, but expanded to include any other valid categories (listed in
GL_WILDREPOS_PERM_CATS)
- consequently, the arguments that parse_acl takes also change the
same way
- (side note: R and RW are quietly converted to READERS and WRITERS;
however, new categories that you define yourself do not have
abbreviations)
- setperms validates perms to make sure only allowed categories are
used; however even if someone changed them behind the scenes,
wild_repo_rights will also check. This is necessary in case the
admin tightened up GL_WILDREPOS_PERM_CATS after someone had already
setperms-d his repos.
- as a bonus, we eliminate all the post-Dumper shenanigans, at least
for READERS and WRITERS. Those two now look, to the compile script,
just like any other usernames.
318 lines
11 KiB
Plaintext
318 lines
11 KiB
Plaintext
# paths and configuration variables for gitolite
|
|
|
|
# please read comments before editing
|
|
|
|
# this file is meant to be pulled into a perl program using "do" or "require".
|
|
|
|
# You do NOT need to know perl to edit the paths; it should be fairly
|
|
# self-explanatory and easy to maintain perl syntax :-)
|
|
|
|
# --------------------------------------
|
|
# Do not change the next two lines unless you know what you're doing
|
|
# $GL_PACKAGE_CONF = "";
|
|
# $GL_PACKAGE_HOOKS = "";
|
|
|
|
# --------------------------------------
|
|
# MIRRORING SUPPORT
|
|
|
|
# $GL_SLAVE_MODE = 0;
|
|
# $ENV{GL_SLAVES} = '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 starting
|
|
# with "/"), it's relative to your $HOME. You may want to put in something
|
|
# like "/bigdisk" or whatever if your $HOME is too small for the repos, for
|
|
# example
|
|
|
|
$REPO_BASE="repositories";
|
|
|
|
# the default umask for repositories is 0077; change this if you run stuff
|
|
# like gitweb and find it can't read the repos. Please note the syntax; the
|
|
# leading 0 is required
|
|
|
|
$REPO_UMASK = 0077; # gets you 'rwx------'
|
|
# $REPO_UMASK = 0027; # gets you 'rwxr-x---'
|
|
# $REPO_UMASK = 0022; # gets you 'rwxr-xr-x'
|
|
|
|
# part of the setup of gitweb is a variable called $projects_list (please see
|
|
# gitweb documentation for more on this). Set this to the same value:
|
|
|
|
$PROJECTS_LIST = $ENV{HOME} . "/projects.list";
|
|
|
|
# giving access to @all users (as in "R = @all") in the config normally does
|
|
# *not* include the special users "gitweb" and "daemon". If you want @all to
|
|
# include these two users, set this variable:
|
|
|
|
# $GL_ALL_INCLUDES_SPECIAL = 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 *absolute*
|
|
# path (i.e., starting with a "/" character)
|
|
|
|
# gitolite admin directory, files, etc
|
|
|
|
$GL_ADMINDIR=$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="$GL_ADMINDIR/logs/gitolite-%y-%m.log";
|
|
|
|
# other choices are below, or you can make your own -- but PLEASE MAKE SURE
|
|
# 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="$GL_ADMINDIR/logs/gitolite-%y-%m-%d.log";
|
|
# $GL_LOGT="$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 different
|
|
# information, are not meant to be as long-lived, and so on
|
|
|
|
# $GL_PERFLOGT="$GL_ADMINDIR/logs/perf-gitolite-%y-%m.log";
|
|
|
|
# --------------------------------------
|
|
|
|
# Please DO NOT change these three paths
|
|
|
|
$GL_CONF="$GL_ADMINDIR/conf/gitolite.conf";
|
|
$GL_KEYDIR="$GL_ADMINDIR/keydir";
|
|
$GL_CONF_COMPILED="$GL_ADMINDIR/conf/gitolite.conf-compiled.pm";
|
|
|
|
# --------------------------------------
|
|
|
|
# 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="";
|
|
# $GIT_PATH="/opt/bin/";
|
|
|
|
# --------------------------------------
|
|
|
|
# ----------------------------------------------------------------------
|
|
# BIG CONFIG SETTINGS
|
|
|
|
# Please read doc/big-config.mkd for details
|
|
|
|
$GL_BIG_CONFIG = 0;
|
|
$GL_NO_DAEMON_NO_GITWEB = 0;
|
|
$GL_NO_CREATE_REPOS = 0;
|
|
$GL_NO_SETUP_AUTHKEYS = 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, which
|
|
# completely disables this feature (meaning you cannot set git configs from
|
|
# the repo config).
|
|
|
|
$GL_GITCONFIG_KEYS = "";
|
|
|
|
# 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 expression
|
|
# patterns, and any one of them must match). For example:
|
|
# $GL_GITCONFIG_KEYS = "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 familiar with
|
|
# regular expressions) is to allow anything and everything:
|
|
# $GL_GITCONFIG_KEYS = ".*";
|
|
|
|
# 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 "foo"
|
|
# category:
|
|
# $GL_GITCONFIG_KEYS = "foo\\..*";
|
|
|
|
# --------------------------------------
|
|
# ALLOW GITCONFIG KEYS EVEN FOR WILD REPOS
|
|
#
|
|
# This is an efficiency issue more than a security issue, since this requires
|
|
# trawling through all of $REPO_BASE looking for stuff :)
|
|
|
|
# $GL_GITCONFIG_WILD = 0;
|
|
|
|
# --------------------------------------
|
|
# EXTERNAL COMMAND HELPER -- HTPASSWD
|
|
|
|
# security note: runs an external command (htpasswd) with specific arguments,
|
|
# including a user-chosen "password".
|
|
|
|
# if you want to enable the "htpasswd" command, give this the absolute path to
|
|
# whatever file apache (etc) expect to find the passwords in.
|
|
|
|
$HTPASSWD_FILE = "";
|
|
|
|
# Look in doc/3 ("easier to link gitweb authorisation with gitolite" section)
|
|
# for more details on using this feature.
|
|
|
|
# --------------------------------------
|
|
# EXTERNAL COMMAND HELPER -- RSYNC
|
|
|
|
# security note: runs an external command (rsync) with specific arguments, 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 disable the
|
|
# rsync helper.
|
|
|
|
$RSYNC_BASE = "";
|
|
|
|
# $RSYNC_BASE = "/home/git/up-down";
|
|
# $RSYNC_BASE = "/tmp/up-down";
|
|
|
|
# --------------------------------------
|
|
# EXTERNAL COMMAND HELPER -- SVNSERVE
|
|
|
|
# security note: runs an external command (svnserve) with specific arguments,
|
|
# as specified below. %u is substituted with the username.
|
|
|
|
# This setting allows launching svnserve when requested by the ssh client.
|
|
# This allows using the same SSH setup (hostname/username/public key) for both
|
|
# SVN and git access. Leave it undefined or set to the empty string to disable
|
|
# svnserve access.
|
|
|
|
$SVNSERVE = "";
|
|
# $SVNSERVE = "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%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 specific
|
|
# 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 as
|
|
# 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 features.
|
|
# Please see doc/4-wildcard-repositories.mkd for details.
|
|
|
|
$GL_WILDREPOS = 0;
|
|
|
|
# --------------------------------------
|
|
# DEFAULT WILDCARD PERMISSIONS
|
|
|
|
# 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 the setperms 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 permissions.
|
|
|
|
# $GL_WILDREPOS_DEFPERMS = '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: MANAGERS,
|
|
# TESTERS, etc).
|
|
|
|
# This variable is a space-sep list of the allowed categories.
|
|
|
|
# PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for
|
|
# caveats and warnings. This is a VERY powerful feature and if you're not
|
|
# careful you could mess up the 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 gitolite):
|
|
$GL_WILDREPOS_PERM_CATS = "READERS WRITERS";
|
|
|
|
# you can use your own categories in addition to the standard ones; I suggest
|
|
# you include READERS and WRITERS for backward compat though:
|
|
# $GL_WILDREPOS_PERM_CATS = "READERS WRITERS MANAGERS";
|
|
# $GL_WILDREPOS_PERM_CATS = "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 paths,
|
|
# change these variables
|
|
|
|
# $UPDATE_CHAINS_TO = "hooks/update.secondary";
|
|
# $ADMIN_POST_UPDATE_CHAINS_TO = "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 read
|
|
# doc/admin-defined-commands.mkd for details.
|
|
|
|
# $GL_ADC_PATH = "";
|
|
|
|
# --------------------------------------
|
|
# SITE-SPECIFIC INFORMATION
|
|
|
|
# Some installations would like to give their users customised information
|
|
# (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 end of
|
|
# the listing.
|
|
|
|
# $GL_SITE_INFO = "";
|
|
# $GL_SITE_INFO = "XYZ.COM DEVELOPERS: PLEASE SEE http://xyz.com/gitolite/help first";
|
|
|
|
# --------------------------------------
|
|
# USERGROUP HANDLING
|
|
|
|
# Some sites would like to store group membership outside gitolite, because
|
|
# 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 username as
|
|
# argument, will return a list of groups that she is a member of.
|
|
|
|
# $GL_GET_MEMBERSHIPS_PGM = "/usr/local/bin/expand-ldap-user-to-groups"
|
|
|
|
# --------------------------------------
|
|
# per perl rules, this should be the last line in such a file:
|
|
1;
|
|
|
|
# Local variables:
|
|
# mode: perl
|
|
# End:
|
|
# vim: set syn=perl:
|