The old method of passing in usergroup info had some problems, which are now fixed. It is also much easier to use now -- no more "wrapper" script, plus it should work identially whether you use sshd or httpd. See doc/big-config.mkd for details on the new method. ---- Notes on problems with the old method: The old method for passing in usergroup info consisted of tacking them on as extra arguments to gl-auth-command, after the username. However, there are some problems with this method. Some actions in gitolite look for permissions for users other than the invoking user. Determining permissions for gitweb and daemon is one. An admin asking for "info" on some other user, is another. However, the list of groups sent in via the command line pertains only to the invoking user, so these actions don't work correctly. They may even pick up the wrong permissions. What it all boils down to is that we need group information for any user dynamically, instead of being passed a (static) list just for the invoking user.
250 lines
7 KiB
Markdown
250 lines
7 KiB
Markdown
# what is a "big-config"
|
|
|
|
In this document:
|
|
|
|
* <a href="#_when_why_do_we_need_it_">when/why do we need it?</a>
|
|
* <a href="#_how_do_we_use_it_">how do we use it?</a>
|
|
* <a href="#_other_optimisations">other optimisations</a>
|
|
* <a href="#_what_are_the_downsides_">what are the downsides?</a>
|
|
* <a href="#_storing_usergroup_information_outside_gitolite_like_in_LDAP_">storing usergroup information outside gitolite (like in LDAP)</a>
|
|
* <a href="#_why">why</a>
|
|
* <a href="#_how">how</a>
|
|
|
|
<a name="_when_why_do_we_need_it_"></a>
|
|
|
|
### when/why do we need it?
|
|
|
|
A "big config" is anything that has a few thousand users and a few thousand
|
|
repos, organised into groups that are much smaller in number (like maybe a few
|
|
hundreds of repogroups and a few dozens of usergroups).
|
|
|
|
So let's say you have
|
|
|
|
@wbr = lynx firefox
|
|
@devs = alice bob
|
|
|
|
repo @wbr
|
|
RW+ next = @devs
|
|
RW master = @devs
|
|
|
|
Gitolite internally translates this to
|
|
|
|
repo lynx firefox
|
|
RW+ next = alice bob
|
|
RW master = alice bob
|
|
|
|
Not just that -- it now generates the actual config rules once for each
|
|
user-repo-ref combination (there are 8 combinations above; the compiled config
|
|
file looks partly like this:
|
|
|
|
%repos = (
|
|
'firefox' => {
|
|
'R' => {
|
|
'alice' => 1,
|
|
'bob' => 1
|
|
},
|
|
'W' => {
|
|
'alice' => 1,
|
|
'bob' => 1
|
|
},
|
|
'alice' => [
|
|
{
|
|
'refs/heads/next' => 'RW+'
|
|
},
|
|
{
|
|
'refs/heads/master' => 'RW'
|
|
}
|
|
],
|
|
'bob' => [
|
|
{
|
|
'refs/heads/next' => 'RW+'
|
|
},
|
|
{
|
|
'refs/heads/master' => 'RW'
|
|
}
|
|
]
|
|
},
|
|
'lynx' => {
|
|
'R' => {
|
|
'alice' => 1,
|
|
'bob' => 1
|
|
},
|
|
'W' => {
|
|
'alice' => 1,
|
|
'bob' => 1
|
|
},
|
|
'alice' => [
|
|
{
|
|
'refs/heads/next' => 'RW+'
|
|
},
|
|
{
|
|
'refs/heads/master' => 'RW'
|
|
}
|
|
],
|
|
'bob' => [
|
|
{
|
|
'refs/heads/next' => 'RW+'
|
|
},
|
|
{
|
|
'refs/heads/master' => 'RW'
|
|
}
|
|
]
|
|
}
|
|
);
|
|
|
|
Phew!
|
|
|
|
You can imagine what that does when you have 10,000 users and 10,000 repos.
|
|
Let's just say it's not pretty :)
|
|
|
|
<a name="_how_do_we_use_it_"></a>
|
|
|
|
### how do we use it?
|
|
|
|
Now, if you had all those 10,000 users and repos explicitly listed (no
|
|
groups), then there is no help. But if, like the above example, you had
|
|
groups like we used above, there is hope.
|
|
|
|
Just set
|
|
|
|
$GL_BIG_CONFIG = 1;
|
|
|
|
in the `~/.gitolite.rc` file on the server (see next section for more
|
|
variables). When you do that, and push this configuration, the compiled file
|
|
looks like this:
|
|
|
|
%repos = (
|
|
'@wbr' => {
|
|
'@devs' => [
|
|
{
|
|
'refs/heads/next' => 'RW+'
|
|
},
|
|
{
|
|
'refs/heads/master' => 'RW'
|
|
}
|
|
],
|
|
'R' => {
|
|
'@devs' => 1
|
|
},
|
|
'W' => {
|
|
'@devs' => 1
|
|
}
|
|
},
|
|
);
|
|
%groups = (
|
|
'@devs' => {
|
|
'alice' => 'master',
|
|
'bob' => 'master'
|
|
},
|
|
'@wbr' => {
|
|
'firefox' => 'master',
|
|
'lynx' => 'master'
|
|
}
|
|
);
|
|
|
|
That's a lot smaller, and allows orders of magintude more repos and groups to
|
|
be supported.
|
|
|
|
<a name="_other_optimisations"></a>
|
|
|
|
### other optimisations
|
|
|
|
The default RC file contains the following lines (we've already discussed the
|
|
first one):
|
|
|
|
$GL_BIG_CONFIG = 0;
|
|
$GL_NO_DAEMON_NO_GITWEB = 0;
|
|
$GL_NO_CREATE_REPOS = 0;
|
|
$GL_NO_SETUP_AUTHKEYS = 0;
|
|
|
|
`GL_NO_DAEMON_NO_GITWEB` is a very useful optimisation that you *must* enable
|
|
if you *do* have a large number of repositories, and do *not* use gitolite's
|
|
support for gitweb or git-daemon access (see "[easier to specify gitweb
|
|
description and gitweb/daemon access][gwd]" for details). This will save a
|
|
lot of time when you push the gitolite-admin repo with changes. This variable
|
|
also control whether "git config" lines (such as `config hooks.emailprefix =
|
|
"[gitolite]"`) will be processed or not.
|
|
|
|
Setting this is relatively harmless to a normal installation, unlike the next
|
|
two variables :-) `GL_NO_CREATE_REPOS` and `GL_NO_SETUP_AUTHKEYS` are meant
|
|
for installations where some backend system already exists that does all the
|
|
actual repo creation, and all the authentication setup (ssh auth keys),
|
|
respectively.
|
|
|
|
Summary: Please **leave those two variables alone** unless you're initials are
|
|
"JK" ;-)
|
|
|
|
Also note that using all 3 of the `GL_NO_*` variables will result in
|
|
*everything* after the config compile being skipped. In other words, gitolite
|
|
is being used **only** for its access control language.
|
|
|
|
<a name="_what_are_the_downsides_"></a>
|
|
|
|
### what are the downsides?
|
|
|
|
There is one minor issue.
|
|
|
|
If you use the delegation feature, you can no longer define or extend
|
|
@groups in a fragment, for security reasons. It will also not let you use any
|
|
group other than the @fragname itself (specifically, groups which contained a
|
|
subset of the allowed @fragname, which would work normally, do not work now).
|
|
|
|
(If you didn't understand all that, you're probably not using delegation, so
|
|
feel free to ignore it!)
|
|
|
|
<a name="_storing_usergroup_information_outside_gitolite_like_in_LDAP_"></a>
|
|
|
|
### storing usergroup information outside gitolite (like in LDAP)
|
|
|
|
[Please NOTE: this is all about *user* groups, not *repo* groups]
|
|
|
|
[WARNING: the earlier method of doing this has been discontinued; please see
|
|
the commit message for details]
|
|
|
|
Gitolite now allows usergroup information to be stored outside its own config
|
|
file. We'll see "why" first, then the "how".
|
|
|
|
<a name="_why"></a>
|
|
|
|
#### why
|
|
|
|
Large sites often have LDAP servers that already contain user and group
|
|
information, including group membership details. Such sites may prefer that
|
|
gitolite just pick up that info instead of having to redundantly put it in
|
|
gitolite's config file.
|
|
|
|
Consider this example config for one repo:
|
|
|
|
repo foo
|
|
RW+ = @lead_devs
|
|
RW = @devs
|
|
R = @interns
|
|
|
|
Normally, you would also need to specify:
|
|
|
|
@lead_devs = dilbert alice
|
|
@devs = wally
|
|
@interns = ashok
|
|
|
|
However, if the corporate LDAP server already tags these people correctly, and
|
|
if there is some way of getting that information out **at run time**, that
|
|
would be cool.
|
|
|
|
<a name="_how"></a>
|
|
|
|
#### how
|
|
|
|
All you need is a script that, given a username, queries your LDAP or similar
|
|
server, and returns a space-separated list of all the groups she is a member
|
|
of. If an invalid user name is sent in, or the user is valid but is not part
|
|
of any groups, it should print nothing.
|
|
|
|
This script will probably be specific to your site. [**Help wanted**: I don't
|
|
know LDAP, so if someone wants to contribute some sample code I'd be happy to
|
|
put it in contrib/, with credit of course!]
|
|
|
|
Then set the `$GL_GET_MEMBERSHIPS_PGM` variable in the rc file to the full
|
|
path to this program, set `$GL_BIG_CONFIG` to 1, and that will be that.
|
|
|
|
[gwd]: http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#gwd
|