We have recently installed SVN 1.6.11 and are attempting to run it using the Apache server (2.2.15) after finding svnserve to come up short of our needs. Our system is RHEL 6, and we would like to use the ADS user accounts since creating a new batch of accounts separately for SVN usage seems like overkill. We are attempting to use pwauth for external authorization using the system accounts.
Thus far, despite following several online tutorials on this, we have had no success getting pwauth to work after setting up Apache, PAM and an authz file for using mod_dav as part of the authentication. To give an idea of what we have used, we have followed the general outline of a few sites on this but have not yet had success.
Here is more information on the Apache server we are running:
[svn]# httpd -V Server version: Apache/2.2.15 (Unix) Server built: Apr 29 2013 04:13:12 Server's Module Magic Number: 20051115:25 Server loaded: APR 1.3.9, APR-Util 1.3.9 Compiled using: APR 1.3.9, APR-Util 1.3.9 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/etc/httpd" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="run/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf"
In httpd.conf, we have set up port 80 to listen, a NameVirtualHost at *:80, and we have this VirtualHost setup:
<VirtualHost *:80> DocumentRoot "/" ServerName usfrk-sw-p1.thermo.com AddExternalAuth pwauth /usr/local/bin/pwauth SetExternalAuthMethod pwauth pipe <Location /repos > DAV svn SVNParentPath /home/svnroot AuthType Basic AuthName "Thermo EPM SVN repository" AuthzSVNAccessFile /home/svnroot/conf/authzapache AuthBasicProvider external AuthExternal pwauth Satisfy Any <limitexcept GET PROPFIND OPTIONS REPORT> Require valid-user </limitexcept> </Location> </VirtualHost>
Earlier, we loaded the DAV modules in this order:
LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so LoadModule authnz_external_module /usr/lib64/httpd/modules/mod_authnz_external.so
The book "Version Control with Subversion" notes that mod_dav.so should be loaded before any other SVN modules. As far as we can tell, these are the only modules we need for this.
For the authzapache file, we have set up two distinct groups of users. The only thing that would seem to be a stalling point is that the names include backslashes, and we haven't fully picked up on whether one or two backslashes are needed since some things strip one (names are of the form DOMAIN\firstname.lastname).
With pwauth, one possible trouble point is the SERVER_UIDS define in the config.h file. Currently, we have it set to the group ID of our local users. However, some documentation seems to suggest it should be the user id of the apache user. We're not sure what we should do here, and for all we know this may be what's stopping us.
Ultimately, we run the command 'net ads info' and get what looks like good feedback. We then set a group of users (AllowUsers) in /etc/ssh/sshd_config.h. The next test is to test out pwauth as an external authenticator, and here's what that looks like:
[svn]$ pwauth && echo 'yay' || echo 'nay' nay
In attempting to get more info on this, we then run and get the following:
[svn]$ pwauth; echo $? 50
According to the site that had this info, a return of 50 suggests that pwauth is being run as an invalid user. We have not figured out how to rectify this as of yet, or if this is even the root of the problem using pwauth.
Somewhere in here is a missing link. SVN is set up and functions fine on the server, but we need to allow access to remote users and also limit some of that access. Any insights would be greatly appreciated.