Re: VisualSVN server / Linux client
Hi, > [...] VisualSVN server that has Basic authentication disabled. > [...] Kerberos on the Linux box; > "Error running context: The requested authentication type(s) are not > supported" when I try anything. This binary server distribution does not support Kerberos in this configuration. You will need to use Integrated Windows Authentication feature available in the paid version. Andreas
Re: VisualSVN server / Linux client
Hello, On Wed, Mar 23, 2016 at 1:25 AM, Cathy Mullican wrote: > I'm trying to get a Linux svn client to work with a VisualSVN server that > has Basic authentication disabled. I've set up Kerberos on the Linux box; I > can get a ticket via kinit, join the domain, and I see service tickets for > cifs and ldap in klist after joining, so I _think_ that part is OK, although > it's definitely not my area of expertise. > > But I'm missing something, because svn gives "Error running context: The > requested authentication type(s) are not supported" when I try anything. > > Ubuntu 14.04, rebuilt serf with the patch from this ticket: > https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1303167 and > rebuilt svn, but no change. > > Any ideas? First of all, use the latest Subversion 1.9.x client. If the server has Integrated Windows Authentication enabled and the Linux machine is joined the AD domain, then the authentication over NTLM\Negotiate should work out of the box without applying any patches to the client. Make sure that this Subversion client has Negotiate auth enabled. Check "servers" file in ".subversion" directory in the user's home directory on the Linux machine. It should not have "http-auth-types" parameter modified. In your case there is a chance that that the parameter was modified. If it was modified, just comment the line with dash sign "#" to return it to defaults and save the file. You can also try the following command-line: [[[ svn info --config-option=servers:global:http-auth-types=Negotiate ]]] On Wed, Mar 23, 2016 at 11:04 AM, Andreas Stieger wrote: > >> "Error running context: The requested authentication type(s) are not >> supported" when I try anything. > > This binary server distribution does not support Kerberos in this > configuration. You will need to use Integrated Windows Authentication feature > available in the paid version. As far as I can guess, the server has Integrated Windows Authentication enabled and Basic disabled. In such case, it's the client that does not support NTLM/Negotaite (NTLM or Kerberos), not the server. It seems that the client supports or is configured to use Basic authentication only. -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: VisualSVN server / Linux client
On Mar 23, 2016 1:04 AM, "Andreas Stieger" wrote: > > Hi, > > > [...] VisualSVN server that has Basic authentication disabled. > > [...] Kerberos on the Linux box; > > > "Error running context: The requested authentication type(s) are not supported" when I try anything. > > This binary server distribution does not support Kerberos in this configuration. You will need to use Integrated Windows Authentication feature available in the paid version. > We are using the paid version and Integrated Windows Authentication; I apologize for not being specific initially.
Re: VisualSVN server / Linux client
On Mar 23, 2016 3:36 AM, "Pavel Lyalyakin" wrote: > > Hello, > > On Wed, Mar 23, 2016 at 1:25 AM, Cathy Mullican wrote: > > I'm trying to get a Linux svn client to work with a VisualSVN server that > > has Basic authentication disabled. I've set up Kerberos on the Linux box; I > > can get a ticket via kinit, join the domain, and I see service tickets for > > cifs and ldap in klist after joining, so I _think_ that part is OK, although > > it's definitely not my area of expertise. > > > > But I'm missing something, because svn gives "Error running context: The > > requested authentication type(s) are not supported" when I try anything. > > > > Any ideas? > > First of all, use the latest Subversion 1.9.x client. If the server > has Integrated Windows Authentication enabled and the Linux machine is > joined the AD domain, then the authentication over NTLM\Negotiate > should work out of the box without applying any patches to the client. > Currently using 1.8.8, which is what apt-get downloaded, but I can try a newer one today. > Make sure that this Subversion client has Negotiate auth enabled. > Check "servers" file in ".subversion" directory in the user's home > directory on the Linux machine. It should not have "http-auth-types" > parameter modified. In your case there is a chance that that the > parameter was modified. If it was modified, just comment the line with > dash sign "#" to return it to defaults and save the file. > I explicitly set http-auth-types to Negotiate, as online research and suggested it had not been enabled by default in some versions, and anything seemed worth a try at that point. > You can also try the following command-line: > [[[ > svn info > --config-option=servers:global:http-auth-types=Negotiate > ]]] > > On Wed, Mar 23, 2016 at 11:04 AM, Andreas Stieger > wrote: > > > >> "Error running context: The requested authentication type(s) are not supported" when I try anything. > > > > This binary server distribution does not support Kerberos in this configuration. You will need to use Integrated Windows Authentication feature available in the paid version. > > As far as I can guess, the server has Integrated Windows > Authentication enabled and Basic disabled. In such case, it's the > client that does not support NTLM/Negotaite (NTLM or Kerberos), not > the server. It seems that the client supports or is configured to use > Basic authentication only. > > -- > With best regards, > Pavel Lyalyakin > VisualSVN Team
Re: VisualSVN server / Linux client
On Wed, Mar 23, 2016 at 3:35 AM, Pavel Lyalyakin wrote: > > > You can also try the following command-line: > [[[ > svn info > --config-option=servers:global:http-auth-types=Negotiate > ]]] > klist to show my kerberos config is active, followed by the command and result: root@revdb1:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: cathy.mulli...@revshare.int Valid starting Expires Service principal 03/22/2016 17:00:50 03/23/2016 03:00:50 krbtgt/revshare@revshare.int renew until 03/23/2016 17:00:43 03/22/2016 17:00:58 03/23/2016 03:00:50 cifs/az-dc3.revshare@revshare.int renew until 03/23/2016 17:00:43 03/22/2016 17:00:58 03/23/2016 03:00:50 ldap/az-dc3.revshare@revshare.int renew until 03/23/2016 17:00:43 root@revdb1:~# svn info https://az-fs1.revshare.int/svn/rad/trunk/db --config-option=servers:global:http-auth-types=Negotiate svn: E120191: Unable to connect to a repository at URL 'https://az-fs1.revshare.int/svn/rad/trunk/db' svn: E120191: Error running context: The requested authentication type(s) are not supported root@revdb1:~# > > On Wed, Mar 23, 2016 at 11:04 AM, Andreas Stieger > wrote: > > > >> "Error running context: The requested authentication type(s) are not > >> supported" when I try anything. > > > > This binary server distribution does not support Kerberos in this > > configuration. You will need to use Integrated Windows Authentication > > feature available in the paid version. > > As far as I can guess, the server has Integrated Windows > Authentication enabled and Basic disabled. In such case, it's the > client that does not support NTLM/Negotaite (NTLM or Kerberos), not > the server. It seems that the client supports or is configured to use > Basic authentication only. This is what I think as well, because connecting with TortoiseSVN from Windows systems works fine. I'm just hoping to figure out how to get the Linux systems to connect without having to re-enable Basic auth.
Re: VisualSVN server / Linux client
Hello, On Wed, Mar 23, 2016 at 09:42:10AM -0700, Cathy Mullican wrote: > On Wed, Mar 23, 2016 at 3:35 AM, Pavel Lyalyakin > wrote: > > As far as I can guess, the server has Integrated Windows > > Authentication enabled and Basic disabled. In such case, it's the > > client that does not support NTLM/Negotaite (NTLM or Kerberos), not > > the server. It seems that the client supports or is configured to use > > Basic authentication only. > > This is what I think as well, because connecting with TortoiseSVN from > Windows systems works fine. I'm just hoping to figure out how to get > the Linux systems to connect without having to re-enable Basic auth. Rimshot idea: on Linux, Konqueror (as opposed to e.g., rather very infamously, Firefox) seems to be more reliably fully properly providing NTLM auth support (AFAIK v2 in addition to v1), thus if http-based URIs are involved (right?), using Konqueror on these (and perhaps enabling additional tracing?) might be able to provide some investigation opportunities. HTH, Andreas Mohr
Re: VisualSVN server / Linux client
On Wed, Mar 23, 2016 at 11:08 AM, Andreas Mohr wrote: > Hello, > > On Wed, Mar 23, 2016 at 09:42:10AM -0700, Cathy Mullican wrote: >> On Wed, Mar 23, 2016 at 3:35 AM, Pavel Lyalyakin >> wrote: >> > As far as I can guess, the server has Integrated Windows >> > Authentication enabled and Basic disabled. In such case, it's the >> > client that does not support NTLM/Negotaite (NTLM or Kerberos), not >> > the server. It seems that the client supports or is configured to use >> > Basic authentication only. >> >> This is what I think as well, because connecting with TortoiseSVN from >> Windows systems works fine. I'm just hoping to figure out how to get >> the Linux systems to connect without having to re-enable Basic auth. > > Rimshot idea: > on Linux, Konqueror (as opposed to e.g., rather very infamously, Firefox) > seems to be more reliably fully properly providing NTLM auth support > (AFAIK v2 in addition to v1), > thus if http-based URIs are involved (right?), > using Konqueror on these (and perhaps enabling additional tracing?) > might be able to provide some investigation opportunities. It's a database server; I'm not sure X is even set up. I normally just ssh in and work on the command line. I just need to be able to pull the svn repo to deploy stored procedures. ldd suggests that svn is not built with GSSAPI support -- neither the 1.8.8 I started with nor the 1.9.3 I installed this morning -- but I"m not sure how to fix that, or even that I'm not missing something, like it being built in to something else.
Re: VisualSVN server / Linux client
On Wed, Mar 23, 2016 at 11:30:47AM -0700, Cathy Mullican wrote: > ldd suggests that svn is not built with GSSAPI support -- neither the > 1.8.8 I started with nor the 1.9.3 I installed this morning -- but I"m > not sure how to fix that, or even that I'm not missing something, like > it being built in to something else. The component to look at would be the serf library (http://serf.apache.org). This is the "HTTP client" used by svn and needs to be built with GSSAPI.
Re: VisualSVN server / Linux client
On Wed, Mar 23, 2016 at 11:39 AM, Stefan Sperling wrote:
> On Wed, Mar 23, 2016 at 11:30:47AM -0700, Cathy Mullican wrote:
>> ldd suggests that svn is not built with GSSAPI support -- neither the
>> 1.8.8 I started with nor the 1.9.3 I installed this morning -- but I"m
>> not sure how to fix that, or even that I'm not missing something, like
>> it being built in to something else.
>
> The component to look at would be the serf library (http://serf.apache.org).
> This is the "HTTP client" used by svn and needs to be built with GSSAPI.
ldd also shows no GSSAPI support for libserf. I've tried building it
a couple of ways, but can't get output that appears to have the
support -- 1.3.3 with the patch from this ticket (
https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1303167 )
builds, but ldd doesn't show anything with 'gss' in the name; trying
1.3.8 with these directions:
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/serf.html gives
permission errors if I use the GSSAPI=/usr option mentioned, as though
it expects the argument to be an executable:
root@revdb1:/tmp/serf-1.3.8# scons GSSAPI=/usr
scons: Reading SConscript files ...
/bin/sh: 1: /usr: Permission denied
OSError: '/usr --cflags gssapi' exited 126:
File "/tmp/serf-1.3.8/SConstruct", line 360:
env.ParseConfig('$GSSAPI --cflags gssapi')
File "/usr/lib/scons/SCons/Environment.py", line 1554:
return function(self, self.backtick(command))
File "/usr/lib/scons/SCons/Environment.py", line 596:
raise OSError("'%s' exited %d" % (command, status))
Re: VisualSVN server / Linux client
Cathy, On Wed, Mar 23, 2016 at 9:53 PM, Cathy Mullican wrote: > > ldd also shows no GSSAPI support for libserf. I've tried building it > a couple of ways, but can't get output that appears to have the > support -- 1.3.3 with the patch from this ticket ( Indeed, libserf-1-1 from 14.04LTS (trusty) doesn't support GSSAPI, whereas the package from 15.04 (vivid) supports it [1,2]. It seems that installing libserf-1-1 1.3.8 with GSSAPI support will solve the problem. [1]: http://packages.ubuntu.com/trusty/libserf-1-1 [2]: http://packages.ubuntu.com/vivid/libserf-1-1 -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: VisualSVN server / Linux client
Cathy Mullican writes: > http://www.linuxfromscratch.org/blfs/view/svn/basicnet/serf.html gives > permission errors if I use the GSSAPI=/usr option mentioned, as though > it expects the argument to be an executable: > root@revdb1:/tmp/serf-1.3.8# scons GSSAPI=/usr > scons: Reading SConscript files ... > /bin/sh: 1: /usr: Permission denied This error indicates that libkrb5-dev is not installed. (It's a bit convoluted, but the script looks for /usr/bin/krb5-config, which is not there, unless you have libkrb5-dev.) Regards, Evgeny Kotkov
Re: VisualSVN server / Linux client
On Wed, Mar 23, 2016 at 2:07 PM, Pavel Lyalyakin wrote: > Cathy, > > On Wed, Mar 23, 2016 at 9:53 PM, Cathy Mullican wrote: >> >> ldd also shows no GSSAPI support for libserf. I've tried building it >> a couple of ways, but can't get output that appears to have the >> support -- 1.3.3 with the patch from this ticket ( > > Indeed, libserf-1-1 from 14.04LTS (trusty) doesn't support GSSAPI, > whereas the package from 15.04 (vivid) supports it [1,2]. It seems > that installing libserf-1-1 1.3.8 with GSSAPI support will solve the > problem. > > [1]: http://packages.ubuntu.com/trusty/libserf-1-1 > [2]: http://packages.ubuntu.com/vivid/libserf-1-1 > Well, that got me a libserf with gssapi, and I managed to get a svn client working properly..,.and somehow broke ssh in the process. But that's off topic for this list.
