On Thu, Dec 3, 2015 at 8:20 PM, Mark Phippard <markphip_at_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 <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.
>
> 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?
Received on 2015-12-04 17:19:54 CET