gitolite/doc/install.mkd

218 lines
7.5 KiB
Markdown
Raw Normal View History

# installing gitolite
2012-03-16 02:54:47 +01:00
<font color="red">**NOTE**: if you're migrating from g2, there are some
settings that MUST be dealt with **before** running `gitolite setup`; please
start [here][migr]. RTFM is *mandatory* for migrations.</font>
## notes and naming conventions
Gitolite uses a single "real" (i.e., unix) user to provide secure access to
git repos to any number of "virtual" users, without giving them a shell.
The real user used is called the **hosting user**. Typically this user is
*git*, and that is what we will use throughout the documentation. However
RPMs and DEBs create a user called *gitolite* for this, so adjust instructions
and examples accordingly.
Notes:
* Any unix user can be a hosting user.
* Which also means you can have several hosting users on the same machine.
* The URLs used will be of the form `git@host:reponame` (or its longer
equivalent starting with `ssh://`). The `.git` at the end is optional. I
recommend you leave it out, so your reponames are consistent with what the
conf file uses.
## #req requirements
### your skills
* If you're installing gitolite, you're a "system admin", like it or not.
Ssh is therefore a necessary skill. Please take the time to learn at
least enough to get passwordless access working.
* You also need to be somewhat familiar with git itself. You cannot
administer a whole bunch of git repositories if you don't know the basics
of git.
* Some familiarity with Unix and shells is probably required.
* Regular expressions are a big part of gitolite in many places but
familiarity is not necessary to do *basic* access control.
### server
* any Unix system with a posix compatible "sh".
* git version 1.6.6 or later
* perl 5.8.8 or later
2012-04-15 07:47:44 +02:00
* openssh (almost any version). Optional if you're using [smart http][http]
* a dedicated Unix userid to be the hosting user, usually "git" but it can
be any user, even your own normal one. (If you're using an RPM/DEB the
install probably created one called "gitolite").
Also see the [WARNINGS][] page for more on what gitolite expects on the server
side.
### client
* openssh client
* git 1.6.6 or later. Almost any git client will work, as long as it knows
how to use ssh keys and send the right one along.
## getting the software
git clone -b g3 git://github.com/sitaramc/gitolite
The -b g3' is needed until g3 becomes "master". Current estimates put this
around June 2012, when the old gitolite (upto v2.x) will be retired and
supported only for security issues.
## the actual install
Gitolite has only one server side "command" now, much like git itself. This
command is `gitolite`. You don't need to place it anywhere special; worst
case you run it with the full path.
2012-03-27 08:01:02 +02:00
"Installation" consists of the following options:
2012-03-16 02:54:47 +01:00
1. Keep the sources anywhere and use the full path to run the `gitolite`
command.
2. Keep the sources anywhere and symlink *just* the `gitolite` program to
some directory on your `$PATH`.
3. Copy the sources somewhere and use that path to run the `gitolite`
command.
2012-03-16 02:54:47 +01:00
Option 2 is the best for general use.
2012-03-16 02:54:47 +01:00
There is a program called 'install' that helps you do these easily. Assuming
your cloned the repo like this:
2012-03-16 02:54:47 +01:00
git clone -b g3 git://github.com/sitaramc/gitolite
2012-03-16 02:54:47 +01:00
you can run the 'install' command in 3 different ways:
2012-03-16 02:54:47 +01:00
# option 1
gitolite/install
2012-03-16 02:54:47 +01:00
# option 2
gitolite/install -ln
# defaults to $HOME/bin, or use a specific directory:
gitolite/install -ln /usr/local/bin
2012-03-16 02:54:47 +01:00
# option 3
gitolite/install -to /usr/local/gitolite/bin
2012-03-16 02:54:47 +01:00
Creating a symlink doesn't need a separate program but 'install' also runs
`git describe` to create a VERSION file, which, trust me, is important!
2012-03-16 02:54:47 +01:00
**Next step**: run [**setup**][setup].
## upgrading
* Update your clone of the gitolite source.
* Repeat the install command you used earlier (make sure you use the same
arguments as before).
2012-04-14 09:15:53 +02:00
* Run `gitolite setup`.
## packaging gitolite
2012-03-16 02:54:47 +01:00
2012-04-14 09:15:53 +02:00
Here are the requirements for gitolite:
2012-03-16 02:54:47 +01:00
2012-04-14 09:15:53 +02:00
* The programs `gitolite` and `gitolite-shell`, and the directories
`commands`, `lib`, `syntactic-sugar`, `triggers`, and `VREF` must all be
in the same directory.
2012-03-16 02:54:47 +01:00
2012-04-14 09:15:53 +02:00
It doesn't matter what this directory is. As an example, Fedora keeps
git's 150 executables in /usr/libexec/git-core, so /usr/libexec/gitolite
may be a good choice; it's upto you.
2012-03-16 02:54:47 +01:00
2012-04-14 09:15:53 +02:00
The rest of this section will assume you chose /usr/libexec/gitolite as
the location. Adjust as needed.
2012-03-16 02:54:47 +01:00
2012-04-14 09:15:53 +02:00
* The program `/usr/libexec/gitolite/gitolite` must then be *symlinked* to
some directory in the PATH. Do not *copy* it; it must be a symlink.
* The `Gitolite` subdirectory in `/usr/libexec/gitolite/lib` can stay there,
**OR**, if your distro policies don't allow that, can be put in any
directory in perl's `@INC` path (such as `/usr/share/perl5/vendor_perl`).
* Finally, a file called `/usr/libexec/gitolite/VERSION` must contain a
suitable version string.
2012-03-16 02:54:47 +01:00
## #migr migrating
2012-03-16 02:54:47 +01:00
<font color="gray">If you're migrating from gitosis, [this][gsmigr] is what
you want to start with.</font>
2012-03-16 02:54:47 +01:00
First things first: g2 will be supported for a good long time for critical
bugs, although enhancements and new features won't happen.
If you're an existing (gitolite v1.x or v2.x) user, and wish to migrate , here
are the steps:
### pre-migration
1. Check the [dev-status][] page to make sure all the features you want have
been implemented in g3.
2. Read the [g2 migration][g2migr] page to see what changes affect you and
your users, and how much time it might take you to migrate. (The closer
you were to a default install of the old gitolite, the less time a
migration will take.)
### migration
**Note**: nothing in any of the gitolite install/setup/etc will ever touch the
*data* in any repository except the gitolite-admin repo. The only thing it
will normally touch in normal repos is the `update` hook.
1. Carefully wipe out the old gitolite
* the **code**
* delete or move away all the old gitolite scripts. Check the path
to the gl-auth-command in `~/.ssh/authorized_keys` if you forgot
where you put them.
* delete or move away the two directories named in the two variables
`GL_PACKAGE_CONF` and `GL_PACKAGE_HOOKS` in `~/.gitolite.rc`
* the **rc file**
* rename `~/.gitolite.rc` to something else
* the **admin repo**
* clone `~/repositories/gitolite-admin.git` to someplace safe
* then delete `~/repositories/gitolite-admin.git`
(make sure you do not delete any other repos!)
* the **admin directory**
* if you need to preserve logs, move the ~/.gitolite/logs` directory
somewhere else
* if you added any custom hooks and wish to preserve them, move the
~/.gitolite/hooks` directory somewhere else
* delete `~/.gitolite`
2. Read about [presetting][rc-preset] the rc file; if you're using any
variables listed as requiring preset, follow those instructions to create
your new rc file.
3. Install gitolite g3; see [quick install and setup][qi] or [install][]
followed by [setup][].
4. Make sure your gitolite-admin clone has the correct pubkey for the
administrator in its `keydir` directory, then `git push -f` to the server
to overwrite the "default" admin repo created by the install.
5. Handle any errors, look for migration issues, etc., as described in the
links at the top of this page.
This also includes building up your new `~/.gitolite.rc` file.
You're done.