deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

(doc) INSTALL doc needs info on URLs

Browse source 
More and more people are using one of the first 3 methods of install
(the ones that don't involve running "src/gl-easy-install" from the
client side) usualy due to RPM/DEB being available now.

Previously, the ending message on running that command was serving this
purpose, and so it never really got written down in so many words.

[thanks to antgel for catching this]

----

while we were there, we removed a now-obsolete section that talks about
how to use just one key; there are better methods now
This commit is contained in:
Sitaram Chamarty 2010-07-05 15:54:44 +05:30
parent 14248a3441
commit 1488973412
2 changed files with 23 additions and 46 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
doc/0-INSTALL.mkd
View file

@ -13,6 +13,7 @@ In this document:
* <a href="#root_method_directly_on_the_server_manually_with_root_access">(root method) directly on the server, manually, with root access</a>
* <a href="#non_root_method_directly_on_the_server_manually_without_root_access">(non-root method) directly on the server, manually, without root access</a>
* <a href="#from_client_method_install_from_the_client_to_the_server">(from-client method) install from the client to the server</a>
* <a href="#URLs_for_gitolite_managed_repos">URLs for gitolite-managed repos</a>
* <a href="#special_cases_multiple_gitolite_servers">special cases -- multiple gitolite servers</a>
* <a href="#package_method_and_root_method">package method and root method</a>
* <a href="#from_client_method">from-client method</a>
@ -165,6 +166,21 @@ documentation.
This method is verbosely documented in [doc/7-install-transcript.mkd][doc7],
including *outputs* of the commands concerned.
<a name="URLs_for_gitolite_managed_repos"></a>
### URLs for gitolite-managed repos
The URL for normal users (i.e., users other than the admin) is always of the
form "git@server:reponame". So, for instance, `git clone git@server:testing`
gets any valid user a copy of the "testing" repo.
In the first 3 install methods, the admin user will also use the same URL
format, like `git clone git@server:gitolite-admin`.
However, in the fourth ("from-client") method, the admin user needs a
different URL (`gitolite:reponame`) to gain access to the gitolite
repositories. Check [here][twokeys] for why.
<a name="special_cases_multiple_gitolite_servers"></a>
### special cases -- multiple gitolite servers
@ -264,4 +280,4 @@ uninstalling gitolite is described in great detail in
[doc7]: http://github.com/sitaramc/gitolite/blob/pu/doc/7-install-transcript.mkd
[doc9unin]: http://github.com/sitaramc/gitolite/blob/pu/doc/9-uninstall.mkd
[doc9ssh]: http://github.com/sitaramc/gitolite/blob/pu/doc/9-ssh-tips.mkd
[twokeys]: http://github.com/sitaramc/gitolite/blob/pu/doc/6-ssh-troubleshooting.mkd#why_two_keys_on_client

51
doc/6-ssh-troubleshooting.mkd
View file

@ -377,53 +377,13 @@ them; the ssh server will always (*always*) pick the first one in sequence
when the key is offered by the ssh client.
So the next question is usually "I have other ways to get a shell on that
account, so why do I need a key for shell access at all?"
account (like `su - git` from some other account), so why do I need a key for
shell access at all?"
The answer to this is that the "easy install" script, being written for the
most general case, needs shell access via ssh to do its stuff.
If you really, really, want to get rid of the extra key, here's a transcript
that should have enough info to get you going (but it helps to know ssh well):
* on "sitaram" user, on my workstation
cd ~/.ssh
cp id_rsa sitaram
cp id_rsa.pub sitaram.pub
cd ~/gitolite-clone
src/gl-easy-install -q git my.git.server sitaram
that last command produces something like the following:
you are upgrading from (unknown) to v0.80-6-gdde8c4e
setting up keypair...
...reusing /home/sitaram/.ssh/sitaram.pub...
creating gitolite para in ~/.ssh/config...
finding/creating gitolite rc...
installing/upgrading...
Pseudo-terminal will not be allocated because stdin is not a terminal.
[master (root-commit) e717a89] start
2 files changed, 11 insertions(+), 0 deletions(-)
create mode 100644 conf/gitolite.conf
create mode 100644 keydir/sitaram.pub
cloning gitolite-admin repo...
Initialized empty Git repository in /home/sitaram/gitolite-admin/.git/
fatal: 'gitolite-admin.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
notice that the final step (the clone of the newly created gitolite-admin
repo) failed, as expected
* now log on to the git hosting account (`git@my.git.server` in this
example), edit `~/.ssh/authorized_keys`, and delete the line with the
first occurrence of your key (this should be *before* the `# gitolite
start` line)
* now go back to your workstation and
git clone git@my.git.server:gitolite-admin
That should do it.
most general case, needs shell access via ssh to do its stuff. If you have
access otherwise, you really should use one of the other 3 install methods to
install gitolite. Please see the [install doc][install] for details.
<a name="some_other_tips_and_tricks"></a>
@ -494,3 +454,4 @@ bigger problems than gitolite install not working!)]
[doc0]: http://github.com/sitaramc/gitolite/blob/pu/doc/0-INSTALL.mkd
[doc9gas]: http://github.com/sitaramc/gitolite/blob/pu/doc/9-gitolite-and-ssh.mkd
[install]: http://github.com/sitaramc/gitolite/blob/pu/doc/0-INSTALL.mkd