Merge branch 'master' into wildrepos
This commit is contained in:
commit
1a80f0182d
|
@ -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.
|
||||||
|
|
|
@ -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.
|
||||||
|
|
||||||
|
|
|
@ -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;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
@ -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"
|
||||||
|
|
Loading…
Reference in a new issue