No, SElinux isn't installed.
I figured it out, finally. It was pretty obscure:
The ssh login is done as user X, which then force-executes the svnserve
wrapper using sudo to the www-data user. When svnserve attempts to execute
the hook, one of the things done in the call to svn_io_start_cmd3 is to
On Sun, Jul 31, 2016 at 11:15 PM, David Chapman wrote:
> On 7/31/2016 2:30 PM, Patrik Jonsson wrote:
>>
>> Hi all,
>>
>> I've been banging my head against this problem for a day and I need some
>> help. We recently updated the machine hosting our svn repo, and this broke
>> commits using svn+ssh.
On 7/31/2016 2:30 PM, Patrik Jonsson wrote:
Hi all,
I've been banging my head against this problem for a day and I need
some help. We recently updated the machine hosting our svn repo, and
this broke commits using svn+ssh. Here's the setup:
* Machine runs debian 3.16.7, svn 1.8.10.
* svn r
Hi all,
I've been banging my head against this problem for a day and I need some
help. We recently updated the machine hosting our svn repo, and this broke
commits using svn+ssh. Here's the setup:
* Machine runs debian 3.16.7, svn 1.8.10.
* svn runs as user "www-data" (the apache user).
* svn+
On Sun, Jul 31, 2016 at 5:55 PM, Stefan wrote:
> Hi,
>
> I went through a long overdue dump/load cycle of our main repository and
> am wondering atm about a difference I see when comparing the dump of the
> repository with the original dump.
>
> There are a few (at a guess around 20-50) difference
Hi,
I went through a long overdue dump/load cycle of our main repository and
am wondering atm about a difference I see when comparing the dump of the
repository with the original dump.
There are a few (at a guess around 20-50) differences of the following
structure (using fc [olddump] [newdump] o
