Set up Gitolite on CentOS 7
Introduction
Gitolite that can easily manage access for each user of git server. There is an article on setting examples in the street, but almost all operations of gitolite are a collection of operations that are commonplace for familiar people, such as “creating a key pair” or “committing”, so rather than a specific procedure Isn’t it quicker to write the necessary requirements?
So, this is an article instead of a memo. I wrote it in the memory of the first installation, so there may be mistakes. If I have to set it up again, maybe I can fix it?
The server environment of the installation destination is CentOS 7, but if you can use yum, there will be no big difference.
Installation
Premise
Isn’t it possible that git isn’t included?
Make a management key pair
Create a key pair for the administrator with ssh-keygen etc. The public key is required on the server side. The private key is used by the admin user for remote access (not required on the server).
yum install & committer settings
“Yum install gitolite 3” with EPEL enabled. By this operation, the user “gitolite3” for gitolite operation is automatically created. Also set a committer for this user to be automatically committed at initialization (probably required). Like this
# yum install gitolite3
# su - gitolite3
$ git config --global user.name username
$ git config --global user.email email address
I also saw an article that included settings for using Japanese in the file name to commit, but I’m not sure how important it is.
Initialization
Since the user gitolite3 has been created by the above work, initialize gitolite3 using the public key created earlier.
$ gitolite setup -pk Administrative public key file
This is the end of the work on the server side. Since a repository called “gitolite-admin” has been created in gitlite, it will be managed from the remote side mainly by committing to the repository.
management
Access from an administrative account
The requirement for access from the admin account is to access “using the admin private key” and “as user gitolite3”. So, for example, add the following entry to .ssh / config
Host gitoliteadmin (please choose your name)
HostName Host name, IP address, etc.
User gitolite3
IdentityFile ~/.ssh/Private key file name
Let’s try “ssh gitolite admin”. Of course, you can set the above information as an option of the ssh command (it’s OK, but after all, adding an entry to config by git operation is almost essential). If you get a login message and you are disconnected, you are successful.
hello gitadmin, this is gitolite3@*** running gitolite3 3.6.12-1.el7 on git ***
R W gitolite-admin
R W testing
Clone the administrative repository
You can clone the management repository “gitolite-admin” with the above access information.
From the git command
git clone gitoliteadmin:/gitolite-admin
You can do it with your favorite git client.
Add user
To add a user, simply add (commit) the public key of the key pair of the user you want to add to the gitolite-admin repository.
For example, if you have “private key: git-user1.pem, public key: git-user1.pub”, put git-user1.pub in (cloned) gitlite-admin / keydir and git commit & push. I’ll give you. The private key is held by the user and used for access.
The important thing is that “this public key file name becomes the user identifier of access control”. So, be careful about the file name when registering the public key. If the file name is “git-user1.pub”, the user identifier will be “git-user1”.
Repository addition / permission setting
In the initial state, gitlite-admin / conf / gitolite.conf should have the following contents.
repo gitolite-admin
RW+ = gitadmin
repo testing
RW+ = @all
Add a line called “repo new repository name” and a line with access privileges “RW + =” to this file, and git commit & push like adding a user. that’s all. Maybe it’s easier than git init on the server?
repo gitolite-admin
RW+ = gitadmin
repo testing
RW+ = @all
repo new-repository
RW+ = @all
To set the authority, set the user identifier or group you want to allow access after “RW + =”. If you want to set multiple users or groups, arrange them separated by spaces. Groups are defined in the same file as “@ group1 = git-user1 git-user2”. A group called “@all” is set in the initial state. There are three types of authority: “R (read only)”, “RW (read / write)”, and “RW + (all possible)”.
@group1 = git-user1 git-user2
repo gitolite-admin
RW+ = gitadmin
repo testing
RW+ = @all
repo new-repository
RW+ = gitadmin
RW = @group1
R = git-user3 git-user4
Use by users
Access from users is basically the same as the administrator. The requirement is to access “using the user’s private key” and “with user gitolite3”. As an example of .ssh / config, I thought it was like this … but it’s completely different from the one for management (because the private key is different).
Host gitolite (name you like)
HostName Host name, IP address, etc.
User gitolite3
IdentityFile ~/.ssh/Private key file name
This is also the same as the administrator, and if you do ssh gitolite, a list of repositories that can be used will be displayed. Let’s try cloning “testing”.
git clone gitolite:/testing
I get a warning “warning: You appear to have cloned an empty repository.” (If no one commits anything), but I don’t care.
Migrate existing repositories
In most cases when you start using gitolite, you’ll want to migrate a repository that was running on raw git. This work is mainly done on the remote side. This is one of the management material, but it is better to do it after adding a user, so I will write it here.
First, perform the above-mentioned “add repository” with the management account. The operation does not change even in the case of migration. When a new repository is created, it is basic to “add a git server” and “git push” on the remote side (there is an existing repository).
As a premise, it is assumed that you are in the repository you want to migrate with the user account on the remote side. If the repository name is “repo1”
git remote add gitolite ssh://gitolite/repo1 #Add git server
git push gitolite master #Basic information+master push
git push gitolite --all #Branches other than master push
git push gitolite --tags #tag
Will be. This will register the contents of the existing repository as a repository in gitolite. If you have a lot of migration repositories, create a shell script or whatever.
By this operation, “gitolite” should be added to your .git / config in addition to “origin”. You can leave it as it is, but if you don’t need to access the original repository or want to use origin instead of gitolite, you can clone it from gitolite or edit .ssh / config. Okay (I did the latter)
Finally
Once you know it, it takes less than a minute to set up (except for repository migration).
In the explanation, I mainly use the git command, but various commit & push can be done comfortably by using source tree.