Nico Kadel-Garcia wrote on Fri, Apr 01, 2011 at 23:46:16 -0400: > On Fri, Apr 1, 2011 at 10:09 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > Doesn't 'svnserve --log-file' handle this? > > > > Clients run 'ssh $host svnserve -t' by default, so you'd have to make > > that invocation spawn an svnserve that has --log-file passed to it. You > > could alter the svnserve in $PATH or use sshd configuration > > (ForceCommand and command="" directives) to achieve that. > > Great. The "--log-file" option is not in the manual page. Time for a > bug report. >
Or a patch. (Good catch, though.) > Modern versions of OpenSSH (such as the version 5 in RHEL 6 and > contemporary Debian releases) does not read your .bashrc for non-login > sessions. (This is actually standards compliant behavior, which > OpenSSH version 4 did not follow.) Are you describing a change in sshd or in bash? zsh does read .zshenv under current Debian's sshd. > This makes stashing an svnserve > alias or $PATH setting unavailable going forward, and dependent on the > typically shared 'svn' user to have this set in their path for > svn+ssh. > > ForceCommand looks like it will *break* ordinary svn+ssh, without True. You could allow shell access if you took other steps to prevent users from running 'cat' or (--log-file)-less 'svnserve' on the repository. > using the SSH_ORIGINAL_COMMAND environment variable. Interesting. It > would take fascinating parsing, and awkward configuration with managed > SSH keys, but it's vaguely feasible. > > That looks...... really awkward to manage, and without any graceful > SSH key management tools for Subversion access, it becomes a alocal > and manually managed setup, and requires the manipulation of the SSH > daemon's sshd_config. That's not very modular. Replacing /usr/bin/svnserve by a 2-line wrapper script works too.
