This reverts commit 6576e82e33.
On oddball configs, where the shell key is reused as the gitolite key by
smart( people|-alecks), the ls-remote stops the program dead, preventing
the "git add" and "git commit" that seed the admin repo.
This makes extra work in terms of fixing it after the fact; removing it
makes the install go further, and all you need to do is (1) delete the
first line from ~/.ssh/authorized_keys on the server and (2) back on the
client do a "git clone gitolite:gitolite-admin".
OK so it needs to be removed. Explaining that was the easy part! The
hard part is explaining why removing it is harmless.
Look at the commit tree around that commit, and see that the commit
before that (b78a720) was partially reverted in e7e6085. b78a720
removed the new_repo call from compile, forcing it to happen only on
auth, which forced this workaround for seeding the admin repo.
Since e7e6085 reverted that part of b78a720, giving back new_repo
functions to compile, this line of code wasn't doing any good. QED and
all that :)
for those not yet able to upgrade (or until I merge this into the branch
you care about), if you have a repo called, say "bk2git", just refer to
it as "bk2git.git" in the clone command!
[Thanks to Mark Frazer for finding this...]
"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>
".../gl-auth-command username" is the normal command that authkeys
forces, and this prevents that key from being used to get a shell.
We now allow the user to get a shell if the forced command has a "-s"
before the "username", like ".../gl-auth-command -s sitaram".
(Now that a plain "ssh gitolite" gets you a shell, there's a new "info"
command that such privileged keys can use to get basic access info).
Thanks to Jesse Keating for the idea! I can't believe this never
occurred to me before, but I guess I was so enamoured of my "innovation"
in converting what used to be an error into some useful info I didn't
think a bit more :/
Looks like I'd forgotten this when I did the autoviv code. Repos
created via gl-compile (when you add a new repo to the config file and
push) worked fine, but repos created via gl-auth (when you autoviv a
repo, wild or not) did not.
This *should* be merged into wildrepos soon after testing; wildrepos
will have a lot more autoviv-ing than master.
The admin repo's post-update hook needs to know where $GL_ADMINDIR is,
and we had a weird way of doing that which depended on gl-install
actually munging the hook code.
We also always assumed the binaries are in GL_ADMINDIR/src.
We now use an env var to pass both these values. This removes the weird
dependency on gl-install that the post-update hook had, as well as make
running other programs easier due to the new $GL_BINDIR env var.
Git repository configurations can be set/unset by declaring "config"
lines in "repo" stanzas in gitolite.conf. For example:
repo gitolite
config hooks.mailinglist = gitolite-commits@example.tld
config hooks.emailprefix = "[gitolite] "
config foo.bar = ""
config foo.baz =
The firs two set (override) the values. Double quotes must be used to
preserve preceding spaces. Third one sets an empty value and the last
removes all keys.
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 :)
all of this is prep for the upcoming, all-new, chrome-plated,
"wildrepos" branch :)
- many variables go to gitolite.pm now, and are "our"d into the other
files as needed
- new functions parse_acl, report_basic to replace inlined code
consider:
repo = "some desc" # some comment
(and note that the regex for recognising a description expects that
dblquote to be the *last* character on the line)
part of comment on b78a720cee:
The only reason it's getting into master is because it looks cool!
I hate it when something that looks cool doesn't work right :(
creating a repo on gitolite-admin push is *needed* in order to get
descriptions and export-ok files to work right
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.
the "create a new repo" code moves from compile to auth.
Only someone who has W access can create it, but he can do so even on a
"R" operation (like clone or ls-remote).
This is a pre-requisite for rebel's wildcard repos, where
autovivification is the only way you can create arbitrary repos matching
a pattern.
The only reason it's getting into master is because it looks cool!
----
OK that's a lie; the real reason is to keep the two branches as similar
as possible, though they;ve diverged quite a bit since the "only
one-line difference" days where "rebel" just meant "deny/exclude"
rules!)
writing the export_ok files and the gitweb project list are now
unconditional. They're idempotent anyway, and I doubt anyone cared
about all the fancy logic to detect and report *just* the new ones on
each compile.
This paves the way for gitweb ownership to be added later; that code was
becoming too complex otherwise...
- refuse to install to root
- when a pubkey is being used that was not freshly created by
ourselves, warn the user that this key can not be used to get shell
access to the server. Prevents some corner cases of people being
locked out...
Also, change the final message to be even more clear that this is all on
the workstation, not the server
I don't have a use for "@all" at all (pun not intended!) other than the
"testing" repo, but <teemu dot matilainen at iki dot fi> sent in a patch
to mark those repos with "R" and "W" in the permissions list, and I
started thinking about it.
This could actually be useful if we *differentiated* such access from
normal (explicit username) access. From the "corporate environment"
angle, it would be nice if a project manager could quickly check if any
of his projects have erroneously been made accessible by @all.
So what we do now is print "@" in the corresponding column if "@all" has
the corresponding access.
Also, when someone has access both as himself *and* via @all, we print
the "@"; printing the "R" or "W" would hide the "@", and wouldn't
correctly satisfy the use case described above.
- it appears that what we call $repo_base, gitweb already needs as
$projectroot
- allow read of repos defined as readable by @all
plus some minor declaration changes to make the sample code work as is
(thanks to teemu dot matilainen at iki dot fi)
We detect an upgrade situation by the presence of
$GL_ADMINDIR/conf/gitolite.conf -- if it exists, we reason, this is not
a fresh install. And if so we skip setting up PTA, and the initial
clone.
Well, turns out this is not always true. I've had a few cases where the
first install didn't go right, but left enough stuff in to make the
subsequent attempt think this is an upgrade.
[This mostly happened to me when I was testing the "oldgits" branch, and
also when I was making it work from msysgit I think... regardless of
why, it'd be good to fix]
So this changes the flow somewhat. Now the *only* difference between a
fresh install and an ugrade is the "initial_conf_key" function call (you
don't want to overwrite an existing conf file or keydir!)
I was trying to determine how close gitolite can come to the ACL model
of a proprietary product called codebeamer, and one of the items was how
to make a "role" (like QA_Lead) have different "members" in different
projects.
I then realised delegation already does that! Which is great, but as I
thought about it more, I realised... well, we'll let the in-code
comments speak for themselves :-)
Anyway, all it needed was a 1-line fix, luckily... <phew> And it would
have only affected people who use delegation.
- all $HOME/blah becomes "$HOME/blah" (bl**dy "Documents and Settings" crap)
- replace bash regex with perl, and in one case replace the check with
something else
- rsync changed to appropriate scp
- since we no longer insist on running from a specific directory, create
tmpgli dir *after* you cd to the right place
msysgit needs this on the initial clone, so it has to be on master. It
doesn't seem to "apply" the gitattributes if you checkout a different branch
later that has that setting; didn't investigate why
