I'm trying to set up a 'Swift All In One' system on a Ubuntu 12.04 VM by the link:http://docs.openstack.org/developer/swift/development_saio.html.
I use VMware WorkStation 12 Pro on Win7 64bit system and use 'Host-only' network mode.The VM ip address is "192.168.137.200".
When I run the command on the VM:
curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://192.168.137.200/auth/v1.0
It works well.
But when I run the command on the host machine(Win7 platform), It fails and returns:
* Could not resolve host: test:tester'; Host not found
* Closing connection #0
curl: (6) Could not resolve host: test:tester'; Host not found
* Could not resolve host: testing'; Host not found
* Closing connection #0
curl: (6) Could not resolve host: testing'; Host not found
* About to connect() to 192.168.137.200 port 80 (#0)
* Trying 192.168.137.200... connected
* Connected to 192.168.137.200 (192.168.137.200) port 80 (#0)
> GET /auth/v1.0 HTTP/1.1
> User-Agent: curl/7.20.1 (amd64-pc-win32) libcurl/7.20.1 OpenSSL/0.9.8n zlib/1.
2.3
> Host: 192.168.137.200
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Date: Fri, 25 Mar 2016 05:57:24 GMT
< Content-Length: 131
< Content-Type: text/html; charset=UTF-8
< Www-Authenticate: Swift realm="unknown"
< X-Trans-Id: tx081d67bec35b457bb4cb8-0056f4d343
< Vary: Accept-Encoding
<
<html><h1>Unauthorized</h1><p>This server could not verify that you are authoriz
ed to access the document you requested.</p></html>* Connection #0 to host 192.1
68.137.200 left intact
* Closing connection #0
Then I make another Ubuntu 12.04 VM and try to run the command above on the second VM, it works well.
Try to use X-Auth-User and X-Auth-Key headers instead.https://swiftstack.com/docs/cookbooks/swift_usage/auth.html
Related
Using HAProxy 1.8, I want to slow down certain traffic. This all works when testing over HTTP 1.1. However as soon as http/2 (h2) is enabled in HAProxy, the 10s delay is no longer taking effect. How can I delay h2 requests?
frontend web
bind [...] alpn h2,http/1.1
tcp-request inspect-delay 10s
tcp-request content accept if WAIT_END
[...]
I'm testing using curl:
time curl -I 'https://[url]/' -v
* Trying 10.233.1.97...
* TCP_NODELAY set
* Connected to [url] (10.233.1.97) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
[...]
* ALPN, server accepted to use h2
[...]
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fd3f5808200)
> GET / HTTP/2
> Host: [...]
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 411
HTTP/2 411
< content-type: text/html; charset=us-ascii
content-type: text/html; charset=us-ascii
< server: Microsoft-HTTPAPI/2.0
server: Microsoft-HTTPAPI/2.0
< date: Thu, 02 Apr 2020 19:18:22 GMT
date: Thu, 02 Apr 2020 19:18:22 GMT
< content-length: 344
content-length: 344
<
* Excess found in a non pipelined read: excess = 344 url = / (zero-length body)
* Connection #0 to host app.cloudbilling.nl left intact
* Closing connection 0
curl -I 'https://[url]/' -v 0.02s user 0.01s system 28% cpu 0.101 total
localhost to view pacts
I have installed brew version of postgres and docker.
Followed the steps in the link https://github.com/DiUS/pact_broker-docker/blob/master/POSTGRESQL.md to create a dockerised pact broker and postgres.
When I run the first command, container got created with error:
docker run --name pactbroker-db -e POSTGRES_PASSWORD=ThePostgresPassword -e POSTGRES_USER=admin -e PGDATA=/var/lib/postgresql/data/pgdata -v /var/lib/postgresql/data:/var/lib/postgresql/data -d postgres
Response:
b8a2007e5dac9554e0ac615147d74467ceb6043dba027a4a21388721cee8f34c
docker: Error response from daemon: Mounts denied:
The path /var/lib/postgresql/data
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing...
Somehow managed to bypass the first step by removing the bind volume option:
docker run --name pactbroker-db -e POSTGRES_PASSWORD=ThePostgresPassword -e POSTGRES_USER=admin -e PGDATA=/var/lib/postgresql/data/pgdata -d postgres
Succeeded 2 and 3 steps in the link specified:
(2)Connect to the container and execute psql via:
(3)Start the PactBroker container via:
After this, tried to curl json using the below command:
curl -v -XPUT -H “Content-Type: application/json” -d #/HelloWorldConsumer-HelloWorldProvider.json http://localhost/pacts/provider/HelloWorldProvider/consumer/HelloWorldConsumer/version/1.0
Getting the below response...
Could not resolve host: application
* Closing connection 0
curl: (6) Could not resolve host: application
* Trying ::1...
* connect to ::1 port 80 failed: Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#1)
> PUT /pacts/provider/HelloWorldProvider/consumer/HelloWorldConsumer/version/1.0 HTTP/1.1
> Host: localhost
> User-Agent: curl/7.49.1
> Accept: */*
> Content-Length: 756
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 756 out of 756 bytes
< HTTP/1.1 415 Unsupported Media Type
< Content-Type: application/json;charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Status: 415 Unsupported Media Type
< Date: Tue, 07 Feb 2017 17:08:40 GMT
< Server: Webmachine-Ruby/1.4.0 Rack/1.2
< X-Powered-By: Phusion Passenger 5.0.15
<
* Connection #1 to host localhost left intact
Not sure whether its success or failure as the first line saying... 'Couldn't resolve host:application' and 'Closing connection'
And when I tried to view the localhost, it appears blank.
Screenshot attached.
Looking out for help as early as possible !! Thanks in advance...
It seems you are attempting to mount a volume on your host machine (/var/lib/postgresql/data) that does not exist.
docker: Error response from daemon: Mounts denied:
The path /var/lib/postgresql/data
is not shared from OS X and is not known to Docker.
The message clearly states this. You should read more about docker volumes, but I'd suggest you mount another directory if this is for development on your Mac.
Secondly, you can see that you're getting an "Unsupported media type" on the upload so it has definitely failed:
HTTP/1.1 415 Unsupported Media Type
It appears as though the Content-Type is not being correctly set, you can see this in the output:
Content-Type: application/x-www-form-urlencoded
Please check that the file actually exists at path /HelloWorldConsumer-HelloWorldProvider.json, that it is a valid JSON file, and that your content type header is formatted correctly (it appears to be).
I'm trying to get the sample webapp play-streaming-scala to run and in some circumstances I get a weird behavior.
I've got the app running directly on port 80 of some host and I'm checking the output with curl -iv --raw http://somehost/scala/eventSource/liveClock.
What I'm expecting is something like this:
* Hostname was NOT found in DNS cache
* Trying 195.176.3.71...
* Connected to somehost (0.0.0.0) port 80 (#0)
> GET /scala/eventSource/liveClock HTTP/1.1
> User-Agent: curl/7.39.0
> Host: somehost
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Content-Type: text/event-stream; charset=utf-8
Content-Type: text/event-stream; charset=utf-8
< Date: Wed, 18 Jan 2017 13:24:55 GMT
Date: Wed, 18 Jan 2017 13:24:55 GMT
<
10
data: 14 24 56
10
data: 14 24 56
10
data: 14 24 56
etc., and clearly see the chunks appear one after the other as time goes by.
Now, on some machines, this works well. On some others on campus, this fails. curl only shows this and then stops:
* Trying 195.176.3.71...
* Connected to somehost (0.0.0.0) port 80 (#0)
> GET /scala/eventSource/liveClock HTTP/1.1
> Host: somehost
> User-Agent: curl/7.43.0
> Accept: */*
>
Now the interesting thing is: if I kill the webapp on the host, curl suddenly “catches up” and spits all the chunks together, closing the connection like this:
10
data: 14 35 20
* transfer closed with outstanding read data remaining
* Closing connection 0
curl: (18) transfer closed with outstanding read data remaining
What can be causing the behavior? What on earth is going on and intercepting these events? Is there any way I can “force flush” something from the Play response?
Turns out the local “hidden” proxy set up automatically by OS X's parental controls system is not forwarding chunked responses properly, thus making a system based on Server-Sent Events inoperable. A shame.
I want to disable TRACE/TRACK HTTP methods in JBoss wildfly 8.1 at server level and not in web.xml. How do do it?
Thanks Federico Sierra for the reply. I have tried again, but it seems by default TRACE is not disabled. I am getting 200 OK status code. See below.
# curl -k -v -X TRACE https://localhost:8443 --user admin:Password#123
* About to connect() to localhost port 8443 (#0)
* Trying ::1...
* Connection refused
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 8443 (#0)
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-SHA384
* Server certificate:
* subject: CN=scspr0021776001.gdl.englab.netapp.com
* start date: 2015-02
* expire date: 2016-02
* common name: scspr0021776001.gdl.englab.netapp.com (does not match 'localhost')
* issuer: CN=scsp
* SSL certificate verify result: self signed certificate (18), continuing anyway.
* Server auth using Basic with user 'admin'
> TRACE / HTTP/1.1
> Authorization: Basic YWRtaW46UGFzc3dvcmRAMTIz
> User-Agent: curl/7.27.0
> Host: localhost:8443
> Accept: */*
>
< HTTP/1.1 200 OK
< Expires: 0
< Cache-Control: no-cache, no-store, must-revalidate
< X-Powered-By: Undertow/1
< Set-Cookie: JSESSIONID=j1Uh0ZpFl08-op1ak9dm6gr7.scspr0021776001; path=; HttpOnly
< Set-Cookie: JSESSIONIDSSO=jIoXps8-b3dByrQektBEZfOP; path=/
< Server: WildFly/8
< Pragma: no-cache
< Date: Wed, 18 Feb 2015 04:24:33 GMT
< Connection: keep-alive
< Content-Type: message/http
< Content-Length: 135
<
TRACE /index.html HTTP/1.1
Authorization: Basic YWRtaW46UGFzc3dvcmRAMTIz
Host: localhost:8443
User-Agent: curl/7.27.0
Accept: */*
* Connection #0 to host localhost left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
By default in Wildfly TRACE and TRACK methods are disabled for security reasons.
You can check with:
curl -v -X TRACE http://localhost:8080
* Rebuilt URL to: http://localhost:8080/
* Adding handle: conn: 0x1ddb0a0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x1ddb0a0) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 8080 (#0)
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> TRACE / HTTP/1.1
> User-Agent: curl/7.33.0
> Host: localhost:8080
> Accept: */*
>
< HTTP/1.1 405 Method Not Allowed
< Connection: keep-alive
< X-Powered-By: Undertow/1
* Server WildFly/8 is not blacklisted
< Server: WildFly/8
< Content-Length: 83
< Content-Type: text/html
< Date: Tue, 17 Feb 2015 20:16:29 GMT
<
<html><head><title>Error</title></head><body>405 - Method Not Allowed</body></html>* Connection #0 to host localhost left intact
I managed to disable the HTTP TRACE in Wildfly 8.2 (it should work with Wildfly 8.1, but I haven't tested) with the following added to the webapp's WEB-INF/undertow-handlers.conf:
method[TRACE] -> response-code[value=405]
If you have multiple webapps you'll have to add it to all that don't need to answer to HTTP TRACE requests.
I'm facing this issue with the Facebook PHP SDK. My application is hosted on AWS EC2 (Virginia).
It's randomly happening but has recently increased. I've read that it was necessary to specified some cURL options, so I've done so:
self::$CURL_OPTS[CURLOPT_IPRESOLVE] = CURL_IPRESOLVE_V4;
self::$CURL_OPTS[CURLOPT_SSLVERSION] = 3;
self::$CURL_OPTS[CURLOPT_CONNECTTIMEOUT] = 20;
Because IPv6 is not supported on EC2 instance, we need to force IPv4
I've read to force SSL version 3
I've tried to increase the timeout from 10 to 20 seconds
I'm still getting the following error:
FacebookAPIException: timed out before SSL handshake
Which I believe is not a Facebook exception but a cURL exception.
I can't really enable the verbose mode because I have many requests and just a small percentage is failing at the moment.
Anyone is having the same issue?
My system:
Centos Linux 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
libcurl.x86_64 7.19.7-37.el6_4
php curl
cURL support => enabled
cURL Information => 7.19.7
...
Protocols => tftp, ftp, telnet, dict, ldap, ldaps, http, file, https, ftps, scp, sftp
Host => x86_64-redhat-linux-gnu
SSL Version => NSS/3.14.0.0
ZLib Version => 1.2.3
libSSH Version => libssh2/1.4.2
UPDATE
I've opened a Facebook bug here: https://developers.facebook.com/x/bugs/1461144600769806/
UPDATE 2
My facebook bug has been closed without any useful answer.
I've managed to log the verbose debug of cURL for this error:
Verbose log:
* About to connect() to graph.facebook.com port 443 (#0)
* Trying 173.252.100.27... * connected
* Connected to graph.facebook.com (173.252.100.27) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* timed out before SSL handshake
* NSS error -5978
* Closing connection #0
On success cURL is doing the following:
Verbose log:
* About to connect() to graph.facebook.com port 443 (#0)
* Trying 173.252.112.23... * connected
* Connected to graph.facebook.com (173.252.112.23) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_SHA
* Server certificate:
* subject: CN=*.facebook.com,O="Facebook, Inc.",L=Palo Alto,ST=California,C=US
* start date: Oct 28 00:00:00 2013 GMT
* expire date: Aug 05 23:59:59 2015 GMT
* common name: *.facebook.com
* issuer: CN=VeriSign Class 3 Secure Server CA - G3,OU=Terms of use at https://www.verisign.com/rpa (c)10,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
> POST /xxxxxxxxxxx/feed HTTP/1.1
User-Agent: facebook-php-3.2
Host: graph.facebook.com
Accept: */*
Content-Length: 244
Content-Type: application/x-www-form-urlencoded
Errors happen randomly. So is it coming from Facebook of from my server?