add 2 new sections to "special features"...

- using pubkeys obtained from elsewhere
  - updating hooks via the admin repo
This commit is contained in:
Sitaram Chamarty 2012-05-25 15:25:48 +05:30
parent 17841e8208
commit 84d123e124
2 changed files with 62 additions and 0 deletions

View file

@ -100,6 +100,8 @@
* ([link][NAME]: the NAME VREF) * ([link][NAME]: the NAME VREF)
* the [subconf][] command * the [subconf][] command
* ([link][partial-copy]: faking selective READ control) * ([link][partial-copy]: faking selective READ control)
* using pubkeys obtained [from elsewhere][keysonly]
* [updating hooks][pushhook] via the admin repo
## interfacing with [external][] tools ## interfacing with [external][] tools

View file

@ -46,3 +46,63 @@ Compared to using arbitrary branch names on the same server, this:
## delegating access control responsibilities ## delegating access control responsibilities
See [this][deleg]. See [this][deleg].
## #keysonly using pubkeys obtained from elsewhere
If you're not managing keys via the gitolite-admin repo, but getting them from
somewhere else, you'll want to periodically "update" the keys.
To do that, first edit your rc file and add something like this:
SSH_AUTHKEYS =>
[
'post-compile/ssh-authkeys',
],
Then write a script that
* gets all the keys and dumps them into `$HOME/.gitolite/keydir` (or into a
subdirectory of it).
* runs `gitolite trigger SSH_AUTHKEYS`.
Run this from cron or however you want.
## #pushhook updating hooks via the admin repo
Gitolite by default maintains the distinction between someone who can push to
the admin repo and someone who has shell access to the server. As a result,
you cannot change any hooks merely by pushing the admin repo.
But some people don't care about this and want to do it anyway. Besides,
there *is* one advantage: your hooks can also be versioned now.
So here's how to add/change hooks when you push the gitolite-admin repo:
1. Put all common hooks in a new directory called 'common-hooks'.
2. Create a trigger program called 'propagate-hooks' in 'src/triggers' that
contains this:
#!/bin/sh
cd $GL_ADMIN_BASE
cp -a common-hooks/* hooks/common
gitolite setup --hooks-only
3. Add this to the `POST_COMPILE` trigger list in the rc file.
And that should be it, pretty much.
If you have lots of repos this is inefficient -- because the hook fixup will
run on *any* change to the admin repo, even if the change has nothing to do
with hooks.
If you're concerned about this, put the script in 'src/commands' instead of
'src/triggers'. (You might want to add some access control; see other
commands for inspiration, but it's not really needed in this case).
Then, whenever any hooks have changed, the admin can run
ssh git@host propagate-hooks