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

from-client (gl-easy-install) is now obsolete

Browse source
This commit is contained in:
Sitaram Chamarty 2011-09-03 09:36:24 +05:30
parent 8b501a1872
commit 2056c95917
17 changed files with 40 additions and 1080 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
contrib/gitweb/gitweb.conf
View file

@ -17,8 +17,6 @@ my $gl_home = $ENV{HOME} = "/home/git";
$ENV{GL_RC} = "$gl_home/.gitolite.rc";
# this can have different values depending on how you installed.
# If you installed using the 'from-client' method it will be this:
$ENV{GL_BINDIR} = "$gl_home/.gitolite/src";
# if you used RPM/DEB or "root" methods it **might** be this:
$ENV{GL_BINDIR} = "/usr/local/bin";
# if you used the "non-root" method it **might** be this:

18
doc/1-INSTALL.mkd
View file

@ -295,9 +295,6 @@ we mean `conf/gitolite.conf` on your gitolite-admin clone.
* even msysgit on Windows is fine; please don't ask me for help if
you're using putty, plink, puttygen, etc., for ssh; I recommend
msysgit for Windows and the openssh that comes with it
* if you're using the "from-client" method of install (see below), the bash
shell is needed
* again, msysgit on Windows is fine
<a name="_server"></a>
@ -446,21 +443,18 @@ uninstalling gitolite is described in great detail in
### appendix a: the from-client method
This method was the only install mode at one time, but the newer ones are much
better, so it's kinda legacy now (Wow -- fancy something being "legacy" in
software that is not yet 2 years old!)
better, so it's gone now, to reduce confusion and support/documentation load.
The only advantage of this method is that it forces you to solve the ssh
The only advantage of this method was that it forced you to solve the ssh
pubkey problem **before** attempting to install.
But I'm not sure if that is worth the hassle of supporting an install scheme
But it turned out not to be worth the hassle of supporting an install scheme
that ends up with the admin user having [two keys][twokeys], though. And this
in turn forces the admin to use a different URL to access gitolite repos than
normal users, which seems to confuse a heck of a lot of people who don't read
in turn forced the admin to use a different URL to access gitolite repos than
normal users, which seemed to confuse a heck of a lot of people who don't read
the prominently displayed messages and/or the documentation.
All in all, I plan to obsolete it eventually. Meanwhile, it is verbosely
documented in this [transcript][], including *outputs* of the commands
concerned.
All in all, it wasn't one of my best ideas.
<a name="_appendix_b_PATH_issues_for_gl_setup"></a>

21
doc/2-admin.mkd
View file

@ -88,16 +88,8 @@ section tells you how to add users and repos.
You can supply your own, custom, hook scripts if you wish. Install gitolite
as usual, then:
* if you installed using "from-client" method (gl-easy-install):
* go to the gitolite *source* clone from which you did the original
install
* add your new hook into "hooks/common"
* run src/gl-easy-install with the same arguments as you ran the first
time
* if you installed using one of the other methods
* go to ~/.gitolite/hooks/common on the server and put your new hook
there
* now run "gl-setup" again
* go to ~/.gitolite/hooks/common on the server and put your new hook there
* now run "gl-setup" again
You can use this procedure to install new hooks as well as to update hooks
that you had previously installed.
@ -361,14 +353,6 @@ if things are not clear -- you can help me fine tune this document :-)
mv repositories/gitolite-admin.git $HOME/old-gitolite-admin.git
find repositories -name gitolite-hooked | xargs rm
* (workstation) if your old server was installed using the "from-client"
method, and you intend to use the same method to install the new server,
then
* edit `~/.ssh/config` and change the line that says `host gitolite` to
`host old-gitolite`, or in fact anything that does not match the
string "host gitolite" :-)
* (workstation, new server) **install** gitolite normally on your new
server. Use whatever install method suits you, but you must use the
**same** name for the admin ("YourName" in the install instructions). You
@ -400,7 +384,6 @@ if things are not clear -- you can help me fine tune this document :-)
* set the URL for the new server
git remote --set-url origin git@newserver:gitolite-admin
# if you used easy install this will be "gitolite:gitolite-admin"
* push the config, including past history

4
doc/3-faq-tips-etc.mkd
View file

@ -571,10 +571,6 @@ have to be first "compiled", and the access control programs use this
"compiled" version of the config. (The compile step also refreshes
`~/.ssh/authorized_keys`).
If you choose the "easy install" method, all this is quite transparent to you
anyway. If you cannot use the easy install and must install manually, I have
clear instructions on how to set it up.
[repout]: http://sitaramc.github.com/gitolite/doc/report-output.html
[delegation]: http://sitaramc.github.com/gitolite/doc/delegation.html
[rmrepo]: http://sitaramc.github.com/gitolite/doc/admin-defined-commands.html#rmrepo

25
doc/hook-propagation.mkd
View file

@ -13,10 +13,8 @@ In this document:
* <a href="#_hooks_used_by_gitolite">hooks used by gitolite</a>
* <a href="#_where_do_I_the_admin_put_the_hooks_">**where** do I (the admin) put the hooks?</a>
* <a href="#_the_from_client_method">the "from-client" method</a>
* <a href="#_the_other_3_methods">the other 3 methods</a>
* <a href="#_the_GL_PACKAGE_HOOKS_directory">the `GL_PACKAGE_HOOKS` directory</a>
* <a href="#_the_HOME_gitolite_directory">the `$HOME/.gitolite` directory</a>
* <a href="#_the_GL_PACKAGE_HOOKS_directory">the `GL_PACKAGE_HOOKS` directory</a>
* <a href="#_the_HOME_gitolite_directory">the `$HOME/.gitolite` directory</a>
* <a href="#_why_two_places_">why two places?</a>
* <a href="#_special_case_the_non_root_method">special case: the "non-root" method</a>
* <a href="#_when_do_hooks_propagate_">**when** do hooks propagate?</a>
@ -51,24 +49,9 @@ used.
(Please refer to [doc/1-INSTALL.mkd][0inst] for what these "methods" are).
<a name="_the_from_client_method"></a>
#### the "from-client" method
Let's get this out of the way first, because it is simple: if you're using the
"from-client" method, there's only one place: the `hooks` directory in your
gitolite clone on the client side. This is where you run
`src/gl-easy-install` from. Nothing else in this section is relevant to this
method; skip to the next section ("when do hooks propagate") if you installed
using the "from-client" method.
<a name="_the_other_3_methods"></a>
#### the other 3 methods
<a name="_the_GL_PACKAGE_HOOKS_directory"></a>
##### the `GL_PACKAGE_HOOKS` directory
#### the `GL_PACKAGE_HOOKS` directory
You might recall that the "root", and "non-root" methods run a command called
`gl-system-install`, the third argument of which is some directory of your
@ -87,7 +70,7 @@ place your hooks.
<a name="_the_HOME_gitolite_directory"></a>
##### the `$HOME/.gitolite` directory
#### the `$HOME/.gitolite` directory
You might also recall that, in these three methods, each **hosting user** has
to run `gl-setup`. This sets up, among other things, `$HOME/.gitolite`

279
doc/install-transcript.mkd
View file

@ -1,279 +0,0 @@
# gitolite install transcript
In this document:
* <a href="#_about_this_document">about this document</a>
* <a href="#_create_userids_on_server_and_client_optional_">create userids on server and client (optional)</a>
* <a href="#_get_pubkey_access_from_client_to_server">get pubkey access from client to server</a>
* <a href="#_get_gitolite_source">get gitolite source</a>
* <a href="#_install_gitolite">install gitolite</a>
* <a href="#_VERY_IMPORTANT_">VERY IMPORTANT...</a>
* <a href="#_examine_what_you_have">examine what you have</a>
* <a href="#_emergency_password_access">emergency password access</a>
----
<a name="_about_this_document"></a>
### about this document
This is a *complete* transcript of a full gitolite install, *from scratch*,
using brand new userids ("sita" on the client, "git" on the server). Please
note that you can use existing userids also, it is not necessary to use
dedicated user IDs for this. In particular, people who have a single user
hosting account can also use this method, as long as they have password access
as a fallback if they screw up the keys somewhere. Also, you don't have to
use some *other* server for all this, both server and client can be
"localhost" if you like.
Please note that this entire transcript can be summarised as:
* create users on client and server (optional)
* get pubkey access to server from client (`ssh-copy-id` or manual eqvt)
* run one command ***on client*** (`gl-easy-install`)
...and only that last step is actually gitolite. In fact, the bulk of the
transcript is **non**-gitolite stuff :)
**Please also note that this method will setup everything on the server, but
you have to run it on your workstation, NOT on the server!**
----
<a name="_create_userids_on_server_and_client_optional_"></a>
### create userids on server and client (optional)
Client side: add user, give him a password
sita-lt:~ # useradd sita
sita-lt:~ # passwd sita
Changing password for user sita.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
Server side: (log on to server, then) add user, give it a password
sita-lt:~ # ssh sitaram@server
sitaram@server's password:
Last login: Fri Dec 18 20:25:06 2009
-bash-3.2$ su -
Password:
sita-sv:~ # useradd git
sita-sv:~ # passwd git
Changing password for user git.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
Server side: allow ssh access to "git" user
This is done by editing the sshd config file and adding "git" to the
"AllowUsers" list (the grep command is just confirming the change we made,
because I'm not showing the actual "vi" session):
sita-sv:~ # vim /etc/ssh/sshd_config
sita-sv:~ # grep -i allowusers /etc/ssh/sshd_config
AllowUsers sitaram git
sita-sv:~ # service sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]
**NOTE**: if the `AllowUsers` setting is completely missing from the sshd
config file, all users are allowed (see `man sshd_config`). You may prefer to
leave it that way -- your choice. I prefer to make the usernames explicit
because I'm paranoid ;-)
----
<a name="_get_pubkey_access_from_client_to_server"></a>
### get pubkey access from client to server
This involves creating a keypair for yourself (using `ssh-keygen`), and
copying the public part of that keypair to the `~/.ssh/authorized_keys` file
on the server (using `ssh-copy-id`, if you're on Linux, or the manual method
described in the `ssh-copy-id` section in `doc/3-faq-tips-etc.mkd`).
sita-lt:~ $ su - sita
Password:
sita@sita-lt:~ $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sita/.ssh/id_rsa):
Created directory '/home/sita/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sita/.ssh/id_rsa.
Your public key has been saved in /home/sita/.ssh/id_rsa.pub.
The key fingerprint is:
8a:e0:60:1b:04:58:68:50:a4:d7:d0:3a:a5:2d:bf:0a sita@sita-lt.atc.tcs.com
The key's randomart image is:
+--[ RSA 2048]----+
|===. |
|+o oo |
|o..=. |
|..= . |
|.o.+ S |
|.oo... . |
|E.. ... |
| . . |
| .. |
+-----------------+
sita@sita-lt:~ $ ssh-copy-id -i ~/.ssh/id_rsa.pub git@server
git@server's password:
/usr/bin/xauth: creating new authority file /home/git/.Xauthority
Now try logging into the machine, with "ssh 'git@server'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Double check to make sure you can log on to `git@server` without a password:
sita@sita-lt:~ $ ssh git@server pwd
/home/git
**DO NOT PROCEED UNTIL THIS WORKS OK!**
----
<a name="_get_gitolite_source"></a>
### get gitolite source
sita@sita-lt:~ $ git clone git://github.com/sitaramc/gitolite gitolite-source
Initialized empty Git repository in /home/sita/gitolite-source/.git/
remote: Counting objects: 1157, done.
remote: Compressing objects: 100% (584/584), done.
remote: Total 1157 (delta 756), reused 912 (delta 562)
Receiving objects: 100% (1157/1157), 270.08 KiB | 61 KiB/s, done.
Resolving deltas: 100% (756/756), done.
<a name="_install_gitolite"></a>
### install gitolite
Note that gitolite is installed from the *client*. The `easy-install` script
runs on the client but installs gitolite on the server!
sita@sita-lt:~ $ cd gitolite-source/src
<font color="red"> **This is the only gitolite specific command in a typical
install sequence**. </font> Run it without any arguments to see a usage
message. Run it without the `-q` to get a more verbose, pause-at-every-step,
install mode that allows you to change the defaults (for example, if you want
a different UMASK setting, or you want the repos to be in a different place,
etc.)
sita@sita-lt:src $ ./gl-easy-install -q git server sitaram
you are upgrading (or installing first-time) to v0.95-38-gb0ce84d
setting up keypair...
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sita/.ssh/sitaram.
Your public key has been saved in /home/sita/.ssh/sitaram.pub.
The key fingerprint is:
2a:8e:88:42:36:7e:71:e8:cc:ff:4c:54:64:8e:cf:19 sita@sita-lt.atc.tcs.com
The key's randomart image is:
+--[ RSA 2048]----+
| o |
| = |
| . E |
| + o |
| . .S+ |
| + o ... |
|+ = + .. |
|oo B .o |
|+ o o..o |
+-----------------+
creating gitolite para in ~/.ssh/config...
finding/creating gitolite rc...
installing/upgrading...
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/
Pseudo-terminal will not be allocated because stdin is not a terminal.
fatal: No HEAD commit to compare with (yet)
[master (root-commit) 2f40d4b] start
2 files changed, 13 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/sita/gitolite-admin/.git/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
---------------------------------------------------------------
done!
Reminder:
*Your* URL for cloning any repo on this server will be
gitolite:reponame.git
*Other* users you set up will have to use
git@server:reponame.git
If this is your first time installing gitolite, please also:
tail -31 ./gl-easy-install
for next steps.
----
<a name="_VERY_IMPORTANT_"></a>
### VERY IMPORTANT...
Please read the text that the easy-install command produces as output when you
run it. People who fail to read this get into trouble later. And I didn't
write all that because I wanted to practice typing.
The text just above this section is an approximation; your version will
contain the correct URLs for your install, including port numbers if
non-standard ports were used).
Try out that `tail -31 ./gl-easy-install` too :)
<a name="_examine_what_you_have"></a>
### examine what you have
The last step of the previous command creates a local clone of your
gitolite-admin repo in `~/gitolite-admin`.
sita@sita-lt:src $ cd ~/gitolite-admin/
sita@sita-lt:gitolite-admin $ git --no-pager log --stat
commit 2f40d4bb80d424dc39aae5d0973f8c1b2e395666
Author: git <git@sita-lt.atc.tcs.com>
Date: Thu Dec 24 21:39:15 2009 +0530
start
conf/gitolite.conf | 12 ++++++++++++
keydir/sitaram.pub | 1 +
2 files changed, 13 insertions(+), 0 deletions(-)
And that's really all. Add keys to keydir here, edit conf/gitolite.conf as
needed, then add, commit, and push the changes to the server.
<a name="_emergency_password_access"></a>
### emergency password access
If you lose your keys or the worst happens and you use the wrong key for the
wrong thing and apparently lose all access, but you still know the password,
this is what you do:
sita@sita-lt:~ $ ssh -o preferredauthentications=password git@server
git@server's password:

3
doc/packaging.mkd
View file

@ -30,9 +30,6 @@ location values please):
$GL_PACKAGE_CONF="X";
$GL_PACKAGE_HOOKS="Y";
* delete `src/gl-easy-install`; that script is meant for a totally different
mode of installation and does *not* play well in this mode :-)
**Step 3**: Move (or arrange to move) the files to their proper locations as
given below:

31
doc/progit-article.mkd
View file

@ -18,36 +18,29 @@ Installing Gitolite is very easy, even if you don't read the extensive documenta
Gitolite is somewhat unusual as far as "server" software goes -- access is via ssh, and so every userid on the server is a potential "gitolite host". As a result, there is a notion of "installing" the software itself, and then "setting up" a user as a "gitolite host".
Gitolite has 4 methods of installation. People using Fedora or Debian systems can obtain an RPM or a DEB and install that. People with root access can install it manually. In these two methods, any user on the system can then become a "gitolite host".
People without root access can install it within their own userids. And finally, gitolite can be installed by running a script *on the workstation*, from a bash shell. (Even the bash that comes with msysgit will do, in case you're wondering.)
Gitolite has 3 methods of installation. People using Fedora or Debian systems can obtain an RPM or a DEB and install that. People with root access can install it manually. In these two methods, any user on the system can then become a "hosting user". However, most people don't want/need to install gitolite system-wide -- they can just install it within one specific hosting user.
We will describe this last method in this article; for the other methods please see the documentation.
You start by obtaining public key based access to your server, so that you can log in from your workstation to the server without getting a password prompt. The following method works on Linux; for other workstation OSs you may have to do this manually. We assume you already had a key pair generated using `ssh-keygen`.
To begin, create a user called `git` on your server and login to this user. Copy your ssh pubkey (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaiming it to `YourName.pub`. Then run these commands:
$ ssh-copy-id -i ~/.ssh/id_rsa.pub gitolite@gitserver
git clone git://github.com/sitaramc/gitolite
cd gitolite
src/gl-system-install
gl-setup -q ~/YourName.pub
# for example, I would run 'gl-setup -q ~/sitaram.pub'
This will ask you for the password to the gitolite account, and then set up public key access. This is **essential** for the install script, so check to make sure you can run a command without getting a password prompt:
Finally, back on your workstation, run `git clone git@server:gitolite-admin`.
$ ssh gitolite@gitserver pwd
/home/gitolite
And you're done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your gitolite setup by making changes to this repository and pushing. See [adding users and repos][aur] to start with.
Next, you clone Gitolite from the project's main site and run the "easy install" script (the third argument is your name as you would like it to appear in the resulting gitolite-admin repository):
$ git clone git://github.com/sitaramc/gitolite
$ cd gitolite/src
$ ./gl-easy-install -q gitolite gitserver sitaram
And you're done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in the home directory of your workstation. You administer your gitolite setup by making changes to this repository and pushing.
That last command does produce a fair amount of output, which might be interesting to read. Also, the first time you run this, a new keypair is created; you will have to choose a passphrase or hit enter for none. Why a second keypair is needed, and how it is used, is explained in the "ssh troubleshooting" document that comes with Gitolite. (Hey the documentation has to be good for *something*!)
[aur]: http://sitaramc.github.com/gitolite/doc/2-admin.html#_adding_users_and_repos
<a name="_Customising_the_Install_"></a>
### Customising the Install ###
While the default, quick, install works for most people, there are some ways to customise the install if you need to. If you omit the `-q` argument, you get a "verbose" mode install -- detailed information on what the install is doing at each step. The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an "rc" file that the server uses. This "rc" file is documented in [doc/gitolite.rc.mkd][rcdoc] so you should be able to make any changes you need quite easily, save it, and continue. This file also contains various settings that you can change to enable or disable some of gitolite's advanced features.
While the default, quick, install works for most people, there are some ways to customise the install if you need to. If you omit the `-q` argument, an editor pops up with a file for you to edit, so you can change certain server-side parameters, such as the location of the actual repositories. This "rc" file is documented in [doc/gitolite.rc.mkd][rcdoc] so you should be able to make any changes you need quite easily, save it, and continue.
<a name="_Config_File_and_Access_Control_Rules_"></a>
@ -72,7 +65,7 @@ Once the install is done, you switch to the `gitolite-admin` repository (placed
repo testing
RW+ = @all
Notice that "sitaram" (the last argument in the `gl-easy-install` command you gave earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
Notice that "sitaram" (the name of the pubkey in the gl-setup command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
The config file syntax for gitolite is documented in [doc/gitolite.conf.mkd][confdoc] so we'll only mention some highlights here.

4
doc/report-output.mkd
View file

@ -4,10 +4,6 @@ Running "ssh git@server info" or "ssh git@server expand" gives you certain
output. This doclet describes the output; you're welcome to help me make it
clearer :)
(Side note: if you installed using the "from-client" method, and you're the
administrator, please replace `ssh git@server` with `ssh gitolite`, all
through this document).
In this document:
* <a href="#_the_info_command">the "info" command</a>

8
doc/shell-games.mkd
View file

@ -8,16 +8,14 @@ fixed as and when found.
Thus, settings that have security implications can be set only from the rc
file, which needs to be edited directly on the server. And adding a new hook
requires adding it to the *gitolite* clone and running easy install again, or
gl-setup, if you used the server-side install method, both of which require
shell access.
requires shell access anyway.
While this is great for my main target (corporate environments), some people
don't like it. They want to do all of this from the *gitolite-admin* repo,
because the security concern mentioned above does not bother them. They don't
want to log on to the server to make a change in the rc file or don't want to
run easy install to propagate a new set of hooks. In addition, they may want
all of these animals versioned in the "gitolite-admin" repo itself, which
run gl-setup to propagate a new set of hooks. In addition, they may want all
of these animals versioned in the "gitolite-admin" repo itself, which
certainly makes sense.
So here's how you might do that.

58
doc/ssh-troubleshooting.mkd
View file

@ -73,28 +73,12 @@ and accessing gitolite.
this is an RPM/DEB install, the hosting user is probably called
"gitolite", however we will use "git" in this document.
* If you installed gitolite using the `from-client` method of installation,
then, in the following description, wherever you see `git@server` just
substitute `gitolite`. Example: `git clone git@server:foo` becomes `git
clone gitolite:foo`.
* No changes are required if you installed using one of the other 3
methods.
* Note: to determine which method you used, in case you forgot, run
grep GL_PACKAGE ~/.gitolite.rc
on the server. If there are only two, **commented**, lines, you're
using the `from-client` method.
<a name="_taking_stock_relevant_files_and_directories"></a>
#### taking stock -- relevant files and directories
* the client has a `~/.ssh` containing a few keypairs. It may also have a
`config` file (if you used the [from-client][fc] method of install it
definitely will have one).
`config` file.
* the client also has a clone of the "gitolite-admin" repo, which contains a
bunch of `*.pub` files in `keydir`. We assume this clone is in `$HOME`;
@ -140,12 +124,8 @@ Here's how normal gitolite key handling works:
### (Other resources)
* people who think installing gitolite is too hard should take a look at
this [transcript][] to **see how simple it *actually* is**. This
transcript uses the 'from-client' method of install.
* someone also wrote a tutorial, see [here][tut]. This uses the 'non-root'
method of install, to provide a different perspective.
People who think installing gitolite is too hard should take a look at this
[tutorial][tut] to **see how simple it *actually* is**.
<a name="_common_problems"></a>
@ -225,19 +205,10 @@ We've managed (thanks to an idea from Jesse Keating) to make it possible for a
single key to allow both gitolite access *and* shell access.
This is done by copying the pubkey (to which you want to give shell access) to
the server and running either
cd $HOME/.gitolite # assuming default $GL_ADMINDIR in ~/.gitolite.rc
src/gl-tool shell-add ~/foo.pub
or
the server and running
gl-tool shell-add ~/foo.pub
The first method is applicable if you installed using the **from-client**
method, while the second method is for any of the other three (see
doc/1-INSTALL.mkd, section on "install methods", for more on this)
**IMPORTANT UPGRADE NOTE**: previous implementations of this feature were
crap. There was no easy/elegant way to ensure that someone who had repo admin
access would not manage to get himself shell access.
@ -324,8 +295,8 @@ You have generated a keypair on your workstation (`ssh-keygen`) and copied the
public part of it (`~/.ssh/id_rsa.pub`, by default) to the server.
On the server you have appended this file to `~/.ssh/authorized_keys`. Or you
ran something, like the `gl-setup` or `gl-easy-install` steps during a
gitolite install, which should have done that for you.
ran something, like the `gl-setup` step during a gitolite install, which
should have done that for you.
You now expect to log in without having to type in a password, but when you
try, you are being asked for a password.
@ -422,10 +393,9 @@ need. Be careful:
#### typical cause(s)
For server-based installs (i.e., not the 'from-client' install mode), the
admin often has passwordless shell access to `git@server` already, and then
used that same key to get access to gitolite (i.e., copied that same pubkey as
YourName.pub and gave it to gitolite in some way).
The admin often has passwordless shell access to `git@server` already, and
then used that same key to get access to gitolite (i.e., copied that same
pubkey as YourName.pub and ran `gl-setup` on it).
As a result, the same key appears twice in the authkeys file now, and since
the ssh server will always use the first match, the second occurrence (which
@ -437,10 +407,6 @@ as YourName.pub, then run `gl-setup YourName.pub` on the server. Remember to
adjust your agent identities using ssh-add -D and ssh-add if you're using
ssh-agent, otherwise these new keys may not work.
NOTE: If you installed using the 'from-client' install method, `gl-setup`
won't work. You will have to use the more generic method described
[here][gssp].
<a name="_appendix_3_ssh_client_may_not_be_offering_the_right_key"></a>
### appendix 3: ssh client may not be offering the right key
@ -501,12 +467,6 @@ 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.
----
[doc9gas]: http://sitaramc.github.com/gitolite/doc/gitolite-and-ssh.html

1
src/gitolite.pm
View file

@ -645,7 +645,6 @@ sub parse_acl
die "parse $GL_CONF_COMPILED failed: " . ($! or $@) unless do $GL_CONF_COMPILED;
}
unless (defined($data_version) and $data_version eq $current_data_version) {
# this cannot happen for 'easy-install' cases, by the way...
warn "(INTERNAL: $data_version -> $current_data_version; running gl-setup)\n";
system("$ENV{SHELL} -l -c gl-setup >&2");

6
src/gl-compile-conf
View file

@ -442,10 +442,8 @@ sub do_normal_repos
wrap_chdir($REPO_BASE);
}
# when repos are copied over from elsewhere, one had to run easy install
# once again to make the new (OS-copied) repo contain the proper update
# hook. Perhaps we can make this easier now, and eliminate the easy
# install, with a quick check (and a new, empty, "hook" as a sentinel)
# detect repos copied from elsewhere by absence of (empty)
# sentinel file, and if it doesn't exist run the ln -sf
unless (-l "$repo.git/hooks/gitolite-hooked") {
ln_sf("$GL_ADMINDIR/hooks/common", "*", "$repo.git/hooks");
# in case of package install, GL_ADMINDIR is no longer the top cop;

655
src/gl-easy-install
View file

@ -1,655 +0,0 @@
#!/bin/bash
# easy install for gitolite
# you run this on the client side, and it takes care of all the server side
# work. You don't have to do anything on the server side directly
# to do a manual install (since I have tested this only on Linux), open this
# script in a nice, syntax coloring, text editor and follow the instructions
# prefixed by the word "MANUAL" in the comments below :-)
# run without any arguments for "usage" info
# important setting: bail on any errors (else we have to check every single
# command!)
set -e
# ----------------------------------------------------------------------
# bootstrap and main
# ----------------------------------------------------------------------
if [[ $1 != boot/strap ]]
then
# did someone tell you you can't call functions before they're defined in
# bash? Don't believe everything you hear ;-)
. $0 boot/strap
main "$@"
cleanup
exit 0
fi
# ----------------------------------------------------------------------
# no direct executable statements after this; only functions
# ----------------------------------------------------------------------
main() {
basic_sanity "$@"
setup_tempdir
version_info "$@"
[[ -n $admin_name ]] && setup_local_ssh
copy_gl # src, conf, etc
run_install
[[ $upgrade == 0 ]] && initial_conf_key
# MANUAL: cd to $GL_ADMINDIR and run "src/gl-compile-conf"
ssh $p_port $user@$host "cd $GL_ADMINDIR; src/gl-auth-command -e src/gl-compile-conf $quiet"
setup_pta
clone_it
}
# ----------------------------------------------------------------------
# setup temp files
# ----------------------------------------------------------------------
setup_tempdir() {
export tmpgli=tmp-gl-install
trap cleanup 0
mkdir -p $tmpgli
}
cleanup() {
[ $? -eq 0 ] || {
printf "\n\n\t\t**ABORTED**\n\n"
printf "Please check messages above carefully, fix whatever is needed, and try again.\n"
printf "Note that the problem may be on the server, not necessarily on the client.\n\n"
}
rm -rf $tmpgli
}
# ----------------------------------------------------------------------
# service functions
# ----------------------------------------------------------------------
die() { echo "$@"; echo; echo "run $0 without any arguments for help and tips"; cleanup; exit 1; } >&2
prompt() {
# receives two arguments. A short piece of text to be displayed, without
# pausing, in "quiet" mode, and a much longer one to be displayed, *with*
# a pause, in normal (verbose) mode
[[ $quiet == -q ]] && [[ -n $1 ]] && {
eval "echo \"$1\""
return
}
shift
echo
echo
echo ------------------------------------------------------------------------
eval "echo \"$1\""
echo
read -p '...press enter to continue or Ctrl-C to bail out'
}
usage() {
cat <<EOFU
Usage: $0 [-q] user host [port] admin_name # install
$0 [-q] user host [port] # upgrade
- (optional) "-q" as first arg sets "quiet" mode: no verbose descriptions of
what is going on, no pauses unless absolutely necessary
- "user" is the username on the server where you will be installing gitolite
- "host" is that server's hostname (or IP address)
- "port" is the ssh server port on "host"; optional, defaults to 22
- "admin_name" is *your* name as it should appear in the eventual gitolite
config file. For upgrades (ie., gitolite is already installed on the
server), this argument is not needed, and will be *ignored* if provided.
- (optional) "host_nickname" is a nickname that can be given to a particular
installation of gitolite. This allows for multiple servers to easily be
administered from this machine. Defaults to "gitolite"
Example usage: $0 git my.git.server sitaram [gitolite_server_1]
Notes:
- "user","admin_name" and "host_nickname" must be simple names -- no
special characters etc please (only alphanumerics, dot, hyphen,
underscore)
- traditionally, the "user" is "git", but it can be anything you want
- "admin_name" should be your name, for clarity, or whoever will be the
gitolite admin
Pre-requisites:
- you must already have pubkey based access to user@host. If you currently
only have password access, use "ssh-copy-id" or something equivalent (or
copy the key manually). Somehow (doesn't matter how), get to the point
where you can type "ssh user@host" and get a command line.
**DO NOT RUN THIS PROGRAM UNTIL THAT WORKS**
EOFU
exit 1;
}
# ----------------------------------------------------------------------
# basic sanity / argument checks
# ----------------------------------------------------------------------
basic_sanity() {
# MANUAL: this *must* be run as "src/gl-easy-install", not by cd-ing to
# src and then running "./gl-easy-install"
bindir=${0%/*}
# switch to parent of bindir; we assume the conf files are all there
cd "$bindir"; cd ..
# are we in quiet mode?
quiet=
[[ "$1" == "-q" ]] && {
quiet=-q
shift
}
# MANUAL: (info) we'll use "git" as the user, "server" as the host, and
# "sitaram" as the admin_name in example commands shown below, if any
[[ -z $2 ]] && usage
user=$1
host=$2
port=22
admin_name=$3
host_nickname=$4
if [ -z $4 ]
then
host_nickname="gitolite"
fi
# but if the 3rd arg is a number, that's a port number, and the 4th arg is
# the admin_name
if echo $3 | perl -lne 'exit 1 unless /^[0-9]+$/'
then
port=$3
admin_name=$4
host_nickname=$5
if [ -z $5 ]
then
host_nickname=gitolite
fi
fi
echo $user | perl -lne 'exit 1 if /[^a-zA-Z0-9._-]/' ||
die "user '$user' invalid"
[[ "$user" == "root" ]] && die I refuse to install to root
echo $admin_name | perl -lne 'exit 1 if /[^a-zA-Z0-9._-]/' ||
die "admin_name '$admin_name' invalid"
echo $host_nickname | perl -lne 'exit 1 if /[^a-zA-Z0-9._-]/' ||
die "host nickname '$host_nickname' invalid"
# MANUAL: make sure you're in the gitolite directory, at the top level.
# The following files should all be visible:
ls hooks/gitolite-admin/post-update \
hooks/common/update \
src/gitolite.pm \
src/gl-install \
src/gl-auth-command \
src/gl-compile-conf \
conf/example.conf \
conf/example.gitolite.rc >/dev/null ||
die "cant find at least some files in gitolite sources/config; aborting"
# MANUAL: make sure you have password-less (pubkey) auth on the server.
# That is, running "ssh git@server" should log in straight away, without
# asking for a password
[[ $port -ne 22 ]] && p_port="-p $port"
ssh $p_port -o PasswordAuthentication=no $user@$host true ||
die "pubkey access didn't work; please set it up using 'ssh-copy-id' or something"
}
# ----------------------------------------------------------------------
# version info
# ----------------------------------------------------------------------
version_info() {
# MANUAL: if needed, make a note of the version you are upgrading from, and to
# record which version is being sent across; we assume it's HEAD
if git rev-parse --is-inside-work-tree >/dev/null 2>&1
then
git describe --tags --long HEAD 2>/dev/null > conf/VERSION || echo '(unknown)' > conf/VERSION
else
[[ -f conf/VERSION ]] || echo '(unknown)' > conf/VERSION
fi
# what was the old version there?
export upgrade_details="you are upgrading \
$(ssh $p_port $user@$host cat gitolite-install/conf/VERSION 2>/dev/null || echo '(or installing first-time)' ) \
to $(cat conf/VERSION)"
prompt "$upgrade_details" "$v_upgrade_details"
}
# ----------------------------------------------------------------------
# new keypair, ssh-config para; only on "install" (not upgrade)
# ----------------------------------------------------------------------
setup_local_ssh() {
# MANUAL: create a new key for you as a "gitolite user" (as opposed to you
# as the "gitolite admin" who needs to login to the server and get a
# command line). For example, "ssh-keygen -t rsa ~/.ssh/sitaram"; this
# would create two files in ~/.ssh (sitaram and sitaram.pub)
prompt "setting up keypair..." "$v_setting_up_keypair"
if [[ -f "$HOME/.ssh/$admin_name.pub" ]]
then
prompt "" "$v_reuse_pubkey"
else
ssh-keygen -t rsa -f "$HOME/.ssh/$admin_name" || die "ssh-keygen failed for some reason..."
fi
# MANUAL: copy the pubkey created to the server, say to /tmp. This would
# be "scp ~/.ssh/sitaram.pub git@server:/tmp" (the script does this at a
# later stage, you do it now for convenience). Note: only the pubkey
# (sitaram.pub). Do NOT copy the ~/.ssh/sitaram file -- that is a private
# key!
# MANUAL: if you're running ssh-agent (see if you have an environment
# variable called SSH_AGENT_PID in your "env"), you should add this new
# key. The command is "ssh-add ~/.ssh/sitaram"
if ssh-add -l &>/dev/null
then
prompt " ...adding key to agent..." "$v_ssh_add"
ssh-add "$HOME/.ssh/$admin_name"
fi
# MANUAL: you now need to add some lines to the end of your ~/.ssh/config
# file. If the file doesn't exist, create it. Make sure the file is
# "chmod 644".
# The lines to be included look like this:
# host gitolite
# user git
# hostname server
# port 22
# identityfile ~/.ssh/sitaram
echo "host $host_nickname
user $user
hostname $host
port $port
identityfile ~/.ssh/$admin_name" > $tmpgli/.gl-stanza
if grep "host *$host_nickname" "$HOME/.ssh/config" &>/dev/null
then
prompt "found gitolite para in ~/.ssh/config; assuming it is correct..." "$v_found_para"
else
prompt "creating gitolite para in ~/.ssh/config..." "$v_creating_para"
cat $tmpgli/.gl-stanza >> "$HOME/.ssh/config"
# if the file didn't exist at all, it might have the wrong permissions
chmod 644 "$HOME/.ssh/config"
fi
}
# ----------------------------------------------------------------------
# server side
# ----------------------------------------------------------------------
copy_gl() {
# MANUAL: copy the gitolite directories "src", "conf", and "doc" to the
# server, to a directory called (for example) "gitolite-install". You may
# have to create the directory first.
ssh $p_port $user@$host mkdir -p gitolite-install
scp $quiet ${p_port/p/P} -p -r src conf doc hooks $user@$host:gitolite-install/
# MANUAL: now log on to the server (ssh git@server) and get a command
# line. This step is for your convenience; the script does it all from
# the client side but that may be too much typing for manual use ;-)
# MANUAL: cd to the "gitolite-install" directory where the sources are.
# Then copy conf/example.gitolite.rc as ~/.gitolite.rc and edit it if you
# wish to change any paths. Make a note of the GL_ADMINDIR and REPO_BASE
# paths; you will need them later
prompt "finding/creating gitolite rc..." "$v_edit_glrc"
# lets try and get the file from there first
if scp ${p_port/p/P} $user@$host:.gitolite.rc $tmpgli &>/dev/null
then
prompt " ...trying to reuse existing rc" \
"Oh hey... you already had a '.gitolite.rc' file on the server.
Let's see if we can use that instead of the default one..."
< $tmpgli/.gitolite.rc perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' | sort > $tmpgli/glrc.old
< conf/example.gitolite.rc perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' | sort > $tmpgli/glrc.new
# msysgit doesn't have "comm". diff is not ideal for our purposes
# because we only care about differences in one direction, but we'll
# have to make do...
set +e
diff -u $tmpgli/glrc.old $tmpgli/glrc.new | grep '^+.*\$' > $tmpgli/glrc.comm13
set -e
if [[ ! -s $tmpgli/glrc.comm13 ]]
then
[[ $quiet == -q ]] || ${VISUAL:-${EDITOR:-vi}} $tmpgli/.gitolite.rc
else
echo new variables found in rc file:
cat $tmpgli/glrc.comm13
echo
# MANUAL: if you're upgrading, read the instructions below and
# manually make sure your final ~/.gitolite.rc has both your existing
# customisations as well as any new variables that the new version of
# gitolite has introduced
prompt "" "$v_upgrade_glrc"
${VISUAL:-${EDITOR:-vi}} conf/example.gitolite.rc $tmpgli/.gitolite.rc
fi
else
cp conf/example.gitolite.rc $tmpgli/.gitolite.rc
[[ $quiet == -q ]] || ${VISUAL:-${EDITOR:-vi}} $tmpgli/.gitolite.rc
fi
# copy the rc across
scp $quiet ${p_port/p/P} $tmpgli/.gitolite.rc $user@$host:
}
run_install() {
prompt "installing/upgrading..." "$v_ignore_stuff"
# extract the GL_ADMINDIR, REPO_BASE and GIT_PATH locations
GL_ADMINDIR=$(ssh $p_port $user@$host gitolite-install/src/gl-query-rc GL_ADMINDIR)
REPO_BASE=$( ssh $p_port $user@$host gitolite-install/src/gl-query-rc REPO_BASE)
GIT_PATH=$( ssh $p_port $user@$host gitolite-install/src/gl-query-rc GIT_PATH)
# determine if this is an upgrade; we decide based on whether a file
# called $GL_ADMINDIR/conf/gitolite.conf exists on the remote side. We
# can't do this till we know the correct value for GL_ADMINDIR
upgrade=0
if ssh $p_port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf &> /dev/null
then
upgrade=1
ssh $p_port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf 2> /dev/null | grep '@SHELL' &&
prompt "" "$v_at_shell_bwi"
[[ -n $admin_name ]] && echo -e "\n *** WARNING ***: looks like an upgrade... ignoring argument '$admin_name'"
else
[[ -z $admin_name ]] && die " *** ERROR ***: doesn't look like an upgrade, so I need a name for the admin"
fi
# MANUAL: still in the "gitolite-install" directory? Good. Run
# "src/gl-install"
ssh $p_port $user@$host "cd gitolite-install; src/gl-auth-command -e src/gl-install $quiet"
# MANUAL: if you're upgrading, run "src/gl-compile-conf" and you're done!
# -- ignore the rest of this file for the purposes of an upgrade
}
# ----------------------------------------------------------------------
# from here on it's install only
# ----------------------------------------------------------------------
# MANUAL: setup the initial config file. Edit $GL_ADMINDIR/conf/gitolite.conf
# and add at least the following lines to it:
# repo gitolite-admin
# RW+ = sitaram
initial_conf_key() {
echo "#gitolite conf
# please see doc/gitolite.conf.mkd for details on syntax and features
repo gitolite-admin
RW+ = $admin_name
repo testing
RW+ = @all
" > $tmpgli/gitolite.conf
# send the config and the key to the remote
scp $quiet ${p_port/p/P} $tmpgli/gitolite.conf $user@$host:$GL_ADMINDIR/conf/
scp $quiet ${p_port/p/P} "$HOME/.ssh/$admin_name.pub" $user@$host:$GL_ADMINDIR/keydir
}
# ----------------------------------------------------------------------
# hey lets go the whole hog on this; setup push-to-admin!
# ----------------------------------------------------------------------
setup_pta() {
# MANUAL: you have to now make the first commit in the admin repo. This
# is a little more complex, so read carefully and substitute the correct
# paths. What you have to do is:
# cd $REPO_BASE/gitolite-admin.git
# GIT_WORK_TREE=$GL_ADMINDIR git add conf/gitolite.conf keydir
# GIT_WORK_TREE=$GL_ADMINDIR git commit -am start
# Substitute $GL_ADMINDIR and $REPO_BASE appropriately. Note there is no
# space around the "=" in the second and third lines.
echo "cd $REPO_BASE/gitolite-admin.git
PATH=\$PATH:$GIT_PATH
git config --get user.email || git config user.email \$USER@\`hostname\`
git config --get user.name || git config user.name \"\$USER on \`hostname\`\"
GIT_WORK_TREE=$GL_ADMINDIR git add conf/gitolite.conf keydir
GIT_WORK_TREE=$GL_ADMINDIR git diff --cached --quiet 2>/dev/null || GIT_WORK_TREE=$GL_ADMINDIR git commit -am start
" | ssh -T $p_port $user@$host
# MANUAL: now that the admin repo is created, you have to set the hooks
# properly. The install program does this. So cd back to the
# "gitolite-install" directory and run "src/gl-install"
ssh $p_port $user@$host "cd gitolite-install; src/gl-auth-command -e src/gl-install $quiet"
# MANUAL: you're done! Log out of the server, come back to your
# workstation, and clone the admin repo using "git clone
# gitolite:gitolite-admin", or pull once again if you already have a
# clone
}
clone_it()
{
cleanup
cd "$HOME"
if [[ -d $host_nickname-admin ]]
then
echo $HOME/$host_nickname-admin exists, skipping clone step...
else
prompt "cloning $host_nickname-admin repo..." "$v_cloning"
git clone $host_nickname:gitolite-admin $host_nickname-admin
fi
# MANUAL: be sure to read the message below; this applies to you too...
echo
echo
echo ---------------------------------------------------------------
eval "echo \"$v_done\""
}
# ----------------------------------------------------------------------
# prompt strings
# ----------------------------------------------------------------------
v_upgrade_details="
\$upgrade_details
Note: getting '(unknown)' for the 'from' version should only happen once.
Getting '(unknown)' for the 'to' version means you are probably installing
from a tar file dump, not a real clone. This is not an error but it's nice to
have those version numbers in case you need support. Try and install from a
clone
"
v_setting_up_keypair="
the next command will create a new keypair for your gitolite access
The pubkey will be \$HOME/.ssh/\$admin_name.pub. You will have to choose a
passphrase or hit enter for none. I recommend not having a passphrase for
now, *especially* if you do not have a passphrase for the key which you are
already using to get server access!
Add one using 'ssh-keygen -p' after all the setup is done and you've
successfully cloned and pushed the gitolite-admin repo. After that, install
'keychain' or something similar, and add the following command to your bashrc
(since this is a non-default key)
ssh-add "\\\$HOME/.ssh/\$admin_name"
This makes using passphrases very convenient.
"
v_reuse_pubkey="
Hmmm... pubkey \$HOME/.ssh/\$admin_name.pub exists; should I just (re-)use it?
IMPORTANT: once the install completes, *this* key can no longer be used to get
a command line on the server -- it will be used by gitolite, for git access
only. If that is a problem, please ABORT now.
doc/ssh-troubleshooting.mkd will explain what is happening here, if you need
more info.
"
v_ssh_add="
you're running ssh-agent. We'll try and do an ssh-add of the
private key we just created, otherwise this key won't get picked up. If
you specified a passphrase in the previous step, you'll get asked for one
now -- type in the same one.
"
v_found_para="
your \\\$HOME/.ssh/config already has settings for gitolite. I will assume
they're correct, but if they're not, please edit that file, delete that
paragraph (that line and the following few lines), Ctrl-C, and rerun.
In case you want to check right now (from another terminal) if they're
correct, here's what they are *supposed* to look like:
\$(cat \$tmpgli/.gl-stanza)
"
v_creating_para="
creating settings for your gitolite access in \$HOME/.ssh/config;
these are the lines that will be appended to your ~/.ssh/config:
\$(cat \$tmpgli/.gl-stanza)
"
v_edit_glrc="
the gitolite rc file needs to be edited by hand. The defaults are sensible,
so if you wish, you can just exit the editor.
Otherwise, make any changes you wish and save it. Read the comments to
understand what is what -- the rc file's documentation is inline.
Please remember this file will actually be copied to the server, and that all
the paths etc. represent paths on the server!
"
v_upgrade_glrc="
looks like you're upgrading, and there are some new rc variables that this
version is expecting that your old rc file doesn't have.
I'm going to run your \\\$EDITOR with two filenames. The first is the example
file from this gitolite version. It will have a block (code and comments) for
each of the variables shown above with a '+' sign.
The second is your current rc file, the destination. Copy those lines into
this file, preferably *with* the surrounding comments (for clarity) and save
it.
This is necessary; please dont skip this!
[It's upto you to figure out how your \\\$EDITOR handles 2 filename arguments,
switch between them, copy lines, etc ;-)]
"
v_ignore_stuff="
ignore any 'please edit this file' or 'run this command' type lines in the
next set of command outputs coming up. They're only relevant for a manual
install, not this one...
"
v_at_shell_bwi="
you are using the @SHELL feature in your gitolite config. This feature has
now changed in a backward incompatible way; see doc/ssh-troubleshooting.mkd
for information on migrating this to the new syntax.
DO NOT hit enter unless you have understood that information and properly
migrated your setup, or you are sure you have shell access to the server
through some other means than the $admin_name key.
"
v_done="
done!
IMPORTANT NOTE -- PLEASE READ!!!
*Your* URL for cloning any repo from this server will be
\$host_nickname:reponame.git
Note: If you are upgrading and you set a host nickname during initial
setup, please use that host nickname instead of \"gitolite\"
above.
*Other* users you set up will have to use
\$user@\$host:reponame.git
However, if your server uses a non-standard ssh port, they should use
ssh://\$user@\$host:\$port/reponame.git
If this is your first time installing gitolite, please also:
tail -31 \$0
for next steps.
"
v_cloning="
now we will clone the gitolite-admin repo to your workstation and see if it
all hangs together. We'll do this in your \\\$HOME for now, and you can move
it elsewhere later if you wish to.
"
tail="
NOTE: All the below stuff is on your *workstation*. You should not, normally,
have to do anything directly on your server to administer/use gitolite.
The admin repo is currently cloned at ~/gitolite-admin. You can reclone it
anywhere else if you wish. To administer gitolite, make changes to the config
file (conf/gitolite.conf) and/or the pubkeys (in subdirectory 'keydir') in any
clone, then git add, git commit, and git push.
ADDING REPOS: Do NOT add repos manually on the server. Edit the config file
to give *some* user access to the repo. When you push, an empty repo will be
created on the server.
ADDING USERS: copy their pubkey as keydir/<username>.pub, add it, commit and
push.
CONFIG FILE FORMAT: see doc/gitolite.conf.mkd
SSH MAGIC: Remember you (the admin) now have *two* keys to access the server
hosting your gitolite setup -- one to get you a command line, and one to get
you gitolite access; see doc/ssh-troubleshooting.mkd. If you're not using
keychain or some such software, you may have to run an 'ssh-add' command to
add that key each time you log in.
URLS: *Your* URL for cloning any repo on this server is different from the
url that the *other* users have to use. The easy install command should tell
you what these URLs look like, at the end of each successful run. Feel free
to re-run easy install again (using the same arguments) if you missed it.
UPGRADING GITOLITE: just pull a fresh clone from github, and run the same easy
install command as before, with the same arguments.
"

2
src/gl-install
View file

@ -112,7 +112,7 @@ if ( -d "gitolite-admin.git/hooks" ) {
}
# fixup program renames
for my $oldname (qw(pta-hook.sh conf-convert.pl 00-easy-install.sh 99-emergency-addkey.sh gl-emergency-addkey install.pl update-hook.pl hooks/update ga-post-update-hook VERSION)) {
for my $oldname (qw(pta-hook.sh conf-convert.pl 00-easy-install.sh gl-easy-install 99-emergency-addkey.sh gl-emergency-addkey install.pl update-hook.pl hooks/update ga-post-update-hook VERSION)) {
unlink "$GL_ADMINDIR/src/$oldname";
unlink "$ENV{HOME}/gitolite-install/src/$oldname";
}

2
src/gl-setup-authkeys
View file

@ -47,7 +47,7 @@ unless ($batch) {
one that is in the same directory as that used by gl-auth-command (and for
what that is, see ~/.ssh/authorized_keys).
Except for the deprecated 'from-client' install mode, this should work:
This should work:
gl-setup-authkeys -batch keydir

1
src/gl-system-install
View file

@ -64,7 +64,6 @@ bindir=`echo $0 | perl -lpe 's/^/$ENV{PWD}\// unless /^\//; s/\/[^\/]+$//;'`
cd $bindir/.. # we assume the standard gitolite source tree is here!
cp src/* $buildroot$gl_bin_dir || die "cp src/* to $buildroot$gl_bin_dir failed"
rm $buildroot$gl_bin_dir/gl-easy-install
perl -lpi -e "s(^GL_PACKAGE_CONF=.*)(GL_PACKAGE_CONF=$gl_conf_dir)" $buildroot$gl_bin_dir/gl-setup
# record which version is being sent across; we assume it's HEAD