Cloudfoundry: How to migrate mongodb data to version 2.0 - migration

I am currently migrating my cloudfoundry app from the soon deprecated version 1.0 of cloudfoundry to version 2.0.
From the command line output it seems the deployment is working fine.
However, I also need to migrate my current mongodb database content.
I successfully dumped my current data using vmc tunnel mongodump, however, I'm not able to restore the data to the new database.
When I enter on the commandline
cf tunnel mongolab-xxxMyAmazingApp mongorestore
I got an error message telling me
Opening tunnel on port 10000... FAILED
CFoundry::NotStaged: 170002: App has not finished staging
For more information, see ~/.cf/crash
The crash file contains among others these lines
RESPONSE: [400]
RESPONSE_HEADERS:
connection : keep-alive
content-length : 61
content-type : application/json;charset=utf-8
date : Fri, 28 Jun 2013 15:27:56 GMT
server : nginx
x-content-type-options : nosniff
x-vcap-request-id : fad06d99-6fe0-4544-b1d1-eff53cea3ddd
RESPONSE_BODY:
{
"description": "App has not finished staging",
"code": 170002
}
>>>
cfoundry-2.1.0/lib/cfoundry/baseclient.rb:160:in `handle_error_response'
cfoundry-2.1.0/lib/cfoundry/baseclient.rb:139:in `handle_response'
cfoundry-2.1.0/lib/cfoundry/baseclient.rb:87:in `request'
cfoundry-2.1.0/lib/cfoundry/baseclient.rb:64:in `get'
cfoundry-2.1.0/lib/cfoundry/v2/base.rb:53:in `instances'
cfoundry-2.1.0/lib/cfoundry/v2/app.rb:55:in `instances'
cfoundry-2.1.0/lib/cfoundry/v2/app.rb:201:in `running_instances'
cfoundry-2.1.0/lib/cfoundry/v2/app.rb:176:in `health'
cfoundry-2.1.0/lib/cfoundry/v2/app.rb:212:in `healthy?'
cf-2.1.0/lib/tunnel/tunnel.rb:97:in `helper_healthy?'
cf-2.1.0/lib/tunnel/tunnel.rb:25:in `open!'
cf-2.1.0/lib/tunnel/plugin.rb:41:in `tunnel'
interact-0.5.1/lib/interact/progress.rb:98:in `with_progress'
cf-2.1.0/lib/tunnel/plugin.rb:40:in `tunnel'
mothership-0.5.1/lib/mothership/base.rb:66:in `send'
mothership-0.5.1/lib/mothership/base.rb:66:in `run'
mothership-0.5.1/lib/mothership/command.rb:72:in `invoke'
mothership-0.5.1/lib/mothership/command.rb:86:in `instance_exec'
mothership-0.5.1/lib/mothership/command.rb:86:in `invoke'
mothership-0.5.1/lib/mothership/base.rb:55:in `execute'
cf-2.1.0/lib/cf/cli.rb:156:in `execute'
cf-2.1.0/lib/cf/cli.rb:167:in `save_token_if_it_changes'
cf-2.1.0/lib/cf/cli.rb:155:in `execute'
cf-2.1.0/lib/cf/cli.rb:101:in `wrap_errors'
cf-2.1.0/lib/cf/cli.rb:151:in `execute'
mothership-0.5.1/lib/mothership.rb:45:in `start'
cf-2.1.0/bin/cf:13
/usr/bin/cf:23:in `load'
/usr/bin/cf:23
So what should I do to solve this problem?

Check this link:
http://support.cloudfoundry.com/entries/24464207-Problem-creating-a-tunnel-to-elephantsql
Hi, as services are now provisioned outside of Cloud Foundry via third party vendors, it is not necessary to use a tunnel to connect to it. To get the connection details for your service, log in to https://console.run.pivotal.io and navigating and find the provisioned in the associated space. Clicking the "manage" button next to the relevant service will take you the providers homepage where you should be able to obtain connection details.
For mongo services is the same. From https://mongolab.com/home you have access to your mongo services.

Related

KotlinJS Ktor server "Connection closed without response" when deployed to Heroku

I'm new to kotlin and having some trouble running my Ktor server on heroku
I'm setting up the server as follows:
val port = System.getenv("PORT")?.toInt() ?: 9090
embeddedServer(Netty, port = port) {
routing {
get("/") {
call.respondText(
this::class.java.classLoader.getResource("index.html")!!.readText(),
ContentType.Text.Html
)
}
static("/static") {
resources("")
}
}
}.start(wait = true)
When running on my localhost, this responds just fine. And when running in heroku, I get the log output that tells me it did start up the server on the port heroku defines:
[main] INFO ktor.application - Responding at http://0.0.0.0:55278
But then when I try to load the heroku app from the browser, I get an error, and the heroku logs say: "Connection closed without response"
heroku[router]: at=error code=H13 desc="Connection closed without response" method=GET path="/" host=melomidi.herokuapp.com request_id=e0cdaa83-eaa4-4733-a51f-947de463c433 fwd="174.246.82.169" dyno=web.1 connect=0ms service=13ms status=503 bytes=0 protocol=http
I have tried with both http and https. I have also tried loading /static/index.html directly and got the same result.
I've also tried adding a SERVER_HOST env var and using that to change the default 0.0.0.0 host to various things, like localhost, 127.0.0.1 and melomidi.herokuapp.com but those resulted in other errors where the server failed to start up.
There are no other details or additional logs being output in the heroku logs when I make the request. Just the one error line per request as displayed above.
Anyone have any suggestions? Thanks in advance!
After shuffling the order of operations around so that my static resources declaration came first, I started seeing the following error in the logs:
2022-01-08T00:19:36.616138+00:00 app[web.1]: Caused by: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
2022-01-08T00:19:36.616138+00:00 app[web.1]: at io.ktor.utils.io.jvm.javaio.ReadingKt$toByteReadChannel$1.invokeSuspend(Reading.kt:53)
2022-01-08T00:19:36.616138+00:00 app[web.1]: at io.ktor.utils.io.jvm.javaio.ReadingKt$toByteReadChannel$1.invoke(Reading.kt)
2022-01-08T00:19:36.616139+00:00 app[web.1]: at io.ktor.utils.io.jvm.javaio.ReadingKt$toByteReadChannel$1.invoke(Reading.kt)
2022-01-08T00:19:36.616139+00:00 app[web.1]: at io.ktor.utils.io.CoroutinesKt$launchChannel$job$1.invokeSuspend(Coroutines.kt:132)
2022-01-08T00:19:36.616139+00:00 app[web.1]: at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
2022-01-08T00:19:36.616139+00:00 app[web.1]: at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
2022-01-08T00:19:36.616139+00:00 app[web.1]: at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
2022-01-08T00:19:36.616140+00:00 app[web.1]: at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
2022-01-08T00:19:36.616140+00:00 app[web.1]: at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
2022-01-08T00:19:36.616140+00:00 app[web.1]: at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
That got me to this post:https://youtrack.jetbrains.com/issue/KTOR-3358 where I found there is a binary compatibility issue with Ktor server 1.6.5 and jdk 1.8
I updated my jvmTarget to 11 and now it's up and running!
Strange that I only encountered the issue on heroku though when both my localhost and heroku were each using jdk 1.8 previously.

Watir-webdriver can't access 127.0.0.1

I receive a "Gateway Timeout" error when running the following ruby code using watir-webdriver.
require 'watir-webdriver'
browser = Watir::Browser.new :ff
The error states:
Server error - server 127.0.0.1 is unreachable at this moment.Please retry the request or contact your adminstrator.
I have a feeling the company proxy is interfering with Watir. Maybe Firefox is trying to connect to Watir running locally on some non-standard port, and the proxy intervenes and can't resolve the address 127.0.0.1. That's just a guess.
Anyone have experience with this error or suggestions for getting watir-webdriver working. Has anyone successfully run watir-webdriver behind a proxy?
Here is the error with stack trace:
504 Gateway Timeout
Gateway Timeout Server error - server 127.0.0.1 is
unreachable at this moment.Please retry the request or contact
your admins trator.
(Selenium::WebDriver::Error::WebDriverError)
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/remote/http/common.rb:66:in
create
_response' C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/remote/http/default.rb:66:in
reque st'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/remote/http/common.rb:40:in
call'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/remote/bridge.rb:640:in
raw_execut e'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/remote/bridge.rb:101:in
create_ses sion'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/remote/bridge.rb:68:in
initialize'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/bridge.rb:36:in
initialize '
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:in
new'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:in
for'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver.rb:67:in
for'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/watir-webdriver-0.6.11/lib/watir-webdriver/browser.rb:46:in initialize' c:/dev/pxmapper/features/support/env.rb:11:innew'
c:/dev/pxmapper/features/support/env.rb:11:in <top (required)>'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/rb_support/rb_language.rb:95:in
load'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/rb_support/rb_language.rb:95:in
load_code_file'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:180:inload_file'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:83:in
block in load_files!'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:82:in
each'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:82:in
load_files!'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:184:in
load_step_definitions'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:42:in
run!'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/lib/cucumber/cli/main.rb:47:in
execute!'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/cucumber-1.3.18/bin/cucumber:13:in
<top (required)>' C:/Ruby193/bin/cucumber:23:inload'
C:/Ruby193/bin/cucumber:23:in `'

Unable to access AWS endpoints

I am using following CURL command to access AWS api's via deltacloud:
curl --user "accesskey:secretaccesskey" -H "X-Deltacloud-Driver:ec2" -H "X-Deltacloud-Provider:us-east-1" "http://IPofdeltacloud.com:3001/api/images?format=xml"
But I am getting following error again and again:
Aws::AwsError:RequestExpired: Request has expired. Timestamp date is 2013-11-21T12:57:45.000Z
REQUEST=ec2.us-east-1.amazonaws.com:443/?AWSAccessKeyId=AKIAIQUAMKYUKBM2RDMA&Action=DescribeImages&Filter.1.Name=image-type&Filter.1.Value.1=machine&Owner.1=amazon&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-11-21T12%3A57%3A45.000Z&Version=2010-08-31&Signature=OfCOFQKH0lBMbHA4pofIBekmRfXEysAI%2F5c8YIjugUM%3D
REQUEST ID=62efe75b-dbad-4a3c-bb0f-d49eaced2d78
/usr/local/lib/ruby/gems/1.9.1/gems/aws-2.5.6/lib/awsbase/awsbase.rb:579:in `request_info_impl'
/usr/local/lib/ruby/gems/1.9.1/gems/aws-2.5.6/lib/ec2/ec2.rb:179:in `request_info'
/usr/local/lib/ruby/gems/1.9.1/gems/aws-2.5.6/lib/awsbase/awsbase.rb:593:in `request_cache_or_info'
/usr/local/lib/ruby/gems/1.9.1/gems/aws-2.5.6/lib/ec2/ec2.rb:207:in `ec2_describe_images'
/usr/local/lib/ruby/gems/1.9.1/gems/aws-2.5.6/lib/ec2/ec2.rb:252:in `describe_images_by_owner'
/root/testgit/deltacloud/server/lib/deltacloud/drivers/ec2/ec2_driver.rb:155:in `block in images'
/root/testgit/deltacloud/server/lib/deltacloud/drivers/exceptions.rb:173:in `call'
/root/testgit/deltacloud/server/lib/deltacloud/drivers/exceptions.rb:173:in `safely'
/root/testgit/deltacloud/server/lib/deltacloud/drivers/ec2/ec2_driver.rb:154:in `images'
/root/testgit/deltacloud/server/lib/deltacloud/helpers/deltacloud_helper.rb:58:in `block in filter_all'
/usr/local/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
Can anyone suggest me what wrong is happening?
You have a time skew on your server, and AWS checks the timestamp of the request in order to prevent replay attacks.
You have to set the correct time on your server. If you're running ubuntu, you can use the following bash command:
ntpdate ntp.ubuntu.com

Getting Faraday::Error::ConnectionFailed when connecting from heroku rails app

My company has a simple oauth server at https://auth.vitalvu.com
I'm developing a rails app that needs to make requests to that server (via the omniauth-oauth2 gem). When I try to run the app on Heroku I get the error:
Faraday::Error::ConnectionFailed: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
I've tested it as described here.
From the app's rails console on my local machine
connection = Faraday::Connection.new 'https://auth.vitalvu.com'
connection.get '/ping.json'
works just fine.
However, after pushing the app to Heroku, heroku run rails console
connection = Faraday::Connection.new 'https://auth.vitalvu.com'
connection.get '/ping.json'
results in the faraday error and
connection = Faraday::Connection.new 'https://auth.vitalvu.com', :ssl => {:ca_file => '/usr/lib/ssl/certs/ca-certificates.crt'}
connection.get '/ping.json'
results in the faraday error and
connection = Faraday::Connection.new 'https://auth.vitalvu.com', :ssl => {:ca_path => "/etc/ssl/certs"}
connection.get '/ping.json'
results in the faraday error
I'm not sure what else to try. Suggestions?
I run heroku restart three times - and than finally is starts to work.

Akephalos: How to ignore SSL warnings?

I'm trying to set up Akephalos for use with Capybara. I ran into this
message when trying to visit the page I am trying to test:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated (NativeException)
(druby://127.0.0.1:35580) org/jruby/RubyKernel.java:2042:in `send'
(druby://127.0.0.1:35580) org/jruby/RubyKernel.java:1417:in `loop'
(druby://127.0.0.1:35580) org/jruby/RubyProc.java:268:in `call'
(druby://127.0.0.1:35580) org/jruby/RubyProc.java:232:in `call'
I wonder if it has anything to do with the fact that we are using a
self-signed certificate. This is what my env.rb file looks like:
# Capybara configuration (using Akephalos)
require 'capybara'
require 'capybara/dsl'
require 'capybara/cucumber'
require 'akephalos'
Capybara.javascript_driver = :akephalos
Capybara.default_driver = :akephalos
Capybara.register_driver :akephalos do |app|
# available options:
# :ie6, :ie7, :ie8, :firefox_3, :firefox_3_6
Capybara::Driver::Akephalos.new(app, :browser => :firefox_3_6)
end
World(Capybara)
Yes, if the server is using a self-signed certificate, this can cause a warning/error such as 'peer not authenticated'.
The proper way around this problem is to specifically add the self-signed certificate to the trusted root store.
The wrong way around this problem is to turn off certificate verification.
I don't know the product you are using well enough to tell you how to do either of these things.