FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Infrastructure

 
 
LinkBack Thread Tools
 
Old 12-21-2010, 06:29 PM
Jesse Keating
 
Default Slush break requested -- Upgrade gitolite package on pkgs01 (pkgs.fedoraproject.org)

Current situation:

pkgs01 was built partially by puppet and partially by hand. We never
went through the step of completely rebuilding pkgs01 via puppet.
Recently I (re)discovered that the gitolite package has locally modified
files (4 of them: /usr/bin/gl-auth-command, /usr/bin/gl-compile-conf,
/usr/share/gitolite/hooks/common/update, /usr/share/perl5/gitolite.pm).
Also most unfortunately it appears I did not keep patch files around,
rather I directly modified files while attempting to make things work.
Shame on me

I have spent the last few days working on an updated package for
gitolite for EL6, to go from 1.5.3 to 1.5.7. Part of this motivation
was to get a new feature for error messages when attempting to clone a
repo that doesn't exist, and the other part is to have proper upstream
support for our setup, eliminating the need to locally modify files.

I have tested the new package on pkgs01.stg.phx2 and adjusted the
gitolite.rc file accordingly (changed in puppet stg branch). I've
tested that expected access works, and expected denials work as well.
I'm confident that the new package + changes from puppet will work in
production.

I'd like to get pkgs01 production to a state where it can be built
entirely from puppet and function correctly. There are a couple
different options at this point:

A) Upgrade gitolite package and cherry-pick gitolite.rc changes from stg
in puppet.

B) rebuild existing gitolite package with local modifications done as
patches and make available in the infrastructure repo (and upgrade the
package in production)

C) use puppet hotfix module to stash the modified files so that puppet
puts them in place.

I'm requesting A, and offering to be on-call for this system during the
break, should something go wrong.

More data:

The changes in gitolite between 1.5.3 and 1.5.7 largely don't effect us.
The biggest change that does is proper upstream support for our setup,
where we don't have gitolite manage ssh files or repo creations. Our
ACL generation script does not need to change.

Diff of gitolite.rc changes:

diff --git a/modules/gitolite/files/distgit/gitolite.rc
b/modules/gitolite/files
index 4af1be8..03149e3 100644
--- a/modules/gitolite/files/distgit/gitolite.rc
+++ b/modules/gitolite/files/distgit/gitolite.rc
@@ -89,6 +89,9 @@ $GIT_PATH="";

$GL_BIG_CONFIG = 1;
$GL_NO_DAEMON_NO_GITWEB = 1;
+$GL_NO_CREATE_REPOS = 1;
+$GL_NO_SETUP_AUTHKEYS = 1;
+

The upstream author of gitolite will be available during the break
should we have any emergency issues.

Summary:

I'm looking for a couple +1s to attempt option A of upgrading gitolite
and merging the gitolite.rc change into production. I will make backups
of the modified files should we need to roll back the changes.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 

Thread Tools




All times are GMT. The time now is 05:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org