Re: Authentication problem with clients > 1.7.22

[Stefan Sperling]

On Wed, Jul 27, 2016 at 06:56:46PM +0200, Krzysztof Smiechowicz wrote:
> Hi All,
> 
> We are having problems accessing our svn server via https with client newer
> than 1.7.22 - 1.8.16 and 1.9.3 to be specific. The problem is that the newer
> clients come up with authentication request during svn checkout which after
> entering correct password fails. The authentication comes at random moments
> during checkout. The difference we could spot so far was that 1.7.22 was
> using ra_neon and newer clients are using ra_serf for HTTPS.

My guess is that you need to increase the MaxKeepAliveRequests setting
in httpd.conf on the SVN server.

Once the MaxKeepAliveRequests limit is reached the server closes the
connection so the client opens a new one and authenticates again.

Serf-based clients send a lot more requests than Neon-based clients.
It seems the Neon-based clients do not trigger the limit in your
situations, while Serf-based clients do.

> AAROS/AROS/arch/all-pc/boot/grub2-aros/configure
> AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/Makefile.common
> AAROS/AROS/arch/all-pc/boot/grub2-aros/Makefile.in
> AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/Makefile.extra-dist
> AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/i386-cygwin-img-ld.sc
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_nw.png
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_e.png
> A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/terminal_box_sw.png
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/theme.txt
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/slider_n.png
> Authentication realm:  AROS TRAC+SVN
> Password for 'guest':
> 
> AAROS/AROS/arch/all-pc/boot/grub2-aros/Makefile.in
> AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/Makefile.extra-dist
> AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/i386-cygwin-img-ld.sc
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_nw.png
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_e.png
> A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/terminal_box_sw.png
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/theme.txt
> AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/slider_n.png
> Authentication realm:  AROS TRAC+SVN
> Password for 'guest': *
> 
> svn: E120190: Error retrieving REPORT: An error occurred during authentication
> 
> The server is running subversion 1.8.10 on Debian 8.
> 
> Any help is appreciated
> 
> Best regards,
> Krzysztof

Re: svnserve takes too much memory for "svn blame"

[Vincent Lefevre]

On 2016-07-27 11:12:47 +0200, Stefan Hett wrote:
> Hi Vincent,
> On 7/27/2016 2:36 AM, Vincent Lefevre wrote:
> > When I do "svn blame" on some file (36972 lines), svnserve takes
> > more than 800 MB on the server (and is killed due to lack of
> > memory). So, it seems that svnserve is inefficient in terms of
> > memory usage (that's at least 22 KB per line!).
> > 
> > svnserve, version 1.8.8 (r1568071)
> > compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu
> > 
> Can you try to bump your svnserve version to at least 1.8.15?

The machine is an Ubuntu 14.04 LTS, and 1.8.8 is the latest version
in this distribution. But I plan to upgrade it to 16.04 LTS in a few
days.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svnserve takes too much memory for "svn blame"

[Stefan Hett]

On 7/28/2016 2:06 PM, Vincent Lefevre wrote:

On 2016-07-27 11:12:47 +0200, Stefan Hett wrote:

Hi Vincent,
On 7/27/2016 2:36 AM, Vincent Lefevre wrote:

When I do "svn blame" on some file (36972 lines), svnserve takes
more than 800 MB on the server (and is killed due to lack of
memory). So, it seems that svnserve is inefficient in terms of
memory usage (that's at least 22 KB per line!).

svnserve, version 1.8.8 (r1568071)
 compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu


Can you try to bump your svnserve version to at least 1.8.15?

The machine is an Ubuntu 14.04 LTS, and 1.8.8 is the latest version
in this distribution. But I plan to upgrade it to 16.04 LTS in a few
days.
An alternative might be to use the packages provided by Wandisco: 
https://www.wandisco.com/subversion/os/downloads



--
Regards,
Stefan Hett

Re: svnserve takes too much memory for "svn blame"

[Vincent Lefevre]

On 2016-07-27 17:36:14 +0200, Bert Huijben wrote:
> 'svn blame' downloads all versions of the file (via binary diffs between the
> revisions that contain actual changes), so the number of lines in the file
> is not a number that really relates to what the server has to do.
> 
> The number of relevant revisions is far more interesting... as is how much
> really changed in the file.

There are 1831 revisions. But once a diff has been sent, I suppose
that it doesn't need to be in the server's memory any longer.

For each new revision, not much is changed in the file: just some
added lines (20 in average), and 1 or 2 modified lines in general
(always the same ones).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svnserve takes too much memory for "svn blame"

[Vincent Lefevre]

On 2016-07-28 14:06:10 +0200, Vincent Lefevre wrote:
> On 2016-07-27 11:12:47 +0200, Stefan Hett wrote:
> > Hi Vincent,
> > On 7/27/2016 2:36 AM, Vincent Lefevre wrote:
> > > When I do "svn blame" on some file (36972 lines), svnserve takes
> > > more than 800 MB on the server (and is killed due to lack of
> > > memory). So, it seems that svnserve is inefficient in terms of
> > > memory usage (that's at least 22 KB per line!).
> > > 
> > > svnserve, version 1.8.8 (r1568071)
> > > compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu
> > > 
> > Can you try to bump your svnserve version to at least 1.8.15?
> 
> The machine is an Ubuntu 14.04 LTS, and 1.8.8 is the latest version
> in this distribution. But I plan to upgrade it to 16.04 LTS in a few
> days.

I forgot that I had kept a very recent copy of the repository
(obtained with dump + load) on a Debian/unstable machine (the goal
was to do some tests before the server upgrade). So, I could test
with it, still using svn+ssh (but here, localhost). An "svn blame"
on the same file takes a small memory footprint for both the svn
client and svnserve (around 16 - 30 MB for resident memory, around
250 MB for virtual memory).

So, I suppose that the memory problem was a bug in 1.8.8.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Authentication problem with clients > 1.7.22

[Krzysztof Smiechowicz]

W dniu 28.07.2016 o 10:01, Stefan Sperling pisze:

On Wed, Jul 27, 2016 at 06:56:46PM +0200, Krzysztof Smiechowicz wrote:

Hi All,

We are having problems accessing our svn server via https with client newer
than 1.7.22 - 1.8.16 and 1.9.3 to be specific. The problem is that the newer
clients come up with authentication request during svn checkout which after
entering correct password fails. The authentication comes at random moments
during checkout. The difference we could spot so far was that 1.7.22 was
using ra_neon and newer clients are using ra_serf for HTTPS.


My guess is that you need to increase the MaxKeepAliveRequests setting
in httpd.conf on the SVN server.

Once the MaxKeepAliveRequests limit is reached the server closes the
connection so the client opens a new one and authenticates again.

Serf-based clients send a lot more requests than Neon-based clients.
It seems the Neon-based clients do not trigger the limit in your
situations, while Serf-based clients do.



Hello,

Thank you for reply. We set this setting to 0 (unlimited), but the problem persists. Should this be entered into 
Subversion bugtracker?


Best regards,
Krzysztof

Re: Authentication problem with clients > 1.7.22

[Pavel Lyalyakin]

Hello,

On Wed, Jul 27, 2016 at 7:56 PM, Krzysztof Smiechowicz  wrote:
>
> Hi All,
>
> We are having problems accessing our svn server via https with client newer 
> than 1.7.22 - 1.8.16 and 1.9.3 to be specific. The problem is that the newer 
> clients come up with authentication request during svn checkout which after 
> entering correct password fails. The authentication comes at random moments 
> during checkout. The difference we could spot so far was that 1.7.22 was 
> using ra_neon and newer clients are using ra_serf for HTTPS.

Is there any service such as active firewall or proxy between the
clients and the server? Which operating system are these clients on?
Windows? Is there any antivirus on the client side?

I'm asking these questions just because I vaguely recall a similar
problem when an authentication prompt occurs in the middle of `svn
checkout`. The root cause was an antivirus or active firewall / proxy.
I regret that I don't remember all the details, but in your case I'd
advise to check an antivirus, firewall or proxy.

--
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: Authentication problem with clients > 1.7.22

[Krzysztof Smiechowicz]

W dniu 28.07.2016 o 18:24, Pavel Lyalyakin pisze:

Hello,

On Wed, Jul 27, 2016 at 7:56 PM, Krzysztof Smiechowicz  wrote:


Hi All,

We are having problems accessing our svn server via https with client newer 
than 1.7.22 - 1.8.16 and 1.9.3 to be specific. The problem is that the newer 
clients come up with authentication request during svn checkout which after 
entering correct password fails. The authentication comes at random moments 
during checkout. The difference we could spot so far was that 1.7.22 was using 
ra_neon and newer clients are using ra_serf for HTTPS.


Is there any service such as active firewall or proxy between the
clients and the server? Which operating system are these clients on?
Windows? Is there any antivirus on the client side?



This was reproduced on svn client running on Windows, Linux Mint 17 32bit and Linux Mint 18 64bit. No proxies being used 
on client side.



I'm asking these questions just because I vaguely recall a similar
problem when an authentication prompt occurs in the middle of `svn
checkout`. The root cause was an antivirus or active firewall / proxy.
I regret that I don't remember all the details, but in your case I'd
advise to check an antivirus, firewall or proxy.


Do you remember if this was a firewall on client or server side?

Best regards,
Krzysztof

Re: Authentication problem with clients > 1.7.22

[Stefan Sperling]

On Thu, Jul 28, 2016 at 05:34:36PM +0200, Krzysztof Smiechowicz wrote:
> W dniu 28.07.2016 o 10:01, Stefan Sperling pisze:
> > My guess is that you need to increase the MaxKeepAliveRequests setting
> > in httpd.conf on the SVN server.
> > 
> > Once the MaxKeepAliveRequests limit is reached the server closes the
> > connection so the client opens a new one and authenticates again.
> > 
> > Serf-based clients send a lot more requests than Neon-based clients.
> > It seems the Neon-based clients do not trigger the limit in your
> > situations, while Serf-based clients do.
> > 
> 
> Hello,
> 
> Thank you for reply. We set this setting to 0 (unlimited),

That's OK for testing. In production you should set this to 1.
See the yellow box at:
http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted

> but the problem persists. Should this be entered into Subversion bugtracker?

If, eventually, we come to agree that there is a bug, then filing an issue
is a good idea, of course. But I still believe this can be explained by a
server-side configuration problem, so I don't think filing a bug is
necessary at this stage.

Let's work some more on making sure keep-alives are configured correctly:

Please ensure the KeepAlive directive is set to 'On'.
http://httpd.apache.org/docs/2.4/mod/core.html#keepalive
  KeepAlive On

And that the KeepAliveTimeout is set to at least 300 seconds:
http://httpd.apache.org/docs/2.4/mod/core.html#keepalivetimeout
  KeepAliveTimeout 300

Does this help?
If it does not, please share more details about your server-side
authentication configuration in httpd.conf and related files.

Thanks,
Stefan