diff options
| -rw-r--r-- | conf/example.conf | 8 | ||||
| -rw-r--r-- | contrib/gerrit.mkd | 111 | ||||
| -rw-r--r-- | doc/0-INSTALL.mkd | 44 | ||||
| -rw-r--r-- | doc/3-faq-tips-etc.mkd | 104 | ||||
| -rw-r--r-- | doc/4-wildcard-repositories.mkd | 10 | ||||
| -rw-r--r-- | doc/7-install-transcript.mkd | 12 | ||||
| -rw-r--r-- | doc/CHANGELOG | 5 | ||||
| -rw-r--r-- | doc/report-output.mkd | 61 | ||||
| -rw-r--r-- | src/gitolite.pm | 15 | ||||
| -rwxr-xr-x | src/gl-auth-command | 2 | ||||
| -rwxr-xr-x | src/gl-compile-conf | 15 | ||||
| -rwxr-xr-x | src/gl-easy-install | 35 |
12 files changed, 314 insertions, 108 deletions
diff --git a/conf/example.conf b/conf/example.conf index 6d8c3d7..5a5b36a 100644 --- a/conf/example.conf +++ b/conf/example.conf @@ -67,13 +67,13 @@ # start line: # repo [one or more repos and/or repo groups] # followed by one or more permissions lines: -# (C|D|R|RW|RW+) [zero or more refexes] = [one or more users] +# (C|R|RW|RW+|RWD|RW+D) [zero or more refexes] = [one or more users] -# there are 5 types of permissions: R, RW, and RW+ are simple (the "+" means +# there are 6 types of permissions: R, RW, and RW+ are simple (the "+" means # permission to "rewind" -- force push a non-fast forward to -- a branch). # The C permission is described in doc/4-wildcard-repositories.mkd. The D -# permission is described in doc/3-faq-tips-etc.mkd, in the "advanced -# features" section. +# addition to RW/RW+ is described in doc/3-faq-tips-etc.mkd, in the section on +# "separating delete and rewind rights". # how permissions are matched: # - user, repo, and access (W or +) are known. For that combination, if diff --git a/contrib/gerrit.mkd b/contrib/gerrit.mkd new file mode 100644 index 0000000..f08a1af --- /dev/null +++ b/contrib/gerrit.mkd @@ -0,0 +1,111 @@ +# comparing gerrit and gitolite + +Gerrit and gitolite have too many high level differences. Size is most +visible of course: 56000 lines of Java versus 1300 lines of perl+shell, +according to David A. Wheeler's 'SLOCCount' tool. Gerrit needs a database, +and even comes with its own ssh server and git server, and since the git +engine is internal it probably has to include a lot of things that normal git +already has; I wouldn't know for sure. + +Gerrit allows a lot more de-centralisation in managing the system, and of +course excels at code review, and it seems geared to really large, open +source-ish projects with lots of contributors. + +Gitolite works on a pure command-line install and a plain text file config, +and is designed to run unobtrusively and quite transparently to all developers +-- other than sending the admin their pubkey, nothing really changes for them +in their workflow, toolset, etc. The "lite" in the name still holds, despite +all the extra features being pumped in! + +Gitolite was mainly written for a corporate environment, where we really, +really, need branch-level ACLs. While they would certainly love the code +review part, things like *voting* on a change, and so on seem a bit alien, and +it seems to me that code review itself is more likely to be a hierarchical +thing, not a peer-to-peer, "anyone can comment" thing. I could be wrong. + +---- + +In short, gitolite doesn't do the main thing that gerrit does, and gerrit is +so much bigger than gitolite in so many ways, it seems really odd to compare +them at all. + +However, it seems gerrit comes closest to gitolite in terms of flexibility of +access control, which is gitolite's main strength, so I thought it would be +useful to compare gitolite with just what is in the "access-control.html" in +the gerrit war file. Or see [this][gdac]. [...and stop sniggering at the +"svn" in the link dammit!] + +[gdac]: http://gerrit.googlecode.com/svn/documentation/2.1.2/access-control.html +[jwzq]: http://regex.info/blog/2006-09-15/247 + +**Administrators**: anyone who has gitolite-admin push privs + +**Anonymous Users**: gitolite doesn't do that, though the "ssh-plus" branch, +combined with git-daemon2 (Ilari) will allow that in future. When git-daemon2 +becomes mainstream, the supporting code in this branch will also be merged +into "master". + +**Registered Users**: @all + +**Account Groups**: @groups in gitolite. We do allow them to be nested, +although the parsing is single-pass. We also don't have group `foo-admin` +managing membership to group `foo` though; all groups are managed by the eqvt +of "Administrators". + +**Project ACLs**: first, let's remember (again) that we don't have any of the code +review stuff :) + + * **Reference-level access controls** make no mention of regexes. I'm not + [JWZ][jwzq], and I strongly consider regexes a plus point :) + + * They also make no mention of giving permissions to individual users, only + groups. If this is true, it would be a little cumbersome when managing + many small projects -- projects where you have only one QA, one + integrator, etc., would end up making many 1-man groups. [If anyone who's + used gerrit can correct me on this I'd appreciate it]. + + * **Evaluation** order and priority of access control rules are different. + Gerrit goes by specificity, gitolite goes by sequence. It shouldn't + matter; they're probably equivalent except perhaps in some far-fetched + scenarios. + + * One big difference is that gitolite does not process "deny" rules ("-1 no + Access" in gerrit terms) for *read* access -- we only support those for + write access. Gerrit uses this to "hide a handful of projects on an + otherwise public server"; in gitolite you'd better avoid giving `R = @all` + in the first place :) + + * [Update 2010-04-14: it appears that Gerrit is also in the process of + implementing *read* access control at the branch level -- they can afford + to even think of that because they have a full jgit stack to play with. + Gitolite is dependent on git itself to provide that -- it just cannot be + done without support from git core. I can see some corporates drooling at + this possibility (makes no sense for open source projects IMO) ;-)] + +**Categories**: + + * gitolite doesnt have an "owner" for each project in any administrative + sense. Perhaps you could consider whoever has `RW+` perms to be an owner + but it doesn't go beyond what that implies. + + * gitolite doesnt do anything special to signed or annotated tags + + * gitolite always allows creating a branch. The only way to prevent that is + to list out allowed branches explicitly (make sure you end the refex with + a `$`!). + + * Force push is the same as delete: historically (and by default, even now) + gitolite does the same . However, I've only recently (and somewhat + reluctantly) changed gitolite to allow treating these two separately. + + Of course, direct pushing clashes with code review, and gerrit recommends + that if you want code review you should not use this feature. [Normal + pushes in gerrit go through a temp branch that is moved to the correct one + after a review is done; direct pushes are all that gitolite has]. + + * author/committer identity: checking these fields in pushed commits is + likely to be important in some projects, but gitolite doesn't have any + notion of this. Hmm... I smell another feature in the future :) + +The rest of it is in areas that the two tools have no overlap on (again, code +review being the main thing). diff --git a/doc/0-INSTALL.mkd b/doc/0-INSTALL.mkd index 4351a46..59f32dc 100644 --- a/doc/0-INSTALL.mkd +++ b/doc/0-INSTALL.mkd @@ -259,17 +259,21 @@ Sometimes you might find gitolite is overkill -- you have only one user (yourself) pushing maybe. Or maybe gitolite is just not enough -- you want a web-based front end that users can use to manage their keys themselves, etc., in which case you'd probably switch to [github][g1], [girocco][g2], -[indefero][g3] or [gitorious][g4]. Either way, you'd like to uninstall -gitolite. +[indefero][g3] or [gitorious][g4]. [Gerrit][g5] is quite nice too, if you +want collaborative code review there's nothing like it. Either way, you'd +like to uninstall gitolite. [g1]: http://github.com [g2]: http://repo.or.cz/w/girocco.git [g3]: http://www.indefero.net/ [g4]: http://gitorious.com/ +[g5]: http://code.google.com/p/gerrit/ + +Uninstalling gitolite is fairly easy, although it is manual. (We'll assume +`$REPO_BASE` in the rc file was left at its default of `~/repositories`; if +not, adjust accordingly): -Uninstalling gitolite is fairly easy. Just log on to the server and do the -following (assuming `$REPO_BASE` in the rc file was left at its default of -`~/repositories`; if not, adjust accordingly): +**server side tasks** * edit `~/.ssh/authorized_keys` and delete the `# gitolite start` and `# gitolite end` markers and all the lines between them. This will prevent @@ -287,18 +291,34 @@ following (assuming `$REPO_BASE` in the rc file was left at its default of ~/.gitolite.rc ~/repositories/gitolite-admin.git - * Then remove all the `update` hooks that git installs on each repository. - The easiest way is: + * You can remove all of `~/repositories` if you have not really started + using gitolite properly yet; that's your choice. + + If you *do* need to preserve the other repos and continue to use them, + remove all the `update` hooks that git installs on each repository. The + easiest way is: find ~/repositories -wholename "*.git/hooks/update" | xargs rm -f but you can do it manually if you want to be careful. - * Finally, any remote users that still have access must update their clone's - remote URLs (edit `.git/config` in the repo) to prefix `repositories/` - before the actual path used, in order for the remote to still work. This - is because you'll now be accessing it through plain ssh, which means you - have to give it the full path. +**client side tasks** + + * Any remote users that still have access must update their clone's remote + URLs (edit `.git/config` in the repo) to prefix `repositories/` before the + actual path used, in order for the remote to still work. This is because + you'll now be accessing it through plain ssh, which means you have to give + it the full path. + + * Finally, you as the gitolite admin will probably have a host stanza for + "gitolite" in your *client*'s `~/.ssh/config`. Find and delete lines that + look like this: + + host gitolite + user git + hostname your.server + port 22 + identityfile ~/.ssh/your-gitolite-admin-username ### appendix C: NOTE TO PACKAGE MAINTAINERS diff --git a/doc/3-faq-tips-etc.mkd b/doc/3-faq-tips-etc.mkd index 5939832..ff8dc09 100644 --- a/doc/3-faq-tips-etc.mkd +++ b/doc/3-faq-tips-etc.mkd @@ -18,7 +18,7 @@ In this document: * two levels of access rights checking * better logging * "exclude" (or "deny") rules - * the "D" permission -- separating delete and rewind rights + * separating delete and rewind rights * file/dir NAME based restrictions * delegating parts of the config file * convenience features @@ -61,32 +61,7 @@ In this document: ## git version dependency -Here's a workaround for a version dependency that the normal flow of gitolite -has. - -When you edit your config file to create a new repo, and push the changes to -the server, gitolite creates an empty, bare repo for you. Normally, you're -expected to clone this on the client side, and start working -- make your -first commit(s), then push, etc. - -However, cloning an empty repo requires a server side git version that is at -least 1.6.2. Gitolite detects this when creating a repo, and warns you. - -The workaround is to use the older (gitosis-style) method on the client: -create an empty repo locally, make a commit or two, set an "origin" remote, -and then push. Something like: - - mkdir my-new-project - cd my-new-project - git init - git commit --allow-empty -m 'Initial repository' - # or, if your client side git is too old for --allow-empty, just make some - # files, "git add" them, then "git commit" - git remote add origin git@gitolite-server:my-new-project.git - git push origin master:master - -Once this is done, the repo is available for cloning by anyone else in the -normal way, since it's not empty anymore. +Gitolite (on the server) now refuses to run if git is not at least 1.6.2. ## other errors, warnings, notes... @@ -367,7 +342,7 @@ And here's how it works: before the third one, and it has a `-` as the permission, so the push fails -#### the "D" permission -- separating delete and rewind rights +#### separating delete and rewind rights Since the beginning, `RW+` meant being able to rewind *or* delete a ref. My stand is that these two are fairly similar, and infact a rewind is almost the @@ -379,13 +354,15 @@ situations where one of them should be restricted more than the other. ([Arguments][sdrr] exist for both sides: restrict delete more than rewind, and vice versa). -So we now allow these two rights to be separated. Just use the new `D` -permission anywhere in the config for the repo, and instantly all `RW+` -permissions (for that repo) cease to permit deletion of the ref matched. +So we now allow these two rights to be separated. Here's how: + + * branch deletion is permitted by using `RWD` or `RW+D` -- essentially the + current branch permissions with a `D` suffixed + * if a repo has a rule containing such a `D`, all `RW+` permissions (for + that repo) cease to permit deletion of the ref matched. -This provides the *greatest* backward compatibility (if you don't specify any -`D` permissions, everything works just as before), while also enabling the new -semantics at the granularity of a repo, instead of the entire config. +This provides the *greatest* backward compatibility, while also enabling the +new semantics at the granularity of a repo, instead of the entire config. Note 1: if you find that `RW+` no longer allows deletion but you can't see a `D` permission in the rules, remember that gitolite allows a repo config to be @@ -395,7 +372,7 @@ files. Be sure to search everywhere :) Note 2: a quick way to make this the default for *all* your repos is: repo @all - D dummy-branch = foo + RWD dummy-branch = foo where foo can be either the administrator, or if you can ignore the warning message when you push, a non-existant user. @@ -428,28 +405,30 @@ Sometimes there are too many repos, maybe even named similarly, or with the potential for typos, confusion about hyphens/underscores or upper/lower case, etc. You'd just like a simple way to know what repos you have access to. -Easy! Just use ssh and try to log in as if you were attempting to get a -shell: - - $ ssh gitolite info - PTY allocation request failed on channel 0 - hello sitaram, the gitolite version here is v0.6-17-g94ed189 - you have the following permissions: - R W Anu-WSD - R ROtest - R W SecureBrowse - R W entrans - R W git-notes - R W gitolite - R W gitolite-admin - R W indic_web_input - R W proxy - @ @ testing - R W vkc - -Note that until this version, we used to put out an ugly `need -SSH_ORIGINAL_COMMAND` error, just like gitosis used to. All we did is put -that code path to better use :-) +Easy! Just use ssh to give the "info" command to the gitolite server: + + $ ssh git@server info + hello sitaram, the gitolite version here is v1.4-9-g34aad34 + the gitolite config gives you the following access: + R W SecureBrowse + R W anu-wsd + R W entrans + @ W git-notes + @ W gitolite + R W gitolite-admin + R W indic_web_input + @ R private/CREATER/[\w.-]+ + R W proxy + @ @ W public/CREATER/[\w.-]+ + @ @ testing + R W vkc + +To understand what these symbols mean, please see doc/report-output.mkd. The +administrator can also say things like: + + ssh gitolite info u1 u2 u3 + +to get this info for other user(s). #### error checking the config file @@ -485,6 +464,17 @@ attempting to run git stuff. Very easy, very simple, and completely transparent to the users :-) +**Note**: sometimes you have a system that already has an older "git" +installed in one of the system PATHs, but you've installed a newer git in some +non-standard location and want that picked up. Because of security reasons, +gitolite will not prepend `GIT_PATH` to the PATH variable, so the older git +comes first and it gets kinda frustrating! + +Here's a simple workaround. Ignore the `GIT_PATH` variable, and directly set +the full PATH in the rc file, like so: + + $ENV{PATH} = "/home/sitaram/bin:$ENV{PATH}"; + #### "personal" branches "personal" branches are great for corporate environments, where diff --git a/doc/4-wildcard-repositories.mkd b/doc/4-wildcard-repositories.mkd index 3717aca..9b01dcb 100644 --- a/doc/4-wildcard-repositories.mkd +++ b/doc/4-wildcard-repositories.mkd @@ -108,11 +108,11 @@ metacharacters. Just for interest, note that this is in contrast to the refexes for the normal "branch" permissions, as described in `conf/example.conf` and elsewhere. -Those "refexes" are *not* anchored; a pattern like `refs/heads/master` -actually matches `foo/refs/heads/master01/bar` as well, even if no one will -actually push such a branch! You can anchor it if you really care, by using -`master$` instead of `master`, but anchoring is *not* the default for -refexes.] +These "refexes" are only anchored at the start; a pattern like +`refs/heads/master` actually can match `refs/heads/master01/bar` as well, even +if no one will actually push such a branch! You can anchor both sides if you +really care, by using `master$` instead of `master`, but that is *not* the +default for refexes. ### Handing out rights to wildcard-matched repos diff --git a/doc/7-install-transcript.mkd b/doc/7-install-transcript.mkd index 026c98e..0127d46 100644 --- a/doc/7-install-transcript.mkd +++ b/doc/7-install-transcript.mkd @@ -17,6 +17,18 @@ transcript is **non**-gitolite stuff :) ---- +### (cleaning out a botched install if needed) + +When people have trouble installing gitolite, they often try to change a bunch +of things manually on the server. This usually makes things worse ;-) so if +you're reading this document as a follow-up to a failed install, please +**first** clean out the botched install (instructions [here][appB]) and +**then** continue with this document. + +[appB]: http://github.com/sitaramc/gitolite/blob/pu/doc/0-INSTALL.mkd#uninstall + +---- + ### create userids on server and client (optional) Client side: add user, give him a password diff --git a/doc/CHANGELOG b/doc/CHANGELOG index d1c1584..32de001 100644 --- a/doc/CHANGELOG +++ b/doc/CHANGELOG @@ -2,6 +2,11 @@ Major changes to gitolite, master branch only, most recent first, no dates but the tags can help you position stuff approximately [NYD = not yet documented due to lack of time...] + - REFUSE TO RUN ON SERVER GIT < 1.6.2 (do NOT upgrade gitolite to or beyond + this point if you are unable to upgrade git itself to at least 1.6.2) + + - "D" must be combined with RW or RW+ (warning: minor backward compat breakage) + - v1.4 - recurse through keydir for pubkeys diff --git a/doc/report-output.mkd b/doc/report-output.mkd new file mode 100644 index 0000000..a0dd87d --- /dev/null +++ b/doc/report-output.mkd @@ -0,0 +1,61 @@ +# output of the "info" and "expand" commands + +Running "ssh git@server info" or "ssh git@server expand" gives you certain +output. This doclet describes the output; you're welcome to help me make it +clearer :) + +There are 3 columns of permissions (create, read, and write) in the output, +although the first column is often blank. + +Here is the output of the 2 commands (info and expand): + +### the "info" command + +Usage: + + ssh git@server info + ssh git@server info [list of users] + +The "info" command shows you all the repos (and repo patterns) in the config +file that you have been given any kind of access to. If you're an admin you +can append a list of users to see their permissions instead of your own. +(Side note: if you installed using easy-install that would probably be `ssh +gitolite info`, by the way). + + * col 1 (exists only if the "repo" name is actually a pattern) + * `@`: `@all` users have permission to create repos matching this + pattern + * `C`: this user has permission to create repos matching this pattern + + * col 2 + * `@`: `@all` users have read access to this repo + * `r`: this user has read access to `@all` repos + * `R`: this user has read access to this repo + + * col 3: same as col 2, but for write access instead of read + +### the "expand" command + +Usage: + + ssh git@server expand [optional pattern] + +The "expand" command trawls through all the repositories on the server, +limiting to repos matching the pattern you provide (default is all repos +found). + +For each repo found, it searches for it in the config -- either the actual +repo entry (when the repo is not a wildcard repo), or an entry for the +wildcard that matches it -- and reports permissions. It also takes into +account extra permissions enabled by the `setperms` command (see +doc/4-wildcard-repositories.mkd). It shows you the "creater" of the repo as +an additional column, defaulting to `<gitolite>` if it was not a wildcard +repo. + + * col 1: not used + + * col 2: same as col 2 for info, except substitute "repo" with "repo or + wildcard matching this repo" + + * col 3: same as col 2, but for write access instead of read + diff --git a/src/gitolite.pm b/src/gitolite.pm index 9850af8..3bc513f 100644 --- a/src/gitolite.pm +++ b/src/gitolite.pm @@ -277,6 +277,12 @@ sub parse_acl # print a report of $user's basic permissions # ---------------------------------------------------------------------------- +sub report_version { + my($GL_ADMINDIR, $user) = @_; + print "hello $user, the gitolite version here is "; + system("cat", ($GL_PACKAGE_CONF || "$GL_ADMINDIR/conf") . "/VERSION"); +} + # basic means wildcards will be shown as wildcards; this is pretty much what # got parsed by the compile script sub report_basic @@ -286,9 +292,8 @@ sub report_basic &parse_acl($GL_CONF_COMPILED, "", "CREATER", "READERS", "WRITERS"); # send back some useful info if no command was given - print "hello $user, the gitolite version here is "; - system("cat", ($GL_PACKAGE_CONF || "$GL_ADMINDIR/conf") . "/VERSION"); - print "\ryou have the following permissions:\r\n"; + &report_version($GL_ADMINDIR, $user); + print "\rthe gitolite config gives you the following access:\r\n"; for my $r (sort keys %repos) { # @all repos; meaning of read/write flags: # @ => @all users are allowed access to this repo @@ -307,8 +312,10 @@ sub report_basic sub expand_wild { - my($GL_CONF_COMPILED, $repo_base_abs, $repo, $user) = @_; + my($GL_ADMINDIR, $GL_CONF_COMPILED, $repo_base_abs, $repo, $user) = @_; + &report_version($GL_ADMINDIR, $user); + print "\ryou have access to the following repos on the server:\r\n"; # this is for convenience; he can copy-paste the output of the basic # access report instead of having to manually change CREATER to his name $repo =~ s/\bCREAT[EO]R\b/$user/g; diff --git a/src/gl-auth-command b/src/gl-auth-command index 583cd4e..24fc5b9 100755 --- a/src/gl-auth-command +++ b/src/gl-auth-command @@ -127,7 +127,7 @@ if ($ENV{SSH_ORIGINAL_COMMAND} =~ $CUSTOM_COMMANDS) { elsif ($verb eq 'expand') { # with a wildcard, you can "expand" it to see what repos actually match die "$repo has invalid characters" unless "x$repo" =~ $REPOPATT_PATT; - expand_wild($GL_CONF_COMPILED, $repo_base_abs, $repo, $user); + expand_wild($GL_ADMINDIR, $GL_CONF_COMPILED, $repo_base_abs, $repo, $user); } else { die "$cmd doesn't make sense to me\n"; } diff --git a/src/gl-compile-conf b/src/gl-compile-conf index 2d9de2f..9411c4d 100755 --- a/src/gl-compile-conf +++ b/src/gl-compile-conf @@ -75,8 +75,7 @@ $ENV{PATH} .= ":$GIT_PATH" if $GIT_PATH; # command and options for authorized_keys $AUTH_COMMAND="$bindir/gl-auth-command"; -$AUTH_OPTIONS="no-port-forwarding,no-X11-forwarding,no-agent-forwarding"; - # note, for most users there's also a "no-pty" added to this, see later +$AUTH_OPTIONS="no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty"; # groups can now represent user groups or repo groups. @@ -191,7 +190,7 @@ sub parse_conf_file s/\bCREAT[EO]R\b/\$creater/g for @repos; } # actual permission line - elsif (/^(-|C|D|R|RW|RW\+) (.* )?= (.+)/) + elsif (/^(-|C|R|RW\+?D?) (.* )?= (.+)/) { my $perms = $1; my @refs; @refs = split(' ', $2) if $2; @@ -262,7 +261,7 @@ sub parse_conf_file # if the user specified even a single 'D' anywhere, make # that fact easy to find; this changes the meaning of RW+ # to no longer permit deletes (see update hook) - $repos{$repo}{DELETE_IS_D} = 1 if $perms eq 'D'; + $repos{$repo}{DELETE_IS_D} = 1 if $perms =~ /D/; # for 2nd level check, store each "ref, perms" pair in order for my $ref (@refs) @@ -409,10 +408,10 @@ for my $repo (sort keys %repos) { } } -warn "\n\t\t***** WARNING *****\n" . +die "\n\t\t***** AAARGH! *****\n" . "\tyour git version is older than 1.6.2\n" . - "\tgitolite will work but you MUST read the section on\n" . - "\t\"git version dependency\" in doc/3-faq-tips-etc.mkd\n" + "\tsince that is now more than one year old, and gitolite needs some of\n" . + "\tthe newer features, please upgrade.\n" if $git_version < 10602; # that's 1.6.2 to you # ---------------------------------------------------------------------------- @@ -544,7 +543,7 @@ for my $pubkey (`find . -type f`) print STDERR "WARNING: a pubkey file can only have one line (key); ignoring $pubkey\n"; next; } - print $newkeys_fh "command=\"$AUTH_COMMAND $user\",$AUTH_OPTIONS,no-pty "; + print $newkeys_fh "command=\"$AUTH_COMMAND $user\",$AUTH_OPTIONS "; print $newkeys_fh $pubkey_content; } # lint check 3; a little more severe than the first two I guess... diff --git a/src/gl-easy-install b/src/gl-easy-install index 7a38f13..c7f522f 100755 --- a/src/gl-easy-install +++ b/src/gl-easy-install @@ -48,7 +48,7 @@ main() { [[ $upgrade == 0 ]] && initial_conf_key # MANUAL: cd to $GL_ADMINDIR and run "src/gl-compile-conf" - ssh -p $port $user@$host "cd $GL_ADMINDIR; \$PWD/src/gl-compile-conf $quiet" + ssh $p_port $user@$host "cd $GL_ADMINDIR; \$PWD/src/gl-compile-conf $quiet" setup_pta @@ -183,7 +183,8 @@ basic_sanity() { # That is, running "ssh git@server" should log in straight away, without # asking for a password - ssh -p $port -o PasswordAuthentication=no $user@$host true || + [[ $port -ne 22 ]] && p_port="-p $port" + ssh $p_port -o PasswordAuthentication=no $user@$host true || die "pubkey access didn't work; please set it up using 'ssh-copy-id' or something" } @@ -200,7 +201,7 @@ version_info() { # what was the old version there? export upgrade_details="you are upgrading \ - $(ssh -p $port $user@$host cat gitolite-install/conf/VERSION 2>/dev/null || echo '(or installing first-time)' ) \ + $(ssh $p_port $user@$host cat gitolite-install/conf/VERSION 2>/dev/null || echo '(or installing first-time)' ) \ to $(cat conf/VERSION)" prompt "$upgrade_details" "$v_upgrade_details" @@ -281,8 +282,8 @@ copy_gl() { # server, to a directory called (for example) "gitolite-install". You may # have to create the directory first. - ssh -p $port $user@$host mkdir -p gitolite-install - scp $quiet -P $port -p -r src conf doc hooks $user@$host:gitolite-install/ + ssh $p_port $user@$host mkdir -p gitolite-install + scp $quiet ${p_port/p/P} -p -r src conf doc hooks $user@$host:gitolite-install/ # MANUAL: now log on to the server (ssh git@server) and get a command # line. This step is for your convenience; the script does it all from @@ -296,7 +297,7 @@ copy_gl() { prompt "finding/creating gitolite rc..." "$v_edit_glrc" # lets try and get the file from there first - if scp -P $port $user@$host:.gitolite.rc $tmpgli &>/dev/null + if scp ${p_port/p/P} $user@$host:.gitolite.rc $tmpgli &>/dev/null then prompt " ...trying to reuse existing rc" \ "Oh hey... you already had a '.gitolite.rc' file on the server. @@ -329,7 +330,7 @@ Let's see if we can use that instead of the default one..." fi # copy the rc across - scp $quiet -P $port $tmpgli/.gitolite.rc $user@$host: + scp $quiet ${p_port/p/P} $tmpgli/.gitolite.rc $user@$host: } run_install() { @@ -337,18 +338,18 @@ run_install() { prompt "installing/upgrading..." "$v_ignore_stuff" # extract the GL_ADMINDIR, REPO_BASE and GIT_PATH locations - GL_ADMINDIR=$(ssh -p $port $user@$host "perl -e 'do \".gitolite.rc\"; print \$GL_ADMINDIR'") - REPO_BASE=$( ssh -p $port $user@$host "perl -e 'do \".gitolite.rc\"; print \$REPO_BASE'") - GIT_PATH=$( ssh -p $port $user@$host "perl -e 'do \".gitolite.rc\"; print \$GIT_PATH'") + GL_ADMINDIR=$(ssh $p_port $user@$host "perl -e 'do \".gitolite.rc\"; print \$GL_ADMINDIR'") + REPO_BASE=$( ssh $p_port $user@$host "perl -e 'do \".gitolite.rc\"; print \$REPO_BASE'") + GIT_PATH=$( ssh $p_port $user@$host "perl -e 'do \".gitolite.rc\"; print \$GIT_PATH'") # determine if this is an upgrade; we decide based on whether a file # called $GL_ADMINDIR/conf/gitolite.conf exists on the remote side. We # can't do this till we know the correct value for GL_ADMINDIR upgrade=0 - if ssh -p $port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf &> /dev/null + if ssh $p_port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf &> /dev/null then upgrade=1 - ssh -p $port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf 2> /dev/null | grep '@SHELL' && + ssh $p_port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf 2> /dev/null | grep '@SHELL' && prompt "" "$v_at_shell_bwi" [[ -n $admin_name ]] && echo -e "\n *** WARNING ***: looks like an upgrade... ignoring argument '$admin_name'" else @@ -358,7 +359,7 @@ run_install() { # MANUAL: still in the "gitolite-install" directory? Good. Run # "src/gl-install" - ssh -p $port $user@$host "cd gitolite-install; src/gl-install $quiet" + ssh $p_port $user@$host "cd gitolite-install; src/gl-install $quiet" # MANUAL: if you're upgrading, run "src/gl-compile-conf" and you're done! # -- ignore the rest of this file for the purposes of an upgrade @@ -388,8 +389,8 @@ repo testing " > $tmpgli/gitolite.conf # send the config and the key to the remote - scp $quiet -P $port $tmpgli/gitolite.conf $user@$host:$GL_ADMINDIR/conf/ - scp $quiet -P $port "$HOME/.ssh/$admin_name.pub" $user@$host:$GL_ADMINDIR/keydir + scp $quiet ${p_port/p/P} $tmpgli/gitolite.conf $user@$host:$GL_ADMINDIR/conf/ + scp $quiet ${p_port/p/P} "$HOME/.ssh/$admin_name.pub" $user@$host:$GL_ADMINDIR/keydir } # ---------------------------------------------------------------------- @@ -413,13 +414,13 @@ setup_pta() { PATH=\$PATH:$GIT_PATH GIT_WORK_TREE=$GL_ADMINDIR git add conf/gitolite.conf keydir GIT_WORK_TREE=$GL_ADMINDIR git diff --cached --quiet 2>/dev/null || GIT_WORK_TREE=$GL_ADMINDIR git commit -am start -" | ssh -p $port $user@$host +" | ssh $p_port $user@$host # MANUAL: now that the admin repo is created, you have to set the hooks # properly. The install program does this. So cd back to the # "gitolite-install" directory and run "src/gl-install" - ssh -p $port $user@$host "cd gitolite-install; src/gl-install $quiet" + ssh $p_port $user@$host "cd gitolite-install; src/gl-install $quiet" # MANUAL: you're done! Log out of the server, come back to your # workstation, and clone the admin repo using "git clone |