Subversion 1.8.9 repository access issue [Urgent]

[Mohsin Abbas]

Team,

I have installed latest subversion 1.8.9 to Linux machine and imported repositories from old server. Actually I have moved my svn from one machine to another machine on old machine svn 1.4.2 was installed and repositories were created with svn 1.4.2 version . Now when I access repositories from new server URL I am getting permission denied [403] error. I have copied same configurations from old server to new server but on new svn server repositories which were created with svn 1.4.2 are not working . Here I am sharing some logs portion when I hit url .

[Mon May 19 21:52:25 2014] [debug] subversion/mod_authz_svn/mod_authz_svn.c(400): [client  x.x.x.x] Path to authz file is /usr/local/apache/conf/extra/authz_svn_ITOPS.conf
[Mon May 19 21:52:25 2014] [error] [client x.x.x.x] Failed to load the mod_authz_svn config: Section name 'Devices:/Trunk/' contains non-canonical fspath '/Trunk/'
[Mon May 19 21:52:25 2014] [error] [client  x.x.x.x] Access denied: 'mabbas' GET MCP:/Trunk/OLTPJ/Documents/

One more point which I want to ask for subversion 1.8.9 I have to use latest svn client tortoise SVN 1.8 or 1.7 or 1.6 client can be used for repository access?

FYI

I am using SVN DAV module for repository access with Apache 2.2.27 integration. 

Please help me I am stuck here.

Regards

Mohsin Abbas

[Stefan Sperling]

On Tue, May 20, 2014 at 12:02:23AM +0000, Mohsin Abbas wrote:
> Team,
>
> I have installed latest subversion 1.8.9 to Linux machine and imported
> repositories from old server. Actually I have moved my svn from one machine
> to another machine on old machine svn 1.4.2 was installed and repositories
> were created with svn 1.4.2 version . Now when I access repositories from
> new server URL I am getting permission denied [403] error. I have copied
> same configurations from old server to new server but on new svn server
> repositories which were created with svn 1.4.2 are not working . Here I am
> sharing some logs portion when I hit url .
>

> *[Mon May 19 21:52:25 2014] [debug]
> subversion/mod_authz_svn/mod_authz_svn.c(400): [client ** x.x.x.x*
>
> *] Path to authz file is

> /usr/local/apache/conf/extra/authz_svn_ITOPS.conf[Mon May 19 21:52:25 2014]
> [error] [client x.x.x.x] Failed to load the mod_authz_svn config: Section
> name 'Devices:/Trunk/' contains non-canonical fspath '/Trunk/'[Mon May 19
> 21:52:25 2014] [error] [client x.x.x.x] Access denied: 'mabbas' GET

> MCP:/Trunk/OLTPJ/Documents/*

Try removing the trailing slash.
Use 'Devices:/Trunk', not 'Devices:/Trunk/'.

> One more point which I want to ask for subversion 1.8.9 I have to use
> latest svn client tortoise SVN 1.8 or 1.7 or 1.6 client can be used for
> repository access?

Yes, any 1.x client can talk to any 1.y server.
There is more information about this here:
http://subversion.apache.org/docs/release-notes/1.8.html#compatibility

[Mohsin Abbas]

Sir ,

Thanks for your quick response.

Here i want to ask question in my previous server with subversion 1.4.2 this trailing slash works fine as i had already mentioned in my first email i copied same configurations which are working absolutely fine with subversion 1.4.2 why this is not working with subversion 1.8.9 either this is some limitations in new svn version ? or some other issue ?

Regards

[Stefan Sperling]

I don't know exactly why this was changed.
It's possible that this change in behaviour was intentional.

It might have been this change: http://svn.apache.org/r1037662
The tests added there treats the path "/a/" as invalid, so your the path
"Devices:/Trunk/" you use in the authz file is now also invalid.

[Mohsin Abbas]

Sir ,

That's make a sense I'll try this today and get back to you . Thank you for your support.

Regards

Mohsin

[Mohsin Abbas]

Hello Sir,

403 permission denied issue has been resolved after removing trailing slash. Thanks for help.

Now one more issue i am facing when i access repositories URL in Tortoise SVN client it gives unable to parse error [207 response code used with WEBDAV protocol]. But old svn 1.4.2 repositories are accessible with same Tortoise SVN but when I import 1.4.2 repositories in new svn 1.8.9 following error occurred.

FYI

SVN Client :
TortoiseSVN 1.6.7

When I hit the URL in browser all data display correctly but in tortoise svn client 207 displays.

In Apache error log:

x.x.x.x - mabbas [21/May/2014:00:52:02 -0400] "PROPFIND /svn/x/x/!svn/vcc/default HTTP/1.1" 207 467
x.x.x.x - mabbas [21/May/2014:00:52:02 -0400] "PROPFIND /svn/x/Ix/!svn/bc/24446/Trunk/Source/JavaAGI/docs HTTP/1.1" 207 449
x.x.x.x - mabbas [21/May/2014:00:52:02 -0400] "PROPFIND /svn/x/x/!svn/bc/24446/Trunk/Source/JavaAGI/docs HTTP/1.1" 207 3858

[Stefan Sperling]

On Wed, May 21, 2014 at 12:14:25AM +0000, Mohsin Abbas wrote:
> Hello Sir,
>
> 403 permission denied issue has been resolved after removing trailing
> slash. Thanks for help.
>
> Now one more issue i am facing when i access repositories URL in Tortoise
> SVN client it gives unable to parse error [207 response code used with
> WEBDAV protocol]. But old svn 1.4.2 repositories are accessible with same
> Tortoise SVN but when I import 1.4.2 repositories in new svn 1.8.9
> following error occurred.
>
> FYI
> SVN Client :
> TortoiseSVN 1.6.7
>
> When I hit the URL in browser all data display correctly but in tortoise
> svn client 207 displays.
>
> In Apache error log:
>
> x.x.x.x - mabbas [21/May/2014:00:52:02 -0400] "PROPFIND

> /svn/x/x/!svn/vcc/default HTTP/1.1" *207* 467

> x.x.x.x - mabbas [21/May/2014:00:52:02 -0400] "PROPFIND

> /svn/x/Ix/!svn/bc/24446/Trunk/Source/JavaAGI/docs HTTP/1.1" *207 *449

> x.x.x.x - mabbas [21/May/2014:00:52:02 -0400] "PROPFIND

> /svn/x/x/!svn/bc/24446/Trunk/Source/JavaAGI/docs HTTP/1.1" *207 *3858

It sounds like you're running into httpd issue 56480:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56480
Note: This is a bug in Apache HTTPD, not Apache Subversion.

Downgrading to httpd 2.2.24 or 2.4.4 should work around it
until a fix is available. This is a bit tricky because such
a downgrade would also undo some security fixes.

If you compile your own HTTPD then applying the patch which
can be found in issue 56480 would be the best thing to do.

As explained in issue 56480 the problem has some history but
intially started with this change:

*) mod_dav: Ensure URI is correctly uriencoded on return. PR 54611
[Timothy Wood <tjw omnigroup.com>]
See http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/CHANGES
or http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/CHANGES

[Mohsin Abbas]

Hello sir,

I have installed Apache 2.2.27 with subversion 1.8.9  version you are saying this Apache version is venerable for this issue ? right ? Now please tell me what Apache version should I use which is not venerable for this issue ?

Regards
 

[Mohsin Abbas]

I want to add one point all repositories are accessible when I access through browser but encountered above reported issue when access through tortoise SVN client why this happen I mean If this is bug in Apache HTTPD then It should not work in browser too .. What to you say about this ?

Regards

On Wed, May 21, 2014 at 2:21 PM, Stefan Sperling <st...@elego.de> wrote:

[Stefan Sperling]

On Wed, May 21, 2014 at 07:22:48PM +0500, Mohsin Abbas wrote:
> I have installed Apache 2.2.27 with subversion 1.8.9 version you are
> saying this Apache version is venerable for this issue ? right ? Now please
> tell me what Apache version should I use which is not venerable for this
> issue ?

Already mentioned:

[Stefan Sperling]

On Wed, May 21, 2014 at 07:28:34PM +0500, Mohsin Abbas wrote:
> I want to add one point all repositories are accessible when I access
> through browser but encountered above reported issue when access through
> tortoise SVN client why this happen I mean If this is bug in Apache HTTPD
> then It should not work in browser too .. What to you say about this ?

Normal browsers do not interact with the repository in the way SVN
clients do. SVN clients use an expanded set of HTTP requests which
most web browsers don't use (I think browsers only use GET requests in
this context). Because of this the problem only shows with SVN clients.

SVN clients use Webdav/DeltaV: http://en.wikipedia.org/wiki/Webdav

[Mohsin Abbas]

Sir,

Thanks for the help I'll compile SVN 1.8.9 with Apache 2.2.24 and check . I'll contact with you if face any issue . Again thanks for your support : )

[Mohsin Abbas]

Stefan Sperling,

Tortoise SVN client working fine with Apache 2.2.24 now everything seems to be fine. Thanks for your all support without you this was not possible.

Regards

Mohsin Abbas

[Mohsin Abbas]

Hello sir,

Hope you are doing well . I have installed SVN V1.8.9 with Apache 2.2.24 all repositories are working fine except one which gives following error when I access from browser. Can you please help me why this specific repository is giving error while others are working fine .

Note : Previous SVN version was 1.4.2 I have installed latest SVN V1.8.9 and r synced SVN V1.4.2 repositories.

Apache error log portion :

[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] (20014)Internal error: Failed to load module for FS type 'bdb'
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not fetch resource information.  [500, #0]
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not open the requested SVN filesystem  [500, #160033]
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not open the requested SVN filesystem  [500, #160033]

Regards

Mohsin

[Branko Čibej]

On 05.07.2014 01:57, Mohsin Abbas wrote:

Hello sir,

Hope you are doing well . I have installed SVN V1.8.9 with Apache 2.2.24 all repositories are working fine except one which gives following error when I access from browser. Can you please help me why this specific repository is giving error while others are working fine .

Note : Previous SVN version was 1.4.2 I have installed latest SVN V1.8.9 and r synced SVN V1.4.2 repositories.

Apache error log portion :

[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] (20014)Internal error: Failed to load module for FS type 'bdb'
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not fetch resource information.  [500, #0]
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not open the requested SVN filesystem  [500, #160033]
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not open the requested SVN filesystem  [500, #160033]

Your 1.8.9 binaries do not contain the BDB repository back-end; that would be libsvn_fs_base-1.so on your Linux box. If you built the binaries yourself, note that you need the Berkeley DB development package in order to compile this library.

-- Brane

--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

[Jacky wong]

[Mohsin Abbas]

Hello All,

Hope you are doing well . I have recently upgraded my SVN from V1.4.2 to V1.8.9 on Linux environment all repositories which were created in SVN V1.4.2 are working fine with V1.8.9 except one which gives error while accessing via Tortoise SVN client or Browser . I have shared Apache error log. Can you please help me why this specific repository is giving error while others are working fine .

Note : I am using SVN V1.8.9 with Apache 2.2.24.

Apache error log portion :

[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] (20014)Internal error: Failed to load module for FS type 'bdb'
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not fetch resource information.  [500, #0]
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not open the requested SVN filesystem  [500, #160033]
[Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] Could not open the requested SVN filesystem  [500, #160033]

Regards

Mohsin Abbas

[Andreas Stieger]

Hi,

On 06/07/14 12:11, Mohsin Abbas wrote:
> [upgraded server from 1.4.2 to 1.8.9]

> [Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] (20014)Internal
> error: Failed to load module for FS type 'bdb'

Your repository is of type bdb, (berkeley db backend), not fsfs. As such
is it not suitable for a direct upgrade. You must dump the repository
contents using the previous version 1.4.2 using svnadmin dump and then
load it into 1.8.9. This is one of the reasons why the bdb back-end has
been deprecated.

Andreas

[Branko Čibej]

On 06.07.2014 13:35, Andreas Stieger wrote:
> Hi,
>
> On 06/07/14 12:11, Mohsin Abbas wrote:
>> [upgraded server from 1.4.2 to 1.8.9]
>> [Fri Jul 04 15:07:43 2014] [error] [client 192.168.x.x] (20014)Internal
>> error: Failed to load module for FS type 'bdb'

I replied to this same question yesterday. Why didn't you read the reply?

> Your repository is of type bdb, (berkeley db backend), not fsfs. As such
> is it not suitable for a direct upgrade.

That's nonsense.

> You must dump the repository
> contents using the previous version 1.4.2 using svnadmin dump and then
> load it into 1.8.9. This is one of the reasons why the bdb back-end has
> been deprecated.

"Deprecated" does not mean "not supported". You can use a BDB repository
in 1.8.9 just fine, but you do have to build the BDB backend library.
See Message-ID: <53B7A54...@wandisco.com>.

[Andreas Stieger]

On 06/07/14 21:58, Branko Čibej wrote:
> On 06.07.2014 13:35, Andreas Stieger wrote:
>> Your repository is of type bdb, (berkeley db backend), not fsfs. As such
>> is it not suitable for a direct upgrade.
>
> That's nonsense.

See DB_VERSION_MISMATCH and others. Building the bdb backend might just
uncover that.

Andreas

[Branko Čibej]

The error in the httpd log is SVN_ERR_FS_UNKNOWN_FS_TYPE. So the part about the BDB back-end not being built is pretty obvious.

Berkeley DB databases can always be upgraded from older BDB versions with db_upgrade, if the BDB version on the new server is incompatible with the one on the old server. Nothing else should really matter.

We do still support all BDB repositories. We did not deprecate the BDB backend because it would be inherently worse than FSFS, but because we simply do not have the resources to adequately maintain and improve two (and soon, three) repository back-ends. That's all.

[Nico Kadel-Garcia]

On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 06.07.2014 23:54, Andreas Stieger wrote:
>
> On 06/07/14 21:58, Branko Čibej wrote:
>
> On 06.07.2014 13:35, Andreas Stieger wrote:
>
> Your repository is of type bdb, (berkeley db backend), not fsfs. As such
> is it not suitable for a direct upgrade.
>
> That's nonsense.
>
> See DB_VERSION_MISMATCH and others. Building the bdb backend might just
> uncover that.
>
>
> The error in the httpd log is SVN_ERR_FS_UNKNOWN_FS_TYPE. So the part about
> the BDB back-end not being built is pretty obvious.
>
> Berkeley DB databases can always be upgraded from older BDB versions with
> db_upgrade, if the BDB version on the new server is incompatible with the
> one on the old server. Nothing else should really matter.

This is not necessarily reliable. I've encountered at least 4 BDB
environments that worked as they were, but for which 'db_upgrade' was
impossible. It even paid serious consulting rates while I backported a
bunch of CentOS tools to work with an old BDB environment that someone
had hand built and not written a usable 'export' function for.

I have never found BDB to be stable or reliable enough for production use.

> We do still support all BDB repositories. We did not deprecate the BDB
> backend because it would be inherently worse than FSFS, but because we
> simply do not have the resources to adequately maintain and improve two (and
> soon, three) repository back-ends. That's all.

Do you intend to discard it in a foreseeable release? While it's been
useful to take old SVN environments and be able to run 'svnadmin
download' on them with newer Subversion releases, I'm not sure if it's
worth just abandoning at some point. Does anyone use it by choice
anymore?

[Branko Čibej]

On 07.07.2014 12:48, Nico Kadel-Garcia wrote:
> On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej <br...@wandisco.com> wrote:
>> On 06.07.2014 23:54, Andreas Stieger wrote:
>>
>> On 06/07/14 21:58, Branko Čibej wrote:
>>
>> On 06.07.2014 13:35, Andreas Stieger wrote:
>>
>> Your repository is of type bdb, (berkeley db backend), not fsfs. As such
>> is it not suitable for a direct upgrade.
>>
>> That's nonsense.
>>
>> See DB_VERSION_MISMATCH and others. Building the bdb backend might just
>> uncover that.
>>
>>
>> The error in the httpd log is SVN_ERR_FS_UNKNOWN_FS_TYPE. So the part about
>> the BDB back-end not being built is pretty obvious.
>>
>> Berkeley DB databases can always be upgraded from older BDB versions with
>> db_upgrade, if the BDB version on the new server is incompatible with the
>> one on the old server. Nothing else should really matter.
> This is not necessarily reliable. I've encountered at least 4 BDB
> environments that worked as they were, but for which 'db_upgrade' was
> impossible. It even paid serious consulting rates while I backported a
> bunch of CentOS tools to work with an old BDB environment that someone
> had hand built and not written a usable 'export' function for.
>
> I have never found BDB to be stable or reliable enough for production use.

That's an answer to a different question. :)

>> We do still support all BDB repositories. We did not deprecate the BDB
>> backend because it would be inherently worse than FSFS, but because we
>> simply do not have the resources to adequately maintain and improve two (and
>> soon, three) repository back-ends. That's all.
> Do you intend to discard it in a foreseeable release? While it's been
> useful to take old SVN environments and be able to run 'svnadmin
> download' on them with newer Subversion releases, I'm not sure if it's
> worth just abandoning at some point. Does anyone use it by choice
> anymore?

http://subversion.apache.org/docs/release-notes/1.8.html#bdb-deprecated

I can't predict anything more than what we wrote in the release notes.
If we do decide to completely remove BDB support, we will definitely
tell our users a couple releases in advance, to give them enough time to
migrate.

[Nico Kadel-Garcia]

On Mon, Jul 7, 2014 at 7:14 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 07.07.2014 12:48, Nico Kadel-Garcia wrote:
>> On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej <br...@wandisco.com> wrote:
>>> On 06.07.2014 23:54, Andreas Stieger wrote:

>>> Berkeley DB databases can always be upgraded from older BDB versions with
>>> db_upgrade, if the BDB version on the new server is incompatible with the
>>> one on the old server. Nothing else should really matter.
>>>
>> This is not necessarily reliable. I've encountered at least 4 BDB
>> environments that worked as they were, but for which 'db_upgrade' was
>> impossible. It even paid serious consulting rates while I backported a
>> bunch of CentOS tools to work with an old BDB environment that someone
>> had hand built and not written a usable 'export' function for.
>>
>> I have never found BDB to be stable or reliable enough for production use.
>
> That's an answer to a different question. :)

Clipping some material: no, it's not a different question. BDB
databases *cannot* always be upgraded with db_upgrade, I thought I was
clear about that.

[Branko Čibej]

The question that started this thread was why a BDB database could not be opened. The answer is, because the BDB back-end was not built. We don't even know that the old and new BDB versions are different.

[Andreas Stieger]

Hi,

> On 7 Jul 2014, at 13:48, Branko Čibej <br...@wandisco.com> wrote:
>
> The question that started this thread was why a BDB database could not be opened. The answer is, because the BDB back-end was not built. We don't even know that the old and new BDB versions are different.

The user informed me that his resolution was a dump with the previous version followed by an import with the current one.

Andreas