Re: [Patch] Expression support for SVNPath and SVNParentPath

[Graham Leggett <mi...@sharp.fm>]

On 27 Feb 2015, at 2:14 AM, Graham Leggett <mi...@sharp.fm> wrote:

> By way of background, I added the regex named grouping support to httpd that allowed you to do stuff like <LocationMatch ^/svn/(?<CUSTOMERNAME>[^/]+)/>, and I’ve been adding expression support to a growing list of httpd directives, starting with all the require directives, and then following up with Alias and Redirect.
> 
> What I’m trying to achieve is to lower the cost of httpd directives, both in terms of the amount of config required to achieve a certain aim, as well as making it possible to administer an httpd server (and svn repository) using changes to an LDAP directory only.
> 
> I chose the two argument layout for SVNPath and SVNParentPath as it was both backwards compatible with existing configs and had the side effect that the expression could be rooted below a specific root directory for safety, given that the directory pointed at by SVNPath isn’t protected (to my knowledge) by <Directory> blocks. It also had the side effect that SVNParentPath could give us a list of repositories rather nicely.

Here is an updated patch below that fixes the return issue (apr_pstrcat does nothing) and some formatting.

I have found a new issue - mod_dav_svn (and mod_dav itself) don’t work properly inside a <LocationMatch>, This is caused as the raw regex is passed as the path, which then triggers an assertion failure inside libsvn. This needs an httpd fix, will look at that in the mean time.

Regards,
Graham
—

Re: [Patch] Expression support for SVNPath and SVNParentPath

[Graham Leggett <mi...@sharp.fm>]

On 02 Mar 2015, at 1:25 PM, Branko Čibej <br...@wandisco.com> wrote:

> You may have missed my mail from a couple days ago:

I did, sorry - I’m not subscribed to the list.

>> I think this would be a nice feature to have in mod_dav_svn. It is, IMO,
>> a better approach than the one currently implemented on the
>> SVNParentPathTemplate branch, even if it is limited to httpd-2.4+.
>> 
>> Graham, I've created a branch for this:
>> 
>>    ^/subversion/branches/mod-dav-svn-expressions
>> 
>> you can commit your patch there, if you will; you have the necessary
>> karma since Subversion-the-project uses the universal-commit bit.
>> 
>> Once that's done, we'll want to tweak our test suite so that we can test
>> the new feature, and probably update docs and so on.
> 
> Please go ahead and commit the patch (and any further changes) to the
> branch.

Over the weekend I discovered that things aren’t that simple (or at least they are simple if you don’t want to use elements of the path in your templates, but that is quite a nasty limitation when we have SVNParentPath doing this very thing).

Two patches posted to the dev@httpd mailing list lift the above limitation[1][2], by providing an optional mechanism to a) pass a proper effective path to mod_dav_svn instead of the (useless) raw regular expression, and b) allow expressions to be used in this effective path so we can place dynamic elements of the uri into our template.

This allows us to do this:

    <LocationMatch /svn/%{env:MATCH_PARTITIONNAME} ^/svn/(?<PARTITIONNAME>[^/]+)/>

      DAV svn
      SVNParentPath /home/${HOST} %{env:MATCH_PARTITIONNAME}/svn
      SVNListParentPath on

    </Location>

The above will map https://svn.example.com/svn/customer1/repo1 to /home/server/customer1/svn/repo1. (Explanation: customer1 has a dedicated partition, and the partition contains a number of services, including but not limited to many svn repos anchored below “svn”)

The most recent path is attached, I’ll commit it to the branch as well. I just wanted to explain the limitation and patches above before anyone reviewed it. Obviously on the httpd side documentation will be updated accordingly.

[1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201503.mbox/%3c05B811A5-1B6E-4417-BC3B-172673A78817@sharp.fm%3e
[2] http://mail-archives.apache.org/mod_mbox/httpd-dev/201503.mbox/%3c03FFF05A-6002-4B71-90FC-6C82B6BCFB6F@sharp.fm%3e

Regards,
Graham
—

Re: [Patch] Expression support for SVNPath and SVNParentPath

[Branko Čibej <br...@wandisco.com>]

On 01.03.2015 15:23, Graham Leggett wrote:
> On 27 Feb 2015, at 2:14 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
>> By way of background, I added the regex named grouping support to httpd that allowed you to do stuff like <LocationMatch ^/svn/(?<CUSTOMERNAME>[^/]+)/>, and I’ve been adding expression support to a growing list of httpd directives, starting with all the require directives, and then following up with Alias and Redirect.
>>
>> What I’m trying to achieve is to lower the cost of httpd directives, both in terms of the amount of config required to achieve a certain aim, as well as making it possible to administer an httpd server (and svn repository) using changes to an LDAP directory only.
>>
>> I chose the two argument layout for SVNPath and SVNParentPath as it was both backwards compatible with existing configs and had the side effect that the expression could be rooted below a specific root directory for safety, given that the directory pointed at by SVNPath isn’t protected (to my knowledge) by <Directory> blocks. It also had the side effect that SVNParentPath could give us a list of repositories rather nicely.
> Here is an updated patch below that fixes the return issue (apr_pstrcat does nothing) and some formatting.
>
> I have found a new issue - mod_dav_svn (and mod_dav itself) don’t work properly inside a <LocationMatch>, This is caused as the raw regex is passed as the path, which then triggers an assertion failure inside libsvn. This needs an httpd fix, will look at that in the mean time.

Hi Graham,

You may have missed my mail from a couple days ago:

> I think this would be a nice feature to have in mod_dav_svn. It is, IMO,
> a better approach than the one currently implemented on the
> SVNParentPathTemplate branch, even if it is limited to httpd-2.4+.
>
> Graham, I've created a branch for this:
>
>     ^/subversion/branches/mod-dav-svn-expressions
>
> you can commit your patch there, if you will; you have the necessary
> karma since Subversion-the-project uses the universal-commit bit.
>
> Once that's done, we'll want to tweak our test suite so that we can test
> the new feature, and probably update docs and so on.

Please go ahead and commit the patch (and any further changes) to the
branch.

-- Brane