-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 5 Sep 2014 12:45:38 +0200 Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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. > > 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 :) I think we should do number 1, followed by 4, then 2 and finally 3 if we have no other options. we have logging currently in /var/log/secure I do not know how upstreams logging works. when we setup dist-git we worked closely with upstream to get our features in. but we have not really be active with them since then. We have broken everyone's clones and required manual intervention in the past. I really would rather we do not do it again. I would like to better understand why upstream did what they did. Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUDyuIAAoJEH7ltONmPFDRIMkQALskmMYmKOUrIsCM5G5lNEUM 8ioSkdjzTXNT5zKg9tbbvjAozRglavD8OtRTYJJE0sSDRa2mHq/X1z2x8XIChtu6 YxRVoLFvlej1VIQsGQun7yDOxa19MRSN355QJKWg2PiT9P/iro2pewW9aR8m36I/ 6pC+i6oMRDPBfvu7YTFNKrdZ8RDz6UB6T0WMmatlNPq1+MbSFzX/9tW5biE4rHel iFzAL2l1QKlV9bcCu/KuN1AvwJSQB59elhrtWt7w82qGnDoT1+H5Mg997inCtP6W Dr77dHbk9INKl9DI7ycDxIp8P4oHu0IbszSAIAnqrBrd45er5WLPuTB7VgXVKe2w qaWHP7UediVHeq1QtSm4w3Q59jqB45g6isR32RlbY+ZwSRO5rGptT4PX2qJz2lfx sCJbPT26jQBNqzy8rHoByt7OwxhgiPH8OJ+SvEqYmCdEfQVlY0X2jvBik8gOdDHh fKMhKdIZIPoAi7JwuKG31LCcRNbknRl8NsbsPtSY12yOM7m4DadZSu03bdTwWadr 6fVjP+WrRxS1kjgwnCBFLNLqLEPGinJPsXKxYURZcK/FzIyklESkzLKb37jdS7QY TT+AGdKEteiiAT9KNzqXvAAxm1WAULo5KnsPD6iq92Enf/fSuAzhzOqTP0OZOlbC Es6rqJLTSxcxvIgQs7R0 =7S0E -----END PGP SIGNATURE----- _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
