Meet gitolite

gitolite is a tool for creating centralized collaborative repositories via git.

Why is it needed?

The native git tools for this task are clearly insufficient for today: the native git protocol does not contain any means of authorization, and to work via ssh you will need to have a full user in the OS (with the shell), which is not always appropriate and desirable.
gitolite will allow you to start users regardless of the account in the OS and flexibly distribute rights.

Presuppositions

• The topic is big. Consequently, not all features are described.
• In its documentation, the gitolite developer refers to a huge number of problems that arise from a lack of understanding of how to work with ssh with public key authentication. Therefore, if you are somewhat “floating” in this question - at the end of the article there is a small howto.
• The article assumes that the server intended for installing gitolite runs on a unix-like system.

')

Installation

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

• We start in the system a new user. For convenience, let's call it git.
• We copy the user's public key, which will be the administrator, to the git user's home folder. Please note that the key name must be in .pub format, where - this is how gitolite will know you. This name may not coincide with any system. If we want gitolite to know us as gitadmin, then the key file must be renamed to gitadmin.pub
  Login 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 gitolite configuration is that almost no configuration operations are performed directly on the server. To add a new user, repository or change permissions, you need to make a git clone special gitolite-admin repository, make changes and make a 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 will need:
  
  • From under the user, the public key of which was added to gitolite during its installation (or any other user with sufficient rights to the gitolite-admin repository) 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 are the public keys of users that gitolite should know about.
  • To add a new user, simply write his public key to the keydir folder. The key name until the end of .pub will be the username in the gitolite system. Examples: user1.pub or john-smith.pub. Dots and underscores are valid in the 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 lines:
    

     repo megaproject RW+ = gitadmin user1 john-smith 

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

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

    
    
  
  A few words about the config file format:
  
  • There is a possibility to use groups. And for both users and 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 access rights 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 or delete the ref (i.e., destroy the information)
    • - (minus) - denies access
    
    
  
  
  

  We work with the newly created repository

  
  Actually, working with gitolite from the user's point of view is completely traditional. Following our example, a developer can execute 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 pair of keys. Authentication via public key is when you generate a pair of keys and give the public key to the host that should recognize you. After that, via ssh, you can log into 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 pupil of the eye, and the second (with the .pub extension) is the public key, which must be transmitted to the remote host. In fact, inside this file is just one long text string, which can be transmitted simply as text.
  And on the machine, access to which you want to provide, you must enter the specified key in the file ~ / .ssh / authorized_keys of the user under which you need to organize access.
  
  

  gitolite - the principle of work

  
  This is for those who are interested in how it works. Actually, as is clear from the description, gitolite works on top of ssh using public-key authentication (more precisely, this is the most popular configuration).
  
  On the server, the only real user is started up, through which work with repositories will take place. And the “magic” of gitolite is that these keys get to 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 actually wanted to execute. At the same time, the original command is saved in the SSH_ORIGINAL_COMMAND variable, which gitolite reads to find out what they wanted from it.