https://wiki.archlinux.org/api.php?action=feedcontributions&user=Eregon&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:17:06ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Gitosis&diff=112515Gitosis2010-07-22T14:34:26Z<p>Eregon: Add a note about the fact the permissions must exactly match, else it will not work</p>
<hr />
<div>[[Category: Daemons and system services (English)]]<br />
{{poor writing}}<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Setting Up Git ACL Using gitosis}}<br />
{{i18n_entry|Türkçe|gitosis Kurulumu}}<br />
{{i18n_links_end}}<br />
<br />
gitosis is simply an access control list for git, the (famous) stupid content tracker. Once you have a git repository, there are many ways to setup how people will access it. You might prefer publishing your repository with read-only access via the git:// protocol. But when it comes to pushing to the repository, it's essential to decide by whom and how the repository will be accessed. Generally, you wouldn't prefer letting everyone pushing changes and hopefully ruin your repository. Therefore you need some kinds of authorization methods such as:<br />
<br />
* SSH Authentication<br />
* HTTP Authentication (webdav)<br />
* gitosis (using SSH)<br />
<br />
The rest of this document is about the third method. (Afterall, the title says it all.)<br />
<br />
== What does gitosis do? ==<br />
<br />
With gitosis, you have the ability to pull from and push to the repository with just one system account. You don't need to create SSH accounts for each user who will have write access to the repository. Once you install the package (see below), there will be system user created on your system called gitosis with a home directory in /srv. Users that will access to the repositories will be using gitosis user for every transaction.<br />
<br />
== Installation ==<br />
Install [http://aur.archlinux.org/packages.php?ID=23419 gitosis-git] from the [[AUR]].<br />
<br />
Once installed, you'll be able to find some example config files in ''/usr/share/doc/gitosis''.<br />
<br />
== Initiating gitosis-admin repository ==<br />
<br />
You will need a public SSH key to continue. If you don't have one, you may generate one on your local computer: <br />
<br />
$ ssh-keygen -t rsa<br />
<br />
In order to make gitosis work, you should first create a SSH key pair (or use the existing one) and use the public key to create the gitosis-admin repository installed within gitosis home directory (''/srv/gitosis''). <br />
<br />
$ sudo -H -u git gitosis-init < /path/to/public_key.pub<br />
Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/<br />
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/<br />
<br />
You should also place the public key you used above as '''.ssh/authorized_keys''' inside gitosis' home directory. The above command will create two directories:<br />
<br />
* gitosis<br />
* repositories<br />
<br />
The directory gitosis includes a single file (''projects.list'') in which some information about the repositories are defined. The repositories directory contains all repositories including the gitosis-admin repository.<br />
<br />
== gitosis-admin repository ==<br />
<br />
gitosis-admin is simply a git repository, that stores the permissions per repository and the keys of users who have access to them. To change the settings of gitosis, add/remote repositories or users, you'll need to clone the repository to some local directory and do the changes like you would do to a normal git repository. After you're done with the files, you'll have to commit the changes and push them to the remote repository you initially cloned from.<br />
<br />
$ git clone git@host:gitosis-admin.git<br />
<br />
For this command to work,<br />
<br />
* the home directory (''/srv/gitosis/'') => '''700'''<br />
* the .ssh directory (''/srv/gitosis/.ssh/'') => '''700'''<br />
* the authorized_keys file (''/srv/gitosis/.ssh/authorized_keys'') => '''600'''<br />
<br />
should have the correct permissions. (These permissions must '''exactly''' match, greater permissions will not work !)<br />
<br />
Once you clone the repository, you'll be able to edit the following:<br />
<br />
* gitosis.conf<br />
* keydir<br />
** user_ssh_key.pub<br />
<br />
== configuration of the repositories ==<br />
<br />
=== gitosis.conf ===<br />
<br />
[gitosis]<br />
gitweb = yes<br />
<br />
[repo foobar]<br />
description = git repository for foobar<br />
owner = user<br />
<br />
[group devs]<br />
members = user1 user2<br />
<br />
[group admins]<br />
members = user1<br />
<br />
[group gitosis-admin]<br />
writable = gitosis-admin<br />
members = @admins<br />
<br />
[group foobar]<br />
writable = foobar<br />
members = @devs<br />
<br />
[group myteam]<br />
writable = free_monkey<br />
members = jdoe<br />
<br />
This defines a new group called "free_monkey", which is an arbitrary string. "jdoe" is a member of myteam and will have write access to the "gitosis" repo.<br />
<br />
Save this addition to gitosis.conf, commit and push it: <br />
<br />
$ git commit -a -m "Allow jdoe write access to free_monkey"<br />
$ git push<br />
<br />
Now the user "jdoe" has access to write to the repo named "free_monkey", but we still haven't created a repo yet. What we will do is create a new repo locally, and then push it: <br />
<br />
$ mkdir free_monkey<br />
$ cd free_monkey<br />
$ git init<br />
$ git remote add origin git@YOUR_SERVER_HOSTNAME:free_monkey.git<br />
<br />
Do some work, git add and commit files<br />
<br />
$ git push origin master:refs/heads/master<br />
<br />
With the final push, you're off to the races. The repository "free_monkey" has been created on the server (in /srv/gitosis/repositories) and you're ready to start using it like any ol' git repo. <br />
<br />
gitosis repositories can also be used with gitweb; just point the directory that contains the repository inside the gitweb configuration.<br />
<br />
=== Adding users ===<br />
<br />
The next natural thing to do is to grant some lucky few commit access to the FreeMonkey project. This is a simple two step process.<br />
<br />
First, gather their public SSH keys, which I'll call "alice.pub" and "bob.pub", and drop them into keydir/ of your local gitosis-admin repository. Second, edit gitosis.conf and add them to the "members" list.<br />
<br />
$ cd gitosis-admin<br />
$ cp ~/alice.pub keydir/<br />
$ cp ~/bob.pub keydir/<br />
$ git add keydir/alice.pub keydir/bob.pub<br />
<br />
Note that the key filename must have a ".pub" extension.<br />
<br />
gitosis.conf changes:<br />
<br />
[group myteam]<br />
members = jdoe alice bob<br />
writable = free_monkey<br />
<br />
Commit and push:<br />
<br />
$ git commit -a -m "Granted Alice and Bob commit rights to FreeMonkey"<br />
$ git push<br />
<br />
That's it. Alice and Bob can now clone the free_monkey repository like so:<br />
<br />
$ git clone git@YOUR_SERVER_HOSTNAME:free_monkey.git<br />
<br />
Alice and Bob will also have commit rights.<br />
<br />
=== Public access ===<br />
<br />
If you are running a public project, you will have your users with commit rights, and then you'll have everyone else. How do we give everyone else read-only access without fiddling w/ SSH keys?<br />
<br />
We just use git-daemon. This is independent of gitosis and it comes with git itself.<br />
<br />
$ sudo -u git git-daemon --base-path=/srv/gitosis/repositories/ --export-all<br />
<br />
This will make all the repositories you manage with gitosis read-only for the public. Someone can then clone FreeMonkey like so:<br />
<br />
$ git clone git://YOUR_SERVER_HOSTNAME/free_monkey.git<br />
<br />
To export only some repositories and not others, you need to touch git-daemon-export-ok inside the root directory (e.g. /srv/gitosis/repositories/free_monkey.git) of each repo that you want public. Then remove "--export-all" from the git-daemon command above.<br />
<br />
=== More tricks ===<br />
<br />
gitosis.conf can be set to do some other neat tricks. Open example.conf in the gitosis source directory (where you originally cloned gitosis way at the top) to see a summary of all options. You can specify some repos to be read-only (opposite of writable), but yet not public. A group members list can include another group. And a few other tricks that I'll leave it to the reader to discover.<br />
Caveats<br />
<br />
If /srv/gitosis/.gitosis.conf on your server never seems to get updated to match your local copy (they should match), even though you are making changes and pushing, it could be that your post-update hook isn't executable. Older versions of setuptools can cause this. Be sure to fix that:<br />
<br />
$ sudo chmod 755 /srv/gitosis/repositories/gitosis-admin.git/hooks/post-update<br />
<br />
If your Python goodies are in a non-standard location, you must additionally edit post-update and put an "export PYTHONPATH=..." line at the top. Failure to do so will give you a Python stack trace the first time you try to push changes within gitosis-admin.<br />
<br />
If you want to install gitosis in a non-standard location, I don't recommend it. It's an edge case that the author hasn't run up against until I bugged him to help me get it working.<br />
<br />
For the brave, you need to edit whatever file on your system controls the default PATH for a non-login, non-interactive shell. On Ubuntu this is /etc/environment. Add the path to gitosis-serve to the PATH line. Also insert a line for PYTHONPATH and set it to your non-standard Python site-packages directory. As an example, this is my /etc/environment:<br />
<br />
$ PATH="/home/$(whoami)/sys/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games"<br />
$ PYTHONPATH=/home/$(whoami)/sys/lib/python2.4/site-packages<br />
<br />
Be sure to logout and log back in after you make these changes.<br />
<br />
Don't use the gitosis-init line I have above for the standard install, instead use this slightly modified one:<br />
<br />
$ sudo -H -u git env PATH=$PATH gitosis-init < /tmp/id_rsa.pub<br />
<br />
Be sure to also set PYTHONPATH in your post-update hook as described above.<br />
<br />
The *should* do it. I am purposefully terse with this non-standard setup as I think not many people will use it. HIt me up in #git on FreeNode if you need more info (my nick is up_the_irons).<br />
<br />
=== Non-standard SSH port ===<br />
<br />
If you run SSH on a non-standard port on your server, don't use the syntax "git@myserver.com:1234:/foo/bar", it won't work. Putting the port in the URL doesn't seem to make gitosis, or git, (not sure which) happy. Instead, put this in your ~/.ssh/config file:<br />
<br />
$ Host myserver.com<br />
$ Port 1234<br />
<br />
* [repo] blocks are used to define some necessary areas being used with gitweb.<br />
* [group] blocks are used for both:<br />
** defining user groups<br />
** defining repository permissions<br />
* @ is used to define user groups.<br />
<br />
You should commit and push any changes you do in this file.<br />
<br />
=== keydir ===<br />
<br />
keydir is simply a directory that contains public keys of the users. Some of the keys can be in the form of user@machine and those keys must be defined with that form inside gitosis.conf. It's better to create user groups and use them as members of the repositories. Once you add new keys to enable some new users, you should add the files to the git repository and commit & push them. The new users will use the above form of git commands like you've used to clone the gitosis-admin repository.</div>Eregon