pkg_config and pkg_postinst both create or discuss a subversion repository with chown -Rf apache:apache ${SVN_REPOS_LOC}/repos, and chmod -Rf 755 ${SVN_REPOS_LOC}/repos. This is all very well if you're using apache web_dav or svnserve directly to access your repository, but for svn+ssh or file access, it simply doesn't work. The - svn over ssh: 1. create an svnserve wrapper in /usr/local/bin to set the umask you want, for example: #!/bin/bash umask 002 exec /usr/bin/svnserve \"\$@\" is all very well, but it doesn't work (you can read from, but not write to the repository). To actually get it to work, I chowned the repo apache:users, and then added group +w permissions (having scratched my head for quite a while - *surely* the standard gentoo setup is right - they know far more than me). Is there any chance you could update the the einfo stuff so that it prints out best practice for getting a working (co and ci) repo for use with file:// and svn+ssh:// accessors? Many thanks.
The proper course of action for these access modes is to use wrapper scripts as described in bug #48809
I suspect that script trick will only work if /usr/local/bin is before /usr/bin in the PATH, which afaik is not the case by default. My PATH looks like follows (broken at some places to prevent this from scrolling off the screen): PATH=/home/jkroon/bin:/bin:/usr/bin:/usr/local/bin:/opt/bin:\ /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3:/opt/sun-jdk-1.5.0.01/bin:\ /opt/sun-jdk-1.5.0.01/jre/bin:/usr/qt/3/bin:/usr/games/bin:/var/qmail/bin Oh, just btw, don't forget the g+s on the db directory or when the berkley db logs rotate you're going to end up with the same problem the lack of the above mentioned script causes.
Unless I'm missing something, this still won't work. The point is that the files will be owned by apache:apache using the default setup. Thus unless the umask is set to 000, a normal user won't be able to write to the repository. Or should you add all svn users to the apache group? If so, wouldn't it be better to use a special svn group?
I suspect this has been fixed recently, at least with baselayout-1.11.12-r4 it's /usr/local/bin first, so the help is once again correct. /etc/profile: if [ "$EUID" = "0" ] || [ "$USER" = "root" ] ; then PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:${ROOTPATH}" else PATH="/usr/local/bin:/usr/bin:/bin:${PATH}" fi
As for the default svn setup, despite the default setup you are still free to create a repository elsewhere with: umask 0002 svnadmin create /path/to/somewhere/else chown -R :writers_group /path/to/somewhere/else
I'm sorry - I think you misunderstand my filing of the bug. The problem is not that you can't create a working repository if you know how, but that the help printed out by the ebuild does not give you a repository that works with svn+ssh (i.e, as per summary the problem is with the _help_, not the installation) The help could be changed to something like: If you wish to use your repository over file:// or svn+ssh:// first chown your repository to :svn_writers and then chmod g+w svn_writers then use this wrapper script <insert wrapper script>. Or, if more appropriate (I don't know which is more gentoo-ish), the instructions should say 'Create a new repo elsewhere and then...'
You only need group write on the db directory (and all files in it) as well as lock/*. The rest never gets modified by group people - and in fact, it would be dangerous to allow group write to hooks (unless of course everybody in the group can be trusted to the fullest extent possible).
The default setup is basically tuned towards apache. To use svnserve a different group or user might be used. The ssh+svn setup is more problematic and I've changed the information to suggest changes of permissions for ssh+svn.
