From 701b1820212f892f8df935c62083613b7f7eb441 Mon Sep 17 00:00:00 2001 From: Sitaram Chamarty Date: Sun, 23 May 2010 12:04:01 +0530 Subject: [PATCH] document the add_host_nickname branch changes --- doc/0-INSTALL.mkd | 55 +++++++++++++++++++++++++---------- doc/6-ssh-troubleshooting.mkd | 33 ++++----------------- 2 files changed, 45 insertions(+), 43 deletions(-) diff --git a/doc/0-INSTALL.mkd b/doc/0-INSTALL.mkd index c21d03c..754f4d2 100644 --- a/doc/0-INSTALL.mkd +++ b/doc/0-INSTALL.mkd @@ -13,11 +13,13 @@ In this document: * (root method) directly on the server, manually, with root access * (non-root method) directly on the server, manually, without root access * (from-client method) install from the client to the server - * special cases -- multiple gitolite instances - * upgrading - * uninstalling - * cleaning out a botched install - * uninstalling gitolite completely + * special cases -- multiple gitolite servers + * package method and root method + * from-client method + * upgrading + * uninstalling + * cleaning out a botched install + * uninstalling gitolite completely ---- @@ -162,13 +164,16 @@ including *outputs* of the commands concerned. -### special cases -- multiple gitolite instances +### special cases -- multiple gitolite servers -With the first two methods (package or root methods) of installation, it's -trivial to create multiple gitolite instances (say one for each department, on -some mega company-wide server). You can even do this without giving shell -access to the admins. Here's an example with just two "departments", and -their admins Alice and Bob: + + +#### package method and root method + +With the first two methods of installation, it's trivial to create multiple +gitolite instances (say one for each department, on some mega company-wide +server). You can even do this without giving shell access to the admins. +Here's an example with just two "departments", and their admins Alice and Bob: * create userids `webbrowser_repos` and `webserver_repos` * ask Alice and Bob for their pubkeys; copy them to the respective home @@ -185,7 +190,27 @@ to have a command line on the server, so don't give them the passwords if you don't need to -- the pubkey will allow them to be gitolite admins on their domain, and that's quite enough for normal operations. - + + +#### from-client method + +Thanks to Matt Perzel, the easy-install command now takes an optional 4th +parameter, which is the "nickname" of the gitolite server. It gets defined in +`~/.ssh/config`, and if not used it defaults to "gitolite". + +So if you used the following command to install gitolite to 2 different +servers: + + ./src/gl-easy-install -q git my.1st.git.server admin_user1 gitolite_server_1 + ./src/gl-easy-install -q git my.2nd.git.server admin_user1 gitolite_server_2 + +you will find that `~/gitolite_server_1-admin` and `~/gitolite_server_2-admin` +have been created as respective clones. Or you can re-clone elsewhere: + + cd ~/admin1; git clone gitolite_server_1:gitolite-admin.git + cd ~/admin2; git clone gitolite_server_2:gitolite-admin.git + + ### upgrading @@ -197,11 +222,11 @@ arguments! Also, remember that some new features may require additional settings in your `~/.gitolite.rc` file. - + ### uninstalling - + #### cleaning out a botched install @@ -219,7 +244,7 @@ here's how to clean the slate. * remove `~/.gitolite`, `~/.gitolite.rc` and `~/repositories/gitolite-admin.git` - + #### uninstalling gitolite completely diff --git a/doc/6-ssh-troubleshooting.mkd b/doc/6-ssh-troubleshooting.mkd index 697ed76..b996549 100644 --- a/doc/6-ssh-troubleshooting.mkd +++ b/doc/6-ssh-troubleshooting.mkd @@ -13,10 +13,9 @@ In this document: * files on client * why two keys on client * some other tips and tricks - * two gitolite servers to manage? - * giving shell access to gitolite users - * losing your admin key - * simulating ssh-copy-id + * giving shell access to gitolite users + * losing your admin key + * simulating ssh-copy-id ---- @@ -421,28 +420,6 @@ That should do it. -#### two gitolite servers to manage? - - * they can have the same key; no harm there (example, sitaram.pub) - - * instead of just one ssh/config para, you now have two (assuming that the - remote user on both machines is called "git"): - - host gitolite - user git - hostname server - identityfile ~/.ssh/sitaram - - host gitolite2 - user git - hostname server2 - identityfile ~/.ssh/sitaram - - * now access one server's repos as `gitolite:reponame.git` and the other - server's repos as `gitolite2:reponame.git`. - - - #### giving shell access to gitolite users We've managed (thanks to an idea from Jesse Keating) to make it possible for a @@ -469,7 +446,7 @@ access would not manage to get himself shell access. Giving someone shell access requires that you should have shell access in the first place, so the simplest way is to enable it from the server side only. - + #### losing your admin key @@ -479,7 +456,7 @@ gitolite-admin repository with a fresh key, take a look at the of course. The top of the script has useful information on how to use it and what it needs. - + #### simulating ssh-copy-id