I've setup local/remote CouchDB servers and I'd like to replicate between them.
Curling on each works fine so I know both databases are running ok:
curl -u admin:password https://remote.host.net/db_name - works
curl -u admin:password http://localhost:5984/db_name - works
However, when I try and setup replication it borks. This is the command used to setup the replication:
curl -u admin:password -X POST http://localhost:5984/_replicate -d '{"source":"https://admin:password#remote.host.net/db_name", "target":"http://admin:password#localhost:5984/db_name"}' -H "Content-Type: application/json"
Error message:
{"error":"replication_auth_error","reason":"{session_request_failed,\"https://remote.host.net/_session\",\n\"admin\",\n{conn_failed,{error,nxdomain}}}"}
Anyone have any ideas what's going wrong here?
I faced the same problem and adding "continuous": true to the request body, returns with a "ok":true.
From the docs, continuous should be used only when you want the replication to be triggered always the source changes, I don't know why the error when it is not included.
[edit]
Even with the success response, the data is not been copied. So we use this script to achieve the replication https://gist.github.com/Aybee5/fba07b06b94442a529ebae5465b77737
Yup.. I know its been almost a year since I posted the original question but I just ran into a similar issue and solved it by using the source_proxy/target_proxy kwargs in the replication request.
I can't remember if I was behind a proxy last time unfortunately.
Related
I want to get data from ServiceNow via a CURL in Putty via a Proxyserver (Plan is to implement it to a PySpark script later on) and then save the data onto the server.
My Command looks like this:
curl -x <proxyadress:port> -U proxyuser:proxypassword -u '<apiuser:apipassword>' -d status="message" "https:/apiadress" -H 'Accept: application/json'
I get the error message:
{"error":{"message":"Invalid content-type. Supported request media types for this service are: [application/json, application/xml, text/xml]","detail":null},"status":"failure"}
A few days ago I was able to have the data printed into the log but didn't manage to replicate the command ... what's wrong?
Thanks for your help
Following is the curl export of the API call which is failing -
curl -X GET \
'http://endpoint.in/dummy/path?mobile=777777777' \
-H 'Content-Type: application/json' \
-H 'auth_token: iubsaicbsaicbasiucbsa'
The header param auth_token is not available at all in the server side, as checked from logs.
The same curl however works when directly issued as a command. I have the latest postman version v6.2.3 installed.
Also, the same API end point works when requested via other tools like Advanced REST client of chrome.
Previously, I had also checked read this thread http://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers
Many servers, like nginx, have a config which if set, discards headers with underscore in name.
However, I could not verify the same because I could not find out exactly how is the server deployed in this. It is a node application and we run this command to run the application -
nohup /bin/forever start -o logs/out.log -e logs/err.log app.js
ps -ef | grep node shows the following -
root 5981 1 0 Jul19 ? 00:00:00 /root/.nvm/v7.2.1/bin/node /usr/lib/node_modules/forever/bin/monitor app.js
root 5991 5981 0 Jul19 ? 00:00:04 /root/.nvm/v7.2.1/bin/node /usr/local/another/path/to/app.js
Update
This is interfering in our automated testing as well, via Jmeter.
Update
We have nginx running on the server and it seems to be calling node process. We observed that on the server where this is working fine, the nginx config file has this setting -
underscores_in_headers on;
But this is not present in the config file of the server where it is not working.
Another observation - I am using latest postman version - 6.2.5, where the issue is there. However, when I sent the same postman collection to another teammate and he hit it after installing postman, it worked for him. I am still not sure whether the issue is with postman or the server setup.
Underscores are not explicitly forbidden in headers, but in the past for CGI underscores were converted to dashes. Because of this legacy NGINX and Apache HTTPD treat underscores in headers as potentially problematic.
https://stackoverflow.com/a/22856867/2955337
You can explicitly set underscores_in_headers on;, but the default is off, so by default NGINX does not accept underscores
http://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers
curl apparently converts underscores to dashes to circumvent this issue.
https://github.com/requests/requests/issues/1292#issuecomment-15997612
Inside a Dockerfile I try to download an artifact using curl. I have checked that although the artifact doesn't exist (thus getting a 404) the docker build keeps running.
RUN curl -H 'Cache-Control: no-cache' ${STANDALONE_LOCATION} -o $JBOSS_HOME/standalone/configuration/standalone.xml
Is there a way to check that the curl response code is 200 and throw an error otherwise?
You can add -f (or --fail) to the curl call, which causes curl to silently fail on server errors. From the curl manpage:
-f/--fail
(HTTP) Fail silently (no output at all) on server errors. This is mostly done to better enable scripts etc to better deal with failed attempts. In normal cases when a HTTP server fails to deliver a document, it returns an HTML document stating so (which often also describes why and more). This flag will prevent curl from outputting that and return error 22.
This method is not fail-safe and there are occasions where non-successful response codes will slip through, especially when authentication is involved (response codes 401 and 407).
I am running a node.js app on Bluemix which basically is a REST API for read/write operations on a Cloudant (CouchDb) database.
Incoming requests are authenticated by an injected passport-http-bearer strategy middleware into the express framework. My app uses the bearer token to receive information about the user.
This is not very performant at the moment (we are working on a caching mechanism), but in general it works. When I send much requests in parallel (e.g. in function tests), sometimes I receive the 502 Bad Gateway response instead of the expected results, which fails nearly every test suite run. On my local deployment it works without problems.
Maybe you have a scaling issue? When you say many parallel requests - is it possible that the service reply times go beyond that what router expects (120 seconds I think) with many requests?
Can you try to push your app a little harder with Apache Bench maybe?
ab -n 10000 -c 100 -s 120 -H "Authorization: Bearer <token>" https://your-app/
And then in parallel check responses with something like:
#!/bin/bash
BEARER=<your-token>
URL=<your-app>
TIMEFORMAT="TIME: %E"
while true; do R=$(time echo -e REQUEST: $(date)\\nREPLY: $(curl -X GET -s --insecure --header "Accept: application/json" --header "Authorization: Bearer $BEARER" "https://$URL") 2>>trace); echo "$R" >>trace; echo $R|grep -q "502" && echo -e "Found 502 reply\n$R"; done
HP
#Jeff-Sloyer is correct in suggesting retry logic in your push script. Additionally, you should check the status of the runtime and any services being used on the Bluemix status page. For more information on why you may be receiving this error, please see the information noted below:
https://www.ng.bluemix.net/docs/troubleshoot/managingapps.html
I have seen this with unreliable networking. I would use some retry login for your push script to guarantee a deploy.
I've recently started playing with CouchDB and just into some small issues.
I am trying to replicate data from a aremote server to my remote computer using
the following command:
curl -X POST -d '{"source":"http://xxx.xxx.xx.xxx:5984/testing_replicate","target":"http://localhost:5984:testing_replicate"}' http://localhost:5984/_replicate
Somehow there is no response from this command.
Doing curl -X GET http://localhost:5984/
and
curl -X GET http://xxx.xxx.xx.xxx:5984/
returns the expected response : {"couchdb":"Welcome","version":"0.10.0"}
can anyone enlighten me?
Best Regards.
There's a goof in your target URL. Change:
... "target":"http://localhost:5984:testing_replicate" ...
^
to
... "target":"http://localhost:5984/testing_replicate" ...
^