You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by foven <ef...@gmail.com> on 2015/12/01 17:30:12 UTC
Commit blocked by pre-commit hook (exit code 255) with no output.
Hi,
This is my first time posting here. Hopefully I'm posting to the right
list with the right formatting and such. Please let me know if I have
made any mistakes.
I am not subscribed to the list and would appreciate being CC:ed
in any responses.
I have already posted a description of my issue here:
http://stackoverflow.com/questions/33789148/svn-e165001-commit-blocked-by-pre-commit-hook-exit-code-255-with-no-output
I'm not sure if I should replicate that post entirely here or try to
provide the parts that I feel may be more useful and try to avoid what
may be useless detail. For now I will attempt the latter, but it may
be useful to view the link as well. I can also copy the post if that
is desired.
I'm configuring Phabricator to host a repository and almost everything
seems to be working. The only issue that I'm currently aware of is
that commits are never successful. Instead the client always gives a
message "svn: E165001: Commit blocked by pre-commit hook
(exit code 255) with no output".
This error seems to occur independent of the actual script. It happens
when using the default hook installed by Phabricator and also occurs
with very simple hooks like the following:
#!/bin/sh
echo "testing" >&2
exit 1
I would expect this script to fail due to the error code and provide
the error message "testing". Instead I receive the previously
mentioned error message. If I change the exit code to 0, it still
fails with the same message. Basically, this happens with any
pre-commit script, regardless of the script's contents.
Based on a discussion in the #svn IRC channel, I tried the following:
sudo svn mkdir file:///var/repo/SVN/TestFolder -m "Add test folder"
with the following output:
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with
output:
testing
So this implies that the hook can work and may not be at fault at all.
Normally changes to the repository are made like so:
svn mkdir svn+ssh://vcs@phabricator.example.com/diffusion/SVN/TestFolder -m
"Testing"
This seems to cause the vcs user to sudo to the phd user and run:
svnserve -t --tunnel-user=foven
I really have no idea what is causing this issue at this point.
It could be some sort of permissions or ownership issue,
but I've tested the hook like this:
[phd@phabricator ~]$ env -i /var/repo/SVN/hooks/pre-commit
testing
and this:
[phd@phabricator ~]$ env - /var/repo/SVN/hooks/pre-commit
testing
(which I think should be identical) and both ways work.
I can even run the script this way as the tunneled user. I'm not sure
if this is actually necessary or advised (is it?), but seems to
indicate that if the script is run as the tunneled user, it shouldn't
be causing this issue.
I have seen where SELinux has caused this problem for others in the
past, but SELinux is disabled.
Any help is greatly appreciated.
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
On Wed, Dec 2, 2015 at 3:07 PM, Philip Martin <ph...@wandisco.com>
wrote:
> foven <ef...@gmail.com> writes:
>
> > On Wed, Dec 2, 2015 at 11:28 AM, <jb...@icloud.com> wrote:
> >
> >>
> >> > On Dec 2, 2015, at 9:11 AM, foven <ef...@gmail.com> wrote:
> >> >
> >> > Thanks for the reply.
> >> >
> >> > If the user running the script just needs to have read and execute
> >> > permission, then if the file has permissions like this:
> >> >
> >> > -rwxr-xr-x 1 phd phd 37 Nov 18 14:39 pre-commit
> >> >
> >> > shouldn't it work no matter who the user running the script is?
> >> >
> >> > That is how the permissions have been set on the script all this time,
> >> > but although the file:// protocol works, svn+ssh:// has always given
> >> > the error message being discussed.
>
> The ssh user also need read access to the parent hooks/ directory.
>
> --
> Philip Martin
> WANdisco
>
This is how the hooks directory looks at the moment.
It seems reasonable to me, does anything look wrong?
sudo ls -la /var/repo/SVN/hooks/
total 48
drwxr-xr-x. 3 phd phd 4096 Dec 2 14:30 .
drwxr-xr-x. 6 phd phd 4096 Dec 2 13:25 ..
-rwxr-xr-x. 1 phd phd 2062 Oct 27 10:17 post-commit.tmpl
-rwxr-xr-x. 1 phd phd 1638 Oct 27 10:17 post-lock.tmpl
-rwxr-xr-x. 1 phd phd 2289 Oct 27 10:17 post-revprop-change.tmpl
-rwxr-xr-x. 1 phd phd 1567 Oct 27 10:17 post-unlock.tmpl
-rwxr-xr-x 1 phd phd 37 Nov 18 14:39 pre-commit
drwxr-xr-x. 2 phd phd 19 Nov 17 17:05 pre-commit-phabricator.d
-rwxr-xr-x. 1 phd phd 3426 Nov 12 15:59 pre-commit.tmpl
-rwxr-xr-x. 1 phd phd 2434 Oct 27 10:17 pre-lock.tmpl
-rwxr-xr-x. 1 phd phd 2786 Oct 27 10:17 pre-revprop-change.tmpl
-rwxr-xr-x. 1 phd phd 2122 Oct 27 10:17 pre-unlock.tmpl
-rwxr-xr-x. 1 phd phd 3163 Oct 27 10:17 start-commit.tmpl
Also, the main repository directory:
sudo ls -la /var/repo/SVN/
total 156
drwxr-xr-x. 6 phd phd 4096 Dec 2 13:25 .
drwxr-xr-x. 5 phd phd 44 Nov 19 13:15 ..
drwxr-xr-x. 2 phd phd 72 Dec 1 16:40 conf
drwxr-sr-x. 6 phd phd 4096 Dec 2 14:23 db
-r--r--r--. 1 phd phd 2 Oct 27 10:17 format
drwxr-xr-x. 3 phd phd 4096 Dec 2 15:20 hooks
drwxr-xr-x. 2 phd phd 39 Oct 27 10:17 locks
-rw-r--r--. 1 phd phd 246 Oct 27 10:17 README.txt
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Philip Martin <ph...@wandisco.com>.
foven <ef...@gmail.com> writes:
> On Wed, Dec 2, 2015 at 11:28 AM, <jb...@icloud.com> wrote:
>
>>
>> > On Dec 2, 2015, at 9:11 AM, foven <ef...@gmail.com> wrote:
>> >
>> > Thanks for the reply.
>> >
>> > If the user running the script just needs to have read and execute
>> > permission, then if the file has permissions like this:
>> >
>> > -rwxr-xr-x 1 phd phd 37 Nov 18 14:39 pre-commit
>> >
>> > shouldn't it work no matter who the user running the script is?
>> >
>> > That is how the permissions have been set on the script all this time,
>> > but although the file:// protocol works, svn+ssh:// has always given
>> > the error message being discussed.
The ssh user also need read access to the parent hooks/ directory.
--
Philip Martin
WANdisco
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
On Fri, Dec 4, 2015 at 11:25 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Dec 4, 2015 at 11:19 AM, foven <ef...@gmail.com> wrote:
>
>> On Thu, Dec 3, 2015 at 8:20 PM, Mark Phippard <ma...@gmail.com> wrote:
>>
>>> What I was thinking is that the hook they've installed would have
>>> something in it to work in the ssh environment they've configured and be
>>> able to call your hook as their docs describe.
>>>
>>>
>
>> That would make sense, but unfortunately when their script (or any
>>>
>> other) is installed, commits just cause the exit code 255 error,
>> regardless of any custom hooks I create.
>>
>> Any other thoughts?
>>
>>
>
> Your issues seem more specific to Phabricator and how they setup their
> environment. I would try their IRC channel or see if they have any forums
> or a public issue tracker you could post in. Their software looks like it
> would want to manage the environment so it would be best to pursue a
> solution that they provide.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
I actually started trying to solve this in their IRC channel, but
eventually it was suggested that it might be something specific to svn.
After your reply I spoke with some people via Phabricator's web chat
interface and at their suggestion I will be opening a task for this
issue. I'm still not sure if this is a Phabricator issue or a
Subversion one, or some combination of the two, but hopefully between
this mailing list and the developers from the Phabricator team, a
solution will be found soon.
Speaking of the mailing list, I noticed on http://svn.haxx.se/users/
that there were recently some replies in this thread that I seem not
to have received. I'm not sure if there is a better way for me to reply
to these or not, so I will do so here.
From: Thorsten Schöning <tschoening_at_am-soft.de>
Date: Fri, 4 Dec 2015 23:34:38 +0100
Guten Tag foven,
am Donnerstag, 3. Dezember 2015 um 21:55 schrieben Sie:
> AuthorizedKeysCommand /usr/libexec/phabricator-ssh-hook.sh
> AuthorizedKeysCommandUser vcs
Did you have a look at that script, is it maybe doing more than just
authorization? Does it handle svn+ssh different from if you ssh and
execute svn commits using file:///?
Mit freundlichen Grüßen,
Thorsten Schöning
I will look into this, but I'm fairly sure that authorization is all
it does. The documentation for sshd_config states that this
property "specifies a program to be used to look up the user's
public keys". It "should produce on standard output zero or more
lines of authorized_keys output".
So far as a difference between svn+ssh and ssh followed by svn
commits using file:///, I'm pretty sure the way that instance of
sshd is configured, it isn't possible to simply ssh in and then run
commands. I'm not able to access the server at the moment, but I
don't think it is possible. There is another sshd instance
running however, with a more typical configuration and that is the
one where I was able to ssh, then svn commit file:///.
From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Fri, 4 Dec 2015 23:09:45 -0500
Is SELinux enabled?
Received on 2015-12-05 05:09:51 CET
No, SELinux is disabled.
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Dec 4, 2015 at 11:19 AM, foven <ef...@gmail.com> wrote:
> On Thu, Dec 3, 2015 at 8:20 PM, Mark Phippard <ma...@gmail.com> wrote:
>
>> What I was thinking is that the hook they've installed would have
>> something in it to work in the ssh environment they've configured and be
>> able to call your hook as their docs describe.
>>
>>
> That would make sense, but unfortunately when their script (or any
>>
> other) is installed, commits just cause the exit code 255 error,
> regardless of any custom hooks I create.
>
> Any other thoughts?
>
>
Your issues seem more specific to Phabricator and how they setup their
environment. I would try their IRC channel or see if they have any forums
or a public issue tracker you could post in. Their software looks like it
would want to manage the environment so it would be best to pursue a
solution that they provide.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
On Thu, Dec 3, 2015 at 8:20 PM, Mark Phippard <ma...@gmail.com> wrote:
> What I was thinking is that the hook they've installed would have
> something in it to work in the ssh environment they've configured and be
> able to call your hook as their docs describe.
>
> Mark
>
> Sent from my iPad
>
> On Dec 3, 2015, at 5:39 PM, foven <ef...@gmail.com> wrote:
>
> On Thu, Dec 3, 2015 at 4:02 PM, Mark Phippard <ma...@gmail.com> wrote:
>
>> Given that you are using Phabricator, have you tried this?
>>
>> https://secure.phabricator.com/book/phabricator/article/diffusion_hooks/
>>
>>
>>
>> On Thu, Dec 3, 2015 at 3:55 PM, foven <ef...@gmail.com> wrote:
>>
>>> On Thu, Dec 3, 2015 at 2:54 PM, <jb...@icloud.com> wrote:
>>>
>>>>
>>>> On Dec 3, 2015, at 9:40 AM, foven <ef...@gmail.com> wrote:
>>>>
>>>> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nk...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Wed, Dec 2, 2015 at 2:12 PM, foven <ef...@gmail.com> wrote:
>>>>>
>>>>> > I looked at the output of "journalctl -n 50", which seems to be
>>>>> enough
>>>>> > to see all that is logged for a commit attempt. I also checked
>>>>> > /var/log/secure. I didn't see anything that seemed obviously wrong
>>>>> to
>>>>> > me either way, although it is possible that I missed something. Are
>>>>> > there any other logs that I should check?
>>>>> >
>>>>> > Also, just to be clear, when I say that svn+ssh is not working, it is
>>>>> > working for checkouts and if I remove the pre-commit hook, it works
>>>>> for
>>>>> > commits as well. Does it still seem likely that this is a ssh issue?
>>>>> >
>>>>> > Is there any more information I can provide that might help?
>>>>>
>>>>> Start at the beginning: As whom is the "svn+ssh" connection being
>>>>> made? I assume it's the "phd" user, and that the SSH keys have been
>>>>> correctly configured?
>>>>>
>>>>
>>>> Well, this repository is hosted by Phabricator.
>>>>
>>>>
>>>> <…snip…>
>>>>
>>>> I hope this helps. Please let me know if you need more information.
>>>>
>>>>
>>>>
>>>> This almost feels to me as if the path "/bin/sh" is not what it seems.
>>>> Do you know if Phabricator is using a chroot'd sshd implementation? They
>>>> are usually rare since sshd does not provide that by default, but I have
>>>> seen some attempts.
>>>>
>>>> -Joseph
>>>>
>>>>
>>>>
>>>>
>>> I'm not totally sure, but I don't think it is. I'm basing this off the
>>> fact that the sshd_config file for Phabricator's sshd instance doesn't
>>> seem to use ChrootDirectory. I don't know much about using chroot with
>>> sshd, but it seems like that is how the chroot directory is specified.
>>> So if it isn't present, that would probably imply that chroot is not
>>> being used.
>>>
>>> Of course, I could be wrong. Not sure what else to look for though.
>>> Phabricator does set some limitations in the sshd_config file.
>>> Here is what the file looks like, in case it is of interest:
>>>
>>>
>>> # NOTE: You must have OpenSSHD 6.2 or newer; support for
>>> AuthorizedKeysCommand
>>> # was added in this version.
>>>
>>> # NOTE: Edit these to the correct values for your setup.
>>>
>>> AuthorizedKeysCommand /usr/libexec/phabricator-ssh-hook.sh
>>> AuthorizedKeysCommandUser vcs
>>> AllowUsers vcs
>>>
>>> # You may need to tweak these options, but mostly they just turn off
>>> everything
>>> # dangerous.
>>>
>>> Port 22
>>> Protocol 2
>>> PermitRootLogin no
>>> AllowAgentForwarding no
>>> AllowTcpForwarding no
>>> PrintMotd no
>>> PrintLastLog no
>>> PasswordAuthentication no
>>> AuthorizedKeysFile none
>>>
>>> PidFile /var/run/sshd-phabricator.pid
>>>
>>>
>>
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>
> I have, but for a different reason.
>
> I don't think it offers a solution for this issue though, since it
> doesn't change the fact that there will always be a hooks/pre-commit
> script of some sort and currently it seems that any hooks/pre-commit
> script will cause the error that I'm experiencing.
>
> Currently, I'm using a very simple hook in place of the one that is
> installed by Phabricator by default, but I am only able to do this
> because I have disabled the Phabricator daemons. This is just for
> testing while I try to resolve this error. When the daemons are
> running, they will overwrite the hooks/pre-commit script before running
> it, if it is changed (at least that seems to be the case).
>
> I think that the hooks/pre-commit script installed by Phabricator is
> responsible for eventually calling the custom hooks discussed in the
> guide that you linked. So if that pre-commit script is not present,
> they will never be called and if it is present, I get the error. So I
> don't think it will help in this case, unless I have missed something.
>
> Also, I just did a quick test:
>
> I moved my test hook to the hooks/pre-commit-phabricator.d/ directory,
> as though it were a custom hook I wanted to use, as explained in the
> linked guide. This created a situation where there was no
> hooks/pre-commit script and the daemons were not running, so none would be
> generated. I then tried a commit and was successful, which my hook
> would have prevented if it had run. So it seems likely that
> Phabricator's hook/pre-commit script is responsible for calling these
> hooks. And of course the presence of this hook causes the error to
> occur.
>
> So, I don't think I can use this to solve my problem. Please let me
> know if I missed anything.
>
> That would make sense, but unfortunately when their script (or any
other) is installed, commits just cause the exit code 255 error,
regardless of any custom hooks I create.
Any other thoughts?
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Mark Phippard <ma...@gmail.com>.
What I was thinking is that the hook they've installed would have something in it to work in the ssh environment they've configured and be able to call your hook as their docs describe.
Mark
Sent from my iPad
> On Dec 3, 2015, at 5:39 PM, foven <ef...@gmail.com> wrote:
>
>> On Thu, Dec 3, 2015 at 4:02 PM, Mark Phippard <ma...@gmail.com> wrote:
>> Given that you are using Phabricator, have you tried this?
>>
>> https://secure.phabricator.com/book/phabricator/article/diffusion_hooks/
>>
>>
>>
>>> On Thu, Dec 3, 2015 at 3:55 PM, foven <ef...@gmail.com> wrote:
>>>> On Thu, Dec 3, 2015 at 2:54 PM, <jb...@icloud.com> wrote:
>>>>
>>>>> On Dec 3, 2015, at 9:40 AM, foven <ef...@gmail.com> wrote:
>>>>>
>>>>>> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>>>>>> On Wed, Dec 2, 2015 at 2:12 PM, foven <ef...@gmail.com> wrote:
>>>>>>
>>>>>> > I looked at the output of "journalctl -n 50", which seems to be enough
>>>>>> > to see all that is logged for a commit attempt. I also checked
>>>>>> > /var/log/secure. I didn't see anything that seemed obviously wrong to
>>>>>> > me either way, although it is possible that I missed something. Are
>>>>>> > there any other logs that I should check?
>>>>>> >
>>>>>> > Also, just to be clear, when I say that svn+ssh is not working, it is
>>>>>> > working for checkouts and if I remove the pre-commit hook, it works for
>>>>>> > commits as well. Does it still seem likely that this is a ssh issue?
>>>>>> >
>>>>>> > Is there any more information I can provide that might help?
>>>>>>
>>>>>> Start at the beginning: As whom is the "svn+ssh" connection being
>>>>>> made? I assume it's the "phd" user, and that the SSH keys have been
>>>>>> correctly configured?
>>>>>
>>>>> Well, this repository is hosted by Phabricator.
>>>>
>>>>
>>>> <…snip…>
>>>>
>>>>> I hope this helps. Please let me know if you need more information.
>>>>
>>>>
>>>> This almost feels to me as if the path "/bin/sh" is not what it seems. Do you know if Phabricator is using a chroot'd sshd implementation? They are usually rare since sshd does not provide that by default, but I have seen some attempts.
>>>>
>>>> -Joseph
>>>
>>> I'm not totally sure, but I don't think it is. I'm basing this off the
>>> fact that the sshd_config file for Phabricator's sshd instance doesn't
>>> seem to use ChrootDirectory. I don't know much about using chroot with
>>> sshd, but it seems like that is how the chroot directory is specified.
>>> So if it isn't present, that would probably imply that chroot is not
>>> being used.
>>>
>>> Of course, I could be wrong. Not sure what else to look for though.
>>> Phabricator does set some limitations in the sshd_config file.
>>> Here is what the file looks like, in case it is of interest:
>>>
>>>
>>> # NOTE: You must have OpenSSHD 6.2 or newer; support for AuthorizedKeysCommand
>>> # was added in this version.
>>>
>>> # NOTE: Edit these to the correct values for your setup.
>>>
>>> AuthorizedKeysCommand /usr/libexec/phabricator-ssh-hook.sh
>>> AuthorizedKeysCommandUser vcs
>>> AllowUsers vcs
>>>
>>> # You may need to tweak these options, but mostly they just turn off everything
>>> # dangerous.
>>>
>>> Port 22
>>> Protocol 2
>>> PermitRootLogin no
>>> AllowAgentForwarding no
>>> AllowTcpForwarding no
>>> PrintMotd no
>>> PrintLastLog no
>>> PasswordAuthentication no
>>> AuthorizedKeysFile none
>>>
>>> PidFile /var/run/sshd-phabricator.pid
>>
>>
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>
> I have, but for a different reason.
>
> I don't think it offers a solution for this issue though, since it
> doesn't change the fact that there will always be a hooks/pre-commit
> script of some sort and currently it seems that any hooks/pre-commit
> script will cause the error that I'm experiencing.
>
> Currently, I'm using a very simple hook in place of the one that is
> installed by Phabricator by default, but I am only able to do this
> because I have disabled the Phabricator daemons. This is just for
> testing while I try to resolve this error. When the daemons are
> running, they will overwrite the hooks/pre-commit script before running
> it, if it is changed (at least that seems to be the case).
>
> I think that the hooks/pre-commit script installed by Phabricator is
> responsible for eventually calling the custom hooks discussed in the
> guide that you linked. So if that pre-commit script is not present,
> they will never be called and if it is present, I get the error. So I
> don't think it will help in this case, unless I have missed something.
>
> Also, I just did a quick test:
>
> I moved my test hook to the hooks/pre-commit-phabricator.d/ directory,
> as though it were a custom hook I wanted to use, as explained in the
> linked guide. This created a situation where there was no
> hooks/pre-commit script and the daemons were not running, so none would be
> generated. I then tried a commit and was successful, which my hook
> would have prevented if it had run. So it seems likely that
> Phabricator's hook/pre-commit script is responsible for calling these
> hooks. And of course the presence of this hook causes the error to
> occur.
>
> So, I don't think I can use this to solve my problem. Please let me
> know if I missed anything.
>
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
On Thu, Dec 3, 2015 at 4:02 PM, Mark Phippard <ma...@gmail.com> wrote:
> Given that you are using Phabricator, have you tried this?
>
> https://secure.phabricator.com/book/phabricator/article/diffusion_hooks/
>
>
>
> On Thu, Dec 3, 2015 at 3:55 PM, foven <ef...@gmail.com> wrote:
>
>> On Thu, Dec 3, 2015 at 2:54 PM, <jb...@icloud.com> wrote:
>>
>>>
>>> On Dec 3, 2015, at 9:40 AM, foven <ef...@gmail.com> wrote:
>>>
>>> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nk...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Dec 2, 2015 at 2:12 PM, foven <ef...@gmail.com> wrote:
>>>>
>>>> > I looked at the output of "journalctl -n 50", which seems to be enough
>>>> > to see all that is logged for a commit attempt. I also checked
>>>> > /var/log/secure. I didn't see anything that seemed obviously wrong to
>>>> > me either way, although it is possible that I missed something. Are
>>>> > there any other logs that I should check?
>>>> >
>>>> > Also, just to be clear, when I say that svn+ssh is not working, it is
>>>> > working for checkouts and if I remove the pre-commit hook, it works
>>>> for
>>>> > commits as well. Does it still seem likely that this is a ssh issue?
>>>> >
>>>> > Is there any more information I can provide that might help?
>>>>
>>>> Start at the beginning: As whom is the "svn+ssh" connection being
>>>> made? I assume it's the "phd" user, and that the SSH keys have been
>>>> correctly configured?
>>>>
>>>
>>> Well, this repository is hosted by Phabricator.
>>>
>>>
>>> <…snip…>
>>>
>>> I hope this helps. Please let me know if you need more information.
>>>
>>>
>>>
>>> This almost feels to me as if the path "/bin/sh" is not what it seems.
>>> Do you know if Phabricator is using a chroot'd sshd implementation? They
>>> are usually rare since sshd does not provide that by default, but I have
>>> seen some attempts.
>>>
>>> -Joseph
>>>
>>>
>>>
>>>
>> I'm not totally sure, but I don't think it is. I'm basing this off the
>> fact that the sshd_config file for Phabricator's sshd instance doesn't
>> seem to use ChrootDirectory. I don't know much about using chroot with
>> sshd, but it seems like that is how the chroot directory is specified.
>> So if it isn't present, that would probably imply that chroot is not
>> being used.
>>
>> Of course, I could be wrong. Not sure what else to look for though.
>> Phabricator does set some limitations in the sshd_config file.
>> Here is what the file looks like, in case it is of interest:
>>
>>
>> # NOTE: You must have OpenSSHD 6.2 or newer; support for
>> AuthorizedKeysCommand
>> # was added in this version.
>>
>> # NOTE: Edit these to the correct values for your setup.
>>
>> AuthorizedKeysCommand /usr/libexec/phabricator-ssh-hook.sh
>> AuthorizedKeysCommandUser vcs
>> AllowUsers vcs
>>
>> # You may need to tweak these options, but mostly they just turn off
>> everything
>> # dangerous.
>>
>> Port 22
>> Protocol 2
>> PermitRootLogin no
>> AllowAgentForwarding no
>> AllowTcpForwarding no
>> PrintMotd no
>> PrintLastLog no
>> PasswordAuthentication no
>> AuthorizedKeysFile none
>>
>> PidFile /var/run/sshd-phabricator.pid
>>
>>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
I have, but for a different reason.
I don't think it offers a solution for this issue though, since it
doesn't change the fact that there will always be a hooks/pre-commit
script of some sort and currently it seems that any hooks/pre-commit
script will cause the error that I'm experiencing.
Currently, I'm using a very simple hook in place of the one that is
installed by Phabricator by default, but I am only able to do this
because I have disabled the Phabricator daemons. This is just for
testing while I try to resolve this error. When the daemons are
running, they will overwrite the hooks/pre-commit script before running
it, if it is changed (at least that seems to be the case).
I think that the hooks/pre-commit script installed by Phabricator is
responsible for eventually calling the custom hooks discussed in the
guide that you linked. So if that pre-commit script is not present,
they will never be called and if it is present, I get the error. So I
don't think it will help in this case, unless I have missed something.
Also, I just did a quick test:
I moved my test hook to the hooks/pre-commit-phabricator.d/ directory,
as though it were a custom hook I wanted to use, as explained in the
linked guide. This created a situation where there was no
hooks/pre-commit script and the daemons were not running, so none would be
generated. I then tried a commit and was successful, which my hook
would have prevented if it had run. So it seems likely that
Phabricator's hook/pre-commit script is responsible for calling these
hooks. And of course the presence of this hook causes the error to
occur.
So, I don't think I can use this to solve my problem. Please let me
know if I missed anything.
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Mark Phippard <ma...@gmail.com>.
Given that you are using Phabricator, have you tried this?
https://secure.phabricator.com/book/phabricator/article/diffusion_hooks/
On Thu, Dec 3, 2015 at 3:55 PM, foven <ef...@gmail.com> wrote:
> On Thu, Dec 3, 2015 at 2:54 PM, <jb...@icloud.com> wrote:
>
>>
>> On Dec 3, 2015, at 9:40 AM, foven <ef...@gmail.com> wrote:
>>
>> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nk...@gmail.com>
>> wrote:
>>
>>> On Wed, Dec 2, 2015 at 2:12 PM, foven <ef...@gmail.com> wrote:
>>>
>>> > I looked at the output of "journalctl -n 50", which seems to be enough
>>> > to see all that is logged for a commit attempt. I also checked
>>> > /var/log/secure. I didn't see anything that seemed obviously wrong to
>>> > me either way, although it is possible that I missed something. Are
>>> > there any other logs that I should check?
>>> >
>>> > Also, just to be clear, when I say that svn+ssh is not working, it is
>>> > working for checkouts and if I remove the pre-commit hook, it works for
>>> > commits as well. Does it still seem likely that this is a ssh issue?
>>> >
>>> > Is there any more information I can provide that might help?
>>>
>>> Start at the beginning: As whom is the "svn+ssh" connection being
>>> made? I assume it's the "phd" user, and that the SSH keys have been
>>> correctly configured?
>>>
>>
>> Well, this repository is hosted by Phabricator.
>>
>>
>> <…snip…>
>>
>> I hope this helps. Please let me know if you need more information.
>>
>>
>>
>> This almost feels to me as if the path "/bin/sh" is not what it seems. Do
>> you know if Phabricator is using a chroot'd sshd implementation? They are
>> usually rare since sshd does not provide that by default, but I have seen
>> some attempts.
>>
>> -Joseph
>>
>>
>>
>>
> I'm not totally sure, but I don't think it is. I'm basing this off the
> fact that the sshd_config file for Phabricator's sshd instance doesn't
> seem to use ChrootDirectory. I don't know much about using chroot with
> sshd, but it seems like that is how the chroot directory is specified.
> So if it isn't present, that would probably imply that chroot is not
> being used.
>
> Of course, I could be wrong. Not sure what else to look for though.
> Phabricator does set some limitations in the sshd_config file.
> Here is what the file looks like, in case it is of interest:
>
>
> # NOTE: You must have OpenSSHD 6.2 or newer; support for
> AuthorizedKeysCommand
> # was added in this version.
>
> # NOTE: Edit these to the correct values for your setup.
>
> AuthorizedKeysCommand /usr/libexec/phabricator-ssh-hook.sh
> AuthorizedKeysCommandUser vcs
> AllowUsers vcs
>
> # You may need to tweak these options, but mostly they just turn off
> everything
> # dangerous.
>
> Port 22
> Protocol 2
> PermitRootLogin no
> AllowAgentForwarding no
> AllowTcpForwarding no
> PrintMotd no
> PrintLastLog no
> PasswordAuthentication no
> AuthorizedKeysFile none
>
> PidFile /var/run/sshd-phabricator.pid
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
Is SELinux enabled?
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag foven,
am Donnerstag, 3. Dezember 2015 um 21:55 schrieben Sie:
> AuthorizedKeysCommand /usr/libexec/phabricator-ssh-hook.sh
> AuthorizedKeysCommandUser vcs
Did you have a look at that script, is it maybe doing more than just
authorization? Does it handle svn+ssh different from if you ssh and
execute svn commits using file:///?
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
On Thu, Dec 3, 2015 at 2:54 PM, <jb...@icloud.com> wrote:
>
> On Dec 3, 2015, at 9:40 AM, foven <ef...@gmail.com> wrote:
>
> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nk...@gmail.com>
> wrote:
>
>> On Wed, Dec 2, 2015 at 2:12 PM, foven <ef...@gmail.com> wrote:
>>
>> > I looked at the output of "journalctl -n 50", which seems to be enough
>> > to see all that is logged for a commit attempt. I also checked
>> > /var/log/secure. I didn't see anything that seemed obviously wrong to
>> > me either way, although it is possible that I missed something. Are
>> > there any other logs that I should check?
>> >
>> > Also, just to be clear, when I say that svn+ssh is not working, it is
>> > working for checkouts and if I remove the pre-commit hook, it works for
>> > commits as well. Does it still seem likely that this is a ssh issue?
>> >
>> > Is there any more information I can provide that might help?
>>
>> Start at the beginning: As whom is the "svn+ssh" connection being
>> made? I assume it's the "phd" user, and that the SSH keys have been
>> correctly configured?
>>
>
> Well, this repository is hosted by Phabricator.
>
>
> <…snip…>
>
> I hope this helps. Please let me know if you need more information.
>
>
>
> This almost feels to me as if the path "/bin/sh" is not what it seems. Do
> you know if Phabricator is using a chroot'd sshd implementation? They are
> usually rare since sshd does not provide that by default, but I have seen
> some attempts.
>
> -Joseph
>
>
>
>
I'm not totally sure, but I don't think it is. I'm basing this off the
fact that the sshd_config file for Phabricator's sshd instance doesn't
seem to use ChrootDirectory. I don't know much about using chroot with
sshd, but it seems like that is how the chroot directory is specified.
So if it isn't present, that would probably imply that chroot is not
being used.
Of course, I could be wrong. Not sure what else to look for though.
Phabricator does set some limitations in the sshd_config file.
Here is what the file looks like, in case it is of interest:
# NOTE: You must have OpenSSHD 6.2 or newer; support for
AuthorizedKeysCommand
# was added in this version.
# NOTE: Edit these to the correct values for your setup.
AuthorizedKeysCommand /usr/libexec/phabricator-ssh-hook.sh
AuthorizedKeysCommandUser vcs
AllowUsers vcs
# You may need to tweak these options, but mostly they just turn off
everything
# dangerous.
Port 22
Protocol 2
PermitRootLogin no
AllowAgentForwarding no
AllowTcpForwarding no
PrintMotd no
PrintLastLog no
PasswordAuthentication no
AuthorizedKeysFile none
PidFile /var/run/sshd-phabricator.pid
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by jb...@icloud.com.
> On Dec 3, 2015, at 9:40 AM, foven <ef...@gmail.com> wrote:
>
> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nkadel@gmail.com <ma...@gmail.com>> wrote:
> On Wed, Dec 2, 2015 at 2:12 PM, foven <effoven@gmail.com <ma...@gmail.com>> wrote:
>
> > I looked at the output of "journalctl -n 50", which seems to be enough
> > to see all that is logged for a commit attempt. I also checked
> > /var/log/secure. I didn't see anything that seemed obviously wrong to
> > me either way, although it is possible that I missed something. Are
> > there any other logs that I should check?
> >
> > Also, just to be clear, when I say that svn+ssh is not working, it is
> > working for checkouts and if I remove the pre-commit hook, it works for
> > commits as well. Does it still seem likely that this is a ssh issue?
> >
> > Is there any more information I can provide that might help?
>
> Start at the beginning: As whom is the "svn+ssh" connection being
> made? I assume it's the "phd" user, and that the SSH keys have been
> correctly configured?
>
> Well, this repository is hosted by Phabricator.
>
<…snip…>
> I hope this helps. Please let me know if you need more information.
>
This almost feels to me as if the path "/bin/sh" is not what it seems. Do you know if Phabricator is using a chroot'd sshd implementation? They are usually rare since sshd does not provide that by default, but I have seen some attempts.
-Joseph
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Wed, Dec 2, 2015 at 2:12 PM, foven <ef...@gmail.com> wrote:
>
> > I looked at the output of "journalctl -n 50", which seems to be enough
> > to see all that is logged for a commit attempt. I also checked
> > /var/log/secure. I didn't see anything that seemed obviously wrong to
> > me either way, although it is possible that I missed something. Are
> > there any other logs that I should check?
> >
> > Also, just to be clear, when I say that svn+ssh is not working, it is
> > working for checkouts and if I remove the pre-commit hook, it works for
> > commits as well. Does it still seem likely that this is a ssh issue?
> >
> > Is there any more information I can provide that might help?
>
> Start at the beginning: As whom is the "svn+ssh" connection being
> made? I assume it's the "phd" user, and that the SSH keys have been
> correctly configured?
>
Well, this repository is hosted by Phabricator.
In following the Phabricator documentation
(https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/)
I now have the following users:
vcs:
The user that users will connect over SSH as.
phd:
This user is the only user which will interact with the
repositories directly. Other accounts will sudo to this account in
order to perform VCS operations.
foven:
Just a normal user.
Users are supposed to connect to the repository as vcs. SSH is set to
use an AuthorizedKeysCommand script and it seems that this enables it to
determine which user is actually connecting, based on the SSH key in
use. This seems to be working, since users can checkout code and commit
code as well, so long as the pre-commit hook does not exist.
>From what I can see, when a user uses a subversion command via svn+ssh,
it is basically working like this:
user (foven):
svn mkdir svn+ssh://vcs@phabricator.example.com/diffusion/SVN/TestFolder
-m "Test commit hooks"
This causes vcs to sudo to the phd user and run this command:
svnserve -t --tunnel-user=foven
So phd is running svnserve, but it is tunneling the user through. I'm
not sure how/if that affects anything. Again, commits work fine this
way if the pre-commit script is not present. Otherwise the client gets
this error message:
svn: E165001: Commit blocked by pre-commit hook (exit code 255) with no
output.
Based on what I've read, it seems that this error message likely
indicates that the script itself is somehow unable to run or it is
encountering an error, causing it to exit with an exit code that doesn't
actually exist within the script itself.
The script that I am testing with looks like this:
#!/bin/sh
echo "testing" >&2
exit 1
I want the script to fail, but with exit code 1 and "testing" for the
error message, not with the error message mentioned earlier.
I thought it could be a permissions issue or the fact that hooks run in
an empty environment, but every user I've mentioned can run the script
using the following commands:
env -i /var/repo/SVN/hooks/pre-commit
env - /var/repo/SVN/hooks/pre-commit
I hope this helps. Please let me know if you need more information.
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Dec 2, 2015 at 2:12 PM, foven <ef...@gmail.com> wrote:
> I looked at the output of "journalctl -n 50", which seems to be enough
> to see all that is logged for a commit attempt. I also checked
> /var/log/secure. I didn't see anything that seemed obviously wrong to
> me either way, although it is possible that I missed something. Are
> there any other logs that I should check?
>
> Also, just to be clear, when I say that svn+ssh is not working, it is
> working for checkouts and if I remove the pre-commit hook, it works for
> commits as well. Does it still seem likely that this is a ssh issue?
>
> Is there any more information I can provide that might help?
Start at the beginning: As whom is the "svn+ssh" connection being
made? I assume it's the "phd" user, and that the SSH keys have been
correctly configured?
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
On Wed, Dec 2, 2015 at 11:28 AM, <jb...@icloud.com> wrote:
>
> > On Dec 2, 2015, at 9:11 AM, foven <ef...@gmail.com> wrote:
> >
> > Thanks for the reply.
> >
> > If the user running the script just needs to have read and execute
> > permission, then if the file has permissions like this:
> >
> > -rwxr-xr-x 1 phd phd 37 Nov 18 14:39 pre-commit
> >
> > shouldn't it work no matter who the user running the script is?
> >
> > That is how the permissions have been set on the script all this time,
> > but although the file:// protocol works, svn+ssh:// has always given
> > the error message being discussed.
>
> Those permissions are correct and should allow the script to run for all
> users of the system.
>
> If file: is working and svn+ssh is not, perhaps you can look into the
> system log to see if sshd is complaining about something.
>
> svn+ssh is essentially the same as file but with a network layer on top.
>
> -Joseph
>
>
>
I looked at the output of "journalctl -n 50", which seems to be enough
to see all that is logged for a commit attempt. I also checked
/var/log/secure. I didn't see anything that seemed obviously wrong to
me either way, although it is possible that I missed something. Are
there any other logs that I should check?
Also, just to be clear, when I say that svn+ssh is not working, it is
working for checkouts and if I remove the pre-commit hook, it works for
commits as well. Does it still seem likely that this is a ssh issue?
Is there any more information I can provide that might help?
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by jb...@icloud.com.
> On Dec 2, 2015, at 9:11 AM, foven <ef...@gmail.com> wrote:
>
> Thanks for the reply.
>
> If the user running the script just needs to have read and execute
> permission, then if the file has permissions like this:
>
> -rwxr-xr-x 1 phd phd 37 Nov 18 14:39 pre-commit
>
> shouldn't it work no matter who the user running the script is?
>
> That is how the permissions have been set on the script all this time,
> but although the file:// protocol works, svn+ssh:// has always given
> the error message being discussed.
Those permissions are correct and should allow the script to run for all users of the system.
If file: is working and svn+ssh is not, perhaps you can look into the system log to see if sshd is complaining about something.
svn+ssh is essentially the same as file but with a network layer on top.
-Joseph
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by foven <ef...@gmail.com>.
Thanks for the reply.
If the user running the script just needs to have read and execute
permission, then if the file has permissions like this:
-rwxr-xr-x 1 phd phd 37 Nov 18 14:39 pre-commit
shouldn't it work no matter who the user running the script is?
That is how the permissions have been set on the script all this time,
but although the file:// protocol works, svn+ssh:// has always given
the error message being discussed.
Re: Commit blocked by pre-commit hook (exit code 255) with no output.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 1, 2015, at 10:30 AM, foven wrote:
> I'm configuring Phabricator to host a repository and almost everything
> seems to be working. The only issue that I'm currently aware of is
> that commits are never successful. Instead the client always gives a
> message "svn: E165001: Commit blocked by pre-commit hook
> (exit code 255) with no output".
>
> This error seems to occur independent of the actual script. It happens
> when using the default hook installed by Phabricator and also occurs
> with very simple hooks like the following:
>
> #!/bin/sh
>
> echo "testing" >&2
> exit 1
>
> I would expect this script to fail due to the error code and provide
> the error message "testing". Instead I receive the previously
> mentioned error message. If I change the exit code to 0, it still
> fails with the same message. Basically, this happens with any
> pre-commit script, regardless of the script's contents.
>
> Based on a discussion in the #svn IRC channel, I tried the following:
>
> sudo svn mkdir file:///var/repo/SVN/TestFolder -m "Add test folder"
>
> with the following output:
>
> svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
> testing
>
> So this implies that the hook can work and may not be at fault at all.
> Normally changes to the repository are made like so:
> svn mkdir svn+ssh://vcs@phabricator.example.com/diffusion/SVN/TestFolder -m "Testing"
>
> This seems to cause the vcs user to sudo to the phd user and run:
>
> svnserve -t --tunnel-user=foven
>
> I really have no idea what is causing this issue at this point.
> It could be some sort of permissions or ownership issue,
> but I've tested the hook like this:
>
> [phd@phabricator ~]$ env -i /var/repo/SVN/hooks/pre-commit
> testing
>
> and this:
>
> [phd@phabricator ~]$ env - /var/repo/SVN/hooks/pre-commit
> testing
>
> (which I think should be identical) and both ways work.
>
> I can even run the script this way as the tunneled user. I'm not sure
> if this is actually necessary or advised (is it?), but seems to
> indicate that if the script is run as the tunneled user, it shouldn't
> be causing this issue.
>
> I have seen where SELinux has caused this problem for others in the
> past, but SELinux is disabled.
Yes, it sounds like permissions on the script are not correct. The permissions need to be such that the user who is running the script has read and execute permission. If you are using the file:// protocol, then that user is the user running the svn command. If you are using the http:// or https:// protocol, then that user is the user your apache server runs as. If you are using the svn:// protocol, then that user is the user your svnserve process runs as. If you are using the svn+ssh:// protocol, then if I'm not mistaken that user is the user you authenticate with.
Typically it would be enough to "chmod 755 pre-commit". SELinux has additional requirements, but you said that's disabled.