diff --git a/doc/hook-propagation.mkd b/doc/hook-propagation.mkd index 99cf4cf..318c7e7 100644 --- a/doc/hook-propagation.mkd +++ b/doc/hook-propagation.mkd @@ -1,8 +1,13 @@ ## hook propagation in gitolite -Advanced users need to know how hooks propagate, and when. They also need to -know where to place their hooks, and since there appear to be two places to -put them, what takes precedence. I'll try and set out the logic here. +Some users like to know how hooks propagate, and when, and why there appear to +be two places to put them, and so on. I'll try and set out the logic here. + +**Note**: This is **not** the document to read if you just want to install a +new custom hook; treat it as more "theory" than "lab". ([Here][ch] is the +"lab" version!) + +[ch]: http://sitaramc.github.com/gitolite/doc/2-admin.html#_custom_hooks In this document: diff --git a/doc/ssh-troubleshooting.mkd b/doc/ssh-troubleshooting.mkd index 0254475..64500a7 100644 --- a/doc/ssh-troubleshooting.mkd +++ b/doc/ssh-troubleshooting.mkd @@ -26,7 +26,7 @@ In this document: * appendix 2: which key is which -- running sshkeys-lint * typical cause(s) * appendix 3: ssh client may not be offering the right key - * appendix 4: making git use the right key using `~/.ssh/config` + * appendix 4: host aliases * appendix 5: why bypassing gitolite causes a problem ---- @@ -452,7 +452,7 @@ won't work. You will have to use the more generic method described If some keys *are* being offered, but not the key that was supposed to be used, you may be using ssh-agent (next bullet). You may also need to - setup/edit `~/.ssh/config` (appendix 4). + create some host aliases in `~/.ssh/config` (appendix 4). * (ssh-agent issues) If `ssh-add -l` responds with either "The agent has no identities." or "Could not open a connection to your authentication @@ -465,30 +465,47 @@ won't work. You will have to use the more generic method described In that case, add the key you want using `ssh-add ~/.ssh/YourName` and try the access again. - + -### appendix 4: making git use the right key using `~/.ssh/config` +### appendix 4: host aliases -If you have several pubkeys with access to the same server, you **need** to -create/edit a file called `~/.ssh/config` to make sure git picks up the right -one when it accesses the server. There is no other way to do this, as far as -I know. +(or "making git use the right options for ssh") - * (side note) this is *mandatory* for the 'from-client' method of install, - and indeed that mode automatically sets up all this anyway. This install - method runs from the client, so it clearly needs a shell-capable key which - is distinct from the gitolite key for the admin user. +The ssh command has several options for non-default items to be specified. +Two common examples are `-p` for the port number if it is not 22, and `-i` for +the public key file if you do not want to use just `~/.ssh/id_rsa` or such. -What you need is to add something like this to `~/.ssh/config`: +Git has two ssh-based URL syntaxes, but neither allows specifying a +non-default public key file. And a port number is only allowed in one of +them. (See `man git-clone` for details). Finally, hosts often have to be +referred with IP addresses (such is life), or the name is very long, or hard +to remember. + +Using a "host" para in `~/.ssh/config` lets you nicely encapsulate all this +within ssh and give it a short, easy-to-remember, name. Example: host gitolite - user git - hostname server - identityfile ~/.ssh/YourName + user git + hostname a.long.server.name.or.annoying.IP.address + port 22 + identityfile ~/.ssh/id_rsa -Now you can use `gitolite:reponame` as the URL to make ssh use the named -key. (Using `git@server:reponame` will end up using the default key -`id_rsa` and, presumably, bypass gitolite). +Now you can simply use the one word `gitolite` (which is the host alias we +defined here) and ssh will infer all those details defined under it -- just +say `ssh gitolite` and `git clone gitolite:reponame` and things will work. + +(By the way, the 'port' and 'identityfile' lines are needed only if you have +non-default values, although I put them in anyway just to be complete). + +If you have *more than one* pubkey with access to the *same* server, you +**must** use this method to make git pick up the right key. There is no other +way to do this, as far as I know. + +> *Side note*: this is *mandatory* in the 'from-client' method of install, +> and indeed that mode automatically sets up all this anyway. This install +> method runs from the client, so it starts with one key that can get a +> shell on the server, and then creates another one as the "gitolite key" +> for the admin user. ----