Introducing gitolite

gitolite is a tool for creating centralized repositories for collaborative development through git.

Why is it needed?

Native git tools for this task are clearly insufficient for today: the native git protocol does not contain any authorization tools, and to work through ssh you will need to have a full-fledged user in the OS (with shell), which is far from always appropriate and desirable.
gitolite will allow you to make users, regardless of the availability of an account in the OS and flexibly give out rights.

Presuppositions

• The topic is big. Therefore, far from all the possibilities are described.
• In his documentation, the gitolite developer refers to a huge number of problems that arise from a lack of understanding of the principles of working with ssh with authentication through public keys. Therefore, if you are somewhat "swimming" in this matter - at the end of the article there is a small howto.
• The article assumes that the server designed to install gitolite runs on a unix-like system

Installation

In fact, in most cases, the installation does not raise any questions.
On server:

• We start a new user in the system. For convenience, let's call it git.
• Copy the public key of the user who will be the administrator into the git user’s home folder. Note that the key name must be in .pub format, where is how gitolite will know you. This name may not match any system name. If we want gitolite to know us as gitadmin, then the key file should be renamed to gitadmin.pub.
  Log in as git and install gitolite:
  

  su git
  cd ~
  git clone git://github.com/sitaramc/gitolite
  gitolite/src/gl-system-install
  gl-setup -q ~/gitadmin.pub
  

  
  
  
  
  

  Customization

  
  The peculiarity of setting up gitolite is that almost no operations to configure it are performed directly on the server. To add a new user, repository or change access rights, you need to make git clone of the special gitolite-admin repository, make changes and do git push. The fact is that gitolite uses a whole system of hooks for these changes to take effect.
  So, to create a new repository and add the necessary users, you will need:
  
  • From the user whose public key was added to gitolite when installing it (or any other user with sufficient rights to the gitolite-admin repository), we execute:
    

    git clone git@server:gitolite-admin
    

    
    This, accordingly, will create a copy of the admin repository in the current folder. It consists of two folders: conf and keydir. The conf folder contains the gitolite.conf file containing a list of repositories and access rights to them. In the keydir folder, public keys of users that gitolite should know about.
  • To add a new user, simply write his public key in the keydir folder. The key name until the end of .pub will be the username on the gitolite system. Examples: user1.pub or john-smith.pub. Dot and underscore characters are allowed in a name.
  • To add a repository and change permissions, edit the conf / gitolite.conf file. Initially, it looks like this:
    

    repo    gitolite-admin
            RW+     =   gitadmin
    repo    testing
            RW+     =   @all
    

    
    Add the lines:
    

    repo    megaproject
            RW+     =   gitadmin user1 john-smith
    

    
    These lines describe the new megaproject repository, which users gitadmin, user1, john-smith have rights to.
  • Then we apply and send all the changes:
    

    git add .
    git commit -a -m "New repo and users added"
    git push
    

    
    
  
  A few words about the config file format:
  
  • It is possible to use groups. And both for users and for repositories. Example:
    

    @oss_repos  =   gitolite linux git perl rakudo entrans vkc
    @staff      =   sitaram some_dev another-dev
    

    
    all is a special, predefined group. It describes - depending on the context - all authenticated users, or all repositories.
    
  • Basic permissions are described as follows:
    
    • R - allows reading
    • RW - allows you to push into an existing ref or create a new ref
    • RW + - allows you to push -f or delete ref (ie destroy information)
    • - (minus) - denies access
    
    
  
  
  

  Working with the newly created repository

  
  Actually, working with gitolite from the point of view of the user is completely traditional. Following our example, the developer can execute the commands:
  

  git clone git@server:megaproject
  cd megaproject
  touch newfile
  git add . 
  git commit -a -m "newfile"
  git push git@server:megaproject master
  

  
  
  

  ssh - public key authentication

  
  As you may know, in ssh, in addition to traditional password authentication, it is possible to pass it using a key pair. Public key authentication is when you generate a key pair and give the public key to the host that should recognize you. After that, through ssh, you can enter the remote machine without entering a password.
  To generate a key pair for your user, execute
  ssh-keygen -t rsa
  This command will create two files in the ~ / .ssh folder: id_rsa and id_rsa.pub. The first is the private key, which should be stored as the apple of an eye, and the second (with the extension .pub) is the public key, which must be transferred to the remote host. In fact, inside this file there is just one long text string that can be transmitted simply as text.
  And on the machine that you want to provide access to, you must enter the specified key into the ~ / .ssh / authorized_keys file of the user whose access you need to organize.
  
  

  gitolite - working principle

  
  This is for those who are interested in how it is generally arranged. Actually, as is already clear from the description, gitolite works on top of ssh using authentication via public-key (more precisely, this is the most popular configuration).
  
  The only real user on the server through whom the work with repositories will take place is started. And the “magic” of gitolite is that these keys get into authorized_keys with the option “command = [path] / gl-auth-command ...”. This option instructs the ssh server to run the specified command regardless of what the user really wanted to execute. In this case, the original command is stored in the SSH_ORIGINAL_COMMAND variable, which gitolite reads to find out what they wanted from it.