Merge branch 'master' into wildrepos

This commit is contained in:
Sitaram Chamarty 2009-12-23 20:00:40 +05:30
commit 1a80f0182d
4 changed files with 35 additions and 3 deletions

View file

@ -217,3 +217,19 @@ repo gitolite
# This does either a plain "git config section.key value" (for the first 3 # This does either a plain "git config section.key value" (for the first 3
# examples above) or "git config --unset-all section.key" (for the last # examples above) or "git config --unset-all section.key" (for the last
# example). Other forms (--add, the value_regex, etc) are not supported. # example). Other forms (--add, the value_regex, etc) are not supported.
# SHELL ACCESS
# ------------
# It is possible to give certain users shell access as well as allow them to
# use gitolite features for their git repo access. The idea is to eliminate
# the need for 2 keys when both shell and gitolite access are needed.
# To give a user shell access, add the username to the special @SHELL group:
@SHELL = sitaram
# Do not add people to this group indiscriminately. AUDITABILITY OF ACCESS
# CONTROL CHANGES (AND OF REPO ACCESSES) WILL BE COMPROMISED IF ADMINS CAN
# FIDDLE WITH THE ACTUAL (PLAIN TEXT) LOG FILES THAT GITOLITE KEEPS, WHICH
# THEY CAN EASILY DO IF THEY HAVE A SHELL.

View file

@ -1,5 +1,20 @@
# ssh troubleshooting # ssh troubleshooting
Update 2009-12-23: most of this document is now of historical interest and
will be totally revamped when I have time. For now, just note this amendment.
The document below says "we can't use the same key for both [gitolite access
and shell access]...". We've managed (thanks to an idea from Jesse Keating)
to get around this. Now it *is* possible for a single key to allow both
gitolite access *and* shell access.
This is done by placing such a user in a special `@SHELL` group in the
gitolite config file. As usual, please see `conf/example.conf` for more info
on this, since I'm using that as a central place to document anything
concerned with the conf file.
----
Ssh has always been the biggest troublespot in all this. While gitolite makes Ssh has always been the biggest troublespot in all this. While gitolite makes
it as easy as possible, you might still run into trouble sometimes. it as easy as possible, you might still run into trouble sometimes.

View file

@ -109,8 +109,9 @@ if ($cmd =~ $CUSTOM_COMMANDS) {
} }
# people allowed to get a shell can get basic access info by asking nicely # people allowed to get a shell can get basic access info by asking nicely
if ($shell_allowed and $cmd eq 'info') { if ($cmd eq 'info') {
&report_basic($GL_ADMINDIR, $GL_CONF_COMPILED, $user); &report_basic($GL_ADMINDIR, $GL_CONF_COMPILED, $user);
print "you also have shell access\n\r" if $shell_allowed;
exit 1; exit 1;
} }

View file

@ -199,8 +199,8 @@ version_info() {
git describe --tags --long HEAD 2>/dev/null > src/VERSION || echo '(unknown)' > src/VERSION git describe --tags --long HEAD 2>/dev/null > src/VERSION || echo '(unknown)' > src/VERSION
# what was the old version there? # what was the old version there?
export upgrade_details="you are upgrading from \ export upgrade_details="you are upgrading \
$(ssh -p $port $user@$host cat gitolite-install/src/VERSION 2>/dev/null || echo '(unknown)' ) \ $(ssh -p $port $user@$host cat gitolite-install/src/VERSION 2>/dev/null || echo '(or installing first-time)' ) \
to $(cat src/VERSION)" to $(cat src/VERSION)"
prompt "$upgrade_details" "$v_upgrade_details" prompt "$upgrade_details" "$v_upgrade_details"