Git provides all the required tools to create remote repositories. As explained in Setup gitosis to manage git repositories, a bare repository can be generated and managed manually or with gitosis, but this is not the only git repository management system. I will show how gitolite, the successor to gitosis, is setup and configured.
Install gitolite
In CentOS, gitolite is not in the standard repository. To install it via yum, the epel repository needs to be installed. If the EPEL repository is not yet installed, follow the instructions at How to Enable EPEL Repository for RHEL/CentOS 7.x/6.x/5.x.
With the EPEL repository installed, the gitolite package can be installed directly via yum.
[Server]$ yum install gitolite3 git
With gitolite installed, a new user can be generated which will be used to host the git repositories in. The following commands create a new group called “gitolite” as well as a user “git” that is added to the secondary group “ssh_login_group”. In Secure SSH server access this group is used to define the users that are allowed to login via ssh.
[Server]$ groupadd gitolite [Server]$ useradd --home-dir /home/git -g gitolite -G ssh_login_group --shell /bin/sh git
As a second step, an ssh-key needs to be generated for the authentication of the gitolite administrator. This key will be configured as an ssh-key to access the gitolite administration repository. Such an ssh-key, if not already existing, can be generated by executing the command below.
[Client]$ ssh-keygen -t rsa -b 4096 -C "public key comment"
This will generate a private and a public key file “~/.ssh/id_rsa” and “~/.ssh/id_rsa.pub”. With the parameter “-f filename” the file name for the key can be defined if necesarry.
Store the public key on the server making it accessible by the created “git” user. I suggest to upload the public key to the home directory of the git user and change the owner to the user as well. This allows the public key file to be accessible by gitolite. After that, change to that git user with su(1).
[Server]$ su - git
With the ssh public key available and changed to the user “git” the setup of gitolite can be started.
[Server]$ gitolite setup --pubkey user.pub
Initialized empty Git repository in /var/lib/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /var/lib/git/repositories/testing.git/
WARNING: /home/git/.ssh missing; creating a new one
(this is normal on a brand new install)
WARNING: /home/git/.ssh/authorized_keys missing; creating a new one
(this is normal on a brand new install)
The above command will initiate the gitolite administration repository. Gitolite grants access to the administration repository with the provided public key. The administration repository can now be cloned to configure it.
Configure repository
The administration repository gitolite-admin.git contains the configuration for gitolite. To change the configuration, clone the repository to the client.
[Client]$ git clone ssh://git@server.example.com/gitolite-admin.git
The cloned repository contains the following files and directories.
[Client]$ tree
.
├── conf
│ └── gitolite.conf
└── keydir
└── user.pub
2 directories, 2 files
Within the repository, the configuration and the key files are clearly separated in two directories. Inside the configuration directory, the gitolite.conf file allows managing the complete configuration.
By default the config looks like this. The first two lines define the gitolite admin repository where full access is granted to the key named “user”. Additionally a second repository called “testing” is configured with full access from any configured key.
repo gitolite-admin
RW+ = user
repo testing
RW+ = @all
The key added in the setup of gitolite is stored in the keydir/ directory with the same name as it was specified. If there are multiple keys for the same user, subdirectories for each location should be created. The key-file in each directory should be named the same so gitolite detects it as the same user. For more details about key management see Basic Administration.
[Client]$ tree
.
├── conf
│ └── gitolite.conf
└── keydir
├── desktop
│ └── user.pub
├── laptop
│ └── user.pub
├── smartcard
│ └── user.pub
└── user.pub
In this example, gitolite is able to treat all these keys as the same user.
With that in place, a new repository can be configured. To do so, add the following two lines to the configuration file.
repo project-test
RW+ = user
When the new repository configuration is pushed, the output will show output similar to the following.
[Client]$ git push origin master remote: Initialized empty Git repository in /home/git/repositories/project-test.git/ To ssh://git@server.example.com/gitolite-admin.git 2863304..54ec78f master -> master
Compared to gitosis where the repository is not created when the configuration is pushed, gitolite creates the empty repository immediately. Instead of creating a local repository that is then pushed to create the remote repository, gitolite allows you to immediately pull the new repository as it is already created on the server.
Read more of my posts on my blog at http://blog.tinned-software.net/.
