Dear all,
This morning Mathieu (bochecha) and I spent some time trying to get gitolite3
work on our pkgs01.stg.
This is an overview of the situation.
By design gitolite is meant to be installed with a dedicated user. Everyone uses
that user. gitolite then maps the public ssh key to its user database and its
configuration file to handle who is allowed to do what on which git repo.
Our setup is quite different from this. We have a single configuration file at
/etc/gitolite/conf/gitolite.conf that contains all the information about who
is allowed to do what on which git repos. In addition we have a single
/etc/gitolite/gitolite.rc configuration file that specifies to gitolite where
are the git repositories located.
Each user has then an account on the machine but by default no shell access.
The access is restricted via ssh with in ~/.ssh/authorized_keys the instructions:
`command="/usr/bin/gl-auth-command"` (people with shell access have a different
command).
That commands combines the info from /etc/gitolite/gitolite.rc and
/etc/gitolite/conf/gitolite.conf and allow or deny the access/action.
Now gitolite3 has changed quite a bit compared to our setup.
Basically, gitolite3 expects the gitolite.rc file to be at ~/.gitolite.rc and
the repositories to be at ~/repositories. Having symlink to these locations
are fine, but they should be there.
What we can do also is play on the $HOME variable.
In pkgs01.stg we kept the configurations files (gitolite.conf and gitolite.rc)
in /etc/gitolite as before, but we created a couple of symlink in /srv/git/
.gitolite -> /etc/gitolite/
repositories -> /srv/git/rpms/
The idea is to be able to set HOME=/srv/git and run the gitolite command.
This way we managed to get the genacls.sh script working. It is the script
that generates the gitolite.conf file based on the pkgdb information and compile
that configuration file so that gitolite can use it.
gitolite3 also changes the command in the ~/.ssh/authorized_keys file to:
command="/usr/share/gitolite3/gitolite-shell user"
That command is set in the sources in `src/triggers/post-compile/ssh-authkeys`
and put in the file by (I believe) `gitolite compile` that is ran by genacls.sh.
In order to test, I (manually) changed Mathieu's authorized_keys to look like:
command="HOME=/srv/git/ /usr/share/gitolite3/gitolite-shell user"
We then tried to get Mathieu to clone a repo and we found out:
- the ~/.gitolite folder, that gitolite3 requires, needs to have a `logs/`
subfolder, and that folder needs to be accessible read and write to everyone
so `chmod 777 -R /srv/git/.gitolite/logs` (ie: chmod 777 /etc/gitolite/logs
since it's a symlink)
- the /etc/gitolite/conf/gitolite.conf-compiled.pm needs to be readable by
everyone since it's the file gitolite uses to see who can do what on which
repo
so `chmod o+r conf/gitolite.conf-compiled.pm
- Mathieu was finally able to clone and push in a repo he has access to and
could not on the kernel repo (as supposed to since he does not have commit
there), but the error returned is just plain ugly
So to conclude:
- we managed to get it to work
- its needs chmod 777 on /srv/git/.gitolite/logs
- its needs chmod o+r on conf/gitolite.conf-compiled.pm (and that after each
time the file is generated)
- we need to find a way to fix the command in the user's ~/.ssh/authorized_keys
so that they specify the HOME variable to use when running the gitolite
command
-> Might very well require to patch gitolite itself for this (and thus keep
the patch in our package ad vitam aeternam)
That being said, I believe our options are:
1) Talk with upstream, in the past I believe he was quite reactive and willing
to help us. We are the largest public deployment of gitolite maybe he'll
still be willing to help us
to discuss:
- setting HOME in the authorized_keys
- writing logs
- accessing gitolite.conf-compiled.pm
2) Stick with gitolite2
-> We need to find out how easy it is to maintain it on epel7 and we need
someone willing to maintain it (knowing that it's perl)
-> Upstream said gitolite2 is still maintain wrt security fixes but I guess
only for some time
3) Move to the model gitolite relies on (1 specific gitolite user everyone
accesses the repo through).
+ No more need to create account on the machine for each and every packager
+ Inline with gitolite's design
- Breaking all existing git clone around (as the push/pull urls change)
--> URLs change could be handled at the fedpkg level
+ We are already forcing an update of fedpkg to our packager with the change
from md5 to sha for the lookaside cache, so we could couple both change in
the same update and preventing forcing two fedpkg updates.
- Huge number of keys to handle for that user
? Performance impact of this number of users?
? Dennis mentionned logging at the meeting yesterday, but it looks like
gitolite does provide logging itself
4) Move away from gitolite.
I did not check what else would be available/suitable for us, so no ideas
there. Suggestions welcome I guess :)
I think that covers most if not all our findings.
Questions and suggestions welcome :)
Pierre and Mathieu
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
