Gitolite3 on pkgs01.stg

Pierre-Yves Chibon pingou at pingoured.fr
Tue Dec 16 15:35:27 UTC 2014


On Tue, Dec 16, 2014 at 04:13:07PM +0100, Pierre-Yves Chibon wrote:
> On Fri, Sep 05, 2014 at 12:45:38PM +0200, Pierre-Yves Chibon wrote:
> > 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.
> 
> So Mathieu and I started to work on this again over the last couple of days.
> 
> We fix the logging issue by simply asking gitolite to rely on syslog. This means
> all logs from gitolite are now ending up in /var/log/messages (this has some
> pros and some cons)
> 
> We updated the configuration file gitolite.rc to the (completely) new one of
> gitolite3.
> 
> At that point we were able to clone and pull but pushing didn't work. Finally,
> Mathieu realized that our setup in ~/.ssh/authorized_keys was incorrect.
> With Gitolite2 we could specify the type of the user (user vs admin) while on
> gitolite3 it requires the username of the user.
> So we adjusted fasClient and the fas.conf configuration file to allow us to set
> the username in the authorized_keys file
> 
> Pull-request at: https://github.com/fedora-infra/fas/pull/97
> 
> So now, pkgs01.stg should work.
> We should be able to clone, push, pull changes.
> Email notifications are working as well, so beware which package you test
> against :)
> 
> Please take a stab at it and let us know if you see any problem with it.
> Once fasClient is updated, we should rebuild the box and do some final testing
> before we can consider moving this to prod.


For the known issue list:

Currently, the people that have shell access to pkgs01.stg, we currently cannot
do a simple ssh pkgs01.stg...

Hopefully, we'll be able to fix this.

Pierre


More information about the infrastructure mailing list