odds-and-ends.mkd

   1 <!-- options: toc -->
   2
   3 % odds and ends
   4
   5 include sidebar-toc
   6
   7 This page has a bunch of stuff that didn't seem to fit anywhere.
   8
   9 # disabling pushes to take backups {#writable}
  10
  11 The `writable` command allows you to disable pushes to all repos or just the
  12 named repo, in order to do file-system level things to the repo directory that
  13 require it not to change, like using normal backup software.
  14
  15 Run `gitolite writable -h` for more info.
  16
  17 # putting 'repositories' and '.gitolite' elsewhere {#elsewhere}
  18
  19 Gitolite insists that the "repositories" and ".gitolite" directories be in
  20 `$HOME`.  If you want them somewhere else:
  21
  22   * do the install as normal,
  23   * *then* move those directories to wherever you want and replace them with
  24     symlinks pointing to the new location.
  25
  26 # using pubkeys obtained from elsewhere {#keysonly}
  27
  28 If you're not managing keys via the gitolite-admin repo, but getting them from
  29 somewhere else, you'll want to periodically "update" the keys.
  30
  31 To do that, first edit your rc file and add something like this:
  32
  33     SSH_AUTHKEYS                =>
  34         [
  35             'post-compile/ssh-authkeys',
  36         ],
  37
  38 Then write a script that
  39
  40   * gets all the keys and dumps them into `$HOME/.gitolite/keydir` (or into a
  41     subdirectory of it), and
  42   * runs `gitolite trigger SSH_AUTHKEYS`.
  43
  44 Run this from cron or however you want.
  45
  46 # giving users their own repos {#gh}
  47
  48 (Please see [this][wild] for background on the ideas in this section).
  49
  50 It's very easy to give users their own set of repos to create, with the
  51 username at the top level.  The simplest setup is:
  52
  53 .#! conf/vim-color
  54     repo CREATOR/..*
  55         C   =   @all
  56         RW+ =   CREATOR
  57         RW  =   WRITERS
  58         R   =   READERS
  59 .end
  60
  61 Now users can create any repo under their own name simply by cloning it or
  62 pushing to it, then use the [perms][] command to add other users to their
  63 WRITERS and READERS lists.
  64
  65 Of course you can get much more creative if you add a few more roles (see
  66 "roles" in [this][wild] page).
  67
  68 <font color="gray">(I prefer using some prefix, say "u", as in `repo
  69 u/CREATOR/..*`.  This helps to keep user-created repos separate, and avoid
  70 name clashes in some far-fetched scenarios).</font>
  71
  72 # administering gitolite directly on the server {#server-side-admin}
  73
  74 The main use of managing gitolite via the admin repo is that you get to
  75 version control the access rules.  But for large sites, there's another use:
  76 you can share the admin load with more people, **without** having to give all
  77 of them shell access on the server.
  78
  79 However, people who use puppet and similar systems already have a conf
  80 versioning and management system.  And they'd like to continue to use that to
  81 manage gitolite repos and users, rather than be forced to do it through the
  82 gitolite-admin repo.
  83
  84 Such sites don't really need the admin repo at all, so here's how to get rid
  85 of it and run things directly on the server (which you can script into your
  86 puppet or similar software quite easily).
  87
  88 First the one-time stuff:
  89
  90   * [install][] the software as normal
  91
  92   * run `gitolite setup -a dummy` instead of the normal [setup][] command
  93
  94   * delete (or move away) `~/repositories/gitolite-admin.git`
  95
  96   * edit `~/.gitolite/conf/gitolite.conf` and remove the gitolite-admin repo
  97     and its access line.
  98
  99   * `mkdir ~/.gitolite/keydir` (because "setup -a" does not create it, but you
 100     will need it later to add keys).
 101
 102   * run `gitolite compile; gitolite trigger POST_COMPILE`
 103
 104 To manage gitolite, you can directly edit files in `~/.gitolite` (or cause
 105 puppet to place files there), and then run the commands in the last step
 106 above.  For example:
 107
 108   * copy someone's pubkey file to `~/.gitolite/keydir`
 109   * edit `~/.gitolite/conf/gitolite.conf` and add a repo or three, giving
 110     access to some user(s)
 111   * run `gitolite compile; gitolite trigger POST_COMPILE`
 112
 113 That's it.