- 'dupkeys' -- catch duplicate keys in keydir
- 'email-check' -- "you can only push your own commits"
plus, 'merge-check' -- how we could have done the no-merges policy
- compile: VREF/ is special, like NAME/
- update hook: use a new "check_vrefs" sub to
- spawn helpers for each vref in @allowed_refs
- for each vref returned by the helper, call check_ref
OK I agree the starting line was *just* misleading enough to give the
opposite impression, but still, when the next para starts with "The
rules are..." wouldn't you expect people would read *that* too?
- redo it in perl
- make it flow easier, with all the cruft in subs
and overall, make it obvious that this program does for a manual install
what doc/packaging.mkd advices packagers to do.
- move wrap_mkdir() to gitolite.pm
- remove junk left over from days when dinosaurs ruled the world
- reuse setup_environment() from gitolite.pm instead of rolling our
own code for PATH and umask
part of it's function (the rest is harmless)
- and most important, remove the last vestiges of the old 'from
client' install method, in the form of 'if ($GL_PACKAGE_HOOKS)'
lines
- clean up the symlinking to be more precisely in line with
doc/hook-propagation.mkd (especially, remove the 'quirk' that
package hooks would also get copied to the user hooks area)
The instructions were written before gl-admin-push was created, I guess,
making things sound a lot more complicated than they should be.
Thanks to Nick (see gitolite mailing list messages, subject line
"replicating a gitolite installation") for helping me realise this
needed fixing.
This compensates for an selinux bug reported on #gitolite by John Hawley
(warthog9). sh/bash uses a tempfile to do this, which in turn causes
some problems in selinux; I really don't [need to] know more than that.
*Technically* this is a bug in selinux/policy, and would qualify for an
entry in "nagp"... but:
(1) the changes are small and localised
(2) the problem makes gitolite -- currently -- unusable with selinux,
and what use is a security program which can't run under selinux
(regardless of whose fault it is)?
and finally
(3) if I can't break my own rules for one of my most high-profile users
then what's the point of owning the code?
:-)
----
Implementation notes: I've only done this for code that is likely/meant
to be used in production
I also slip-streamed in a URL fix (from when I changed all the online
document rendering)
Please don't use this setting in a production system but in some
environments it is needed for completely automated *testing* to be able
to use ssh correctly.
Thanks to Kacper Kornet for catching this...
(by the way, there's a simple workaround if you are affected by this but
can't upgrade to this commit or later: just create an empty
$PROJECTS_LIST file, which is by default ~/projects.list)
If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will
get caught later when someone whom youhave given that role tries to
access the repo (look for another occurrence of the same error message
as this one).
So there's no access violation but it would be nice to be told upfront
that it won't work.
Apparently some people want gitolite-admin as a non-repo. Completely
outside gitolite, managed by puppet or such, and leaving only symlinks
for 'conf' and 'keydir' in $GL_ADMINDIR.
But then when they have to run 'gl-setup', the 'git add' complains about
the symlink. Hence this patch.
----
Meanwhile, if you're one of those puppet masters, here's the script I
gave them for the *compile* (this has nothing to do with this patch; I'm
just throwing it in here so I won't lose it):
#!/bin/bash
# let's say you install using "non-root" method. (Adjust GL_BINDIR for root
# method or package method).
# install normally, then make changes directly in $GL_ADMINDIR/conf and
# $GL_ADMINDIR/keydir. (Please leaves "logs/" and "hooks/" alone).
# Then run this:
export GL_ADMINDIR=$HOME/.gitolite
export GL_BINDIR=$HOME/bin
export GL_RC=$HOME/.gitolite.rc
cd $GL_ADMINDIR
$GL_BINDIR/gl-compile-conf
# BE SURE TO REMOVE THE ADMIN REPO ITSELF FROM conf/gitolite.conf, as well as
# repositories/gitolite-admin.git, lest a push by someone end up overwriting
# this hand- (or machine-) crafted config.
# you can get away even further from gitolite's control. You can, for
# example, set GL_NO_SETUP_AUTHKEYS in the rc file, and manage even the keys
# yourself. Just put the full path to $GL_BINDIR/gl-auth-command followed by
# the username in the "command=" part of the authkeys file you generate.
since gl-shell-setup runs as root, the comment in the generated key was
'root@...' instead of whatever userid it was being created for.
This does not affect gitolite or ssh but it seems some people don't
treat "comment" and "comment" and actually *do* stuff with it.
(only code is from author; commit message is from committer)
