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)
(can_* == can_read, can_write, and can_create)
See top of contrib/adc/adc.common-functions for more on this.
Note: the old style (calling get_rights_and_owner with $repo, then
checking $perm_read, $perm_write, etc.), will still work fine.
gl-shell-setup has a "run as hosting user" piece that basically
automates the adding of the user's (new) key to the admin repo.
This is now gone. (It's not that hard to automate yourself if you want
to do it anyway, using gl-admin-push).
I did this because I needed to allow someone in through a gateway, and
realised that that has the exact same needs. So the whole scheme has
been changed to treat the proxy and the gitolite host as being two
different servers.
At that point it became cumbersome to do the second bit, and I left it
out.
Other changes:
- you can define exceptions for the default shell in gl-shell
- the doc has been simplified.
I got tired of being told "TL;DR". Now the online versions of most
documents fit on a page or two, or at least most of them do. The rest
has been split out (and you can see the links to the split out sections
right where the text is in the raw Markdown).
This is much more pleasant to read, and I've improved the linking so
it's much less effort for me to keep the links correct.
Normally, I use the word "user" in gitolite to mean *my* users, who are
actually admins on their setups. All my documentation has been geared
to that class of person.
Last night my most famous "user" (not "admin", a real gitolite user)
mentioned that he found it very hard to find info on what a *user* could
do, and he was right. So here goes...
any sane system should have $HOME/bin in $PATH, but apparently there are
quite a few insane systems around ;-)
(also changes the usage message etc a bit)
e5c3b0e on a machine without CGI::Util makes gitolite unusable. I
checked that it was part of perl core, since `corelist CGI::Util`
returns `CGI::Util was first released with perl 5.006001`.
But apparently Fedora (at least) splits out core perl itself into
smaller chunks. And on my devbox I never noticed because I had gitweb
installed, which pulled it in as a dep.
I found this out when I tried to upgrade my own prod server!
For example, this program
#!/bin/sh
die() { echo die called with $1; exit 1; } >&2
die foo
die bar
will print *both* those messages!
I honestly don't care if this is posix or not, but it is BRAIN DEAD for
the ">&2" to change the meaning from {} to ()
Oh and the grep thing is even worse.
echo foo | grep ^/
works fine in an interactive shell but in a script it attempts to
*execute* "/", complains, while simultaneously complaining about usage
of grep.
It's almost like it's treating ^ like |
- support for ADCs with unchecked arguments
- rsync, htpasswd, and svnserve gone from core; turned into ADCs
Backward compat breakage and fix: Please see documentation for details,
but if you're using gitolite to control rsync you will now need to setup
ADCs (admin defined commands), and install at least the new "rsync" ADC.
----
Thanks to Joey Hess (see commit prior to this) for forcing me to stop
being lazy and get this out of my long term todo list.
- strictly speaking, this should be phrased: "deny" rules for the
first level access check
- requires a gitolite option to be set, like so:
config gitolite-options.deny-repo = 1
(Not sure how I missed this earlier, but if you can't upgrade yet, a
mitigation is to note the job number that gets printed on your terminal
when a mirror push starts, and look a log file entries beginning with
that number.)
