home/gitolite
2
0
Fork 0
mirror of https://github.com/wahyd4/gitolite.git synced 2026-08-09 04:55:55 +10:00
Code Issues Packages Projects Releases Wiki Activity

autogenerated from 67dad88ea977f7 (Merge branch 'vrs' into HEAD)

Browse Source
This commit is contained in:
Sitaram Chamarty
2011-11-07 22:30:57 +05:30
parent 4691b7b82f
commit e99cf50ad1
9 changed files with 140 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.label-store
+2 -1
View File
@@ -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"',
1000-words-all.html
+62
View File
@@ -105,3 +105,65 @@ paragraphs, maybe like this, and save the file:</p>
<p>You do NOT add the repos directly anywhere on the server; you do it by
cloning, adding keys, and pushing.</p>
<p><a name="flow"></a></p>
<h2>gitolite flow</h2>
<p>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.</p>
<p>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.</p>
<p>Authentication (<strong>AUTHN</strong>) is typically done by sshd, but could also be httpd
etc. This step invokes <code>gl-auth-command</code> (<strong>GLAC</strong>), which is the main entry
point for gitolite, passing it a username and a command. The most common
commands look like one of these:</p>
<pre><code>git-upload-pack 'repo'
git-receive-pack 'repo'
</code></pre>
<p>GLAC first checks the command to see if it is a read or a write (<strong>RW</strong>)
operation (upload-pack is a read, receive-pack is a write).</p>
<p>At this point, GLAC knows the username, the reponame, and the type of
operation. It executes the first <a href="tipssec__.html#2levels" title="two levels of access rights checking">level</a> access check (<strong>AC1</strong>),
which passes if the user has at least one ref for which the operation is
allowed.</p>
<p><font color="gray">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:</p>
<pre><code>repo foo
- = alice
RW = alice
</code></pre>
<p>although some other user, say "bob", will not.</font></p>
<img src="images/1000-words-0004" title="Figure 4" />
<p>Once AC1 has passed, GLAC calls the <a href="hooks.html#pre-git" title="&quot;gl-pre-git&quot; hook"><code>gl-pre-git</code></a> hook (<strong>PGH</strong>), 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.</p>
<p>If PGH passes, GLAC now invokes git itself, which runs the command specified.
If the command is <code>git-upload-pack</code>, nothing else happens and the process
completes.</p>
<p>However, if it is a push operation (<code>git-receive-pack</code>) then git calls the
update hook (<strong>UP</strong>), per <code>man githooks</code>. The update hook executes the second
<a href="tipssec__.html#2levels" title="two levels of access rights checking">level</a> access check (<strong>AC2</strong>), and depending on its success, the
operation succeeds or fails.</p>
<p>The update hook calls a secondary hook, <a href="hooks.html#hookchaining" title="hook chaining"><code>update.secondary</code></a>
(<strong>SEC</strong>) if it exists. Similar to PGH, this allows the admin to add
site-local checks before allowing the update to complete.</p>
admin-all.html
+5 -2
View File
@@ -195,7 +195,7 @@ processing you wish to do in your hook code:</p>
you need this functionality, just supply a hook called "gl-post-init" with
whatever code you want in it.</p>
<p><a name="_gl_pre_git_hook_"></a></p>
<p><a name="pre-git"></a></p>
<h3>"gl-pre-git" hook</h3>
@@ -360,6 +360,9 @@ given below. Please follow all the steps; do not skip or improvise! Ask me
if things are not clear -- you can help me fine tune this document :-)</p>
<ul>
<li><p>(workstation, old server) <strong>pull</strong> the latest changes to the
<code>gitolite-admin</code> repo to your workstation, if you don't have them
already. You'll need them later on.</p></li>
<li><p>(old server) <strong>disable</strong> 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 <code>~/.gitolite.rc</code> on the old server:</p>
@@ -409,7 +412,7 @@ git commit -m "new server, new key"
</code></pre></li>
<li><p>set the URL for the new server</p>
<pre><code>git remote --set-url origin git@newserver:gitolite-admin
<pre><code>git remote set-url origin git@newserver:gitolite-admin
</code></pre></li>
<li><p>push the config, including past history</p>
hooks.html
+1 -1
View File
@@ -128,7 +128,7 @@ processing you wish to do in your hook code:</p>
you need this functionality, just supply a hook called "gl-post-init" with
whatever code you want in it.</p>
<p><a name="_gl_pre_git_hook_"></a></p>
<p><a name="pre-git"></a></p>
<h3>"gl-pre-git" hook</h3>
images/1000-words-0004
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

master-toc.html
+2 -1
View File
@@ -22,6 +22,7 @@
<li><a href="pictures.html#installation_and_setup_">installation and setup</a></li>
<li><a href="pictures.html#adding_users_to_gitolite_">adding users to gitolite</a></li>
<li><a href="pictures.html#adding_repos_to_gitolite_">adding repos to gitolite</a></li>
<li><a href="pictures.html#flow">gitolite flow</a> <!-- (flow) --></li>
</ul></li>
</ul>
@@ -72,7 +73,7 @@
<li><a href="hooks.html#hookchaining">hook chaining</a> <!-- (hookchaining) --></li>
<li><a href="hooks.html#environment_variables_available_to_hooks_">environment variables available to hooks</a></li>
<li><a href="hooks.html#_gl_post_init_hook_">"gl-post-init" hook</a></li>
<li><a href="hooks.html#_gl_pre_git_hook_">"gl-pre-git" hook</a></li>
<li><a href="hooks.html#pre-git">"gl-pre-git" hook</a> <!-- (pre-git) --></li>
</ul></li>
<li><a href="admin.html#other_features_">other features</a>
<ul>
master-toc.mkd
+2 -1
View File
@@ -18,6 +18,7 @@
* [installation and setup](pictures.html#installation_and_setup_)
* [adding users to gitolite](pictures.html#adding_users_to_gitolite_)
* [adding repos to gitolite](pictures.html#adding_repos_to_gitolite_)
* [gitolite flow](pictures.html#flow) <!-- (flow) -->
----
@@ -55,7 +56,7 @@
* [hook chaining](hooks.html#hookchaining) <!-- (hookchaining) -->
* [environment variables available to hooks](hooks.html#environment_variables_available_to_hooks_)
* ["gl-post-init" hook](hooks.html#_gl_post_init_hook_)
* ["gl-pre-git" hook](hooks.html#_gl_pre_git_hook_)
* ["gl-pre-git" hook](hooks.html#pre-git) <!-- (pre-git) -->
* [other features](admin.html#other_features_)
* [moving pre-existing repos into gitolite](moverepos.html) <!-- (moverepos) -->
* [moving the whole thing from one server to another](moveserver.html) <!-- (moveserver) -->
moveserver.html
+4 -1
View File
@@ -43,6 +43,9 @@ given below. Please follow all the steps; do not skip or improvise! Ask me
if things are not clear -- you can help me fine tune this document :-)</p>
<ul>
<li><p>(workstation, old server) <strong>pull</strong> the latest changes to the
<code>gitolite-admin</code> repo to your workstation, if you don't have them
already. You'll need them later on.</p></li>
<li><p>(old server) <strong>disable</strong> 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 <code>~/.gitolite.rc</code> on the old server:</p>
@@ -92,7 +95,7 @@ git commit -m "new server, new key"
</code></pre></li>
<li><p>set the URL for the new server</p>
<pre><code>git remote --set-url origin git@newserver:gitolite-admin
<pre><code>git remote set-url origin git@newserver:gitolite-admin
</code></pre></li>
<li><p>push the config, including past history</p>
pictures.html
+62
View File
@@ -104,3 +104,65 @@ paragraphs, maybe like this, and save the file:</p>
<p>You do NOT add the repos directly anywhere on the server; you do it by
cloning, adding keys, and pushing.</p>
<p><a name="flow"></a></p>
<h2>gitolite flow</h2>
<p>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.</p>
<p>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.</p>
<p>Authentication (<strong>AUTHN</strong>) is typically done by sshd, but could also be httpd
etc. This step invokes <code>gl-auth-command</code> (<strong>GLAC</strong>), which is the main entry
point for gitolite, passing it a username and a command. The most common
commands look like one of these:</p>
<pre><code>git-upload-pack 'repo'
git-receive-pack 'repo'
</code></pre>
<p>GLAC first checks the command to see if it is a read or a write (<strong>RW</strong>)
operation (upload-pack is a read, receive-pack is a write).</p>
<p>At this point, GLAC knows the username, the reponame, and the type of
operation. It executes the first <a href="tipssec__.html#2levels" title="two levels of access rights checking">level</a> access check (<strong>AC1</strong>),
which passes if the user has at least one ref for which the operation is
allowed.</p>
<p><font color="gray">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:</p>
<pre><code>repo foo
- = alice
RW = alice
</code></pre>
<p>although some other user, say "bob", will not.</font></p>
<img src="images/1000-words-0004" title="Figure 4" />
<p>Once AC1 has passed, GLAC calls the <a href="hooks.html#pre-git" title="&quot;gl-pre-git&quot; hook"><code>gl-pre-git</code></a> hook (<strong>PGH</strong>), 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.</p>
<p>If PGH passes, GLAC now invokes git itself, which runs the command specified.
If the command is <code>git-upload-pack</code>, nothing else happens and the process
completes.</p>
<p>However, if it is a push operation (<code>git-receive-pack</code>) then git calls the
update hook (<strong>UP</strong>), per <code>man githooks</code>. The update hook executes the second
<a href="tipssec__.html#2levels" title="two levels of access rights checking">level</a> access check (<strong>AC2</strong>), and depending on its success, the
operation succeeds or fails.</p>
<p>The update hook calls a secondary hook, <a href="hooks.html#hookchaining" title="hook chaining"><code>update.secondary</code></a>
(<strong>SEC</strong>) if it exists. Similar to PGH, this allows the admin to add
site-local checks before allowing the update to complete.</p>