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 <effoven_at_gmail.com> wrote:
>
>> On Thu, Dec 3, 2015 at 4:02 PM, Mark Phippard <markphip_at_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 <effoven_at_gmail.com> wrote:
>>>> On Thu, Dec 3, 2015 at 2:54 PM, <jblist_at_icloud.com> wrote:
>>>>
>>>>> On Dec 3, 2015, at 9:40 AM, foven <effoven_at_gmail.com> wrote:
>>>>>
>>>>>> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>>>>>> On Wed, Dec 2, 2015 at 2:12 PM, foven <effoven_at_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.
>
Received on 2015-12-04 02:21:05 CET