Hi!
Firstly, thanks for your quick answer!
On 8 July 2014 21:24, Lieven Govaerts <lgo_at_mobsol.be> wrote:
> Hi Nico,
>
[...]
>>
>> Everything ran fine so far. I then upgraded to TSVN 1.8.7 which ships
>> with svn 1.8.9 binaries.
>> Now, on every repository involving action I get kerberos errors in my
>> apache log:
>>
>> [Tue Jul 08 15:08:10 2014] [error] [client 192.168.1.152]
>> gss_accept_sec_context() failed: No credentials were supplied, or the
>> credentials were unavailable or inaccessible (, Unknown error)
>>
>> Strange thing is, TSVN works fine from a user perspective (no error
>> displayed whatsoever...). I then tried to use the svn command line
>> binaries, same result, evrythings works, but apache error log is DOSed
>> with these error entries.
>
> That's because you have this directive in your apache config:
> KrbMethodK5Passwd on
>
> With this configuration, mod_auth_kerb will offer both Negotiate and
> Basic authentication. Your logs show that Negotiate authentication
> fails, but in this case svn will automatically fall back to Basic
> authentication, which succeeds.
>
>> I tried to either "prefer" or deny BulkUpdates on the server, nothing changes.
>
> This option has nothing to do with authentication, it specifies how -
> after authentication succeeded - svn+serf will communicate with
> mod_dav_svn.
Apparently, yes :)
I tried this option, because to me it seemed as if the svn client
reauthenticates all the time during a svn operation (e.g. update).
So I thought this might help - i.e. many requests vs. one big. I
excpected to happen the error only once when using BulkUpdates,
because it should only authenticate once. Unfortunately it seems I'm
wrong :|
>> From the linux cmd (on the svn server itself), I can use kerberos
>> (kinit + svn command afterwards) just fine, without any errors popping
>> up in the apache log.
>>
>
> Which GSSAPI implementation are you using on the server? MIT? Heimdal?
> Which versions?
[root_at_svn log]# rpm -qa | grep krb
krb5-libs-1.10.3-15.el6_5.1.x86_64
python-krbV-1.0.90-3.el6.x86_64
krb5-devel-1.10.3-15.el6_5.1.x86_64
krb5-workstation-1.10.3-15.el6_5.1.x86_64
pam_krb5-2.3.11-9.el6.x86_64
Info about krb5-workstation:
Installed Packages
Name : krb5-workstation
Arch : x86_64
Version : 1.10.3
Release : 15.el6_5.1
Size : 1.0 M
Repo : installed
From repo : updates
Summary : Kerberos 5 programs for use on workstations
URL : http://web.mit.edu/kerberos/www/
License : MIT
Description : Kerberos is a network authentication system. The krb5-workstation
: package contains the basic Kerberos programs (kinit,
klist, kdestroy,
: kpasswd). If your network uses Kerberos, this package should be
: installed on every workstation.
> Debugging this stuff will not be easy. Most likely you'll find some
> more information in the Kerberos implementation logging, which is
> configured in your krb5.conf file. On my system the log file is
> /var/log/krb5.log. Try to increase the log level to get more detailed
> error information.
>
> The best alternative is to find out what's going over the wire.
> Disable your SSL configuration and set KrbMethodK5Passwd to off (on a
> test server) and use Wireshark to trace all traffic between your
> Windows client and svn server. Wireshark on Windows can decode the
> SPNego tokens in the Authorization headers (at least for NTLM but I
> suppose for Kerberos also). This allows you to see if all info is
> correct (domain, username etc). If you want you can send me the
> wireshark trace privately and I'll have a look.
I tried to do some testing, and got weird results.
First of all, I don't get the kerberos error mentioned above anymore.
Instead TSVN and the command line client just hang on every operation.
Well, it seems they hang, but they finish eventually 30 minutes later,
even on the simplest actions. This was on a server that is not part of
our domain.
(maybe the server not being part of our domain was the problem
yesterday, because it would try negotiate without success then)
Next, I switched to a Windows 2008 sevrer which is part of our domain.
I cleaned any user properties (e.g. subversion folder and saved auth
stuff) before every run.
I tested with svn command line clients version 1.7.10 and 1.8.9
(shipped with the corresponding TSVN version)
Test command:
Simple checkout of a project
svn client version 1.7.10
1. KrbMethodNegotiate on: asks for password, works
2. KrbMethodNegotiate off: asks for password, works
svn client version 1.8.9
3. KrbMethodNegotiate on: does not ask for password, does not always work
4. KrbMethodNegotiate off: asks for password, works
Test case 1 and 2 seem reasonable, IIRC neon just can't do negotiate
but the password fallback works.
Test case 4 seems to work well, i.e. the password fallback is enforced
and everything works, even with serf in place.
Test case 3 produces very strange results.
First I get random svn: E200014: Checksum mismatch errors and the
checkout just stops. Sometimes I get an segmentation fault and
checkout stops as well.
Sometimes checkout runs fine.
And I found a path, that when checked out, makes the svn client hang
indefinitely...
At the same time I get the following error in my apache error log:
[Wed Jul 09 14:18:28 2014] [error] [client 172.16.37.37] Provider
encountered an error while streaming a REPORT response. [500, #0]
[Wed Jul 09 14:18:28 2014] [error] [client 172.16.37.37] A failure
occurred while driving the update report editor [500, #103]
This happens on the file 'ext-all-debug-w-comments.js' (from the ExtJS
framework, > 2 MB).
This hang situation can be reproduced with the linux client as well.
This hang only occurs with negotiate on + ssl... If I switch either
of, it works...
I never encountered the kerberos error from yesterday during my tests again...
Checksum mismatches and segmentation faults are too hard to chew for
our develpoment machine. Unfortunately I don't have enough time to dig
into these issues very deeply and I wouldn't know where to start
either. Since our current version of TSVN does not support kerberos
negotiate, I think I'll switch it off.
We're using trac for ticket managment as well, and as said before,
negotiation works fine there (i.e. webbrowser as clients).
I'll happily provide any additional information, since the errors
mentioned above seem quite serious. If the kerberos implementation on
the server is flawed, that's one thing. But the svn client should not
produce segfaults and checksum mismatches in such a condition.
Well, maybe it's not the client itself, but the serf library...
Greetings
Nico
Received on 2014-07-09 15:37:56 CEST