diff --git a/.label-store b/.label-store index 32b40b9..ab172a1 100644 --- a/.label-store +++ b/.label-store @@ -76,7 +76,6 @@ '_deny_rules_for_the_entire_repo_' => 'aac.html#_deny_rules_for_the_entire_repo_ ""deny" rules for the entire repo"', '_fake_repos_and_access_control_for_non_git_programs_' => 'ADCs.html#_fake_repos_and_access_control_for_non_git_programs_ ""fake" repos and access control for non-git programs"', '_gl_post_init_hook_' => 'hooks.html#_gl_post_init_hook_ ""gl-post-init" hook"', - '_gl_pre_git_hook_' => 'hooks.html#_gl_pre_git_hook_ ""gl-pre-git" hook"', '_poking_the_admin_repo_to_force_a_compile_' => 'tips.html#_poking_the_admin_repo_to_force_a_compile_ ""poking" the admin repo to force a compile"', '_site_local_commands_' => 'user.html#_site_local_commands_ ""site-local" commands"', '_when_do_hooks_propagate__' => 'hook_prop.html#_when_do_hooks_propagate__ "**when** do hooks propagate?"', @@ -161,6 +160,7 @@ 'exbac' => 'exbac.html "basic access control"', 'expand' => 'info_expand.html#expand "the "expand" command"', 'features_' => 'tips.html#features_ "features"', + 'flow' => 'pictures.html#flow "gitolite flow"', 'fork' => 'ADCs.html#fork "the \'fork\' ADC"', 'from_perl_' => 'dev_notes.html#from_perl_ "from perl"', 'from_shell_' => 'dev_notes.html#from_shell_ "from shell"', @@ -280,6 +280,7 @@ 'pictures' => 'pictures.html "gitolite in pictures"', 'playing_with_gitolite_' => 't_.html#playing_with_gitolite_ "playing with gitolite"', 'please_read_this_first_' => 'admin.html#please_read_this_first_ "please read this first"', + 'pre-git' => 'hooks.html#pre-git ""gl-pre-git" hook"', 'pre_requisites_' => 'mirr_complex_example.html#pre_requisites_ "pre-requisites"', 'problems_' => 'password_access.html#problems_ "problems"', 'problems_with_the_old_mirroring_model_' => 'mirrdisc.html#problems_with_the_old_mirroring_model_ "problems with the old mirroring model"', diff --git a/1000-words-all.html b/1000-words-all.html index 693a2b3..4fbc968 100644 --- a/1000-words-all.html +++ b/1000-words-all.html @@ -105,3 +105,65 @@ paragraphs, maybe like this, and save the file:
You do NOT add the repos directly anywhere on the server; you do it by cloning, adding keys, and pushing.
+ + + +This is the overall flow of gitolite, showing how the various parts fit +together. This is particularly useful for an admin to see where his +site-local hooks fit, how they get called, and what stages of the process they +affect.
+ +Legend: diamonds are decision boxes whose results can abort the operation. +Arrows are calls/invocations. Dashed lines just point to sub-parts of the +process on the left side. Blue processes are external to gitolite. Green is +gitolite code. Yellow is site-local code that you (the admin of your site) +can add, to influence gitolite's behaviour.
+ +Authentication (AUTHN) is typically done by sshd, but could also be httpd
+etc. This step invokes gl-auth-command (GLAC), which is the main entry
+point for gitolite, passing it a username and a command. The most common
+commands look like one of these:
git-upload-pack 'repo'
+git-receive-pack 'repo'
+
+
+GLAC first checks the command to see if it is a read or a write (RW) +operation (upload-pack is a read, receive-pack is a write).
+ +At this point, GLAC knows the username, the reponame, and the type of +operation. It executes the first level access check (AC1), +which passes if the user has at least one ref for which the operation is +allowed.
+ +Note that neither "deny" rules nor the rule sequences are +taken into account for this step. For instance, user "alice" will pass this +step even with this configuration:
+ +repo foo
+ - = alice
+ RW = alice
+
+
+although some other user, say "bob", will not.
+ +Once AC1 has passed, GLAC calls the gl-pre-git hook (PGH), if
+it is present. This hook allows the admin to add his own checks at this first
+stage and even abort the operation if needed.
If PGH passes, GLAC now invokes git itself, which runs the command specified.
+If the command is git-upload-pack, nothing else happens and the process
+completes.
However, if it is a push operation (git-receive-pack) then git calls the
+update hook (UP), per man githooks. The update hook executes the second
+level access check (AC2), and depending on its success, the
+operation succeeds or fails.
The update hook calls a secondary hook, update.secondary
+(SEC) if it exists. Similar to PGH, this allows the admin to add
+site-local checks before allowing the update to complete.
(workstation, old server) pull the latest changes to the
+gitolite-admin repo to your workstation, if you don't have them
+already. You'll need them later on.
(old server) disable the old server so your users will not push any
changes to it. There are several ways to do this, but the simplest is to
insert this line at the top of ~/.gitolite.rc on the old server:
set the URL for the new server
-git remote --set-url origin git@newserver:gitolite-admin
+git remote set-url origin git@newserver:gitolite-admin
push the config, including past history
diff --git a/hooks.html b/hooks.html index 46bf2f0..a37a4d4 100644 --- a/hooks.html +++ b/hooks.html @@ -128,7 +128,7 @@ processing you wish to do in your hook code: you need this functionality, just supply a hook called "gl-post-init" with whatever code you want in it. - +(workstation, old server) pull the latest changes to the
+gitolite-admin repo to your workstation, if you don't have them
+already. You'll need them later on.
(old server) disable the old server so your users will not push any
changes to it. There are several ways to do this, but the simplest is to
insert this line at the top of ~/.gitolite.rc on the old server:
set the URL for the new server
-git remote --set-url origin git@newserver:gitolite-admin
+git remote set-url origin git@newserver:gitolite-admin
push the config, including past history
diff --git a/pictures.html b/pictures.html index ef3b7c2..287a80f 100644 --- a/pictures.html +++ b/pictures.html @@ -104,3 +104,65 @@ paragraphs, maybe like this, and save the file:You do NOT add the repos directly anywhere on the server; you do it by cloning, adding keys, and pushing.
+ + + +This is the overall flow of gitolite, showing how the various parts fit +together. This is particularly useful for an admin to see where his +site-local hooks fit, how they get called, and what stages of the process they +affect.
+ +Legend: diamonds are decision boxes whose results can abort the operation. +Arrows are calls/invocations. Dashed lines just point to sub-parts of the +process on the left side. Blue processes are external to gitolite. Green is +gitolite code. Yellow is site-local code that you (the admin of your site) +can add, to influence gitolite's behaviour.
+ +Authentication (AUTHN) is typically done by sshd, but could also be httpd
+etc. This step invokes gl-auth-command (GLAC), which is the main entry
+point for gitolite, passing it a username and a command. The most common
+commands look like one of these:
git-upload-pack 'repo'
+git-receive-pack 'repo'
+
+
+GLAC first checks the command to see if it is a read or a write (RW) +operation (upload-pack is a read, receive-pack is a write).
+ +At this point, GLAC knows the username, the reponame, and the type of +operation. It executes the first level access check (AC1), +which passes if the user has at least one ref for which the operation is +allowed.
+ +Note that neither "deny" rules nor the rule sequences are +taken into account for this step. For instance, user "alice" will pass this +step even with this configuration:
+ +repo foo
+ - = alice
+ RW = alice
+
+
+although some other user, say "bob", will not.
+ +Once AC1 has passed, GLAC calls the gl-pre-git hook (PGH), if
+it is present. This hook allows the admin to add his own checks at this first
+stage and even abort the operation if needed.
If PGH passes, GLAC now invokes git itself, which runs the command specified.
+If the command is git-upload-pack, nothing else happens and the process
+completes.
However, if it is a push operation (git-receive-pack) then git calls the
+update hook (UP), per man githooks. The update hook executes the second
+level access check (AC2), and depending on its success, the
+operation succeeds or fails.
The update hook calls a secondary hook, update.secondary
+(SEC) if it exists. Similar to PGH, this allows the admin to add
+site-local checks before allowing the update to complete.