ed5c78349e
the changes to cp/scp are because without "-p" they dont carry perms across to existing files. So if you forgot to chmod +x your custom hook and ran easy install, then after that you have to go to the server side to fix the perms...
148 lines
6.3 KiB
Markdown
148 lines
6.3 KiB
Markdown
# 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
|
|
* moving pre-existing repos into gitolite
|
|
* specifying gitweb and daemon access
|
|
* custom hooks
|
|
* when you need your own "update" hook
|
|
* custom git config
|
|
|
|
### 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][genpub]) for how to do this
|
|
|
|
[genpub]: http://sitaramc.github.com/0-installing/2-access-gitolite.html#generating_a_public_key
|
|
|
|
* 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
|
|
|
|
#### moving pre-existing repos into gitolite
|
|
|
|
One simple way to add a pre-existing repo to gitolite is to let gitolite
|
|
create it as a brand new repo as in the previous section, and then, from an
|
|
existing clone, "push --all" to the new one.
|
|
|
|
However, if you have many existing repos to add, this can be time-consuming
|
|
and error-prone. Here's how to take a bunch of existing repos and add them to
|
|
gitolite:
|
|
|
|
* make sure they're *bare* repos ;-)
|
|
|
|
* log on to the server and copy the repos to `$REPO_BASE` (which defaults to
|
|
`~/repositories`), making sure that the directory names end in ".git".
|
|
|
|
* back on your workstation, add each repo (without the `.git` suffix) to
|
|
`conf/gitolite.conf` in your gitolite-admin repo clone. Then add, commit,
|
|
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][ss]
|
|
document for easy ways to specify access for multiple repositories.
|
|
|
|
[ss]: http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#gwd
|
|
|
|
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"
|
|
|
|
You can also specify an owner for gitweb to show, if you like:
|
|
|
|
gitolite "Sitaram Chamarty" = "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 (plus owner name, if given) 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 `hooks/common` of your gitolite
|
|
clone before running easy-install. As distributed, there are only two files
|
|
there, 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 `hooks/common` 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.**
|
|
|
|
#### when you need your own "update" hook
|
|
|
|
Gitolite basically takes over the update hook for all repos, but some setups
|
|
really need the update hook functionality for their own purposes too. In
|
|
order to allow this, Gitolite now exec's a hook called `update.secondary` when
|
|
it's own "update" hook is done and everything is ready to go.
|
|
|
|
You can create this `update.secondary` hook selectively on some repos on the
|
|
server, or use the mechanism in the previous section to make gitolite install
|
|
it on *all* your repos.
|
|
|
|
#### custom git config
|
|
|
|
The custom hooks feature is a blunt instrument -- all repos get the hook you
|
|
specified and will run it. In order to make it a little more fine-grained,
|
|
you could set your hooks to only work if a certain "gitconfig" variable was
|
|
set. Which means we now need a way to specify "git config" settings on a per
|
|
repository basis.
|
|
|
|
Thanks to Teemu (teemu dot matilainen at iki dot fi), gitolite now does this
|
|
very easily. For security reasons, this can only be done from the master
|
|
config file (i.e., if you're using delegation, the delegated admins cannot
|
|
specify git config settings).
|
|
|
|
Please see `conf/example.conf` for syntax. Note that this only supports the
|
|
basic forms of the "git config" command:
|
|
|
|
git config section.key value # value may be an empty string
|
|
git config --unset-all section.key
|
|
|
|
It does not (currently) support other options like `--add`, the `value_regex`,
|
|
etc.
|