1. Does ssh.sh has execute permissions set correctly?
   2. Is ssh.sh sitting in a mount point with `noexec` set? (mount | grep 
   noexec)

I'll double check these when I get chance (can't seem to access bash from 
work), but in the meantime I tried setting GIT_SSH to just "ssh".  It ran 
it without an error, although github refused the push since it wasn't 
authenticated (as expected).

I read up and GIT_SSH isn't capable of taking command arguments, so most 
people use a .sh script.  I've managed to get rid of the permissions error 
but it now complains about not being able to find the file 
(/app/git_ssh.sh) even though I test for it's existence in the app and it's 
definitely there (also set 0755 permissions to be sure).

"error: cannot run /app/git_ssh.sh: No such file or directory\nfatal: unable to 
fork\n"


Very confused at the moment :P

Dave

On Wednesday, April 3, 2013 12:36:53 PM UTC+1, mi...@bolser.co.uk wrote:
>
> Glad you're making progress and the file system isn't going to cause 
> issues for you.
>
> I don't know the solution but am pretty sure that error is a UNIX 
> permission error, so two things I'd check:
>
>
>    1. Does ssh.sh has execute permissions set correctly?
>    2. Is ssh.sh sitting in a mount point with `noexec` set? (mount | grep 
>    noexec)
>
> Does that help?
>
> On Wednesday, April 3, 2013 12:04:48 PM UTC+1, David Boyer wrote:
>>
>> Hi Daniel,
>>
>> Thanks for the extra information on the file system, good to know I've 
>> got that right :)
>>
>> Stuffing the key into a config var does make sense, thanks for the 
>> suggestion.  I seem to still be missing a piece of the puzzle though.  I've 
>> the keys needed set as config vars, plus GIT_SSH set as a "ssh.sh" script 
>> which contains lines to materialise the keys as files and then make use of 
>> it got the push.  But I'm running into the error:
>> "fatal: cannot exec './ssh.sh': Permission denied\nfatal: unable to 
>> fork\n"
>>
>> I noticed that a wallmart project called 
>> "mock-server"<https://github.com/walmartlabs/mock-server>appears to have 
>> code that supports heroku and funcationality for git keys. 
>>  I've tried to follow what they have with the keys as config vars and the 
>> .sh script.
>>
>> Dave
>>
>> On Wednesday, 3 April 2013 09:53:33 UTC+1, Daniel Farina wrote:
>>>
>>> Hello, 
>>>
>>> On Wed, Apr 3, 2013 at 1:11 AM, David Boyer <da...@yougeezer.co.uk> 
>>> wrote: 
>>> > Looks like the ephemeral file system won't be an issue.  I've read up 
>>> and it 
>>> > appears that it'll only lose any created files when the dyno is 
>>> stopped or 
>>> > restarted.  That works fine for me since if the process is stopped / 
>>> > restarted, I wouldn't want those files anyway.  Plus each batch would 
>>> be 
>>> > independent, not requiring any from a previous batch of files. 
>>>
>>> Your reading is correct.  Many, many applications -- including quite a 
>>> few Heroku components -- rely on manipulating the file system within 
>>> the running container with the understanding that it will go away 
>>> after the container is destroyed.  You can have a shot at knowing when 
>>> this is happening by treating SIGTERM in a program.  The grace period 
>>> is some handful of seconds. 
>>>
>>> > Just need to work out the SSH github deploy key needs to be configured 
>>> for 
>>> > heroku to have repository access for the push.  Possibly this? 
>>>
>>> I'd suggest (although it may seem bizarre) stuffing the key into a 
>>> config var if you do this, and then materializing it on the file 
>>> system to aid 'git push'. 
>>>
>>> -- 
>>> fdr 
>>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Heroku" group.

To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"Heroku Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to heroku+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to