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.
Related
I updated ddev to version 1.3.0 and ran ddev config. After that I changed the configuration from nginx-fpm to apache-fpm. After starting ddev and checked the HTTP headers, there is nginx/1.15.3 used. Is there something else to do, to get Apache working?
My config.yaml:
APIVersion: v1.3.0
name: example
type: typo3
docroot: public
php_version: "7.2"
webserver_type: apache-fpm
router_http_port: "8080"
router_https_port: "8443"
xdebug_enabled: true
additional_hostnames: []
additional_fqdns: []
provider: default
hooks:
post-start:
- exec: composer install -d /var/www/html
- exec: ../vendor/bin/typo3cms cache:flush
- exec: ../vendor/bin/typo3cms database:updateschema
- exec: yarn --cwd typo3conf/ext/theme/Resources/Private install
That is such a good question! I know because I already got stumped by it myself when writing tests.
The answer is: Apache runs in the web container but when you use the http://*.ddev.local URL, it goes through ddev-router, which is an nginx reverse proxy, and that's why you see the nginx headers. But rest assured you are using Apache. You can confirm that these ways:
ddev ssh and ps -ef to see what's running
Hit the 127.0.0.1 URL reported by ddev start and ddev describe. That URL goes directly to the web container, for example http://127.0.0.1:33221 - You'll see the apache headers on that one.
Your question is so good - Could you please edit the title to something like "Why do I see nginx headers when ddev is configured to use apache?" - I think other people will find it that way.
$ curl -I http://127.0.0.1:33224
HTTP/1.1 200 OK
Date: Fri, 12 Oct 2018 02:18:26 GMT
Server: Apache/2.4.25 (Debian)
Cache-Control: must-revalidate, no-cache, private
X-Drupal-Dynamic-Cache: HIT
X-UA-Compatible: IE=edge
Content-language: en
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Vary:
X-Generator: Drupal 8 (https://www.drupal.org)
X-Drupal-Cache: MISS
Content-Type: text/html; charset=UTF-8
I've setup my gitlab installation from source, secured it with letsencrypt and deployed it under https://gitlab.mydomain.com. I can access the website and create repositories, etc. but I can't find a way to register a gitlab ci runner for the installation.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
https://gitlab.mydomain.com/ci
Please enter the gitlab-ci token for this runner:
xxxxxxxx-xxxxxxxx
Please enter the gitlab-ci description for this runner:
[server]: test
Please enter the gitlab-ci tags for this runner (comma separated):
test
ERROR: Registering runner... failed runner=xxxxxxx
status=couldn't execute POST against https://gitlab.mydomain.com/ci/api/v1/runners/register.json:
Post https://gitlab.mydomain.com/ci/api/v1/runners/register.json:
read tcp [ipv6address]:33518->[ipv6address]:443: read: connection reset by peer
PANIC: Failed to register this runner. Perhaps you are having network problems
My gitlab system is working fine and I really ran out of explanations why there would be a connection reset by peer. When I try to curl the address from the error message directly, it returns a correct response.
curl -v https://gitlab.mydomain.com/ci/api/v1/runners/register.json
* Trying ipv6address...
* Connected to gitlab.mydomain.com (ipv6address) port 443 (#0)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* found 700 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: mydomain.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=mydomain.com
* start date: Wed, 18 May 2016 14:35:00 GMT
* expire date: Tue, 16 Aug 2016 14:35:00 GMT
* issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
* compression: NULL
* ALPN, server did not agree to a protocol
> GET /ci/api/v1/runners/register.json HTTP/1.1
> Host: gitlab.mydomain.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 405 Method Not Allowed
< Server: nginx
< Date: Sun, 29 May 2016 09:14:09 GMT
< Content-Type: application/json
< Content-Length: 2
< Connection: keep-alive
< Allow: OPTIONS, POST
< Cache-Control: no-cache
< Status: 405 Method Not Allowed
If the runner and gitlab are running on the same host you can get around this problem by entering a the first question the following instead what is given in the docs:
http://gitlab:port
where gitlab is the container name and port the left port number of the container. If you are using gitlab internal ssl certs you specify https instead of http. This always solves this problem when I get it.
For those that are using docker:
The issue its about docker network.
If you try
"$docker container inspect $id"
You are going to see the IPAddress of gitlab container.
Point to that ip adress on first question to works fine.
Problem went away after updating gitlab to 8.8.3 and gitlab-multi-ci-runner to the most recent version.
I also started my gitlab nginx configuration files from scratch.
In the end, I can't tell which change exactly solved the problem.
I had so far many errors and issue starting with Error 404, 403 and endings with problem with post request.
For me, problem seems to be incompatibility between GitLab and ci-runner.
Solution, same on post issue, was install older version of ci-runner:
sudo apt install gitlab-ci-multi-runner=1.11.1
I've solved it by installing gitlab-ci-multi-runner=1.11.1.
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
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