The admin repo's post-update hook needs to know where $GL_ADMINDIR is,
and we had a weird way of doing that which depended on gl-install
actually munging the hook code.
We also always assumed the binaries are in GL_ADMINDIR/src.
We now use an env var to pass both these values. This removes the weird
dependency on gl-install that the post-update hook had, as well as make
running other programs easier due to the new $GL_BINDIR env var.
Git repository configurations can be set/unset by declaring "config"
lines in "repo" stanzas in gitolite.conf. For example:
repo gitolite
config hooks.mailinglist = gitolite-commits@example.tld
config hooks.emailprefix = "[gitolite] "
config foo.bar = ""
config foo.baz =
The firs two set (override) the values. Double quotes must be used to
preserve preceding spaces. Third one sets an empty value and the last
removes all keys.
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
we had usurped the email style syntax to separate multiple keys
belonging to the same person, like sitaram@desktop.pub and
sitaram@laptop.pub. If you have so many users that you need the full
email address to disambiguate some of them (or you want to do it for
just plain convenience), you couldn't.
This patch fixes that in a backward compatible way. See
doc/3-faq-tips-etc.mkd for details.
all of this is prep for the upcoming, all-new, chrome-plated,
"wildrepos" branch :)
- many variables go to gitolite.pm now, and are "our"d into the other
files as needed
- new functions parse_acl, report_basic to replace inlined code
consider:
repo = "some desc" # some comment
(and note that the regex for recognising a description expects that
dblquote to be the *last* character on the line)
part of comment on b78a720cee:
The only reason it's getting into master is because it looks cool!
I hate it when something that looks cool doesn't work right :(
creating a repo on gitolite-admin push is *needed* in order to get
descriptions and export-ok files to work right
Summary: much as I did not want to use "excludes", I guess if we don't put the
code in "master" it's OK to at least *write* (and test) the code!
See the example config file for how to use it.
See "design choices" section in the "faq, tips, etc" document for how it
works.
the "create a new repo" code moves from compile to auth.
Only someone who has W access can create it, but he can do so even on a
"R" operation (like clone or ls-remote).
This is a pre-requisite for rebel's wildcard repos, where
autovivification is the only way you can create arbitrary repos matching
a pattern.
The only reason it's getting into master is because it looks cool!
----
OK that's a lie; the real reason is to keep the two branches as similar
as possible, though they;ve diverged quite a bit since the "only
one-line difference" days where "rebel" just meant "deny/exclude"
rules!)
writing the export_ok files and the gitweb project list are now
unconditional. They're idempotent anyway, and I doubt anyone cared
about all the fancy logic to detect and report *just* the new ones on
each compile.
This paves the way for gitweb ownership to be added later; that code was
becoming too complex otherwise...
I was trying to determine how close gitolite can come to the ACL model
of a proprietary product called codebeamer, and one of the items was how
to make a "role" (like QA_Lead) have different "members" in different
projects.
I then realised delegation already does that! Which is great, but as I
thought about it more, I realised... well, we'll let the in-code
comments speak for themselves :-)
Anyway, all it needed was a 1-line fix, luckily... <phew> And it would
have only affected people who use delegation.
You can now add your own hooks into src/hooks/ and they get propagated
along with the update hook that is present there now. Please read the
new section in the admin document, and make sure you understand the
security implications of accidentally fiddling with the "update" script.
This also prompted a major rename spree of all the files to be
consistent, etc. Plus people said that the .sh and .pl suffixes should
be avoided (and I was feeling the same way). I've also been
inconsistent with that "gl-" prefix, so I cleaned that up, and the 00-
and 99- were also funny animals.
Time to get all this cleaned up before we get 1.0 :)
So these are the changes, in case you're looking at just the commit
message and not the diffstat:
src/pta-hook.sh -> src/ga-post-update-hook
src/conf-convert.pl -> src/gl-conf-convert
src/00-easy-install.sh -> src/gl-easy-install
src/99-emergency-addkey.sh -> src/gl-emergency-addkey
src/install.pl -> src/gl-install
src/update-hook.pl -> src/hooks/update
Packaging gitolite for debian requires the rc file to be in /etc/gitolite.
But non-root installs must still be supported, and they need it in $HOME.
This means the rc file is no longer in a fixed place, which needs code to find
the rc file first. See comments inside new file 'gitolite.pm' for details.
The rest of the changes are in the other programs, to replace the hard-coded
rc filename with a call to this new code.
- add better comments on the 2 main hashes
- work around an inefficiency caused by the exclude prep code needing
a list instead of a hash at a certain place
[Note: this is a fairly involved commit, compared to most of the others.
See doc/5-delegation.mkd for a user-level feature description.]
parse delegated config fragments (found as conf/fragments/*.conf). Any
repos being referenced within a fragment config *must* belong to the
"@group" with the same name as the fragment.
That is, a fragment called conf/fragments/abc.conf can only refer to repos
that are members of the "@abc" repo group. It cannot specify access
control for any other repos. If it does, those settings are ignored, and
a warning message is produced.
since the delegated config must have the flexibility of (re-)defining
group names for internal convenience, and since all such definitions go
into the same "groups" hash, it is quite easy for conf/fragments/abc.conf
to write in its own (re-)definition of "@abc"! That would be a neat
little security hole :)
The way to close it is to consider only members of the "@abc" groupset
defined in the main ("master") config file for this purpose.
Again, prep for delegation, when we'll be reading fragments of config rules
from various files and tacking them onto the %repos hash.
note: this patch best viewed with "git diff -w", clicking "Ignore space
change" in gitk, or eqvt :-)
- warn about files in keydir/ that dont end with ".pub"
- warn about pubkey files for which the user is not mentioned in config
- warn more sternly about the opposite (user in config, no pubkey!)
update hook: add reponame to message on deny
auth: minor typo
Summary:
DONT forget to run src/gl-compile-conf as the last step in the upgrade
Details:
The compiled file format has changed quite a bit, to make it easier for the
rebel edition coming up :-)
compile:
- we don't split RW/RW+ into individual perms anymore
- we store the info required for the first level check separately now:
(repo, R/W, user)
- the order for second level check is now:
repo, user, [{ref=>perms}...] (list of hashes)
update hook logic: the first refex that:
- matches the incoming ref, AND
- contains the perm you're trying to use,
causes the match loop to exit with success. Fallthrough is failure
- detect/warn git version < 1.6.2
- create documentation with details on client-side workaround
- change the "git init --bare" to (older) "git --bare init", since the old
syntax still works anyway
why should just usernames have all the fun :) The "expand_userlist" function
is now "expand_list" and serves generically. The example conf has also been
updated correspondingly
- logs go into $GL_ADMINDIR/logs by default, named by year-month
- logfile name template (including dir prefix) now in $GL_LOGT
- two new env vars passed down: GL_TS and GL_LOG (timestamp, logfilename)
- log messages timestamps more compact, fields tab-delimited
- old and new SHAs cut to 14 characters
system("...") run from perl on sol does not seem to like "~" (regardless of
what $SHELL is set to), so use $ENV{HOME} instead
thanks again to evocallaghan
In the "create new repos" loop, we need an absolute value for REPO_BASE, in
order to be able to chdir back and forth. But (taking the "normal user with
no privileges" assumption too far!) we assumed REPO_BASE would be within
$HOME, and relative to it. So it fails when someone wants the repo_base
elsewhere.
Now we don't prefix $HOME if REPO_BASE is already absolute (begins with a "/")
bug reported by evocallaghan
