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, [email protected] 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 <[email protected]> 
>>> 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
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to