compile, all docs/confs: specify gitweb/daemon access + bonus
bonus: documented the "bits and pieces" thing properly; should have done this long ago, but it came to the forefront now thanks to this item
This commit is contained in:
parent
8217ef9d5b
commit
70d26d810b
|
@ -38,7 +38,11 @@ that:
|
|||
|
||||
* no one in $DAYJOB type environments will use or approve access methods
|
||||
that work without any authentication, so I didn't need gitweb/daemon
|
||||
support in the tool or in the config file
|
||||
support in the tool or in the config file.
|
||||
|
||||
Update 2009-09-24: I don't use this feature but someone wanted it, so I
|
||||
added it... see the "faq, tips, etc" document for more
|
||||
|
||||
* the idea that you admin it by pushing to a special repo is nice, but not
|
||||
really necessary because of how rarely these changes are made, especially
|
||||
considering how much code is involved in that piece
|
||||
|
|
|
@ -8,9 +8,13 @@
|
|||
|
||||
# objectives, over and above gitosis:
|
||||
# - simpler syntax
|
||||
# - no gitweb/daemon control
|
||||
# - allows ff/non-ff control
|
||||
# - allows branch level control
|
||||
# - easier gitweb/daemon control
|
||||
# - specify who can push a branch/tag
|
||||
# - specify who can rewind a branch/rewrite a tag
|
||||
|
||||
# convenience: allow specifying the access control in bits and pieces, even if
|
||||
# they overlap. Keeps the config file smaller and saner. See the example in
|
||||
# the "faq, tips, etc" document
|
||||
|
||||
# ----------------------------------------------------------------------------
|
||||
# LISTS
|
||||
|
@ -97,3 +101,14 @@ repo @privrepos thirdsecretrepo
|
|||
RW refs/tags/ss/ = @secret_staff
|
||||
RW tmp/.* = @secret_staff
|
||||
R = @secret_staff
|
||||
|
||||
# ----------------------------------------------------------------------------
|
||||
# GITWEB AND DAEMON CONTROL
|
||||
|
||||
# there is no special syntax for this. If a repo gives read permissions to
|
||||
# the special user "gitweb" or "daemon", the corresponding changes are made
|
||||
# when you compile; see "faq, tips, etc" document for details.
|
||||
|
||||
# this means you cannot have a real user called "gitweb" or "daemon" but I
|
||||
# don't think that is a problem :-)
|
||||
|
||||
|
|
|
@ -24,6 +24,11 @@ $REPO_UMASK = 0077; # gets you 'rwx------'
|
|||
# $REPO_UMASK = 0027; # gets you 'rwxr-x---'
|
||||
# $REPO_UMASK = 0022; # gets you 'rwxr-xr-x'
|
||||
|
||||
# part of the setup of gitweb is a variable called $projects_list (please see
|
||||
# gitweb documentation for more on this). Set this to the same value:
|
||||
|
||||
$PROJECTS_LIST = "/home/git/projects.list";
|
||||
|
||||
# --------------------------------------
|
||||
|
||||
# I see no reason anyone may want to change the gitolite admin directory, but
|
||||
|
|
|
@ -42,6 +42,12 @@ And you're done.
|
|||
If any extra steps beyond the generic ones above are needed, they will be
|
||||
listed here, newest first.
|
||||
|
||||
#### upgrading from 8217ef9
|
||||
|
||||
Between 8217ef9 and this version, gitolite learnt to handle gitweb/daemon
|
||||
access. As a result, the rc file acquired a new variable, `$PROJECTS_LIST`,
|
||||
which you have to set to whatever your gitweb installation requires.
|
||||
|
||||
#### upgrading from 86faae4
|
||||
|
||||
Between 86faae4 and this version, gitolite had a *major* change in the
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
# migrating from gitosis to gitolite
|
||||
|
||||
[TODO: make the migration tool fix up gitweb and daemon control also...]
|
||||
|
||||
Migrating from gitosis to gitolite is pretty easy, because the basic design is
|
||||
the same. The differences are:
|
||||
|
||||
|
|
|
@ -32,6 +32,29 @@ Please read on to see how to do this correctly.
|
|||
should be exactly the same as their keyfile names, but without the
|
||||
`.pub` extension
|
||||
|
||||
#### specifying gitweb and daemon access
|
||||
|
||||
This is a feature that I personally do not use (corporate environments don't
|
||||
like unauthenticated access of any kind to any repo!), but someone wanted it,
|
||||
so here goes.
|
||||
|
||||
There's **no special syntax** for this -- just give read permission to a user
|
||||
called `gitweb` or `daemon`! (This also means you can't have a normal user
|
||||
with either of those two names, but I doubt that's a problem!). See the "faq,
|
||||
tips, etc" document for easy ways to specify access for multiple repositories.
|
||||
|
||||
Note that this does **not** install or configure gitweb/daemon -- that is a
|
||||
one-time setup you must do separately. All this does is:
|
||||
|
||||
* for gitweb, add the repo to the list of projects to be served by gitweb
|
||||
(see the config file variable `$PROJECTS_LIST`, which should have the same
|
||||
value you specified for `$projects_list` when setting up gitweb)
|
||||
* for daemon, create the file `git-daemon-export-ok` in the repository
|
||||
|
||||
`src/gl-compile-conf` will keep these files consistent with the config
|
||||
settings -- this includes removing such settings if you remove "read"
|
||||
permissions for the special usernames.
|
||||
|
||||
#### compiling
|
||||
|
||||
* backup your `~/.ssh/authorized_keys` file if you feel nervous :-)
|
||||
|
|
|
@ -6,8 +6,10 @@ In this document:
|
|||
* git version dependency
|
||||
* other errors, warnings, notes...
|
||||
* differences from gitosis
|
||||
* simpler syntax
|
||||
* two levels of access rights checking
|
||||
* error checking the config file
|
||||
* easier to specify gitweb/daemon access
|
||||
* built-in logging
|
||||
* one user, many keys
|
||||
* who am I?
|
||||
|
@ -92,6 +94,49 @@ Apart from the big ones listed in the top level README, and subjective ones
|
|||
like "better config file format", there are some small, but significant and
|
||||
concrete, differences from gitosis.
|
||||
|
||||
#### simpler syntax
|
||||
|
||||
The basic syntax is simpler and cleaner but it goes beyond that: **you can
|
||||
specify access in bits and pieces**, even if they overlap.
|
||||
|
||||
Some access needs are best grouped by repo, some by username, and some by
|
||||
both. So just do all of them, and gitolite will combine all the access lists!
|
||||
Here's an example:
|
||||
|
||||
# define groups of people
|
||||
@bosses = phb1 phb2 phb3
|
||||
@devs = dev1 dev2 dev3
|
||||
@interns = int1 int2 int3
|
||||
|
||||
# define groups of projects
|
||||
@open = git gitolite linux rakudo
|
||||
@closed = c1 c2 c3
|
||||
@topsecret = ts1 ts2 ts3
|
||||
|
||||
# all bosses have read access to all projects
|
||||
repo @open @closed @topsecret
|
||||
R = @bosses
|
||||
|
||||
# everyone has read access to "open" projects
|
||||
repo @open
|
||||
R = @bosses @devs @interns
|
||||
|
||||
[...or any other combination you want...]
|
||||
|
||||
# later in the file:
|
||||
|
||||
# specify access for individual repos (like RW, RW+, etc)
|
||||
repo c1
|
||||
[...]
|
||||
|
||||
[...etc...]
|
||||
|
||||
If you notice that `@bosses` are given read access to `@open` via both rules,
|
||||
do not worry that this causes some duplication or inefficiency. It doesn't
|
||||
:-)
|
||||
|
||||
See the "specify gitweb/daemon access" section below for one more example.
|
||||
|
||||
#### two levels of access rights checking
|
||||
|
||||
Gitolite has two levels of access checks. The **first check** is what I will
|
||||
|
@ -134,6 +179,38 @@ In gitolite, you have to "compile" the config file first (this step takes the
|
|||
place of the commit+push in gitosis), and keyword typos *are* caught so you
|
||||
know right away.
|
||||
|
||||
#### easier to specify gitweb/daemon access
|
||||
|
||||
Specifying gitweb and/or daemon access for a repo is simple: give "read"
|
||||
permissions to two special usernames: `gitweb` and `daemon`.
|
||||
|
||||
You can also keep these pieces separate from the detailed, branch level access
|
||||
for each repo, if you like, since you can write the access control specs in
|
||||
bits and pieces. Here's an example, using short repo names for convenience:
|
||||
|
||||
# maybe near the top of the file, for ease of access:
|
||||
|
||||
@only_web = r1 r2 r3
|
||||
@only_daemon = r4 r5 r6
|
||||
@web_and_daemon = r7 r8 r9
|
||||
|
||||
repo @only_web
|
||||
R = gitweb
|
||||
repo @only_daemon
|
||||
R = daemon
|
||||
repo @web_and_daemon
|
||||
R = gitweb
|
||||
R = daemon
|
||||
|
||||
# ...maybe much later in the file:
|
||||
|
||||
repo r1
|
||||
# normal developer access lists for r1 and its branches/tags in the
|
||||
# usual way
|
||||
|
||||
repo r2
|
||||
# ...and so on...
|
||||
|
||||
#### built-in logging
|
||||
|
||||
...just in case of emergency :-)
|
||||
|
|
|
@ -15,6 +15,11 @@ $Data::Dumper::Indent = 1;
|
|||
# (gl-)update hook need this, and it seems easier to do this than
|
||||
# replicate the parsing code in both those places. As a bonus, it's
|
||||
# probably more efficient.
|
||||
# (3) - finally does what I have resisted doing all along -- handle gitweb and
|
||||
# git-daemon access. It won't *setup* gitweb/daemon for you -- you have
|
||||
# to that yourself. What this does is make sure that "repo.git"
|
||||
# contains the file "git-daemon-export-ok" (for daemon case) and the
|
||||
# line "repo.git" exists in the "projects.list" file (for gitweb case).
|
||||
|
||||
# how run: manual, by GL admin
|
||||
# when:
|
||||
|
@ -42,7 +47,7 @@ $Data::Dumper::Indent = 1;
|
|||
# common definitions
|
||||
# ----------------------------------------------------------------------------
|
||||
|
||||
our ($GL_ADMINDIR, $GL_CONF, $GL_KEYDIR, $GL_CONF_COMPILED, $REPO_BASE, $REPO_UMASK);
|
||||
our ($GL_ADMINDIR, $GL_CONF, $GL_KEYDIR, $GL_CONF_COMPILED, $REPO_BASE, $REPO_UMASK, $PROJECTS_LIST);
|
||||
|
||||
# now that this thing *may* be run via "push to admin", any errors have to
|
||||
# grab the admin's ATTENTION so he won't miss them among the other messages a
|
||||
|
@ -227,6 +232,73 @@ warn "\n\t\t***** WARNING *****\n" .
|
|||
"\t\"git version dependency\" in doc/3-faq-tips-etc.mkd\n"
|
||||
if $git_too_old;
|
||||
|
||||
# ----------------------------------------------------------------------------
|
||||
# handle gitweb and daemon
|
||||
# ----------------------------------------------------------------------------
|
||||
|
||||
# How you specify gitweb and daemon access is quite different from gitosis. I
|
||||
# just assume you'll never have any *real* users called "gitweb" or "daemon"
|
||||
# :-) These are now "pseduo users" -- giving them "R" access to a repo is all
|
||||
# you have to do
|
||||
|
||||
wrap_chdir("$repo_base_abs");
|
||||
|
||||
# get the current project list; note that the file may not yet exist if no
|
||||
# gitweb access has been specified so far
|
||||
my %projlist = ();
|
||||
if (-f $PROJECTS_LIST) {
|
||||
my $projlist_fh = wrap_open( "<", $PROJECTS_LIST);
|
||||
while(<$projlist_fh>) {
|
||||
chomp;
|
||||
$projlist{$_} = 1;
|
||||
}
|
||||
close $projlist_fh;
|
||||
}
|
||||
my $projlist_changed = 0;
|
||||
|
||||
# daemons first...
|
||||
for my $repo (sort keys %repos) {
|
||||
my $export_ok = "$repo.git/git-daemon-export-ok";
|
||||
if ($repos{$repo}{'R'}{'daemon'}) {
|
||||
unless (-f $export_ok) {
|
||||
system("touch $export_ok");
|
||||
print STDERR "daemon add $repo.git\n";
|
||||
}
|
||||
} else {
|
||||
if (-f $export_ok) {
|
||||
unlink($export_ok);
|
||||
print STDERR "daemon del $repo.git\n";
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# ...then gitwebs
|
||||
for my $repo (sort keys %repos) {
|
||||
if ($repos{$repo}{'R'}{'gitweb'}) {
|
||||
unless ($projlist{"$repo.git"}) {
|
||||
# not in the old list; add it to the new one
|
||||
$projlist{"$repo.git"} = 1;
|
||||
$projlist_changed = 1;
|
||||
print STDERR "gitweb add $repo.git\n";
|
||||
}
|
||||
} else {
|
||||
if ($projlist{"$repo.git"}) {
|
||||
# delete it from new list
|
||||
delete $projlist{"$repo.git"};
|
||||
$projlist_changed = 1;
|
||||
print STDERR "gitweb del $repo.git\n";
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# has there been a change?
|
||||
if ($projlist_changed) {
|
||||
print STDERR "updating gitweb project list $PROJECTS_LIST\n";
|
||||
my $projlist_fh = wrap_open( ">", $PROJECTS_LIST);
|
||||
print $projlist_fh join("\n", sort keys %projlist), "\n" if %projlist;
|
||||
close $projlist_fh;
|
||||
}
|
||||
|
||||
# ----------------------------------------------------------------------------
|
||||
# "compile" ssh authorized_keys
|
||||
# ----------------------------------------------------------------------------
|
||||
|
|
Loading…
Reference in a new issue