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" ...
^
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
I'm running a flutter desktop app on linux and i need get the response from the following curl request
curl -sS --unix-socket /run/snapd.socket http://localhost/v2/snaps/ -X GET
I've got the process_run package installed so making the call is fairly straightfoward, i just dont know how to get the response from the call in to my dart code.
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 and perhaps more simple problem to solve: proxy authentication by MSCHAPv2)
Summary: I am using a Ubuntu 18, the proxy is working with web-browser but not with terminal applications (wget, curl or apt update). Any clues? Seems the problem is to interpretate a proxy's "PAC file"... Is it? How to translate to Linux's proxy variables? ... Or the problem is simple: my proxy-config (see step-by-step procedure below) was wrong?
Details:
By terminal env | grep -i proxy we obtain
https_proxy=http://user:pass#pac._ProxyDomain_/proxy.pac:8080
http_proxy=http://user:pass#pac._ProxyDomain_/proxy.pac:8080
no_proxy=localhost,127.0.0.0/8,::1
NO_PROXY=localhost,127.0.0.0/8,::1
ftp_proxy=http://user:pass#pac._ProxyDomain_/proxy.pac:8080
and browser (Firefox) is working fine for any URL, but:
wget http://google.com say Resolving pac._ProxyDomain_ (pac._ProxyDomain_)... etc.etc.0.26 connecting to pac._ProxyDomain_ (pac._ProxyDomain_)|etc.etc.0.26|:80... conected.
Proxy request has been sent, waiting for response ... 403 Forbidden
2019-07-25 12:52:19 ERROR 403: Forbidden.
curl http://google.com say "curl: (5) Could not resolve proxy: pac._ProxyDomain_/proxy.pac"
Notes
(recent news here: purge exported proxy changes something and not tested all again...)
The proxy configuration procedures that I used (there are some plug-and-play PAC file generator? I need a PAC file?)
Config procedures used
All machine was running, with a direct non-proxy internet connection... Them the machine goes to the LAN with the proxy.
Add lines of "export *_proxy" (http, https and ftp) in my ~/.profile. The URL definitions are in the form http_proxy="http://user:pwd#etc" (supposing that is correct, because testesd before with user:pwd#http://pac.domain/proxy.pac syntax and Firefox promped proxy-login)(if the current proxy-password is using # character, need to change?)
Add lines of "export *_proxy" in my ~root/.profile.(need it?)
(can reboot and test with echo $http_proxy)
visudo procedure described here
reboot and navigate by Firefox without need of login, direct (good is working!). Testing env | grep -i proxy, it shows all correct values as expected.
Testing wget and curl as the begin of this report, proxy bug.
Testing sudo apt update, bug.
... after it more one step, supponing that for apt not exist a file, created by sudo nano /etc/apt/apt.conf.d/80proxy and add 3 lines for Acquire::*::proxy "value"; with value http://user:pass#pac._ProxyDomain_/proxy.pac:8080. where pass is etc%23etc, url-encoded.
Summary of tests performed
CONTEXT-1.1
(this was a problem but now ignoring it to focus on more relevant one)
After (the proxied) cable connection and proxy configurations in the system. (see above section "Config procedures used"). Proxy-password with special character.
curl http://google.com say "curl: (5) Could not resolve proxy..."
When change all .profile from %23 to # the error on wget changes, but curl not. Wget changes to "Error parsing proxy URL http://user:pass#pac._ProxyDomain_/proxy.pac:8080: Bad port number"
PS: when used $ on password the system (something in the internal export http_proxy command or use of http_proxy confused it with a variable).
CONTEXT-1.2
Same as context-1.1 above, but password with no special character. Good and clean proxy-password.
curl http://google.com say "curl: (5) Could not resolve proxy..."
CONTEXT-2
After (the proxied) cable connection and no proxy configurations in the system (but confirmed that connection is working on browser after automatic popup form login).
curl -x 192.168.0.1:8080 http://google.com "curl: (7) Failed to connect..."
curl --verbose -x "http://user:pass#pac._proxyDomain_/proxy.pac" http://google.com say "curl: (5) Could not resolve proxy..."
Other configs in use
As #Roadowl suggested to check:
files ~/.netrc and ~root/.netrc not exists
file more /etc/wgetrc exists, but all commented, exept by passive_ftp = on
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).