Gitolite v3 installation and Configuration Guide

Gitolite v3 installation and Configuration Guide
Gitolite has recently made a lot of code changes and upgraded to V3. I am using v3.5.2. As mentioned in the Git authoritative guide, there are many things that are not suitable for the current v3 version, such as installation and user-owned warehouse configuration, some public parts are excerpted from the book. 1. the ssh protocol is used to provide Git with Remote read/write operations. It is a standard service for remote write operations. It is the only standard service for write operations before the emergence of the smart HTTP protocol. Ssh can be used for remote logon. openssh-server must be installed on the server, and openssh-client must be installed on the client. The reason for introducing the ssh protocol is that gitolite and gitosis are both based on ssh public key authentication. $ Ssh-keygen this command will generate two id_rsa private key files under the. ssh directory under the user directory. Is created based on the RSA algorithm. The private key file should be properly kept and kept confidential. Id_rsa.pub public key file. This file is a pair of id_rsa files that can be made public as a public key file. $ Ssh-copy-id-I ~ /. Ssh/id_rsa.pub user @ server provides the local public key to the remote server to achieve direct login without a password. In fact, id_rsa.pub is added to authorized_keys, and direct operations on authorized_keys have the same effect. Remote logon method: ssh user @ server logon using host alias: Edit ~ /. Ssh/confighost serveruser adminport 22 identityfile ~ /. Ssh/jiangxing # specify the local public key used for Logon. The public key of different aliases can be generated locally by Using ssh-keygen-f ~ /. Ssh/<filename> 2. create a git user $ sudo adduser -- system -- shell/bin/bash -- group git system. Only users of specific user groups (such as ssh user groups) can log on through the SSH protocol, add the new git user to the ssh user group. $ Sudo adduser git ssh set password $ passwd git 3. generate ssh key to switch to git User: $ su git $ ssh-keygen $ ssh-copy-id git@127.0.0.1 4. download gitolite git clone git: // github.com/sitaramc/gitolite 5. I installed the installation configuration in the git user root directory. Create the bin folder in the root directory and execute :~ /Gitolite/install-~ /Binmv ~ /. Ssh/authorized_keys ~ /Git. pub ~ /Bin/gitolite setup-pk ~ /Git. after pub is successful, it appears: Initialize the empty Git repository in/home/git/repositories/gitolite-admin.git/initialize the empty Git repository in/home/git/repositories/testing. git/installed successfully. Update means re-installation. 6. the test is still under the git user ssh git@127.0.0.1 if such information is returned: hello git, this is git @ linux-dev running gitolite3 v3.5.2-4-g62fb317 on git1.8.1.2 r w gitolite-admin r w testing stands for gitolite to work normally 7. you can see in step 1 that after successful installation, gitolite will automatically generate two storages, one of which is testing. git is used for testing, and another gitolite-admin is used to manage gitolite configuration warehousing. Clone the gitolite-admin.git to the local, note: it is still under the git user, because currently only git users have read and write permissions on it. $ Git clone git@127.0.0.1: gitolite-admin successfully clone to the local, you can see the structure of this directory is as follows: git @ linux-dev :~ /Gitolite-admin $ tree. ├ ── conf │ └ ── gitolite. conf └ ── keydir └ ── git. pub 2 directories, 2 filesconf is the directory where the configuration file is placed, gitolite. conf is the configuration file of gitolite, including the configuration of user, warehouse, and warehouse permissions. The keydir directory is used to place all user public keys. Git. pub is the user public key of setup-pk during installation. To add a user, add the public key of the target user to keydir and rename it as the user name. pub. Target User: $ echo ~ /. Ssh/id_rsa.pubssh-rsa restart/1f1BHhd + xxxxxxxxxx + large + zl7ftBPxtVYwSluJ + om4V4mbXT9 + large/UBNkQuub8l + large/large + large PaeB keven @ linux-dev will show the content to the git user, or paste it under the git user. If the target user name is keven, you should save it as a git user in the keydir directory, name it keven. pub, and add the user's permissions. All users under keydir belong to the @ all user group. Other user groups can be defined by gitolite. conf. For example, @ admin = git keven repo gitolite-admin RW + = @ admin repo testing RW + = git RW = @ all @ admin the user group has two users: git keven, corresponding to git under keydir respectively. pub, keven. pub. The read/write/force update permissions of the gitolite-admin warehouse are only available to the @ admin user group. The read/write/force update permissions of the testing warehouse are all for you and only for git users, all other users with public keys under keydir have read/write permissions. 8. The permission configuration permission is configured in gitolite. conf. The comment is represented. CC indicates creation. It can be used only when the wildcard version library is authorized. Used to specify who can create a version library that matches the wildcard. R, RW, and RW + R are read-only. RW is the read/write permission. RW + indicates that in addition to reading and writing, rewind can be forcibly pushed for submission. RWC and RW + C can be used only when regular references (branches and milestones defined by regular expressions) are defined in authorization commands. The meaning of C is to allow the creation of references (branches or milestones, etc.) that match with regular references ). RWD, RW + D can be used only when the authorization command defines regular references (branches and milestones defined by regular expressions. The meaning of "D" is to allow you to delete references (branches or milestones) that match the regular expression reference ). RWCD and RW + CD can be used only when regular references (branches and milestones defined by regular expressions) are defined in authorization commands. The meaning of C is to allow the creation of references (branches or milestones) that match the regular expression reference, and D is to allow the deletion of references that match the regular expression reference (branches or milestones, etc ). -It is a forbidden command. This function only applies to write operations. That is, the user's write operations are disabled. Next, the actual analysis of a slightly more complex configuration file 1 @ admin = git keven admin1 admin22 @ devteam = dev1 dev2 dev3 fish3 4 repo gitolite-admin5 RW + = git keven6 7 repo Projects /. + 8 C = @ admin9 RW = @ all10 11 repo testing12 RW + = @ admin13-= fish14 RW master = @ dev15 RW + dev = dev116 RW wip $ = dev2 line by line explanation: 1: @ admin user group has git keven admin1 admin2 four users 2: @ devteam user group has dev1 dev2 dev3 fish four users 4: warehouse for gitolite-admin 5: two git keven users have read, write, and force update permissions. 7. All git Repositories under Projects (/. + indicates recursion.) 8: @ admin user group has the permission to create a warehouse. 9: Everyone can read/write. 11: for testing. git12: @ admin user group has the read, write, and force update permissions. 13. fish is a newbie and has the write blocking permission on it. Because it belongs to the @ dev group, only the R read permission is left. 14: The @ dev user group has the read/write permission on the branches starting with the master. 15: the dev1 user has the read/write/force update permission on the branch starting with dev 16: The dev2 user has the read/write permission on the wip Branch (strictly matched, you need to have a certain understanding of gitolite. Sometimes you may need to create your own storage on the server. At this time, you need to do the following: 1 @ admin = git keven admin1 admin22 repo pub/CREATOR /. + $3 C = @ all4 RW + = CREATOR5 R = @ admin each user can create his/her own repository in the users/<User Name> directory, you have full permissions. The Administrator only has read permissions. NOTE: If RW + = CREATOR is lost, only the init empty warehouse cannot push the content up. Usage: in the User shell, enter the warehouse to be submitted to the server and execute: git push git @ server: pub/<username>/somegit. git <branch> Users can set the warehousing permissions through ssh git @ server perms, allowing other users to have write permissions. The read permission is READERS, and the read/write permission is WRITERS: ssh git @ server perms pub/<username>/somegit READERS user1ssh git @ server perms pub/<username>/somegit WRITERS user2 9. remote creation/deletion of warehouse creation: There are three methods for creating a warehouse:. log on to the remote server, create an ssh logon server, switch to the git user, enter the relevant directory, and create a warehouse mkdir somegit. gitcd somegit. gitgit init -- bare created B. modify gitolite. open gitolite-admin/conf/gitolite to create a warehouse in conf. conf, add: repo testing2 RW + = @ all to save the changes and submit them. Git @ linux-dev :~ /Gitolite-admin $ git commit-m'add test2' [master b26be9a] add test21 file changed, 4 insertions (+) git @ linux-dev :~ /Gitolite-admin $ git push origin masterCounting objects: 7, done. delta compression using up to2 threads. compressing objects: 100% (3/3), done. writing objects: 100% (4/4), 350 bytes, done. total 4 (delta 1), reused0 (delta0) remote: Initialize the empty Git repository at/home/git/repositories/testing2.git/To git@127.0.0.1: gitolite-admin 0c409e4 .. b26be9a master-> master can see that gitolite automatically detects the configuration file and finds that no storage is created automatically. C. high-end atmospheric level for the wildcard version library, that is, repo Projects /. + type. Execute mkdir somegitcd somegitgit initgit commit -- allow-emptygit remote add origin git @ server: Projects/somegit locally in the User shell With the creation permission. gitgit push origin mastergitolite will directly create a new warehouse. Delete: 1. in conf/gitolite. delete related storage configuration information in conf (gitolite does not automatically delete files on the server, which is different from add); 2. log on to the server to delete the storage to be deleted. Rename is the same as the delete operation.