I have a problem with HttpFS service of hadoop.When i try to curl some resource:
curl -i http://192.168.4.180:14000/webhdfs/v1/user/hadoop/?op=LISTSTATUS
the response i get is:
HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Mon, 17 Aug 2015 08:57:47 GMT
But when i try to do the same with webhdfs it works:
curl -i http://192.168.4.180:50070/webhdfs/v1/user/hadoop/?op=LISTSTATUS
HTTP/1.1 200 OK
and so on ....
Httpfs service is running on port 14000, i have checked it via nmap.
Any suggestions or ideas what might be the problem?
I meet the same problem. And solved by this link
In brief, you need to add the symbol link:
# Point to the 'webapps' in current.
cd /etc/hadoop-httpfs/tomcat-deployment
ln -s /usr/hdp/current/hadoop-httpfs/webapps webapps
Related
I am completely new to APISIX and I am following the getting-started tutorial.
The problem is in editing routes. More specifically, I create a route using this example of the tutorial and it works as expected. Next I am editing the route's uri using:
# Please notice the extra 'g' in the uri value 'anythingg' compared to the previous uri
curl "http://127.0.0.1:9080/apisix/admin/routes/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PATCH -d '
{
"uri": "/anythingg/*"
}'
Then I am trying to connect to the endpoint using the new and the old uri but I am getting an 404 in both cases with different messages! The requests-responses:
New uri
$ curl -i -X GET "http://127.0.0.1:9080/anythingg/foo?arg=10" -H "Host: example.com"
HTTP/1.1 404 NOT FOUND
Content-Type: text/html; charset=utf-8
Content-Length: 233
Connection: keep-alive
Date: Tue, 13 Sep 2022 09:13:40 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Server: APISIX/2.15.0
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.</p>
Old uri
$ curl -i -X GET "http://127.0.0.1:9080/anything/foo?arg=10" -H "Host: example.com"
HTTP/1.1 404 Not Found
Date: Tue, 13 Sep 2022 09:13:45 GMT
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/2.15.0
{"error_msg":"404 Route Not Found"}
How could I update the route rules and get the expected results and what is the cause of the observed behavior?
Thanks!
The error in the new URI indicates that it was returned by httpbin, not APISIX; in the old URI, it was returned by APISIX.
You can update the route in its entirety via the PUT method to ensure it is updated successfully.
I am using a consul client to deregister a service from my junit tests. I am using vert-consul-client . the consul version i am using is 1.11.1 . the service is not registered with the consul , but just testing what will happen if we try to deregister a service that is not registered.
from the logs i get this error
Status message: 'Not Found'. Body: 'Unknown service "BadService"'
strangely i dont get this error when testing with 1.10.6 consul version.
appreciate if you can help
thanks
strangely i dont get this error when testing with 1.10.6 consul version.
Consul recently changed the HTTP response code that is sent when an attempt is made to deregister a non-existent service.
Prior to Consul 1.11.0, and when ACLs were disabled, Consul would respond with a HTTP 200 response code and no response body when deregistering a non-existent service.
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 200 OK
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:07:35 GMT
Content-Length: 0
This behavior was changed in Consul 1.11.0 by PR hashicorp/consul#10632 wherein Consul now returns a HTTP 404 response code if a service does not exist, regardless of whether ACLs are enabled. (See diff of consul/agent/acl.go).
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 404 Not Found
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:24:21 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
You're obviously not seeing an error in vertx-consul-client when communicating to Consul 1.10.6 because the HTTP 200 code indicates that the request was successful, whereas the HTTP 404 response correctly signals that the resource does not exist, and an error is correctly raised (see vert-consul-client/src/main/java/io/vertx/ext/consul/impl/ConsulClientImpl.java#L1320-L1333).
Interestingly in Consul 1.10.x, when ACLs are enabled on the cluster, Consul would reply with a HTTP 500 error code and a corresponding error message instead of the 200 response code. This is because when ACLs are enabled, the vetServiceUpdateWithAuthorizer function does not prematurely return (if authz == nil { return nil }) and proceeds with checking whether service exists, then raising an error because it does not (see consul/agent/acl.go#L96-L104).
$ curl --include \
--header "X-Consul-Token: $CONSUL_HTTP_TOKEN" \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 500 Internal Server Error
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
Date: Wed, 05 Jan 2022 03:14:52 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
If you had tested 1.10.6 with ACLs enabled, you would've also received a similar error as you are seeing with 1.11.1.
I started experimenting with Traefik on Windows 10 and I need assistance with some very basic steps. Two are my main stumbling blocks: configuring Traefik natively on Windows 10 and http2 support.
1) Native Traefik on Windows
Following the instructions at https://docs.traefik.io/ I successfully managed to install the docker image of Traefik and see the dashboard on localhost:8080
However, when I try to start Traefik natively as "traefik -c traefik.toml" Traefik seems to "hang" no matter what I put in traefik.toml.
Can anybody show me a minimal Windows 10 configuration (.toml) to achieve what I achieve using the Docker version of Traefik?
2) HTTP2 support
Following the test shown at https://docs.traefik.io/#test-it, I execute this on the command line:
curl -v --http2 -H Host:whoami.docker.localhost http://127.0.0.1
but on the output I see:
< HTTP/1.1 200 OK
< Content-Length: 327
< Content-Type: text/plain; charset=utf-8
< Date: Wed, 05 Jul 2017 18:51:00 GMT
Does it mean that the response back is http 1.1 ?
Any help is much appreciated.
I have checked it at: http://www.ipchecking.com/ and they say they are the same. but when I visit each of them they are different
ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com - 404 error Problem accessing /. Reason: Not Found
54.206.38.225 - returns apache default page
ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com/jenkins - jenkins launchs
54.206.38.225/jenkins - not found
My understanding was that the host name should resolve to the ip address and thus they shouldboth take me to the same place?
What you are probably seeing is due to named based virtual hosts.
When your browser makes an HTTP request, it includes a header that says what host it is looking for. This allows a server to have more than 1 site hosted on a single IP address and port.
This can also allow a load balancer to redirect your traffic to different machines on its network for handling.
You can find more information at
https://en.wikipedia.org/wiki/Virtual_hosting
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Check this:
# curl -I -s http://ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com | head -3
HTTP/1.1 404 Not Found
Date: Tue, 05 Jan 2016 06:15:49 GMT
Server: Jetty(winstone-2.9)
# curl -I -s http://54.206.38.225 | head -3
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2016 06:16:00 GMT
Server: Apache/2.4.7 (Ubuntu)
# curl -I -s http://ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com/jenkins | head -3
HTTP/1.1 302 Found
Date: Tue, 05 Jan 2016 06:16:18 GMT
Server: Jetty(winstone-2.9)
# curl -I -s http://54.206.38.225/jenkins | head -3
HTTP/1.1 404 Not Found
Date: Tue, 05 Jan 2016 06:16:28 GMT
Server: Apache/2.4.7 (Ubuntu)
From above commands (look at the HTTP response code closely),
When FQDN is used, the HTTP request is responded by JeTTy.
When IP Address is used, the HTTP request is responded by Apache.
Jetty is aware of /jenkins path
Apache is not aware of /jenkins path.
So this implies that, You have JeTTy acting as Reverse_Proxy/Load_Balancer. So the connection looks like this:
USER --> JeTTy --> Apache
Now, you need to figure out how JeTTy is configured for redirecting/denying requests. This link might be helpful.
However, Usually, I have seen that an application server is fronted by a web server as Reverse_Proxy/Load_Balancer. So, you might find that your setup looks like below:
USER --> Apache --> JeTTy
If this is the case then figure out how Apache is configured for redirecting/denying requests.
I have read about Web Hdfs in all this links
link1 link2 link3
checking with telnet - the port is OPEN
made the needed settings in cloudera ( virtual box) to make webhdfs enable
testing directly on cloudera works:
[cloudera#quickstart ~]$ curl -i -L "http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN"
HTTP/1.1 307 TEMPORARY_REDIRECT
http://quickstart.cloudera:50075/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN&namenoderpcaddress=quickstart.cloudera:8020&offset=0
Content-Length: 0
Server: Jetty(6.1.26.cloudera.4)
HTTP/1.1 200 OK
Cache-Control: no-cache
Expires: Tue, 01 Dec 2015 14:08:07 GMT
Date: Tue, 01 Dec 2015 14:08:07 GMT
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Server: Jetty(6.1.26.cloudera.4)
trying directly on cloudera web browser also work for :
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN
I am able to send PING C:\Users\User>ping 10.0.0.88
Telnet working for port 50070.
But when trying this command outside the cluster it dosnt work (HOST)
"http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN"
more info
LISTSTATUS works from HOST
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFileop=LISTSTATUS&user.name=hadoop`
returns
{"FileStatuses":{"FileStatus":[
{"accessTime":1448982310759,"blockSize":134217728,"childrenNum":0,"fileId":26625,"group":"cloudera","length":47,"modificationTime":1448978300739,"owner":"cloudera","pathSuffix":"","permission":"644","replication":1,"type":"FILE"}
]}}
but op=OPEN from HOST
"http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN&user.name=hadoop"
returns
This webpage is not available
what could be the problem ?
It seems there is syntax problem in
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?`op=OPEN&user.name=hadoop`
Try
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN