2011-12-24

Gitolite Install



In recent weeks, I've been curious about Github
and how they host their private/public repositories. It was obvious they used SSH to
establish the connection, which I thought was awesome from a security standpoint. However,
for personal educational gain, I was curious how they did it. I ran across a Google search
result that said you could host your own
private GIT server.
So, I followed the user's advice and found it was rather easy to use a generic SSH connection
to establish your own private GIT repository. I thought it was really awesome, but after
a while, I wanted to show my work off to a select few, but at the same time, the idea of
just about anybody having SSH access to a user on my system just wasn't ideal. So, I looked
for the authentication method used to manage users accessing the GIT server in question
and found this nifty thing called Gitolite.



Gitolite is a branch from an older base of code that was used to manage users who connected
to the same server under the same [and potentially other] users. In order for this to
work properly, though, one must disable password authentication and setup the user(s) for
the git repositories.



I figured it would be a good idea to retrace my steps and provide a starter guide for
those trying to setup their own GIT server repos and need the right kind of nudge to
create a place where private GIT repositories can be stored.



First things first: install git and SSH. This can be done by the package manager. I'll
assume that, as the astute system administrator you are, you'll understand how to install GIT
and SSH. Please note: on debian-based systems, `git-core' is both the client and the server
as you will see in this post; the `git' command is sufficient enough to both manage the
client and server repositories.



Once you have the basics down, it's time to install the GIT gateway. Debian comes with the
package
for installation. I highly recommend this tutorial on
installing gitolite.
Please heed the advice on familiarizing yourself with SSH keys as you will need that to
understand how gitolite works in authenticating users.



Run `gl-setup [key]' where [key] is the public key you want to use as the git administrator.
Be sure to copy the file to a temporary directory and ensure it ends with a .pub extension.
Also, ensure this command is executed as the GIT user you intend to use for the GIT repositories.
Typically, the public key of the GIT administrator is selected so that it may have access
to the admin repository. Once that's setup, you should have ~/repositories in your home
directory. Your ~/.ssh/authorized_keys file should have changed as well. Now, when you
execute `ssh git@localhost' (if `git' is the user selected for the GIT administration),
you should see you have access to a repository called `gitolite-admin'. Run the following
command to checkout a copy of this admin repo:


git clone git@localhost/gitolite-admin.git ~/gitolite-admin


That should clone a GIT repository in your home dir. To add a user's access to the ACL,
merely add their key to the ./keydir/ directory and ensure their name is in the
./conf/gitolite-admin.conf. The syntax is defined in the
documentation.
Commit and push your changes. You will note that gitolite will automatically configure
itself as necessary on push , so there's no need to worry about the raw configuration in
the repo.


Caveats



If the group name defined is the same as the username, then it is unnecessary to include
the user's group identifier in the definition for the user. For example, let's assume we
have the key joe@example. In the configuration, let's assume you have the group @example.
In the config, there would be no need to say:



@example joe@example
repo projects/testing
RW+ @example


However, if joe is to be defined in a different group, the full identifier (`joe@example')
would be required. This lesson learned the hard way by yours truly ;)


EDIT (2011-12-28): I found out that the filenames match the permissions in the gitolite.conf file. So, let's assume you have the key by `user@example.com'. You would put that in `keydir/user_example.com.pub'. In conf/gitolite.conf, you would refer to the user `user_example.com'. I would discourage the use of the "@" character in filenames referencing the keys.

** For those of you who use a different flavor of linux, be it Slackware, RedHat, CentOS,
Gentoo, ArchLinux, or anything else, feel free to hit me up with the package name and
package manager and I'll update this post with the appropriate command for the selected
distribution. I'm sure this can also be done in Windows, but it's been so long since I've
managed a Micro$oft-based server, I'm almost completely out of touch with it. Again, if
there are suggestions on how to install and manage GIT, feel free to contact me and I'll
update this blog post.


No comments:

Post a Comment