mirror of
https://github.com/wahyd4/gitolite.git
synced 2026-08-09 04:55:55 +10:00
202 lines
7.5 KiB
HTML
202 lines
7.5 KiB
HTML
<head>
|
|
<style>
|
|
body { background: #fff; margin-left: 40px; font-size: 0.9em; font-family: sans-serif; max-width: 800px; }
|
|
h1 { background: #ffb; margin-left: -30px; border-top: 5px solid #ccc; }
|
|
h2 { background: #ffb; margin-left: -20px; border-top: 3px solid #ddd; }
|
|
h3 { background: #ffb; margin-left: -10px; }
|
|
h4 { background: #ffb; }
|
|
code { font-size: 1.1em; background: #ddf; }
|
|
pre { margin-left: 2em; background: #ddf; }
|
|
pre code { font-size: 1.1em; background: #ddf; }
|
|
</style>
|
|
|
|
</head>
|
|
|
|
<p style="text-align:center">
|
|
<a href="master-toc.html">master TOC</a>
|
|
|
|
|
<a href="master-toc.html#developer-notes">chapter TOC</a>
|
|
</p>
|
|
|
|
<!-- file: dev_notes -->
|
|
|
|
<h1>developer/patch maintainer notes</h1>
|
|
|
|
<p><a name="_general_stuff"></a></p>
|
|
|
|
<h2>general stuff</h2>
|
|
|
|
<ul>
|
|
<li><p>all scripts and libraries must be in the same directory. However, RPM/DEB
|
|
packagers can put the libraries where they want, as long as they can be
|
|
found in perl's default <code>@INC</code>.</p></li>
|
|
<li><p>gl-auth-command <strong>requires</strong> an actual <code>~/.gitolite.rc</code> (except if your
|
|
initials are "JK" or "DG", in which case <code>/etc/gitolite/gitolite.rc</code> also
|
|
works!) It knows how to look around and set env vars etc correctly</p></li>
|
|
<li><p>all programs except gl-auth-command <strong>require</strong> the environment variables
|
|
<code>GL_RC</code> and <code>GL_BINDIR</code> set properly. Your best bet is to run them <em>via</em>
|
|
gl-auth-command, like so:</p>
|
|
|
|
<pre><code>path/to/gl-auth-command -e other_program other_program_arguments
|
|
</code></pre>
|
|
|
|
<p>In any case none of these programs are meant to be run manually -- pretty
|
|
much all of them are run via gl-auth-command or from something that was
|
|
forked from it so the variables <em>will</em> exist during normal operation.</p></li>
|
|
</ul>
|
|
|
|
<p><a name="_the_rc_file"></a></p>
|
|
|
|
<h2>the rc file</h2>
|
|
|
|
<p>The 'rc' file has one major change from v1: any new values in the rc file need
|
|
to be added to the @EXPORT list in <code>src/gitolite_rc.pm</code>.</p>
|
|
|
|
<p><a name="_modules"></a></p>
|
|
|
|
<h2>modules</h2>
|
|
|
|
<p>There are 3 "modules" (<code>gitolite_rc</code>, <code>gitolite_env</code>, and <code>gitolite</code> itself).
|
|
Their purposes should be fairly obvious.</p>
|
|
|
|
<p><a name="_that_bindir_thing"></a></p>
|
|
|
|
<h2>that 'bindir' thing</h2>
|
|
|
|
<p>The importance of <code>GL_BINDIR</code> is that the command= argument in
|
|
<code>~/.ssh/authorized_keys</code> must be a full path, ideally, and the compile script
|
|
gets this from <code>GL_BINDIR</code>.</p>
|
|
|
|
<p><a name="_from_perl"></a></p>
|
|
|
|
<h3>from perl</h3>
|
|
|
|
<ul>
|
|
<li><p>for frequently run perl programs, I prefer my method</p>
|
|
|
|
<ul>
|
|
<li>gl-auth-command -- this is invoked with a full path</li>
|
|
<li>gl-mirror-shell -- same as above</li>
|
|
<li>gl-time -- same as above</li>
|
|
</ul></li>
|
|
<li><p>"their" ideal is "FindBin". I will use it only on manually or
|
|
infrequently run programs</p>
|
|
|
|
<ul>
|
|
<li>gl-setup-authkeys (external shim to compile keys separately from PTA)</li>
|
|
</ul></li>
|
|
</ul>
|
|
|
|
<p><a name="_from_shell"></a></p>
|
|
|
|
<h3>from shell</h3>
|
|
|
|
<ul>
|
|
<li><p>a perl program called gl-query-rc finds its own BINDIR (using my perl
|
|
method, not FindBin). This is suitable for calling from shell scripts
|
|
as <code>${0%/*}/gl-query-rc GL_BINDIR</code></p>
|
|
|
|
<ul>
|
|
<li>gl-setup</li>
|
|
<li>gl-tool</li>
|
|
<li>gl-mirror-push</li>
|
|
</ul></li>
|
|
</ul>
|
|
|
|
<p><a name="_OUTLIER_"></a></p>
|
|
|
|
<h3>OUTLIER!</h3>
|
|
|
|
<ul>
|
|
<li>gl-admin-push is an outlier. For some silly reason I have the notion that
|
|
even if it runs from /tmp it should get the right values, so it is the
|
|
only one that interrogates <code>~/.ssh/authorized_keys</code> to get the actual
|
|
BINDIR in use!</li>
|
|
</ul>
|
|
|
|
<p><a name="_special_types_of_setups"></a></p>
|
|
|
|
<h2>special types of setups</h2>
|
|
|
|
<p><a name="_Fedora"></a></p>
|
|
|
|
<h3>Fedora</h3>
|
|
|
|
<p>Fedora has a very special setup, as follows:</p>
|
|
|
|
<ul>
|
|
<li>each user has his own userid and login</li>
|
|
<li>his/her ~/.ssh/authkeys file (containing only his/her key) has a
|
|
"command=" clause invoking gl-auth-command</li>
|
|
<li><p>trusted users have "gl-auth-command -s" meaning they can get a shell if
|
|
they want to</p></li>
|
|
<li><p>actual git repos are under "git" (or some such), and include the chmod g+s
|
|
(git init --shared) unix perms tricks for shared access</p></li>
|
|
<li><p>but since they're coming through gl-auth, branch-level acls are in effect</p></li>
|
|
<li><p>the gitolite config file is generated from some database and compiled (all
|
|
via cron)</p></li>
|
|
<li><p>the keydir/ is empty; in fact they probably don't use the admin repo at
|
|
all, AFAIK</p></li>
|
|
</ul>
|
|
|
|
<p>The most important implication of this setup is that <strong>the RC file is no
|
|
longer is <code>$HOME</code> of the 'git' user</strong>. They keep it in
|
|
<code>/etc/gitolite/gitolite.rc</code>. This means that a properly setup rc file must
|
|
already be present in <code>/etc/gitolite/gitolite.rc</code> before doing any such
|
|
installs.</p>
|
|
|
|
<p>There are also some other "impedance mismatches" that may show up. For
|
|
example, the gl-setup triggered by detecting a change in <code>$data_version</code>
|
|
following an RPM update once caused problems. This auto-update is designed to
|
|
run on the next "hit" of any kind (which arguably makes things very easy in
|
|
normal installations), but in Fedora's case it also means it runs <em>as that
|
|
user</em>. Who may not have "write" access to <code>$GL_ADMINDIR</code>! So the compile
|
|
fails, and you now have new code trying to work with old format data.</p>
|
|
|
|
<p>The solution is to explicitly run a compile, from a properly privileged
|
|
userid, as soon as you do an RPM upgrade.</p>
|
|
|
|
<!-- file: developer-notes -->
|
|
|
|
<p><a name="_Why_v2_"></a></p>
|
|
|
|
<h1><strong>Why v2?</strong></h1>
|
|
|
|
<p>I went onto <code>#perl</code> to ask some question about setpriority() and got yelled at
|
|
for writing "horrible code". And that was one of the kinder comments; my
|
|
rather fragile ego is trying to forget the rest ;-)</p>
|
|
|
|
<p>They also gave me a link to a PDF book, "Modern Perl" by 'chromatic'. Nice
|
|
book; one of the first things you learn from it is that you should not go to
|
|
<code>#perl</code> for general help.</p>
|
|
|
|
<p>Anyway, the summary of the collective angst of <code>#perl</code> (well 2 people anyway)
|
|
was: use Getopt::Long, FindBin, 'use lib', a library for HTTP stuff, stop
|
|
prefixing subs with '&', and get rid of the huge number of 'our' declarations.</p>
|
|
|
|
<p>That last item is the only one I totally agree with, because it was on my long
|
|
term todo list anyway. And 'use lib' sorta goes with it, so that's fine too.
|
|
And as soon as I found that vim colors the sub names differently if you take
|
|
out the '&' I decided I'd do that too :-) [But honestly, if <code>&sub</code> is so bad
|
|
shouldn't "man perlsub" at least say something negative about it, other than
|
|
"disables prototype checking", which doesn't matter here since I'm not using
|
|
prototypes?]</p>
|
|
|
|
<p>As for the rest, FindBin brings in a good 1000+ lines for something that I do
|
|
in a line or two (since I don't care about all the pathological edge cases).
|
|
Getopt::Long is 2649 lines to replace the code below [note that there <em>is</em>
|
|
only one possible option to this command, and it is <em>never</em> run manually
|
|
either, so I don't need any fancy features]:</p>
|
|
|
|
<pre><code>my $shell_allowed = 0;
|
|
if (@ARGV and $ARGV[0] eq '-s') {
|
|
$shell_allowed = 1;
|
|
shift;
|
|
}
|
|
</code></pre>
|
|
|
|
<p>Apparently TMTOWTDI has given way to TOOWTDI.</p>
|
|
|
|
<p>Anyway, I spent a few hours refactoring it. And I do thank them for pushing
|
|
me to stop being lazy on the "our" business.</p>
|