gitolite/doc/2-admin.mkd
Sitaram Chamarty c54d3eabbc all src: (please read full commit message): allow local admin-defined hooks
You can now add your own hooks into src/hooks/ and they get propagated
along with the update hook that is present there now.  Please read the
new section in the admin document, and make sure you understand the
security implications of accidentally fiddling with the "update" script.

This also prompted a major rename spree of all the files to be
consistent, etc.  Plus people said that the .sh and .pl suffixes should
be avoided (and I was feeling the same way).  I've also been
inconsistent with that "gl-" prefix, so I cleaned that up, and the 00-
and 99- were also funny animals.

Time to get all this cleaned up before we get 1.0 :)

So these are the changes, in case you're looking at just the commit
message and not the diffstat:

    src/pta-hook.sh -> src/ga-post-update-hook
    src/conf-convert.pl -> src/gl-conf-convert
    src/00-easy-install.sh -> src/gl-easy-install
    src/99-emergency-addkey.sh -> src/gl-emergency-addkey
    src/install.pl -> src/gl-install
    src/update-hook.pl -> src/hooks/update
2009-11-13 18:37:46 +05:30

3.8 KiB

administering and running gitolite

Note: some of the paths in this document use variable names. Just refer to ~/.gitolite.rc for the correct values for your installation.

In this document:

  • administer
    • adding users and repos
    • specifying gitweb and daemon access
    • custom hooks

administer

First of all, do NOT add new repos manually, unless you know how to add the required hook as well. Without the hook, branch-level access control will not work for that repo, which sorta defeats the idea of using gitolite :-)

Please read on to see how to do this correctly.

adding users and repos

  • ask each user who will get access to send you a public key. See other sources (for example here) for how to do this
  • rename each public key according to the user's name, with a .pub extension, like sitaram.pub or john-smith.pub. You can also use periods and underscores

  • copy all these *.pub files to keydir in your gitolite-admin repo clone

  • edit the config file (conf/gitolite.conf in your admin repo clone). See conf/example.conf in the gitolite source for details on what goes in that file, syntax, etc. Just add new repos as needed, and add new users and give them permissions as required. The users names should be exactly the same as their keyfile names, but without the .pub extension

  • when done, commit your changes and push

specifying gitweb and daemon access

This is a feature that I personally do not use (corporate environments don't like unauthenticated access of any kind to any repo!), but someone wanted it, so here goes.

To make a repo or repo group accessible via "git daemon", just give read permission to the special user "daemon". See the faq, tips, etc document for easy ways to specify access for multiple repositories.

There's a special user called "gitweb" also, which works the same way. However, setting a description for the project also enables gitweb permissions so you may as well use that method and kill two birds with one stone, like so:

gitolite = "fast, secure, access control for git in a corporate environment"

Note that gitolite does not install or configure gitweb/daemon -- that is a one-time setup you must do separately. All this does is:

  • for daemon, create the file git-daemon-export-ok in the repository
  • for gitweb, add the repo to the list of projects to be served by gitweb (see the config file variable $PROJECTS_LIST, which should have the same value you specified for $projects_list when setting up gitweb)
  • put the description, if given, in $repo/description

The "compile" script will keep these files consistent with the config settings -- this includes removing such settings/files if you remove "read" permissions for the special usernames or remove the description line.

custom hooks

If you want to put in your own, custom, hooks every time a new repo is created by gitolite, put a tested hook script in src/hooks. As distributed, the only file there is the update hook, but everything (everything) in that directory will get copied to the hooks/ subdirectory of every new repo created.

In order to push a new or updated hook script to existing repos as well, just run easy install once again; it'll do it to existing repos also.

VERY IMPORTANT SECURITY NOTE: the update hook in src/hooks is what implements all the branch-level permissions in gitolite. If you fiddle with the hooks directory, please make sure you do not mess with this file accidentally, or all your fancy per-branch permissions will stop working.