If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will
get caught later when someone whom youhave given that role tries to
access the repo (look for another occurrence of the same error message
as this one).
So there's no access violation but it would be nice to be told upfront
that it won't work.
Apparently some people want gitolite-admin as a non-repo. Completely
outside gitolite, managed by puppet or such, and leaving only symlinks
for 'conf' and 'keydir' in $GL_ADMINDIR.
But then when they have to run 'gl-setup', the 'git add' complains about
the symlink. Hence this patch.
----
Meanwhile, if you're one of those puppet masters, here's the script I
gave them for the *compile* (this has nothing to do with this patch; I'm
just throwing it in here so I won't lose it):
#!/bin/bash
# let's say you install using "non-root" method. (Adjust GL_BINDIR for root
# method or package method).
# install normally, then make changes directly in $GL_ADMINDIR/conf and
# $GL_ADMINDIR/keydir. (Please leaves "logs/" and "hooks/" alone).
# Then run this:
export GL_ADMINDIR=$HOME/.gitolite
export GL_BINDIR=$HOME/bin
export GL_RC=$HOME/.gitolite.rc
cd $GL_ADMINDIR
$GL_BINDIR/gl-compile-conf
# BE SURE TO REMOVE THE ADMIN REPO ITSELF FROM conf/gitolite.conf, as well as
# repositories/gitolite-admin.git, lest a push by someone end up overwriting
# this hand- (or machine-) crafted config.
# you can get away even further from gitolite's control. You can, for
# example, set GL_NO_SETUP_AUTHKEYS in the rc file, and manage even the keys
# yourself. Just put the full path to $GL_BINDIR/gl-auth-command followed by
# the username in the "command=" part of the authkeys file you generate.
(can_* == can_read, can_write, and can_create)
See top of contrib/adc/adc.common-functions for more on this.
Note: the old style (calling get_rights_and_owner with $repo, then
checking $perm_read, $perm_write, etc.), will still work fine.
any sane system should have $HOME/bin in $PATH, but apparently there are
quite a few insane systems around ;-)
(also changes the usage message etc a bit)
e5c3b0e on a machine without CGI::Util makes gitolite unusable. I
checked that it was part of perl core, since `corelist CGI::Util`
returns `CGI::Util was first released with perl 5.006001`.
But apparently Fedora (at least) splits out core perl itself into
smaller chunks. And on my devbox I never noticed because I had gitweb
installed, which pulled it in as a dep.
I found this out when I tried to upgrade my own prod server!
For example, this program
#!/bin/sh
die() { echo die called with $1; exit 1; } >&2
die foo
die bar
will print *both* those messages!
I honestly don't care if this is posix or not, but it is BRAIN DEAD for
the ">&2" to change the meaning from {} to ()
Oh and the grep thing is even worse.
echo foo | grep ^/
works fine in an interactive shell but in a script it attempts to
*execute* "/", complains, while simultaneously complaining about usage
of grep.
It's almost like it's treating ^ like |
- support for ADCs with unchecked arguments
- rsync, htpasswd, and svnserve gone from core; turned into ADCs
Backward compat breakage and fix: Please see documentation for details,
but if you're using gitolite to control rsync you will now need to setup
ADCs (admin defined commands), and install at least the new "rsync" ADC.
----
Thanks to Joey Hess (see commit prior to this) for forcing me to stop
being lazy and get this out of my long term todo list.
- strictly speaking, this should be phrased: "deny" rules for the
first level access check
- requires a gitolite option to be set, like so:
config gitolite-options.deny-repo = 1
(Not sure how I missed this earlier, but if you can't upgrade yet, a
mitigation is to note the job number that gets printed on your terminal
when a mirror push starts, and look a log file entries beginning with
that number.)
also
- new "WEB_INTERFACE" variable (defaults to 'gitweb')
- setup_web_access (write a plain list of repos out)
- add_del_web_access (add/delete a single repo from projects.list)
The backward compat breakage is for people who already have all kinds of
arbitrary characters in filenames *and* use `NAME/` rules. See the doc
change in this commit for details and mitigation. See this link for
background:
http://groups.google.com/group/gitolite/browse_thread/thread/8dc5242052b16d0f
Thanks to Dan Carpenter for the audit.
major changes
- (src) one error message got more detail
- long overdue fixup to developer notes doc
plus many minor changes that have been piling up
PS: to dig into the "alliterative animal" comment, check the channel
logs around aug 23rd ;-)
comments from contributor via email:
* Translates all repos from gitosis to gitolite, even if their are not
associated with any groups
* Transfers gitweb settings (gitweb, description and owner)
* Transfers git-dameon settings
* Maintains comments for groups and repos
As far as I can tell, the results from this filter are working fine
for our transfer from gitosis to gitolite.
wrap_print() was written to create a new file and rename the old one to
avoid a partially written file being read by other processes. This has
only been reported for the 'projects.list' file, but I just did it for
all files as a matter of course.
list of files currently written via this function:
gl-creater, gl-perms, description, git-daemon-export-ok, projects.list
However, some people want to do the following:
- set REPO_UMASK tight (0077, default)
- manually change the perms to something looser (typically g+rX) for
specific repos
- set core.sharedRepository to 0750 (git is documented to honor that
config if available and to override umask)
Except that core.sharedRepository does not apply to files written by
gitolite and not git itself. So they would open up their description
files and the next compile would close them again!
This patch prevents this from happening. If the file already exists, it
maintains the same permissions after the rename.
previously, these two would produce different results
config aa.bb = 'true' # config file line includes single quotes
config aa.bb = "true" # config file line does not include any quotes
Now the former will also behave like the latter.
Without this, complex mirroring scenarios will be unpredictable. For
example (abbreviating "gitolite.mirror." to "gimo.") something as simple
as this will not give "foo" his different mirror setup
repo @all
config gimo.master = "frodo"
config gimo.slaves = "sam"
repo foo
config gimo.master = "sam"
config gimo.slaves = "frodo gollum"
repo foo bar
RW = u1
Even worse things happen when you have wild cards.
Now, however, they all come in the right sequence and the most recent
one takes effect (unlike ACL rules, where the first match wins, because
there you're trying to just find a match and get out, while here you're
just mindlessly applying config lines in the right order).
