Bug 713020
| Summary: | Patch in gitolite RPM breaks git hook functionality | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Steve Snodgrass <ssnodgra> | ||||||
| Component: | gitolite | Assignee: | Lubomir Rintel <lkundrak> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | el6 | CC: | blair, dcantrell, gwync, jh.xsnrg, lkundrak | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | gitolite-2.0.3-2.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-09-24 22:00:41 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 504743 [details] Revised patch for gitolite RPM I've attached a revision to the gitolite-1.5.7-rpm patch which I believe fixes the issue - it works for me at least. It appears that the original patch was designed to hack around a failure to properly set the GL_PACKAGE_CONF and GL_PACKAGE_HOOKS variables in gitolite.rc. This new patch sets these values and removes the hacks, allowing hook functionality to work properly. For more info, see the gitolite packaging documentation here: http://sitaramc.github.com/gitolite/doc/packaging.html I can reproduce this issue with gitolite-2.0.2-1.fc16.noarch.rpm onto a fully updated Fedora 15 system. As the original reporter stated, an easy way to check that this isn't running is to do the following: 1. Install the RPM. 2. su - gitolite 3. gl-setup /path/to/my/key.pub 4. cd .gitolite/hooks/common 5. ln -s /bin/true my-test-hook 6. gl-setup 7. ls ~/repositories/testing.git/hooks 8. there should be a my-test-hook in that directory listing. While this RPM is being worked on, the README in the git checkout for the source RPM contains some outdated information mentioning running gl-easy-setup, which is no longer accurate, since the RPM doesn't even contain that script. I just noticed this bug is reported against el6 but it's also present in Rawhide. Should I open a new ticket for Rawhide? Thanks, Blair Blair, I've heard nothing but crickets since I filed this one. If you like, I can send you the working source or binary RPM that integrates the patch I posted. Steve, yes, definitely, I'll take you up on your offer for the source RPM. Thanks! Blair BTW, my current workaround is to leave the hook in ~gitolite/.gitolite/hooks/common and then make a symlink to it in /usr/share/gitolite/hooks/common. That way I won't loose the hook since it's part of the ~gitolite area if I have to rebuild the system and all the repositories will pick up the hook. I don't know if this is appropriate on this bugzilla (it is on the projects I directly contribute on), but I'm adding Jon Ciesla to the cc list, since he's done many of the commits in the git repo (git://pkgs.fedoraproject.org/gitolite) and also committed the patch Steve has modified. Thanks for adding me, I wasn't aware of this since I'm not officially a co-maintainer and so don't see BZ emails for it, but I do a lot on gitolite, I'll take a look this afternoon. I have an SRPM and RPM of the parts of your patch not already in the 2.0-rpm patch applied. http://zanoni.jcomserv.net/fedora/gitolite/ Please test. If it works, I'll push this to rawhide, f15, f14, and el6. Also, this version's README was already updated, and is, AFAIK, current. Jon, thanks, I'll take a look at these by Monday PST at the latest. Blair, I was going to send the source RPM this morning but since you are already using gitolite v2 and I'm still on 1.5.7 you are probably better off with Jon's RPM anyway. Jon, thanks for taking a look at this. Jon, While I admit I have not tested the new RPM you submitted, I looked at the code and it still appears broken to me. You should understand that the patch I submitted above for the 1.5.7 version *replaces* an existing patch in the RPM that reverted many of the changes in the patch - sorry if that was confusing. It appears that the gitolite-2.0-rpm.patch file in your RPM still contains many of those broken changes - including the replacement of GL_ADMINDIR with /usr/share/gitolite, which is incorrect. Anytime. I think part of the confusion may come from the fact that several portions of your patch were already present in the 2.0-rpm patch. If not /usr/share/gitolite, what should GL_ADMINDIR be set to? Taking a step back, the number of patches in our SRPM takes a while to understand what everything is doing. The upstream packaging guide suggests there isn't much configuring to be done: https://github.com/sitaramc/gitolite/blob/pu/doc/packaging.mkd To answer your question on GL_ADMINDIR, I looked at a bleeding edge Ubuntu oneiric install with gitolite 2.0 on my VirtualBox VM: $ /usr/share/gitolite/gl-query-rc GL_ADMINDIR /var/lib/gitolite/.gitolite I also took a look at Ubuntu's source package, which only has three patches. I'm wondering if Fedora's patch set should be reset to simplify the entire install. Here's Ubuntu patches, nothing really going on there: $ cat fix-gl-setup Author: Gerfried Fuchs <rhonda> vim:ft=diff: Description: gl-setup uses non-posix shell stuff - switching to bash Index: b/src/gl-setup =================================================================== --- a/src/gl-setup +++ b/src/gl-setup @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash GL_PACKAGE_CONF=/usr/share/gitolite/conf # must be the same as the value for the same variable in $ cat fix-paths Author: Gerfried Fuchs <rhonda> vim:ft=diff: Description: set some required paths Index: b/conf/example.gitolite.rc =================================================================== --- a/conf/example.gitolite.rc +++ b/conf/example.gitolite.rc @@ -19,8 +19,8 @@ $GL_CONF_COMPILED="$GL_ADMINDIR/conf/git # DO NOT CHANGE THE NEXT FOUR LINES UNLESS YOU REALLY KNOW WHAT YOU'RE DOING. # These variables are set automatically by the install method you choose. # (PACKAGE MAINTAINERS: PLEASE READ doc/packaging.mkd) -# $GL_PACKAGE_CONF = ""; -# $GL_PACKAGE_HOOKS = ""; +$GL_PACKAGE_CONF = "/usr/share/gitolite/conf"; +$GL_PACKAGE_HOOKS = "/usr/share/gitolite/hooks"; # ------------------------------------------------------------------------------ # most often used/changed variables Index: b/src/gl-setup =================================================================== --- a/src/gl-setup +++ b/src/gl-setup @@ -1,6 +1,6 @@ #!/bin/sh -GL_PACKAGE_CONF=/tmp/share/gitolite/conf +GL_PACKAGE_CONF=/usr/share/gitolite/conf # must be the same as the value for the same variable in # $GL_PACKAGE_CONF/example.gitolite.rc. Sorry about the catch-22 :) $ cat fix-.ssh-permissions Author: Gerfried Fuchs <rhonda> vim:ft=diff: Description: set proper permission for created .ssh directory Index: b/src/gl-setup =================================================================== --- a/src/gl-setup +++ b/src/gl-setup @@ -92,7 +92,7 @@ fi # authkeys etc., because in this case it seems appropriate ( cd $HOME - mkdir -p .ssh + mkdir -p -m700 .ssh chmod go-rwx .ssh touch .ssh/authorized_keys chmod go-w . .ssh .ssh/authorized_keys I tried the RPM in a fresh Fedora 15 VirtualBox and two things didn't work:
1) Immediately after running
su - gitolite
gl-setup /tmp/blair.pub
then .ssh/authorized_keys has the 0600 correct permissions, but after
running gl-setup once again, it has 0660, which ssh doesn't like so
it cannot log in. This appears to be due to the /etc/profile on Fedora
15 which sets gitolite's umask to 0002. On my VM, gitolite's uid/gid
is 493/490.
2) Trying the above recipe by dropping a file into
~gitolite/.gitolite/hooks/common and running gl-setup, it didn't put the
hook into ~gitolite/repositories/testing.git/hooks.
Thanks,
Blair
Hey Jon, My bad on my previous comments about the patches, my git checkout showed all of them so I assumed they all were applied to the source. However, looking at a SRPM today, I was wondering why it only had one patch in it, as compared to the git checkout, and saw that it only applies the 2.0 patch. There's not a lot in it, so it's definitely not as confusing as it appears, but maybe we should remove unused patches from git so people don't assume all the patches there are applied. Regards, Blair Heh. It occurs to me that I was keeping them around for historical reasons. In a git repo. <facepalm> I've removed them in rawhide. So where are we? Jon, I tried the RPMs on your site and they don't fix the reproduction recipe. Do you have a VM you can set up to mess around with a vanilla gitolite install? With that, it'll be easy to reproduce the issues. Blair Not currently, but I can make one. Sorry, for the delay, I've put up a test build that drops the offending section. Can you see if it works for you? http://zanoni.jcomserv.net/fedora/gitolite/ Hi Jon, sorry I've been busy for a while. Do you have the source RPM for that test? Thanks. Hi Jon, In my testing of the new RPM, it works great. Thanks! The only outstanding issue is that running gl-setup as gitolite results in a ~gitolite/.ssh/authorized_keys that has 0664 permissions, which is then ignored by sshd. This is on Fedora 15 due to it's newer umask setting for system accounts. See this thread that I just started on the root cause and asking where is the best place to fix it: http://groups.google.com/group/gitolite/browse_thread/thread/61b0a6615603c3bf Regards, Blair Cool, thanks! I see he's thinking about cutting a release this weekend. If he does it by Saturday evening, I'll get it out then, if not, Monday first thing. New 2.0.3 with patch corrections in rawhide. Check it out, and if it's good, it's going to EL-6 and f16. Jon, am I missing something? I'm looking here: http://download.fedora.redhat.com/pub/fedora/linux/development/rawhide/source/SRPMS/ I only see gitolite 2.0.2-2.fc16. You'll see it there after the next rawhide compose. But see it now, in full color, in koji. http://koji.fedoraproject.org/koji/buildinfo?buildID=257593 I'm afraid there are still problems with that version. Most of the issue boils down to messing with GL_ADMINDIR or GL_PACKAGE_HOOKS, either hardcoding them or setting them to an incorrect value, both of which will cause problems in various scenarios. Now that the PACKAGE variables are set right, there's no reason for any of those patches. I produced a new version of the patch that I believe will work right - just replace the existing gitolite-2.0-rpm.patch with my new attachment and I think you will be good. Created attachment 517272 [details]
RPM patch updated for gitolite 2.0.3
Replacing the existing patch (gitolite-2.0-rpm.patch) in the 2.0.3 source RPM with this one should yield better results.
With new patch: http://koji.fedoraproject.org/koji/buildinfo?buildID=257697 From my testing of the 2.0.3-2 RPM (compiled on f15) it works. All the use cases that I had that didn't work now work. Thanks! Blair Excellent, on it's way to f16. CCing Jesse Keating. Jesse, Do you have any objection to my upgrading el6 to 2.0.3, so long as I apply, rebasing if needed, your central gitolite.rc patch? gitolite-2.0.3-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/gitolite-2.0.3-2.fc16 (In reply to comment #32) > Excellent, on it's way to f16. > > CCing Jesse Keating. > > Jesse, Do you have any objection to my upgrading el6 to 2.0.3, so long as I > apply, rebasing if needed, your central gitolite.rc patch? No objection here. In attempting to forward-port you patch, it looks like the bits you're patching have moved to gl-install, which make me think it's behaving differently and I'd like you to take a look, if you don't mind, to make sure we get this right. I'm not sure what we're doing there should be done the same way. gitolite-2.0.3-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. I just looked at the 2.0.3 upstream code, and my patch has been integrated (and moved to gitolite_rc.pm). So you can move to 2.0.3 and drop my patch. gitolite-2.0.3-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/gitolite-2.0.3-2.el6 Awesome, done. Thanks! Bohdi on it's way. Package gitolite-2.0.3-2.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing gitolite-2.0.3-2.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/gitolite-2.0.3-2.el6 then log in and leave karma (feedback). gitolite-2.0.3-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. It seems there may still be a bug with this package. I updated on the 6th of October, and all seemed okay, but I did not try creating any new repos until later. When I tried, repo creation failed. Upon further looking at the problem, some of the symlinks in the gitolite-admin project were broken. Simply running gl-setup again seems to have fixed all the symlinks and the problem. This should be a post-update step that appears to be missing? It typically is called automatically at the first interaction with gitolite, commit, etc. In the update for 2.1, I did add a note to make sure that some varibles were set properly. . . IMPORTANT: For users from older installs, please make sure that in your .gitolite.rc; $GL_PACKAGE_CONF="/usr/share/gitolite/conf" $GL_PACKAGE_HOOKS="/usr/share/gitolite/hooks" before re-running gl-setup. |
Description of problem: The gitolite source RPM contains a patch called "gitolite-1.5.7-rpm.patch". One of the bits in this patch is: - ln_sf("$GL_ADMINDIR/hooks/common", "*", "$repo/hooks"); + ln_sf("/usr/share/gitolite/hooks/common", "*", "$repo/hooks"); This breaks the ability to place hooks under the gitolite home directory in /var/lib/gitolite/.gitolite/hooks/common, as documented here: http://sitaramc.github.com/gitolite/doc/2-admin.html#_using_hooks I don't understand why this patch is applied, because the code a few lines below should have handled the functionality that it gives you: ln_sf("$GL_PACKAGE_HOOKS/common", "*", "$repo/hooks") if $GL_PACKAGE_HOOKS; Version-Release number of selected component (if applicable): 1.5.7-2.1.el6 How reproducible: Always Steps to Reproduce: 1. Create working gitolite server with this RPM 2. Place a hook in /var/lib/gitolite/.gitolite/hooks/common. 3. Run the gl-setup script to update hooks Actual results: No hooks are installed Expected results: Hooks should be installed in the gitolite repos Additional info: In addition to this problem, the gitolite RPM contains several .orig files from patches in /usr/bin. I'm assuming this is accidental.