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.]
people will NOT read documentation, especially the bloody install
documentation. I'm about ready to throw in the towel and declare
gitolite unsupported, take-it-or-leave-it.
But I'm making one last attempt to refocus the install doc to better
suit the "I know I'm very smart and I dont have to read docs so it's
clearly your fault that I am not able to install gitolite" crowd.
As a bonus, though, I ended up making proper, hyper-linked, TOCs for
most of the docs, and moved a whole bunch of stuff around. Also finally
got some of the ssh stuff over from my git-notes repo because it really
belongs here.
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 has been a format change to the compiled output file. As the
CHANGELOG says:
Upgrading to v1.5 from any version prior to v1.5 requires an extra
step for people who installed gitolite using the "system install /
user setup" method described in doc/0-INSTALL.mkd. For such
installations, after the administrator has upgraded gitolite
system-wide, each "gitolite host" user must run `gl-setup` once
(without any arguments).
This is *not* an issue if you installed using src/gl-easy-install.
Move the example code from doc/3 to contrib/gitweb/ and modify it
to work with both wildcard and non-wildcard setups.
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
(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)
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.
- 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.
There are some disadvantages to the old-style personal branch scheme.
It only allows one specific pattern (of refname) to be used, forces that
pattern to be applicable to *all* repos in the entire config, and
requires editing the rc file (on the server) to be edited to achieve
this.
In other words, it's a very blunt instrument...
The new style depends on using lines like this within a specific repo
config:
RW+ personal/USER/ = @userlist
The important thing is that the "branch" name should contain `/USER/`
(including the slashes). Access is still determined by the right hand
side of course.
This gives you the following advantages:
- allow it only for repos that need it
- allow different patterns to be used for different repos
- allow *multiple* patterns; just add more than one such line
- allow the pattern to have suffixes (eg: foo/USER/bar)
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...
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
(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 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).
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)
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.
It's not clear whether $projectroot has or does not have a trailing
slash. Current code assumes it does, but we need to cater for it not
having one also. Otherwise the final reponame ends up with a leading
slash, once $projectroot has been stripped from the beginning of the
full repo path.
I know hardly anyone is using delegation, but if you find yourself
locked out from pushing because of this one little thing, do this:
* on your gitolite-admin clone, add the required lines per this patch,
and commit
* on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and
delete the following line
'NAME_LIMITS' => 1
from the entry for "gitolite-admin" (if you don't know what that
means delete *all* such lines) and save the file
* back on your admin repo clone, do a push
I know hardly anyone is using delegation, but if you find yourself
locked out from pushing because of this one little thing, do this:
* on your gitolite-admin clone, add the required lines per this patch,
and commit
* on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and
delete the following line
'NAME_LIMITS' => 1
from the entry for "gitolite-admin" (if you don't know what that
means delete *all* such lines) and save the file
* back on your admin repo clone, do a push
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
This is a backward incompatible change. If you are using delegation and
you upgrade to this version, please do the following:
* change your gitolite.conf file to use the new syntax (see
doc/5-delegation.mkd in this commit)
* for each branch "foo" in the gitolite-admin repo, do this:
# (on "master" branch)
git checkout foo -- conf/fragments/foo.conf
* git add all those new fragments and commit to master
* delete all the branches on your clone and the server
# again, for each branch foo
git branch -D foo
git push origin :foo
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.
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.
This feature has *no* warranty, and so no documentation. Not more than
this transcript anyway.
config file:
@prof = u1
@TAs = u2 u3
@students = u4 u5 u6
repo assignments/CREATER/a[0-9][0-9]
C = @students
RW+ = CREATER
RW = WRITERS @TAs
R = READERS @prof
session:
as user "u4":
# check your permissions
$ ssh git@server
PTY allocation request failed on channel 0
hello u4, the gitolite version here is v0.95-31-gbcb14ca
you have the following permissions:
C assignments/CREATER/a[0-9][0-9]
@ @ testing
Connection to localhost closed.
# autovivify repos for assignment 12 and 24
$ git clone git@server:assignments/u4/a12 a12
Initialized empty Git repository in /home/sitaram/t/a12/.git/
Initialized empty Git repository in /home/gitolite/repositories/assignments/u4/a12.git/
warning: You appear to have cloned an empty repository.
$ git clone git@server:assignments/u4/a24 a24
Initialized empty Git repository in /home/sitaram/t/a24/.git/
Initialized empty Git repository in /home/gitolite/repositories/assignments/u4/a24.git/
warning: You appear to have cloned an empty repository.
# check what repos you autovivified
$ ssh git@server expand assignments/u4/a[0-9][0-9]
(u4) assignments/u4/a12
(u4) assignments/u4/a24
as user "u5":
# check your basic permissions
$ ssh git@server
PTY allocation request failed on channel 0
hello u5, the gitolite version here is v0.95-31-gbcb14ca
you have the following permissions:
C assignments/CREATER/a[0-9][0-9]
@ @ testing
Connection to localhost closed.
# see if you have access to any of u4's repos
$ ssh git@server expand assignments/u4/a[0-9][0-9]
# (no output produced)
as user "u4":
# allow "u5" read access to assignment 12
# note you type in "R u5", hit enter, then hit Ctrl-D. Gitolite
# then produces a confirmation message starting "New perms are:"
$ ssh git@server setperms assignments/u4/a12
R u5
New perms are:
R u5
as user "u5":
# again see if you have access to any u4 repos
$ ssh git@server expand assignments/u4/a[0-9][0-9]
(u4) assignments/u4/a12
as user "u4":
# check what permissions you gave to assignment 12
$ ssh git@server getperms assignments/u4/a12
R u5
# add RW access to "u6" to assignment 12
# again, type 'em in, then hit Ctrl-D; and note each time you run
# this you're starting from scratch -- you can't "add to" the
# permissions. Deal with it...
$ ssh git@server setperms assignments/u4/a12
R u5
RW u6
New perms are:
R u5
RW u6
as user "u6":
# check what u4 stuff you have access to
$ ssh git@server expand assignments/u4/a[0-9][0-9]
(u4) assignments/u4/a12
@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.]
