I am using DMS to migrate date from MySQL to Redshift. I need to add new task,but it does not run because endpoint connection test fails, but I use already working endpoint. Although task with this endpoint is running without error, test is failing with this strange error
Test Endpoint failed: Application-Status: 1020912, Application-Message: Failed in prepare imp for Redshift Base general error.
Restarting DMS instance fixed the issue.
I have wildfly 10 and installed APIMAN 1.5.1.APIMAN. Organization/API creation is done and while publishing the API, I'm getting below error
io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed to publish API.
I too had this issue, in my case problem was with the ElasticSearch.
apiman.es.host defined in standalone/configuration/apiman.properties was not working.
Check host and port that are mentioned are open/working.
I am trying to deploy a simple web application written using Play Framework in Scala to Amazon web service.
The web application is running OK in development mode and production mode in my local machine, and I've changed its default port to 80.
I used Boxfuse to deploy to AWS as suggested.
I first run "sbt dist"
then "boxfuse run -env=prod"
Things went well as desired. The image is fused and pushed to AWS. AMI is created. Instance was started and my application was running.
i-0f696ff22df4a2b71 => 2017-07-13 01:28:23.940 [info] play.api.Play - Application started (Prod)
Then came the error message:
WARNING: Healthcheck (http://35.156.38.90/) returned 400 instead of 200. Retrying for the next 300 seconds ...
i-0f696ff22df4a2b71 => 2017-07-13 01:28:24.977 [info] p.c.s.AkkaHttpServer - Listening for HTTP on /0.0.0.0:80
i-0f696ff22df4a2b71 => 2017-07-13 01:28:25.512 [warn] p.f.h.AllowedHostsFilter - Host not allowed: 35.156.38.90
The instance was terminated after repeated try after 3 minutes. It gave a warning like:
Ensure your application responds with an HTTP 200 at / on port 80
But I've made sure the application responds in local machine, and I tried both Windows and Ubuntu, all works well.
Also, running "boxfuse run" on local machine, I can connect to it using "http://localhost", but still have the error.
Hope someone with experience can give me some suggestions. Thanks in advance.
ps: not sure if relevant, I added these settings to application.conf
http {
address = 0.0.0.0
port = 80
}
Judging from the error message, it looks like the problem might be related to play.filters.hosts.allowed not set up in application.conf. The filter lets you configure which hosts can access your application. More details about the Play filter is available here.
Here's a configuration example:
play.filters.hosts {
allowed = ["."]
}
Note that allowed = ["."] matches all hosts hence would not be recommended in a production environment.
As stated in the Boxfuse Play Documentation:
If your application uses the allowed hosts filter you must ensure play.filters.hosts.allowed in application.conf allows connections from anywhere as this filter otherwise causes ELB healthchecks to fail. For example:
play.filters.hosts {
allowed = ["."]
}
More info in the official Play documentation.
I have fabric composer 0.72 installed on my mac, and I was able to follow this thread to get it connected to my Blockchain (v.61 of Fabric) on Bluemix.
fabric-composer-integration-with-bluemix-blockchain-service
Now I am trying to build an ubuntu (16.04) docker container and run composer-rest-server there. When I try to connect to my blockchain service from my docker container (using the same id, WebAppAdmin, that I used on my mac) I get an error:
Discovering types from business network definition ...
Connection fails: Error: Identity or token does not match.
It will be retried for the next request.
{ Error: Identity or token does not match.
at /home/composer/.nvm/versions/node/v6.10.3/lib/node_modules /composer-rest-server/node_modules/grpc/src/node/src/client.js:417:17 code: 2, metadata: Metadata { _internal_repr: {} } }
I tried copying the cert from my mac to my docker container:
/home/composer/.composer-credentials/member.WebAppAdmin
but when I did that I got a different error that says "signature does not verify". I did some additional testing, and I discovered that if I used an id that I had not previously used with composer (i.e. user_type1_0) then I could connect, and I could see a new cert in my .composer-credentials directory.
I tried deleting that container and building a new one (I dorked something else up) I could not use that same userid again.
Does anybody know how security and these certs are supposed to work? It would seem as though something to do with certificate generation/validation is tied to the client (i.e. hardware address), such that if I try to re-use an id on a different machine, the certs or keys or something don't match. I have a way to make things work, but it doesn't seem like it's the right way if I can't use the same id from different machines.
Thanks!
Hi i tried to recreate this by having blockchain running on a unix machine and then i copied my connection profile and certificate to my mac and then edited my connection profile to update the ip address and key store. I then did a composer network ping and it worked fine.
I am using composer v0.7.4 so you could try that?
I have also faced this issue, and concluded that
There is inconsistent behavior while deploying network using composer on Cloud environment includeing Bluemix. Problem is not with composer, but with fabric 0.6.
I am assuming that this issue is also indirectly related to following known bugs into fabric 0.6, which will not be fixed in fabric 0.6.
ERROR:
"
throw er; // Unhandled 'error' event
^
Error
at ClientDuplexStream._emitStatusIfDone (/home/ubuntu/.nvm/versions/node/v6.9.5/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:189:19)
at ClientDuplexStream._readsDone (/home/ubuntu/.nvm/versions/node/v6.9.5/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:158:8)
at readCallback (/home/ubuntu/.nvm/versions/node/v6.9.5/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:217:12)
"
So far, We have understood that following three JIRA are root cause , where essentially the cloud networking layer ends up killing the idle event hub connection after a period of inactivity and the fabric SDK cannot handle this.
https://jira.hyperledger.org/browse/FAB-4002 FAB-3310
https://jira.hyperledger.org/browse/FAB-3310
or FAB-2787
Conclusion:
There is no alternative way of fixing this issue with Bluemix or any cloud environment with fabric 0.6
You may not experience this issue with Fabric 1.0, but there is still possibilities as all above mentioned defects are not fixed yet.
I am trying to configure ejabberd on DIY cartridge on openshift, following the guide here:
Erlang and Ejabberd on OpenShift
I followed everything successsfully up to here:
Next you can start ejabberd running the following 2 commands, which you’ll want to put in your .openshift/action_hooks/start script
there is no error and ejabberd seems to be started, but the next command:
$OPENSHIFT_DATA_DIR/erl_home/sbin/ejabberdctl register admin localhost password1234
failed with this error:
Failed RPC connection to the node ‘ejabberd#127.7.131.1′: {‘EXIT’, {badarg, [{ets,lookup, [local_config, ejabberdctl_access_commands], []}, {ejabberd_config, get_local_option, 1, [{file, "ejabberd_config.erl"}, {line,590}]}, {ejabberd_ctl, get_accesscommands, 0, [{file, "ejabberd_ctl.erl"}, {line,236}]}, {ejabberd_ctl, process,1, [{file, "ejabberd_ctl.erl"}, {line,199}]}, {rpc, ‘-handle_call_call/6-fun-0-’, 5, [{file, "rpc.erl"}, {line,205}]}]}}
Commands to start an ejabberd node: start Start an ejabberd node in server mode debug Attach an interactive Erlang shell to a running ejabberd node live Start an ejabberd node in live (interactive) mode
Optional parameters when starting an ejabberd node: –config-dir dir Config ejabberd: /var/lib/openshift/52c9674d5973ca7734000180/app-root/data//erl_home/etc/ejabberd –config file Config ejabberd: /var/lib/openshift/52c9674d5973ca7734000180/app-root/data//erl_home/etc/ejabberd/ejabberd.cfg –ctl-config file Config ejabberdctl: /var/lib/openshift/52c9674d5973ca7734000180/app-root/data//erl_home/etc/ejabberd/ejabberdctl.cfg –logs dir Directory for logs: /var/lib/openshift/52c9674d5973ca7734000180/app-root/data//erl_home/var/log/ejabberd –spool dir Database spool dir: /var/lib/openshift/52c9674d5973ca7734000180/app-root/data//erl_home/var/lib/ejabberd –node nodename ejabberd node name: ejabberd#127.7.131.1
I am not sure what causes the error... it seems like it is trying to connect to localhost (due to the nodename: ejabberd#127.7.131.1). However, I have sed every localhost smell from the previous commands on the blog.
Anybody ever encounter this before? Any clue on how to debug is also highly appreciated, as I am not very familiar with openshift or ejabberd as well as linux... Thank you very much in advance!
I wrote the blog post, and saw this error on a new DIY Application I created. It was due to a bug with erlang and the openssl package in the openshift box. I put in a patch in the erlang source so that new compilations will work.
The bug that was causing the issue was here: https://bugzilla.redhat.com/show_bug.cgi?id=1023017
You'll need to run using your host instead of localhost.
$OPENSHIFT_DATA_DIR/erl_home/sbin/ejabberdctl register admin <replacewithyourhost> password1234
For that
OPENSHIFT_DATA_DIR/erl_home/sbin/ejabberdctl register admin $OPENSHIFT_DIY_IP password1234
However it returns error as well:
{error_logger,{{2014,1,13},{21,11,24}},"Protocol: ~tp: register/listen error: ~tp~n",["inet_tcp",econnrefused]} {error
above
You need to kill all the ejabberd process including epmd.
I had this problem one time, My solution was to edit /etc/hosts(for windows- C:\Windows\System32\drivers\etc\hosts) file and make sure that there was a hostname entry for my public ip address and the domain I wanted ejabber to respond to.
0.0.0.0 hostname.domain.com hostname
1.1.1.1(your ip) your-hostname.your-domain your-hostname