Update to 1.6.13 *now* . I assume you're using RHEL 5 or CentOS 5,
which is pinned at version 1.4.2? RPMforge has the updates available.
They're absolutely worth using, there are so many performance
improvements and security updates available that there is just no
point in sticking with the old one.
You'll then want to review each host's individual ~apache/.subversion/
configuration files, and to do "sudo -s -H -u apache" to try and do
things directly as the apache user to examine the errors more
directly, without the 'sudo' interfering. In particular, the 'sudo'
may be inheriting home directory settings from the sudo user, not the
apache user, on each system. "sudo -H" can be very handy to avoid that
sort of issue.
On Wed, Nov 10, 2010 at 3:41 PM, Bob Bonifield <bobbonifield_at_gmail.com> wrote:
> Ok admittedly, this might be a server configuration issue instead of
> specifically SVN, but I can't say for sure.
> I have a two different client machines, both updating from the same source
> repo. Both machines use the same version of SVN (1.4.2), the same kernel,
> and the same sudoers configuration. I try to run "sudo -u apache -H svn
> list https://domain.com/repos/myrepo". One machine will auth just fine,
> while the other gives me the "Error validating server certificate" error.
> The cert is indeed invalid. However, the problem is that I can hit 'p' to
> accept the certificantly permanently, but yet, SVN doesn't remember the
> certificate or my acceptance of it.
> I'm not sure, but it seems that one machine will use the user's home
> directory SVN configuration properly while the other will not. For
> instance, the one that auths properly will grab the password from the
> /auth/svn.simple file and process the auth. The one that does not work
> properly will attempt to use `apache` as the user with no stored password.
> I've looked into the user .subversion directories on both machines, and
> things match up there. I'm stumped.
Received on 2010-11-11 02:10:26 CET