On Thu, Dec 3, 2015 at 8:20 PM, Mark Phippard <markp...@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 <effo...@gmail.com> wrote: > > On Thu, Dec 3, 2015 at 4:02 PM, Mark Phippard <markp...@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 <effo...@gmail.com> wrote: >> >>> On Thu, Dec 3, 2015 at 2:54 PM, <jbl...@icloud.com> wrote: >>> >>>> >>>> On Dec 3, 2015, at 9:40 AM, foven <effo...@gmail.com> wrote: >>>> >>>> On Wed, Dec 2, 2015 at 9:50 PM, Nico Kadel-Garcia <nka...@gmail.com> >>>> wrote: >>>> >>>>> On Wed, Dec 2, 2015 at 2:12 PM, foven <effo...@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?
