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.
