diff --git a/contrib/gitweb/gitweb.conf b/contrib/gitweb/gitweb.conf index c88e4cc..726486e 100644 --- a/contrib/gitweb/gitweb.conf +++ b/contrib/gitweb/gitweb.conf @@ -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: diff --git a/doc/1-INSTALL.mkd b/doc/1-INSTALL.mkd index ab5584e..d8a41db 100644 --- a/doc/1-INSTALL.mkd +++ b/doc/1-INSTALL.mkd @@ -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 @@ -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. diff --git a/doc/2-admin.mkd b/doc/2-admin.mkd index aa29580..293bad9 100644 --- a/doc/2-admin.mkd +++ b/doc/2-admin.mkd @@ -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 diff --git a/doc/3-faq-tips-etc.mkd b/doc/3-faq-tips-etc.mkd index 5bccc38..0325ca5 100644 --- a/doc/3-faq-tips-etc.mkd +++ b/doc/3-faq-tips-etc.mkd @@ -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 diff --git a/doc/hook-propagation.mkd b/doc/hook-propagation.mkd index 318c7e7..9401239 100644 --- a/doc/hook-propagation.mkd +++ b/doc/hook-propagation.mkd @@ -13,10 +13,8 @@ In this document: * hooks used by gitolite * **where** do I (the admin) put the hooks? - * the "from-client" method - * the other 3 methods - * the `GL_PACKAGE_HOOKS` directory - * the `$HOME/.gitolite` directory + * the `GL_PACKAGE_HOOKS` directory + * the `$HOME/.gitolite` directory * why two places? * special case: the "non-root" method * **when** do hooks propagate? @@ -51,24 +49,9 @@ used. (Please refer to [doc/1-INSTALL.mkd][0inst] for what these "methods" are). - - -#### 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. - - - -#### the other 3 methods - -##### 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. -##### 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` diff --git a/doc/install-transcript.mkd b/doc/install-transcript.mkd deleted file mode 100644 index 178ba1a..0000000 --- a/doc/install-transcript.mkd +++ /dev/null @@ -1,279 +0,0 @@ -# gitolite install transcript - -In this document: - - * about this document - * create userids on server and client (optional) - * get pubkey access from client to server - * get gitolite source - * install gitolite - * VERY IMPORTANT... - * examine what you have - * emergency password access - ----- - - - -### 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!** - ----- - - - -### 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 ;-) - ----- - - - -### 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!** - ----- - - - -### 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. - - - -### 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 - - **This is the only gitolite specific command in a typical -install sequence**. 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. - ----- - - - -### 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 :) - - - -### 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 - 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. - - - -### 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: diff --git a/doc/packaging.mkd b/doc/packaging.mkd index c3c4b56..1bc548e 100644 --- a/doc/packaging.mkd +++ b/doc/packaging.mkd @@ -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: diff --git a/doc/progit-article.mkd b/doc/progit-article.mkd index f539867..338143d 100644 --- a/doc/progit-article.mkd +++ b/doc/progit-article.mkd @@ -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 ### 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. @@ -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. diff --git a/doc/report-output.mkd b/doc/report-output.mkd index 9aa5475..3872a18 100644 --- a/doc/report-output.mkd +++ b/doc/report-output.mkd @@ -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: * the "info" command diff --git a/doc/shell-games.mkd b/doc/shell-games.mkd index d8250cf..0775756 100644 --- a/doc/shell-games.mkd +++ b/doc/shell-games.mkd @@ -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. diff --git a/doc/ssh-troubleshooting.mkd b/doc/ssh-troubleshooting.mkd index 64500a7..fc063f9 100644 --- a/doc/ssh-troubleshooting.mkd +++ b/doc/ssh-troubleshooting.mkd @@ -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. - #### 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**. @@ -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]. - ### 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 diff --git a/src/gitolite.pm b/src/gitolite.pm index 5d6d8bb..85ee660 100644 --- a/src/gitolite.pm +++ b/src/gitolite.pm @@ -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"); diff --git a/src/gl-compile-conf b/src/gl-compile-conf index 2d4110f..18d85c6 100755 --- a/src/gl-compile-conf +++ b/src/gl-compile-conf @@ -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; diff --git a/src/gl-easy-install b/src/gl-easy-install deleted file mode 100755 index 7b6b062..0000000 --- a/src/gl-easy-install +++ /dev/null @@ -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 </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/.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. -" diff --git a/src/gl-install b/src/gl-install index 231a37d..de7aefd 100755 --- a/src/gl-install +++ b/src/gl-install @@ -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"; } diff --git a/src/gl-setup-authkeys b/src/gl-setup-authkeys index afedf33..6a3d9db 100755 --- a/src/gl-setup-authkeys +++ b/src/gl-setup-authkeys @@ -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 diff --git a/src/gl-system-install b/src/gl-system-install index ce328d4..3fec38d 100755 --- a/src/gl-system-install +++ b/src/gl-system-install @@ -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