ArticleDirectory
- (1) Since gitosis is developed based on python, install the python-setuptools rpm
- (2) clone code from the gitosis Official Website
- (2) Prepare to manage the user's public key
- (3) initialize gitosis
- (4) Add a Public Key
- (5) Permission Control
- (6) Others
@ Http://www.inanu.net/post/742.html
To study puppet over the past few days, you just need to build a git repository. Briefly record the process and problems encountered.
Environment: centos 6.2 x86_64
1. Install rpm
[Root@c1.inanu.net] # Yum install httpd [root@c1.inanu.net] # Yum install git Git-daemon
Httpd and gitweb are installed here to facilitate the browsing and Management of git through the Web. Apache can also be used to replace webrick of puppet.
2. Configure git
In centos, git provides services in Xinetd mode. The default xinetd configuration file is:/etc/xinetd. d/git.
Edit the configuration file. The following is a modified git xinetd configuration file:
12345678910111213 |
# Default: Off# Description: The git d has mon allows git repositories to be exported using \# The GIT: // protocol.ServiceGit{Disable = No socket_type = streamWait= No user = Nobody Server =/USR/Libexec/Git-core/Git-daemonServer_args =-- Base-Path=/VaR/Lib/Git -- Export-all -- User-Path= Public_git-- Syslog -- Inetd -- VerboseLog_on_failure + = userid} |
Start the xinetd service:
[Root@c1.inanu.net] # service xinetd start
3. Create a git repository on the puppet Server
[Root@c1.inanu.net] # useradd-D/var/lib/Git-S/usr/bin/Git-shell git # create git user [root@c1.inanu.net] # passwd git # Set git User Password [root@c1.inanu.net] # chown-r git: git/var/lib/git [root@c1.inanu.net] # su git # Switch to git user [git@c1.inanu.net] $ Cd ~ [Git@c1.inanu.net] $ mkdir. SSH [git@c1.inanu.net] $ chmod 700. SSH [git@c1.inanu.net] $ touch. SSH/authorized_keys [git@c1.inanu.net] $ chmod 600. SSH/authorized_keys [git@c1.inanu.net] $ mkdir/var/lib/git/puppet. git # create puppet server-side git repository [git@c1.inanu.net] $ CD/var/lib/git/puppet. git [git@c1.inanu.net] $ git -- bare init # initialize puppet server-side git Repository
4. Create a git local repository on the client
[Root@c2.inanu.net] # ssh-keygen-t rsa # generate the ssh-key pair used by the user [root@c2.inanu.net] # ssh-copy-ID git@c1.inanu.net # copy the ssh-key public key generated in the previous step in the server git user [root@c2.inanu.net] # mkdir-P/data/git/repo/puppet [root@c2.inanu.net] # cd/data/git/repo/puppet [root@c2.inanu.net] # git init # Initialization the GIT repository [root@c2.inanu.net] # git clone git@c1.inanu.net: puppet [root@c2.inanu.net] # git config -- global user. name 'nanu' [root@c2.inanu.net] # git config -- global user. email 'nanu @ inanu.net '[root@c2.inanu.net] # rsync-avz -- Progress -- RSH = SSH root@c1.inanu.net:/etc/puppet /. /# synchronize the existing puppet master configuration file to the GIT repository [root@c2.inanu.net] # git add. # add all files and directories to git Version Control [root@c2.inanu.net] # git status # view operation results, confirm that all files have been added to the [root@c2.inanu.net] # git commit-m'init '# submit to the local git repository [root@c2.inanu.net] # git push-u origin master # submit to the remote git Repository
5. Update the puppet configuration file for Detection
Run the following command on the Puppet Master (c1.inanu.net:
The [root@c1.inanu.net] # cd/etc/puppet [root@c1.inanu.net] # git clone git@c1.inanu.net: puppet
In this way, the puppet configuration file is updated.
6. gitweb Configuration
After all the RPM packages are installed, gitweb can run. The default access address is http: // ip/git /.
The Apache configuration file of gitweb is located at:/etc/httpd/CONF. d/gitweb. conf
You can customize gitweb In the GIT repository configuration file on the server side. The above puppet repository is used as an example:
[Root@c1.inanu.net] # vi/var/lib/git/puppet/config
Open the config file of the puppet git repository and edit it. The default config file is as follows:
1234 |
[Core]Repositoryformatversion =0Filemode =TrueBare =True |
Add the configuration segment for gitweb to the following content:
12345678 |
[Core]Repositoryformatversion =0Filemode =TrueBare =True [Gitweb]Owner =NanuURL =Git@c1.inanu.net: puppet. Git |
Some repository information is specified in the newly added [gitweb] configuration section.
7. Git permission Control
Git does not provide permission management by default. It is generally implemented through the operating system's own security control mechanism, which is very troublesome and inflexible. We need to use a third-party git application for management. The most commonly used is gitosis.
The practice of saving the public keys of all users in the authorized_keys file can only be done for a while. When the number of users reaches several hundred, it will be very painful to manage them. You must log on to the server for each change, deletion, and deletion operation. This operation also lacks necessary permission management. Everyone has full read and write permissions for all projects.
Gitosis is a set of scripts used to manage the authorized_keys file and implement simple connection restrictions. Interestingly, it is not through web pages that are used to add users and Set permissions.ProgramInstead of managing a special git repository. You only need to set the corresponding settings in this special warehouse, and then push it to the server, gitosis will change the running policy accordingly, it sounds cool, right?
(1) Since gitosis is developed based on python, install the python-setuptools rpm
[Root@c1.inanu.net] # Yum install Python-setuptools
(2) clone from gitosis Code
[Root@c1.inanu.net] # cd/usr/local/src [root@c1.inanu.net] # git clone git: // eagain.net/gitosis.git?root@c1.inanu.net## CD gitosis [root@c1.inanu.net] # Python setup. py install
(2) Prepare to manage the user's public key
Create the main directory of gitosis:
[Root@c1.inanu.net] # mkdir-P/data/gitosis
Gitosis will help us manage the user's public key, so we will first back up the current control file to re-add it later, ready for gitosis to automatically manage the authorized_keys file:
[Root@c1.inanu.net] # mv/var/lib/git/. Ssh/authorized_keys/var/lib/git/. Ssh/authorized_keys.bak
Next, change the previous git user's logon Git-shell to a normal shell. After the change, you still cannot log on through this account. Because the authorized_keys file is no longer available, don't worry, it will be handed over to gitosis for implementation. So now, first modify the/etc/passwd file and find the line where the GIT user is located:
1 |
Git: X:501:501:/Var/lib/git:/usr/bin/Git-shell |
Change this line:
1 |
Git: X:501:501:/Var/lib/git:/bin/bash |
(3) initialize gitosis
[Root@c1.inanu.net] # su git [git@c1.inanu.net] $ Cd ~ [Git@c1.inanu.net] $ gitosis-init <. SSH/authorized_keys.bakinitialized empty git repository in/var/lib/git/repositories/gitosis-admin.git/reinitialized existing git repository in/var/lib/git/repositories/gitosis-admin.git/
Note: Do not change the default shell of the GIT user back to git-shell. Otherwise, an error will be reported when gitosis-serve is executed!
In this way, the owner of the public key can modify the special git repository used to configure gitosis. Next, you need to manually add executable permissions to the post-update script in the repository:
[Git@c1.inanu.net] $ chmod 755/var/lib/git/repositories/gitosis-admin.git/hooks/post-Update
This is basically good. If there is no error in the setup process, you can try to log on to the server by using SSH as the owner of the public key that initializes gitosis. It should be shown as follows:
[Root@c2.inanu.net] # SSH git@c1.inanu.netPTY allocation request failed on channel 0 fatal: Unrecognized command 'gitosis-serve nanu' connection to gitserver closed.
Gitosis recognizes the user's identity, but does not run any git command, so it cut off the connection. Now, run an actual git command-clone the gitosis Control Repository:
[Root@c2.inanu.net] # git clone git@c1.inanu.net: gitosis-admin.git
This will get a working directory named gitosis-admin, which consists of two parts:
[Root@c2.inanu.net] # cd gitosis-Admin [root@c2.inanu.net] # Find.../gitosis. conf./keydir./keydir/Scott. Pub
Gitosis. conf
This is a control file used to set users, warehouses, and permissions.
Keydir
This is the place where the public key of all users with access permissions is saved, one for each user. The file name in keydir (for example, Scott. Pub above) should be different from yours. Gitosis automatically obtains the name from the description at the end of the public key imported using the gitosis-init script.
Let's take a look at the content of the gitosis. conf file. It should only contain information related to the cloned gitosis-Admin:
12345 |
[Gitosis] [Group gitosis-Admin]Writable =Gitosis-AdminMembers =Nanu |
It shows that the user Nanu (the owner who initializes the gitosis Public Key) is the only one who can manage the gitosis-Admin project.
Now let's manage the previous puppet repository. Therefore, we need to create a new section named puppet, which lists the O & M team members and projects with write permissions. Since Nanu is the only user in the system, we set it as the only user and allow it to read and write a project named puppet:
123 |
[Group puppet]Writable =PuppetMembers =Nanu |
After the modification, submit the changes in gitosis-admin and push them to the server to make them take effect:
[Root@c2.inanu.net] # git commit-am 'modify puppet '[root@c2.inanu.net] # git push
Next, because the default git repository location has changed to/var/lib/git/repositories after gitosis is installed, you must first put the previous location in/var/lib/git/puppet. the GIT repository is moved to/var/lib/git/repositories/. Otherwise, during the first check or push operation, gitosis automatically creates a new puppet in/var/lib/git/repositories. git repository.
[Git@c1.inanu.net] $ mV/var/lib/git/puppet. Git/var/lib/git/repositories/
(4) Add a Public Key
To work with friends on a project, you have to re-add their public key. However, you do not need to manually add them one by one on the server ~ At the end of the/. Ssh/authorized_keys file, you only need to manage the public key file in the keydir directory. The file name will determine the user ID in gitosis. conf. Now we add the public key for Tyra:
[Root@c2.inanu.net] # cp/tmp/id_rsa.tyra.pub keydir/Tyra. Pub
Then add them to the 'puppet 'team to grant them the read and write permissions on the puppet Repository:
123 |
[Group puppet]Writable =PuppetMembers =Nanu Tyra |
Finally, submit the gitosis-Admin repository again.
(5) Permission Control
Gitosis also has simple access control functions. If you want Tyra to have only the read permission, you can do this:
1234567 |
[Group puppet]Writable =PuppetMembers =Nanu [Group puppet_ro]Readonly =PuppetMembers =Tyra |
Now Tyra can clone and retrieve updates, but gitosis won't allow her to push anything to the project. A group like this can be created at will, but there are no restrictions on the number. Each group can contain several different users and projects. You can even specify a group as one of the members (with the @ prefix before the group name) to automatically inherit the members of the group:
12345678910 |
[Group puppet_committers]Members =Nanu Tyra [Group puppet_1]Writable=PuppetMembers=@ Puppet_committers [Group puppet_2]Writable=Another_puppetMembers=@ Nanu_committers VV |
(6) Others
After gitosis is installed, if gitweb is enabled, You need to modify the CGI program of gitweb. After gitosis is installed, the default git repository storage location has changed.
[Root@c1.inanu.net] # vi/etc/httpd/CONF. d/git. conf
Search for '/var/lib/git' and change it to '/var/lib/git/repositories '.
if you encounter an unexpected problem, try to add loglevel = debug to the [gitosis] section.
If the configuration is accidentally incorrect and the push permission is lost, you can also manually modify the/var/lib/git/. gitosis. conf file on the server. Gitosis actually reads information from this file. It saves the new gitosis. conf to this path when obtaining the push data. Therefore, if you manually edit the file, it will remain until the new version of configuration content is pushed to gitosis-Admin next time.