THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO
NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade
means should be fine, though.
Originally, we only allowed "R" and "RW" as categories of users supplied
to the `setperms` command. These map respectively to "READERS" and
"WRITERS" in the access rules.
Now:
- we prefer READERS instead of R and WRITERS instead of RW
- we allow the admin to define other categories as she wishes
(example: MANAGERS, TESTERS, etc). These do not have abbreviations,
however, so they must be supplied in full.
PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for
more info. This is a VERY powerful feature and if you're not careful
you could mess up the ACLs nicely.
Backward compat note: you can continue to use the "R" and "RW"
categories when running the "setperms" command, and gitolite will
internally convert them to READERS and WRITERS categories.
----
implementation notes:
- new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of
the allowed categories in a gl-perms file; defaults to "R RW" if not
specified
- wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if
"R $user", $r = '@all' if "R @all", and similarly with $w and "RW".
Instead it returns $c and a new hash that effectively gives the same
info, but expanded to include any other valid categories (listed in
GL_WILDREPOS_PERM_CATS)
- consequently, the arguments that parse_acl takes also change the
same way
- (side note: R and RW are quietly converted to READERS and WRITERS;
however, new categories that you define yourself do not have
abbreviations)
- setperms validates perms to make sure only allowed categories are
used; however even if someone changed them behind the scenes,
wild_repo_rights will also check. This is necessary in case the
admin tightened up GL_WILDREPOS_PERM_CATS after someone had already
setperms-d his repos.
- as a bonus, we eliminate all the post-Dumper shenanigans, at least
for READERS and WRITERS. Those two now look, to the compile script,
just like any other usernames.
Till now I did not have an RC var whose name was a prefix of another
valid RC var, so I never noticed that editrc would set the longer one
also when you set the shorter one.
Fixed
Well from now on they will be called "YourName".
Even better quote from essial on #git (after literally typing in
"sitaram.pub" instead of substituting his name as the instructions [in
bold] tell him to do):
come on you know how ubuntu users are
if they see fixed width fonts inside a box they immediately copy-paste it
UBUNTU USERS: I DIDN'T SAY THAT, SOMEONE ELSE DID! For details see
http://colabti.org/irclogger/irclogger_log/git?date=2010-11-04#l2417
[Although, since you apparently are quite happy to use a system that
default installs mono I doubt these little jibes matter to you
anyway...]
[idea: distribute my own pubkey with gitolite and instantly get access
to every gitolite install that is not behind a firewall, anywhere in the
world. No one will notice or realise what I'm doing - MUAHAHAHAHA!!!]
- get_rights_and_owner normalises its arg1 by stripping .git if
supplied, then sets the variable "repo" to the result as a side
effect
- new "help" adc with some default text but main purpose is to allow
site local help text
- other adc's refer to 'help' adc when appropriate
- 'undelete' renamed to 'restore'; that's what the KDE "trashcan"
program calls that operation
- minor typo in sample script in documentation
- main adc doc points to contrib/adc/repo-deletion.README now
This was a very old quirk/oddity. Doing
R = @all alice
would fail, but you could still do
R = @all
R = alice
Now we fixed it so it's consistent.
----
This also fixed a curious bug that no one ever caught:
@all = u1 u2 # yes -- there was no check on redefining @all
repo foo
R = @all u3 # now would not fail because of defining @all
would have given only those 3 users R access to foo, not really @all
users! This was because the previous failure message was an artifact of
not finding an expansion for @all, not a genuine "why are you saying
@all and then specifying some user explicitly" warning!
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.
The sudo adc should make life easier for any admin wishing to run an adc
as some other user.
As a result, the rmrepo adc also goes back to its simple roots. Now you
just run it via the sudo adc if you (as gitolite admin) needs to rmrepo
some user's repo.
- dont do anything if he doesn't even have read access
- move the GL_USER check to the right place! (to when you actually
will be doing something)
That spurious check for GL_USER that we (re)moved would not only have
shown an incomplete set of log lines, it would have made the wrong log
line look like the "last" one. (No real harm would result, of course,
since the update-ref would blow up due to the actual SHA being something
other than what it was expecting, but it would be confusing to the 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.
for people who don't get the continual reference to towels when talking
about the "gl-dont-panic" program, all I can say is that your education
is incomplete ;-)
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.
