I had someone delete the admin repo on the server, then run gl-setup
again, and complain that included config files did not get restored.
There have been others (see below) before with similar demands, but
those at least had the excuse of being provoked by genuine mistakes.
This guy was intentionally breaking stuff server side.
Wish I could say he was stupid, but actually he was probably smarter
than I. Just that his idea of the limits of gitolite's responsibility
was vastly different from mine.
----
[1] There was this guy who, as root, went on a "chmod go-rwx" spree for
security, which bollixed up gitweb access to all his repos, so he tells
me gitolite should be able to fix all the permissions on the next admin
push at least? (That is, instead of just setting umask as it currently
does, it should go on a chmod spree just like he did).
[2] Then there was the guy who told me gitolite should re-create all the
"gl-creater" files for his wildcard repos because he was restoring from
a git push --mirror backup and that doesn't preserve those files? I
tried to tell him that a git push --mirror doesn't preserve "config" or
"description" or "info/exclude" or any of the other files that git (not
gitolite) maintains, but he didn't care -- losing those did not affect
him (or he never had them), but losing these affected access control,
and it's my fault.
The old method of passing in usergroup info had some problems, which are
now fixed. It is also much easier to use now -- no more "wrapper"
script, plus it should work identially whether you use sshd or httpd.
See doc/big-config.mkd for details on the new method.
----
Notes on problems with the old method:
The old method for passing in usergroup info consisted of tacking them
on as extra arguments to gl-auth-command, after the username.
However, there are some problems with this method.
Some actions in gitolite look for permissions for users other than the
invoking user. Determining permissions for gitweb and daemon is one.
An admin asking for "info" on some other user, is another.
However, the list of groups sent in via the command line
pertains only to the invoking user, so these actions don't work
correctly. They may even pick up the wrong permissions.
What it all boils down to is that we need group information for any user
dynamically, instead of being passed a (static) list just for the
invoking user.
- hardcode 0700 mode for GL_ADMINDIR tree (thanks to ma at
ibitsense.com) for catching this
- honor REPO_UMASK for GL_REPO_BASE_ABS creation
- plus a minor doc update
- 79f0a5f ("(big one!) more than one wildcard may match a repo...")
makes some of the dire warnings about this irrelevant
- d1d2c3e and ad64f99 ("git config settings in wild repos: part 1" and
"...part 2") makes this caveat also useless
While we were about it, we added a quick intro and tried to make some
other details a little clearer.
As usual there's more documentation than code.
Unlike usual, however, this isn't completely tested. Please read the
documentation for details of what works, what doesn't, what has been
tested, what hasn't, and so on.
- all anchors prefixed by AUTO_ now
- some bad links fixed (maybe still a few I didn't catch)
- misc wording changes/additions (support section to README,
"technical skills" section to install doc, etc).
because someone else found the doc overwhelming. However, the suggested
reading order (which so far existed only on the wiki) was probably a
good thing to have at the top of the README, and the disclaimers about
ssh may help keep my sanity a little longer ;-)
jefferai pointed out that some of the links about this were broken, and
a quick look showed that it was described in multiple places too.
Brought it all together...
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
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
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.
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 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 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)
see doc/3 for details (look for "separating delete and rewind rights"
----
and for gerrit, this is one more thing it can do that we can too ;-)
[the original text was somewhat misleading. We mean "prevent someone
from creating a branch that they have permissions to push". That is
what is now possible, where it was not possible before.]
people will NOT read documentation, especially the bloody install
documentation. I'm about ready to throw in the towel and declare
gitolite unsupported, take-it-or-leave-it.
But I'm making one last attempt to refocus the install doc to better
suit the "I know I'm very smart and I dont have to read docs so it's
clearly your fault that I am not able to install gitolite" crowd.
As a bonus, though, I ended up making proper, hyper-linked, TOCs for
most of the docs, and moved a whole bunch of stuff around. Also finally
got some of the ssh stuff over from my git-notes repo because it really
belongs here.
