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

more docfixes, esp the install doc

Browse source
This commit is contained in:
Sitaram Chamarty 2011-04-30 06:39:01 +05:30
parent 0d1e05c7e1
commit 074fc61d3a
2 changed files with 38 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
doc/1-INSTALL.mkd
View file

@ -38,13 +38,26 @@ In this document:
Please make sure you understand the following points first. Please make sure you understand the following points first.
* gitolite runs as a single user on a server, and is invoked via ssh. Thus, * gitolite runs as a single (real) user on a server, and is invoked via ssh.
every user on the server is a potential "gitolite host". Traditionally, this "hosting user" is "git" or "gitolite".
* gitolite depends **heavily** on ssh pubkey (passwordless) access. Do not * there is *usually* only one hosting user per server (machine), but
assume you know all about ssh -- most people **don't**. If in doubt, use gitolite makes it trivial to have as many as you want. In fact, every
a dedicated userid on both client and server for installation and user on the server is a potential hosting user. Advanced users can
administration of gitolite. look [here][mgs]!)
* using this single user and sshd (or httpd) authentication, gitolite allows
you to create any number of "virtual" users. Virtual user names only mean
something to gitolite, and they need not be the same as any real userid on
the server or any of the clients accessing it.
* the first such virtual user is the "admin user", created during the
install sequence.
* gitolite, in its most commonly used form, depends **heavily** on ssh
pubkey (passwordless) access. Do not assume you know all about ssh --
most people **don't**. If in doubt, use a dedicated userid on both client
and server for installation and administration of gitolite.
To make matters worse, ssh problems in gitolite don't always look like ssh To make matters worse, ssh problems in gitolite don't always look like ssh
problems. See [doc/ssh-troubleshooting.mkd][doc6] for help. problems. See [doc/ssh-troubleshooting.mkd][doc6] for help.
@ -54,14 +67,11 @@ Please make sure you understand the following points first.
Apparently this was not obvious to some people. Apparently this was not obvious to some people.
A gitolite setup has: Thus a bare minimum gitolite setup has:
* a server * a server
* a "hosting user" on the server -- the userid under which gitolite runs. * a real "hosting user" on the server -- usually "git" or "gitolite"
(Side note: there is *usually* only one hosting user per server (machine), * a virtual "admin user" -- the user who sets up gitolite and configures it.
but gitolite makes it trivial to have as many as you want. Advanced users
can look [here][mgs]!)
* an "admin user" -- the user who sets up gitolite and configures it
* the admin user's client or workstation, from which he does all his work * the admin user's client or workstation, from which he does all his work
It is possible to have the server and the client be the same machine, and even It is possible to have the server and the client be the same machine, and even
@ -219,14 +229,15 @@ we mean `conf/gitolite.conf` on your gitolite-admin clone.
mkdir -p /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks mkdir -p /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks
src/gl-system-install /usr/local/bin /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks src/gl-system-install /usr/local/bin /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks
* on the server, "su - git", then as "git" user, run `which gl-setup`. This * on the server, as root, run "su - git", then as "git" user, run `which
should respond with `/usr/local/bin/gl-setup`. If this is not what you gl-setup`. This should respond with `/usr/local/bin/gl-setup`. If this
get, you have some `$PATH` issues. Make sure `/usr/local/bin` is in the is not what you get, you have some `$PATH` issues. Make sure
`$PATH` for the git user, and that no prior components of the path contain `/usr/local/bin` is in the `$PATH` for the git user, and that no prior
another copy of `gl-setup`. You *must* run the one in the directory that components of the path contain another copy of `gl-setup`. You *must* run
is the first argument of `gl-system-install` above. the one in the directory that is the first argument of `gl-system-install`
above.
* now run `gl-setup /tmp/YourName.pub`. * on the server, still as "git", run `gl-setup /tmp/YourName.pub`.
* on the client, run `cd; git clone git@server:gitolite-admin` * on the client, run `cd; git clone git@server:gitolite-admin`
@ -243,8 +254,8 @@ to handle multiple keys in ssh.**
* from your workstation, copy your `~/.ssh/id_rsa.pub` file to the server. * from your workstation, copy your `~/.ssh/id_rsa.pub` file to the server.
Put it in `/tmp/YourName.pub`. Put it in `/tmp/YourName.pub`.
* if `$HOME/bin` is not on the default PATH, fiddle with your `.bashrc` or * if `$HOME/bin` is not on the default PATH for the "git" user, fiddle with
`.bash_profile` or similar files and add it somehow. the `.bashrc` or `.bash_profile` or similar files and add it somehow.
* (U) on the server, as "git", do the following: * (U) on the server, as "git", do the following:

7
doc/gitolite-and-ssh.mkd
View file

@ -1,6 +1,11 @@
# how gitolite uses ssh # how gitolite uses ssh
***Gitolite is heavily dependent on ssh***! Although other forms of authentications exist (see
[doc/gitolite-without-ssh.mkd][ws]), ssh is the one that most git users use.
***Therefore, gitolite is (usually) heavily dependent on ssh***.
[ws]: http://sitaramc.github.com/gitolite/doc/gitolite-without-ssh.html
Most people didn't realise this, and even if they did they didn't know ssh Most people didn't realise this, and even if they did they didn't know ssh
well enough to help themselves. If you don't understand how ssh public key well enough to help themselves. If you don't understand how ssh public key