great idea by Robin Smidsrød: since users are already capable of
authenticating themselves to gitolite via ssh keys, use that to let them
set or change their own HTTP passwords (ie, run the "htpasswd" command
with the correct parameters on behalf of the "git" user on the server)
code, rc para, and documentation. In fact everything except... ahem...
testing ;-)
and while we're about it, we also reorganised the way these helper
commands (including the venerable "info" are called)
This is actually a pretty big deal, and I am seriously starting wonder
if calling this "gito*lite*" is justified anymore.
Anyway, in for a penny, in for a pound...
This patch implements a generic way to allow access control for external
commands, as long as they are invoked via ssh and present a server-side
command that contains enough information to make an access control
decision.
The first (and only, so far) such command implemented is rsync.
Please read the changes in this commit (at least the ones in conf/ and
doc/) carefully.
Stop conflating the privilege to push changes to the admin repo with the
privilege to get a shell on the server.
Please read doc/6 carefully before upgrading to this version. Also
please ensure that the gitolite key is *not* your only means to get a
command line on the server
Gitolite allows you to restrict changes by file/dir name. The syntax
for this used "PATH/" as a prefix to denote such file/dir patterns.
This has now been changed to "NAME/" because PATH is potentially
confusing.
While this is technically a backward-incompatible change, the feature
itself was hitherto undocumented, and only a few people were using it,
so I guess it's not that bad...
Also added documentation now.
"repo @all" can be used to set permissions or configurations for all
already defined repos. (A repository is defined if it has permission
rules associated, empty "repo" stanza or "@group=..." line is not enough.)
For example to allow a backup user to clone all repos:
# All other configuration
[...]
repo @all
R = backup
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 in a deny rule doesnt work as it might look in the config file,
because @all rights are checked last. This is fine if you dont have any
DENYs (and so rule order doesn't matter), but with DENY it causes some
problems.
I never bothered to document it because I did not expect that any repo
that is "serious" enough to have deny rules *at all* should then allow
*any* kind of "write* access to @all. That's a very big contradiction
in terms of paranoia!
Translation: this will not be supported. Don't bother asking. You know
who you are :)
Well, something even more outrageous than deny rules and path-based
limits came along, so I decided that "rebel" was actually quite
"conformist" in comparision ;-)
Jokes apart, the fact is that the access control rules, even when using
deny rules and path-limits, are still *auditable*. Which means it is
good enough for "corporate use".
[The stuff that I'm working on now takes away the auditability aspect --
individual users can "own" repos, create rules for themselves, etc.
So let's just say that is the basis of distinguishing "master" now.]
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.
- example config file is now all comments (should have been that way anyway)
- we detect if it is an upgrade and act accordingly (see below)
IMPORTANT: we assume that $admin_name remains the same in an upgrade -- that's
how we detect it is an upgrade! Change that name or his pubkey, and you're
toast!
- added comments to easy install to help do it manually
- README: some stuff moved to tips doc, brief summary of extras
(over gitosis) added
- INSTALL: major revamp, easy install and manual install,
much shorter and much more readable!
plus other docs changed as needed, and updated the tips doc to roll in
some details from "update.mkd" in the "ml" branch
collect the delegated config fragments from correspondingly named branches of
the gitolite-admin repo, and put them all in conf/fragments/
also deprecate changes to conf and keydir locations from now on
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
(thanks to SethX for feedback)
- install: a little more verbosity in the mkdir
- install and example conf: some of the help text made more clear
- auth: error message on bad $cmd is now clearer, plus no perl-warnings to
confuse people
- 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
- install.sh is now install.pl (had to happen sooner or later!)
- now handles updates more gracefully, doesn't overwrite important stuff :)
- makes the install sequence much easier to understand
(just run it and follow the prompts!)
- made ~/.gitolite.rc much clearer to edit
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
