You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Cathy Mullican <cm...@gmail.com> on 2016/03/22 23:25:13 UTC

VisualSVN server / Linux client

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?

Re: VisualSVN server / Linux client

Posted by Cathy Mullican <cm...@gmail.com>.
On Mar 23, 2016 1:04 AM, "Andreas Stieger" <An...@gmx.de> 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

Posted by Cathy Mullican <cm...@gmail.com>.
On Wed, Mar 23, 2016 at 2:07 PM, Pavel Lyalyakin
<pa...@visualsvn.com> wrote:
> Cathy,
>
> On Wed, Mar 23, 2016 at 9:53 PM, Cathy Mullican <cm...@gmail.com> 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.

Re: VisualSVN server / Linux client

Posted by Pavel Lyalyakin <pa...@visualsvn.com>.
Cathy,

On Wed, Mar 23, 2016 at 9:53 PM, Cathy Mullican <cm...@gmail.com> 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

Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Cathy Mullican <cm...@gmail.com> 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

Posted by Cathy Mullican <cm...@gmail.com>.
On Wed, Mar 23, 2016 at 11:39 AM, Stefan Sperling <st...@elego.de> 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

Posted by Stefan Sperling <st...@elego.de>.
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

Posted by Cathy Mullican <cm...@gmail.com>.
On Wed, Mar 23, 2016 at 11:08 AM, Andreas Mohr <an...@lisas.de> 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
>> <pa...@visualsvn.com> 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

Posted by Andreas Mohr <an...@lisas.de>.
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
> <pa...@visualsvn.com> 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

Posted by Cathy Mullican <cm...@gmail.com>.
On Wed, Mar 23, 2016 at 3:35 AM, Pavel Lyalyakin
<pa...@visualsvn.com> wrote:
>
>
> You can also try the following command-line:
> [[[
> svn info <URL-TO-REPOSITORY>
> --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.mullican@REVSHARE.INT

Valid starting       Expires              Service principal
03/22/2016 17:00:50  03/23/2016 03:00:50  krbtgt/REVSHARE.INT@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.int@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.int@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
> <An...@gmx.de> 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

Posted by Cathy Mullican <cm...@gmail.com>.
On Mar 23, 2016 3:36 AM, "Pavel Lyalyakin" <pa...@visualsvn.com>
wrote:
>
> Hello,
>
> On Wed, Mar 23, 2016 at 1:25 AM, Cathy Mullican <cm...@gmail.com>
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 <URL-TO-REPOSITORY>
> --config-option=servers:global:http-auth-types=Negotiate
> ]]]
>
> On Wed, Mar 23, 2016 at 11:04 AM, Andreas Stieger
> <An...@gmx.de> 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

Posted by Pavel Lyalyakin <pa...@visualsvn.com>.
Hello,

On Wed, Mar 23, 2016 at 1:25 AM, Cathy Mullican <cm...@gmail.com> 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 <URL-TO-REPOSITORY>
--config-option=servers:global:http-auth-types=Negotiate
]]]

On Wed, Mar 23, 2016 at 11:04 AM, Andreas Stieger
<An...@gmx.de> 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

Posted by Andreas Stieger <An...@gmx.de>.
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