(thanks to Kevin Fleming for the need/use case)
TODO: tests
TODO: proper documentation; meanwhile, just read this:
- you can give gitweb and daemon read rights to wild card repos also,
and it'll all just work -- when a new repo is 'C'reated, it'll pick
up those rights etc
- you can assign descriptions (and owners) to individual repos as
before, except now you can assign them to repos that actually were
created from wild card patterns. So for example, you can define
rules for
repo foo/..*
and then assign descriptions like
foo/repo1 = "repo one"
foo/repo2 = "repo two"
foo/dil "scott" = "scott's dilbert repo"
However, this only works for repos that already exist, and only when
you push the admin repo.
Thumb rule: have the user create his wild repo, *then* add and push
the admin config file with the description. Not the other way
around.
implementation notes:
- wildcard support for git config revamped, refactored...
it's not just git config that needs wildcard support. daemon and
gitweb access also will be needing it soon, so we start by factoring
out the part that finds the "pattern" given a "real" repo name.
- GL_NO_DAEMON_NO_GITWEB now gates more than just those two things;
see doc/big-config.mkd for details
- we trawl through $GL_REPO_BASE_ABS *once* only, collecting repo
names and tying them to either the same name or to a wild pattern
that the repo name was created from
- nice little subs to setup gitweb, daemon, and git config
- god bless $GL_REPOPATT and the day I decided to set that env var
whenever a user hits a wild repo in any way :-)
- the code in gl-compile-conf is very simple now. Much nicer than
before
make it a sort of "super global" (an ENV var) all through, because
*everyone* seems to need it *and* this variable is pretty much constant
for the entire install
- new GL_GITCONFIG_WILD to gate it
- new sub to do all the hard work (refactored from a few lines in
compile)
- split the call from "compile" into two sets -- first for non-wild,
then for wild
This ensures that after a "compile" (admin push) all git configs are
applied.
TODO: apply them when a new wild repo is created by a user, and then on
the "fork" (admin-defined command)
conf/example.gitolite.rc
- "slave mode" flag to disable pushes and "list of slaves"
hooks/common/post-receive.mirrorpush
- code to push to the mirror, creating the repo if needed
src/mirror-shell
- shell for master pushing to a slave, because we don't actually want
to go through gitolite itself, yet we have to take care of
$REPO_BASE being wherever. And of course we have to set
GL_BYPASS_UPDATE_HOOK to 1 for the push to happen!
src/gl-mirror-sync
- manually runnable program to sync from current server to another
NOTE: there are no *functional* changes in this for *normal*
gitolite users. It's just a chunk of code moving into a new
subroutine etc.
KDE needs to populate the authkeys file from an LDAP store. Other large
projects may have similar means to store keys, depending on how they do
their user provisioning so a generic solution is worth exploring.
This means that in these special cases
- the gitolite-admin repo's keydir/ directory is not needed [1]
- but they still need to create the authkeys file somehow
Implementation:
- write a shim program to make the authkeys-generation code callable
from the command line/shell.
- set $GL_NO_SETUP_AUTHKEYS=1 in the rc file to disable authkey
generation during a "compile" (admin repo push)
Expected usage of new program gl-setup-authkeys:
- LDAP change triggers some script
- this script collects all keys from LDAP, puts them in some
directory, and then calls gl-setup-authkeys, passing it the name of
the directory
ALSO PLEASE SEE COMMENTS AT THE TOP OF THE NEW PROGRAM IN THIS COMMIT
FOR SOME IMPORTANT DISCUSSION.
----
Footnotes:
[1] It doesn't make sense to use it if the keys will be maintained by
some other entity and can be called up as needed, and it adds an
unnecessary extra step.
- stop erroring out if run from elsewhere than $HOME (by localising
the "cd" we need somewhere in between)
- catch the admin@home.pub usage early
- minor fix to the backticked commands
- gl-setup now does 'chmod go-rwx .ssh'
gl-emergency-addkey replaced by totally new gl-dont-panic, which does
more (including recovering from a botched push, not just lost keys), is
cleaner, and works for all install methods
sometimes I want to quickly test a few lines of change within the context of
a currently-running/just-ran test, *without* doing the rollback etc.
Here's how you do that now:
- in your source tree, make the change and then run:
cp -a src hooks contrib/adc /some/tmp/place
- go to the tester userid and re-run your tests like so:
GQT=/some/tmp/place ./test-driver.sh
it'll rollback as normal then overwrite src and hooks from $GQT
Also, there's now a "dbg" sub that can be used for quick printf-style
debugging.
"WARNING: a pubkey file can only have one line (key); ignoring $pubkey"
message was a bit confusing, because elsewhere the docs claim multiple
keys are suported. Added note on how to add multiple keys for single
user and pointer to the doc file concerned.
Fedora, till now, had no hope in hell of running the info command. Why?
Because the output of the info command is semantically the same as the
output of the compile script *before* the big-config mode was created.
And we all know how _that_ went ;-)
So now you get to give "info" a partial reponame or a pattern, just like
in the case of "expand". And if you're under GL_BIG_CONFIG this pattern
is mandatory. And if you try to cheat it'll still stop after showing 5
entries to prevent (accidental?) DOSs
Anyway, see doc changes in this commit for more details.
thanks to Jesse from the Fedora team for pointing this out. They use
GL_NO_CREATE_REPOS, so sometimes the physical repo on disk doesn't exist
at the time the config file is written.
We're talking about non-wild repos only here, so this means it should
never happen to normal gitolite users. But now -- in the rare case that
there is a disk-side problem -- people who have rights to a repo will
get a more specific error message.
there are people who cannot click a "doc/" link on the first google hit,
and think you have to clone the whole thing to see the docs...
I suspect they aren't even hitting the "read more" link that github
shows in the description blurb, or if they go there they aren't even
going to the end of the second para, which contains a nice link.
More and more people are using one of the first 3 methods of install
(the ones that don't involve running "src/gl-easy-install" from the
client side) usualy due to RPM/DEB being available now.
Previously, the ending message on running that command was serving this
purpose, and so it never really got written down in so many words.
[thanks to antgel for catching this]
----
while we were there, we removed a now-obsolete section that talks about
how to use just one key; there are better methods now
this allows the first part of the repo name (if wildcard repos are
activated) to have a regex like [a-zA-Z0-9]+.
----
Note added by committer:
he assumption used to be that all wildcard repos will have some common
prefix like "users", but I did not imagine it would be like
repo [a-zA-Z0-9]+/users/CREATOR/[a-zA-Z0-9]+
(viz., the "users" is in the middle).
Sounds reasonable...
allows a default 'setperms' string to be set for new wildcard
repositories.
Also, fix a bug in the fork script where a failure in the git command
would still cause the rest of the script to attempt to run.
fixes:
- allow "grouped" admins to get basic info for other users by checking
more than just the *user*'s right to the admin repo
- report_basic is called with a $user argument, but it's not easy
(right now) to propagate this to parse_acl. Use a simple kludge,
(for now at least).
thanks to bcooksley for catching this
This is what I *should* have done back then; thanks to Jeff Mitchell for
pointing out a problem with the old method.
The old one is *definitely* a kludge. <shamefaced grin>
The main use case is for people who give most people access via @all,
which is somewhat unusual but in some situations it probably makes
sense.
See also a related commit made a month or so ago (aa8da93).
Actually these two lint checks were made to help people spot typos in
the config, which sorta becomes meaningless if you have more than a few
such cases anyway, so for most people it should not matter that I am now
merely summarising the number of such cases if there are more then 10.
The log message format has changed. All log messages now have a common
prefix (timestamp, user, IP). This is followed by $SSH_ORIGINAL_COMMAND
(or, in one special case, the name of the user's login shell). Any
further text appears after this (currently this only happens in the case
of a successful push -- one for each ref pushed successfully)
in addition, due to "+" becoming a valid character in a normal reponame,
(think gtk+, etc), the pattern
repo dev/CREATOR/.+
doesn't look like a wildcard repo anymore, so we add an extra check that
if CREATOR is mentioned, it *is* a wildcard.
This has been added *only* to the report_basic function; it doesn't
really matter anywhere else.
