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

README.mkd

@@ -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

conf/example.conf

@@ -8,9 +8,13 @@
 
 # objectives, over and above gitosis:
 #     - simpler syntax
-#     - no gitweb/daemon control
+#     - easier gitweb/daemon control
-#     - allows ff/non-ff control
+#     - specify who can push a branch/tag
-#     - allows branch level control
+#     - 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 :-)
+

conf/example.gitolite.rc

@@ -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

doc/0-UPGRADE.mkd

@@ -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

doc/1-migrate.mkd

@@ -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:
 

doc/2-admin.mkd

@@ -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 :-)

doc/3-faq-tips-etc.mkd

@@ -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 :-)

src/gl-compile-conf

@@ -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
 # ----------------------------------------------------------------------------