TODO: if the verb doesn't actually contain "git-receive-pack", I am
assuming it is some sort of read. The list in services[] in
http-backend.c does not seem to look like any other verb is a "write";
need to check this with someone.
For normal git commands:
- PATH_INFO gives you the repo name
- REQUEST_URI gives you the verb
- we construct a fake SSH_ORIGINAL_COMMAND so the rest of the
processing does not have to change
For our special commands:
- PATH_INFO is actually the verb
- QUERY_STRING has the parameters
- we again fake out the SSH_ORIGINAL_COMMAND
- we print the extra HTTP headers in anticipation of the actual output
Either way, we also fake out the SSH_CONNECTION so that the IP address
can get logged ok
And of course REMOTE_USER is now the incoming userid
Finally, at the end, we exec GIT_HTTP_BACKEND instead of the normal one
adapted from code by kpfleming@digium.com. I basically cherry-picked
the top commit on "pu-work" (30068d1) on his fork at github, and made
some minor fixups to it
By default, @all does not include gitweb and daemon, but if that's what
you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL
variable in conf/example.gitolite.rc
This should hopefully be the final step in making wildrepos as close to
normal repos as possible. You can now do pretty much anything with them
that you can do with normal repos [1]
Implementation notes:
- compile puts out %groups into the compiled config file regardless of
GL_BIG_CONFIG because this feature needs it
- wild_repo_rights caches %groups because the part of the %groups hash
we care about will not change between calls in the same run
----
[1] **except** use the full-blown config file syntax within the gl-perms
file :-) I don't plan to do that; it's too complicated! [2]
[2] yeah yeah I know -- famous last words!
modifications:
- call setup_gitweb_access and setup_daemon_access from with
get_set_perms so when the user sets a perm explicitly it works
- in setup_gitweb_access, do not delete description file or
gitweb.owner if the repo is wild
- make the "fork" adc set gitweb.owner *and* call setperms using
GL_WILDREPOS_DEFPERMS
- add tests
bug fixes:
- gl-auth did not even *look* at GL_WILDREPOS_DEFPERMS when
auto-"C"reating a wild repo; fixed
- setup_gitweb_access did not delete the description file as
consistently as it deleted the owner
what will NOT work:
- removing gitweb permissions does not clear the name from
"projects.list". That's complicated, so just wait till the next
"compile" to make this happen
(thanks to Jefferai for driving this...)
----
mildly puzzling:
for some strange reason, after a "git ls-remote ...try3" in t58,
instead of not creating a "description" file, we started seeing a
73-byte file containing this message:
Unnamed repository; edit this file 'description' to name the repository.
I'm an idiot. I say I won't do it, then I go and do it anyway.
Fortunately, in this case, the code and execution remain exactly the
same for people who do not set $GL_PERFLOGT in the rc file, so it's
tolerable.
<evil grin> People who want even more than this can contact Greg Lonnon
(see the mailing list archives at
http://groups.google.com/group/gitolite for an obfuscated but easy to
guess email address) ;-)
plus it can also be matched by a normal repo line. In other words, with
repo foo/bar
RW = u1
repo foo/..*
RW = u2
user u2 has access to foo/bar (the non-wild does not cause the wild to
be completely ignored any longer)
implementation notes:
get_memberships:
- no more highlander ("there can only be one") for patterns in
@repo_plus
- return $wild as a space-separated list of matched patterns
collect_repo_patts:
- as of the last change to this section of code it appears we
weren't using the values anyway, but I had forgotten :-)
repo_rights: (big change: $wild no longer implies $creator present,
or vice versa)
- new type of "creator" (like "was_sitaram") is now possible
Implementation notes:
- %repo_config is now "our", not "my"
- collect_repo_patts now uses repo_rights to get the name of the wild
card repo (if any) that pertains to the physical $repo, instead of
all that new code (duh!)
- new "can_read(repo, user)" sub (to help daemon and gitweb use)
- the "convenience copy on steroids" thing now copies %repo_config
also, not just %repos. This makes setup_repo_configs simpler
- $creator gets substituted into %groups also; we need that now that
we (%repos and %groups) are working closer together :)
(thanks to Kevin Fleming for the need/use case)
TODO: tests
TODO: proper documentation; meanwhile, just read this:
- you can give gitweb and daemon read rights to wild card repos also,
and it'll all just work -- when a new repo is 'C'reated, it'll pick
up those rights etc
- you can assign descriptions (and owners) to individual repos as
before, except now you can assign them to repos that actually were
created from wild card patterns. So for example, you can define
rules for
repo foo/..*
and then assign descriptions like
foo/repo1 = "repo one"
foo/repo2 = "repo two"
foo/dil "scott" = "scott's dilbert repo"
However, this only works for repos that already exist, and only when
you push the admin repo.
Thumb rule: have the user create his wild repo, *then* add and push
the admin config file with the description. Not the other way
around.
implementation notes:
- wildcard support for git config revamped, refactored...
it's not just git config that needs wildcard support. daemon and
gitweb access also will be needing it soon, so we start by factoring
out the part that finds the "pattern" given a "real" repo name.
- GL_NO_DAEMON_NO_GITWEB now gates more than just those two things;
see doc/big-config.mkd for details
- we trawl through $GL_REPO_BASE_ABS *once* only, collecting repo
names and tying them to either the same name or to a wild pattern
that the repo name was created from
- nice little subs to setup gitweb, daemon, and git config
- god bless $GL_REPOPATT and the day I decided to set that env var
whenever a user hits a wild repo in any way :-)
- the code in gl-compile-conf is very simple now. Much nicer than
before
make it a sort of "super global" (an ENV var) all through, because
*everyone* seems to need it *and* this variable is pretty much constant
for the entire install
- new GL_GITCONFIG_WILD to gate it
- new sub to do all the hard work (refactored from a few lines in
compile)
- split the call from "compile" into two sets -- first for non-wild,
then for wild
This ensures that after a "compile" (admin push) all git configs are
applied.
TODO: apply them when a new wild repo is created by a user, and then on
the "fork" (admin-defined command)
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
NOTE: there are no *functional* changes in this for *normal*
gitolite users. It's just a chunk of code moving into a new
subroutine etc.
KDE needs to populate the authkeys file from an LDAP store. Other large
projects may have similar means to store keys, depending on how they do
their user provisioning so a generic solution is worth exploring.
This means that in these special cases
- the gitolite-admin repo's keydir/ directory is not needed [1]
- but they still need to create the authkeys file somehow
Implementation:
- write a shim program to make the authkeys-generation code callable
from the command line/shell.
- set $GL_NO_SETUP_AUTHKEYS=1 in the rc file to disable authkey
generation during a "compile" (admin repo push)
Expected usage of new program gl-setup-authkeys:
- LDAP change triggers some script
- this script collects all keys from LDAP, puts them in some
directory, and then calls gl-setup-authkeys, passing it the name of
the directory
ALSO PLEASE SEE COMMENTS AT THE TOP OF THE NEW PROGRAM IN THIS COMMIT
FOR SOME IMPORTANT DISCUSSION.
----
Footnotes:
[1] It doesn't make sense to use it if the keys will be maintained by
some other entity and can be called up as needed, and it adds an
unnecessary extra step.
- stop erroring out if run from elsewhere than $HOME (by localising
the "cd" we need somewhere in between)
- catch the admin@home.pub usage early
- minor fix to the backticked commands
- gl-setup now does 'chmod go-rwx .ssh'
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
sometimes I want to quickly test a few lines of change within the context of
a currently-running/just-ran test, *without* doing the rollback etc.
Here's how you do that now:
- in your source tree, make the change and then run:
cp -a src hooks contrib/adc /some/tmp/place
- go to the tester userid and re-run your tests like so:
GQT=/some/tmp/place ./test-driver.sh
it'll rollback as normal then overwrite src and hooks from $GQT
Also, there's now a "dbg" sub that can be used for quick printf-style
debugging.
"WARNING: a pubkey file can only have one line (key); ignoring $pubkey"
message was a bit confusing, because elsewhere the docs claim multiple
keys are suported. Added note on how to add multiple keys for single
user and pointer to the doc file concerned.
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.
thanks to Jesse from the Fedora team for pointing this out. They use
GL_NO_CREATE_REPOS, so sometimes the physical repo on disk doesn't exist
at the time the config file is written.
We're talking about non-wild repos only here, so this means it should
never happen to normal gitolite users. But now -- in the rare case that
there is a disk-side problem -- people who have rights to a repo will
get a more specific error message.
this allows the first part of the repo name (if wildcard repos are
activated) to have a regex like [a-zA-Z0-9]+.
----
Note added by committer:
he assumption used to be that all wildcard repos will have some common
prefix like "users", but I did not imagine it would be like
repo [a-zA-Z0-9]+/users/CREATOR/[a-zA-Z0-9]+
(viz., the "users" is in the middle).
Sounds reasonable...
allows a default 'setperms' string to be set for new wildcard
repositories.
Also, fix a bug in the fork script where a failure in the git command
would still cause the rest of the script to attempt to run.
fixes:
- allow "grouped" admins to get basic info for other users by checking
more than just the *user*'s right to the admin repo
- report_basic is called with a $user argument, but it's not easy
(right now) to propagate this to parse_acl. Use a simple kludge,
(for now at least).
thanks to bcooksley for catching this
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 main use case is for people who give most people access via @all,
which is somewhat unusual but in some situations it probably makes
sense.
See also a related commit made a month or so ago (aa8da93).
Actually these two lint checks were made to help people spot typos in
the config, which sorta becomes meaningless if you have more than a few
such cases anyway, so for most people it should not matter that I am now
merely summarising the number of such cases if there are more then 10.
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)
in addition, due to "+" becoming a valid character in a normal reponame,
(think gtk+, etc), the pattern
repo dev/CREATOR/.+
doesn't look like a wildcard repo anymore, so we add an extra check that
if CREATOR is mentioned, it *is* a wildcard.
This has been added *only* to the report_basic function; it doesn't
really matter anywhere else.
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.]
It works fine when you're installing off of a tar file because the
Makefile also generates a VERSION file, but when doing from a clone you
still need to generate it.
(plus minor fix to easy install, in the same area of code)
the commits leading up to v1.5 caused the data format to change (we
added a rule sequence number).
This in turn caused a problem for people who may have installed using
the "system install / user setup" mode of install (which includes people
who used RPM/DEB to install it) -- they would now have to *manually* run
"gl-setup" once after the rpm/deb upgrade.
This commit *tries* to mitigate this problem by recording a data format
version number in the compiled output file. On any access to that file,
if the version number is not found or is found to be not equal to the
current version, gl-setup is run again.
The reason I say "*tries*" is that the exact command used to do this is
a bit of a hack for now. However, if it works for Fedora and Debian,
I'm going to leave it at that :)
There were 2 problems with rule sequencing.
Eli had a use case where everyone is equal, but some are more equal than
the others ;-) He wanted a way to say "everyone can create repos under
their own names, but only some people should be able to rewind their
branches".
Something like this would be ideal (follow the rules in sequence for
u1/u2/u3/u4, and you will see that the "deny" rule kicks in to prevent
u1/u2 from being able to rewind, although they can certainly delete
their branches):
@private-owners = u1 u2
@experienced-private-owners = u3 u4
repo CREATOR/.*
C = @private-owners @experienced-private-owners
RWD = CREATOR
RW = WRITERS
R = READERS
- = @private-owners
RW+D = CREATOR
In normal gitolite this doesn't work because the CREATOR rules (which
get translated to "u1" at runtime) end up over-writing the "deny" rule
when u1 or u2 are the creators. This over-writing happens directly at
the "do compiled.pm" step.
With big-config, this does not happen (because @private-owners does not
get expanded to u1 and u2), but the problem remains: the order of
picking up elements of repo_plus and user_plus is such that, again, the
RW+D wins (it appears before the "-" rule).
We fix all that by
- making CREATOR complete to more than just the creator's name (for
"u1", it now becomes "u1 - wild", which is actually illegal to use
for real so there's no possibility of a name clash!)
- maintaining a rule sequence number that is used to sort the rules
eventually applied (this also resulted in the refex+perm hash
becoming a list)
[Please NOTE: this is all about *user* groups, not *repo* groups]
SUMMARY: gl-auth-commmand can now take an optional list of usergroup
names after the first argument (which is the username).
See doc/big-config.mkd in the next commit or so
Since it is possible to do all sorts of shenanigans with wildcards and
repo groups, we
- allow only a fragment called "foo" to set permissions for a group
called "@foo", in addition to a repo called "foo"
- forbid defining any groups within a fragment conf. All "@foo = bar
baz" must be done in the main config file now.
If this proves too limiting for anyone I'll worry about it then.
If you have many thousands of repos and users, neatly organised into
groups, etc., the normal gitolite fails. (It actually runs out of
memory very fast while doing the "compile" when you push the config, due
to the number of combinations of repo/user being stored in the hash!)
This commit series will stop doing that if you set $GL_BIG_CONFIG = 1 in
the rc file.
Some notes:
- deny rules will still work but somewhat differently -- now they must
be placed all together in one place to work like before. Ask me for
details if you need to know before I get done with the docs
- I've tested most of the important features, but not every single
nuance
- the update hook may be a tad less efficient now; we can try and
tweak it later if needed but it shouldn't really hurt anything
significantly even now
- docs have not been written yet
(as if we didn't already have enough programs with the word "install" in
their names!)
Anyway, this does what an RPM or a DEB would do -- basically implement
the instructions in Appendix C of doc/0.
You can use this to do a system-wide install if your distro isn't as
smart, forward-looking, and uptodate as Fedora ;-)
Clone the repo somewhere, cd to it, and run, for example:
sudo src/gl-system-install /usr/local/bin /var/gitolite/conf /var/gitolite/hooks
or something like that. See doc/0 for details. Run without arguments
for help.
Ouch! How mortifying :) I'd always thought this was one of the Brit/US
differences, but to find out that it really *isn't* a word... hmph!
Anyway, in the interest of not breaking existing wild repos, the
ownership file is still called "gl-creater". Everything else has been
changed.
(...thanks to Sverre)
The "fork" adc cannot simply do a "git clone..."; hooks and gl-creater
won't get set up. We need a way to initiate the *creation* of a repo
from a shell command, and then fetch the refs over.
For a long time, we used to trick gitolite into creating a repo for us
by simply using "git ls-remote host:reponame" ;-) Now we have an actual
command, so we can say "ssh git@server git-init \'reponame\'"
Yes; those single quotes are required. Deal with it.
This commit series allows an admin to designate a set of commands that
users can run. For example, he can allow users to delete a repo that
they have created:
ssh git@server rmrepo foo/me/bar
or fork (to use github's terminology) a repo they have "R" access to,
into a new one they have "C" access to:
ssh git@server fork foo/someone-else/bar foo/me/bar
Please see documentation for details
----
(this commit)
- (rc) new variable $GL_ADC_PATH; without this none of this is enabled
- (pm) new helper routine "cli_repo_rights" to get rights/ownership
from outside
- (auth) call $GL_ADC_PATH/$cmd if it exists
This commit series refactors all the rights querying logic.
- old repo_rights sub renamed to wild_repo_rights
- new repo_rights sub to be a single entry point for most rights
queries
- callable from gl-auth-command and expand_wild
- callable from *outside* too, as long as $ENV{GL_USER} is set
- the format of the returned permissions contains C, R, and W as
applicable, with sigils reflecting the 3 possible ways in which you
can get R or W perms (2 ways for C):
@R means @all users have the same access
#R means you're a "super user" (think root's shell prompt) so
you can see all repos
R is the normal, explicit, access
Always passing "-p 22" to ssh (or "-P 22" to scp) if no custom port is given on
the command line causes trouble when not using a host name but an SSH session
name (as defined in .ssh/config) which defines a non-standard port, because the
port given on the command line overrides that port.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Having to specify "D" separately from RW or RW+ was cumbersome, and
although I don't actually use this feature, I can see the point.
One way to think of this is:
- RW and RW+ were the only existing branch level rights
- it doesnt make sense to have D rights without W (hence RW) rights
- so we simply suffix a D to these if required.
Thus you can have RW, RW+, RWD, RW+D.
I hope the (hopefully few) of you who have started to use this feature
will convert your configs when you next upgrade to "pu".
I now regret pushing the previous syntax to master too quickly -- lots
of people use master only, and on the next promotion of pu the syntax
will change. To reduce this exposure, this change will be promoted to
master very soon.
Previous implementations of "give shell access to some gitolite users"
feature were crap. There was no easy/elegant way to ensure that someone
who had repo admin access would not manage to get himself shell access.
Giving someone shell access requires that you should have shell access
in the first place, so the simplest way is to enable it from the server
side only.
So now that we decided to do that, we may as well prepare for other,
future, commands by starting a server-side utility program with
sub-commands (the only current one being "shell-add")
normally, RW+ means permission to rewind or delete.
Now, if you use "D" permission anywhere in a repo config, that means
"delete" and RW+ then means only "rewind", no delete.
All this is about a user trying to look if a repo exists or not, when he
does not have any access to that repo. Ideally, "repo does not exist"
should be indistinguishable from "you dont have perms to that repo".
(1) if $GL_WILDREPOS is not set, you either get a permissions error, or
a "$repo not found in compiled config" death. Fixed.
(2) if $GL_WILDREPOS is set, you either get either a permissions error,
or a "$repo has no matches" death. Fixed.
(3) The following combination leaks info about repo existence:
- actual repo doesn't exist
- spying user don't have C perms
- repo patt doesn't contain CREATER
- RW+ = CREATER is specified (as is normal)
In such case, the "convenience copy" of the ACL that parse_acl
makes, coupled with substituting CREATER for the invoking user means
$repos{$actual_repo} has RW+ for the spying user. This means the
access denied doesn't happen, and control passes to git, which
promptly expresses it unhappiness and angst over being given a repo
that 'does not appear to be a git repository'
This doesn't happen if all those conditions are not met:
- if repo exists, CREATER is set to the real creater, so RW+ =
CREATER does not gain spying user anything
- if spying user has C perms it just gets created, because he has
rights. This is also info leak but we can't prevent it; tighten
the config (maybe by including CREATER in repo pattern) if this
is not wanted
- if repo patt contains CREATER it will never match someone else's
repo anyway!
a configuration like this:
repo CREATER/.*
C = CREATER
RW+ = WRITERS
was buggy; CREATER was implicitly part of WRITERS so he got RW
permissions implicitly, so the push went through
what this means is that until now, everyone who used easy-install
(without needing to set $GIT_PATH in the rc file) had a client-side PATH
that was perfectly valid on the server side also!
- no need to put it at the end of the config file now, yeaaay!
- @all for @all is meaningless and not supported. People asking will
be told to get a life or use git-daemon.
- NAME/ limits for @all repos is ignored for efficiency reasons.
Data dumper was failing (returning an empty string!) on an input config
file of about 350 lines or so (output 2400 lines or so).
Removing the sort sub fixed the problem.
To recap why that sub was put in (see deleted lines in this commit for
details), what we really want is that $creater must appear *last* in the
resulting dump.
So we trick it. "man ascii" tells you that ~ is the highest valued
ASCII character (yes, I know, not utf-8 safe etc... I'll deal with that
if and when needed or punt!). So we just put that in front of $creater
and remove it later...
You *don't* want to do this for $readers and $writers -- then they will
once again sort *after* $creater, which would be a bad thing. Also,
it's probably better this way, because now the order of the hash keys
will be: $readers, $writers, any actual users listed, and then $creater.
This means the effective access rights will be:
1. if you are the creater you get CREATER's rights
2. else if your userid is listed *explicitly* in the config, you get
those rights
3. else if you've been setperm'd as a writer, you get WRITERS rights
4. else if you've been setperm'd as a reader, you get READERS rights
This is different from what used to happen till now; READERS and WRITERS
used to trump explicitly given rights. I'd been meaning to fix that
somehow, but never got around to it, until this DDD (damn Data Dumper!)
forced my hand :)
The new style personal branches work by interpreting the special
sequence /USER/ (including the slashes) in a refname. Docs should be in
the next commit...
the changes to cp/scp are because without "-p" they dont carry perms
across to existing files. So if you forgot to chmod +x your custom
hook and ran easy install, then after that you have to go to the server
side to fix the perms...
I've been unwilling to create the authkeys file if it does not already
exist, because it represents a significant change in accessibility for
that account.
However, in the "distro package" scenario, one wants to make it as easy
as possible for the end-user (who is actually an admin for the gitolite
being hosted on his account, let's not forget) to use.
And it seems that in some cases that might mean he does not (yet) have a
~/.ssh even...
when repos are copied over from elsewhere, one had to run easy install
once again to make the new (OS-copied) repo contain the proper update
hook.
We eliminate this step now, using a new, empty, "hook" as a sentinel and
having "compile" check/fix all repos' hooks.
Since you have to add the repos to conf anyway, this makes it as
seamless as possible. The correct sequence now is
- (server) copy the repo at the OS level
- (admin clone) add it to conf/gitolite.conf, commit, push
Currently the pattern of expand command is line anchored. This is
different than in e.g. grep, and causes extra work to add '.*' prefix
and/or suffix in many use cases.
The new semantics now mean you might get more matches than you would
have gotten earlier. However, the expand command is still totally
undocumented, so I think it is acceptable to change the functionality.
;)
This patch removes the anchoring. So for earlier behavior the specified
pattern needs be in form of '^<pattern>$'. The default pattern is also
changed from '.*' to '^', so there might be even a small speed
improvement. =)
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
stupid me; committed the easy install patch on master *and* pushed,
instead of on pu...
Since I dont want to rewind master, we end up with this completely
unnecessary merge.
let expand_list be just that "expand a list", and leave checking to be
done outside.
otherwise, commit 690604d79 has the side effect of restricting refs to
$REPOPATT_PATT, and so for instance barfing on the perfectly valid
RW+ refs/(?!heads/master) = alice bob
(thanks to Teemu for catching this)
[TODO: allow a callback for a password checking function, such as
"passwd_policy_check". Question is where the function would go.
~/.gitolite.rc is the only possible place among the current set of files
but I'd rather leave that as a list of simple name=value lines for all
sorts of reasons. So maybe something like ~/.gitolite.pm (analogous to
the "gitolite.pm" in the sources I supply), which would get "require'd"
if found, and would contain all user-defined functions like this one...
needs some thinking about]
this came up in some other discussion with bremner. As usual I said no
I won't do it because I don't see any real need.
...then I realised it's just one line :)
(about this commit)
The install doc now describes both the ways of installing gitolite.
It also has a handy appendix for package maintainers describing what
they need to do.
(about the "dps" -- distro packaging support -- commit series)
This commit is the last in the chain meant to make gitolite more
friendly for package maintainers.
Frankly, I never really thought gitolite would get big enough or
important enough for someone to package it, and I always did just
the bare minimum I needed to get it working, first for myself, then
anyone who hopped onto #git and asked. As a result, it had some
quirks in terms of what is expected where and so on...
Luckily, it didn't take a lot of changes to fix it, and this series
of commits should help make it very easy to package gitolite for
system-wide use.
The old install method will now use conf/VERSION instead of src/VERSION everywhere.
The new one, if you use the builtin make file to "make branch.tar" will also create just such a file
gl-install copies
- the initial rc file to ~/.gitolite.rc if it doesn't exist
- src and hooks to GL_ADMINDIR
Make it aware of a package-based setup sequence, where the above two
change somewhat; see code diff.
This should be the last bit of change needed to prepare gitolite setup
so that a distro package maintainer does not have to fiddle too much
with code inside.
(What remains is docs, and a setup script for server-side use, to
replace the latter part of easy install)
if you have read access to the admin repo, you can say
ssh git@server info user1 [...]
Original idea and code by Karteek E. The motivation is to quickly and
easily check what perms a user has. Technically nothing that you can't
glean from the config file itself but it serves as a double check or a
mild debugging aid perhaps.
However note that the branch level rules are much more complex and they
do not, as yet, have any such "helpful" aids. Life is like that
sometimes.
Gitolite allows you to set git repo options using the "config" keyword;
see conf/example.conf for details and syntax.
However, if you are in an installation where the repo admin does not
(and should not) have shell access to the server, then allowing him to
set arbitrary repo config options *may* be a security risk -- some
config settings may allow executing arbitrary commands.
This patch fixes it, introducing a new RC variable to control the
behaviour. See conf/example.gitolite.rc for details
Although I have washed my hands off the security aspect if you use
external commands, that doesn't mean I won't make them as tight as I can
;-) Right now, this is just a place holder -- if people use it and
complain that the pattern is too restrictive, I'll change it.
The wildrepos branch has been merged into master, and deleted. It will no
longer exist as a separate branch. Instead, a new variable
called $GL_WILDREPOS has been added which acts as a switch; when
off (which is the default), many wildrepos features are disabled.
(the "C" permissions, and the getperms (etc.) commands mainly).
Important: if you are using wildrepos, please set "$GL_WILDREPOS = 1;" in
the RC file when you upgrade to this version (or just before you do the
upgrade).
Allow users to set and display description (for gitweb) for their
own wildcard repositories using ssh commands:
setdesc <repo>
getdesc <repo>
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
brought on by realising that you lost $shell_allowed when refactoring
(previous commit) but perl hadn't caught it because -- damn -- you
didn't have "use strict" in gitolite.pm
lots of conflicts, esp in gl-auth-command, due to refactoring the
"special commands" stuff on master
Conflicts:
doc/3-faq-tips-etc.mkd
src/gitolite.pm
src/gl-auth-command
src/gl-compile-conf
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)
Gitolite uses projects.list to set the owners for gitweb's use.
Unfortunately, this does not work for gitweb setups that set
$projectroot to a directory, thus generating the list of
repositories on the fly.
This patch changes that: gitolite now writes the gitweb.owner
configuration variable for each repository (and properly cleans up after
itself if the owner is removed).
The patch causes gitolite not to write the owner to projects.list
anymore, as this would be redundant.
The owner also needs no longer be escaped, so this patch removes the
poor man's 's/ /+/g' escaping previously in place.
Note that I am not a Perl coder. Thus there are probably better ways to
implement this, but at least it works.
Cc: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: martin f. krafft <madduck@madduck.net>
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.
