Jamis,
It does not work with the -N option, I´m not getting the login prompt
on the gateway.
This however works:
ssh -L :target:22 mart...@stepstone
# Opens a connection to stepstone and I get a shell there.
# New terminal window:
$ ssh -i ~/.ssh/id_rsa-target localhost -p
On 4/23/09 2:11 AM, martins wrote:
Jamis,
It does not work with the -N option, I´m not getting the login prompt
on the gateway.
Right...that's the point. All you need the gateway for is the tunnelled
connection in the next command. You don't need the shell. So you do it
with the -N, like
I recently renamed my github account and have been having problems
since. For some reason when I run the cap deploy command the remote
server continues to make calls to old github address.
The old account name no longer exists any where within the project and
I am able to make committals to the
Oops, a copy and past issue on the previous console output. Here is
the correction.
$ cap deploy
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
updating the cached checkout on all servers
executing locally: git ls-remote
Chris,
The cloned repository on your server is probably still set to the old path,
which deploy strategy (:deploy_via) are you using?
Also, for the sake of the list, please gist or pastie large blocks of
output!
- Lee
2009/4/23 chris olsen.ch...@gmail.com
Oops, a copy and past issue on the
You're probably using the remote cache strategy, .git/config on the
server still points to the old github account.
Just manually edit it or remove the cache directory and redeploy.
Il giorno 23/apr/09, alle ore 15:27, chris olsen.ch...@gmail.com ha
scritto:
Oops, a copy and past issue
That I am. I have checked the .git/config files on the server, but
the only thing in them is:
[core]
repositoryformatversion = 0
filemode = true
Is there another config file that I am missing?
On Apr 23, 7:49 am, Giovanni Intini inti...@gmail.com wrote:
You're probably using
The easiest thing to do is to just blow away the cached-copy directory
on all your deployment servers, and redeploy:
rm -rf /var/rails/app_name/shared/cached-copy
Deleting that directory will have no effect on your running application.
It will just cause capistrano to reclone your
Chris,
I'd honestly just try erasing the cache on the server, and taking the hit of
1 slow(er) deploy and see how you fair, the config file would suggest that
it isn't specifically attached to one repository but you could also try
`git remote show` (I think?)
- Lee
2009/4/23 chris
Thanks for the help. I will give this a go when I get home this
evening.
On Apr 23, 8:28 am, Lee Hambley lee.hamb...@gmail.com wrote:
Chris,
I'd honestly just try erasing the cache on the server, and taking the hit of
1 slow(er) deploy and see how you fair, the config file would suggest that
I have removed the cached-copy dir and tried to deploy again. I am
now getting the following:
[li33-xx.members.linode.com] executing command
[li33-xx.members.linode.com :: out] ERROR: Permission to NEW_NAME/
my_app denied to OLD_NAME/my_app.
[li33-xx.members.linode.com :: out] fatal:
11 matches
Mail list logo
