traefik.frontend.rule=Host:example.com redirect requests to example.com to that backend. Then what is the usage of traefik.domain?
Default frontend rule is Host:{containerName}.{domain} or Host:{service}.{project_name}.{domain}
Assuming you are using Docker as a provider, setting traefik.frontend.rule=foobar.example.com is equivalent to setting traefik.domain=exemple.com with a container called foobar
This is documented here
Related
I'm try to configure traefik with file backend to contact a grafana server in a LXC container.
This is my configuration file:
[file]
# rules
[backends]
[backends.backend2.servers.server1]
url = "http://192.168.255.250:3000"
[frontends]
[frontends.frontend2]
entryPoints = ["http"]
backend = "backend2"
passHostHeader = true
[frontends.frontend2.routes]
[frontends.frontend2.routes.route0]
rule = "PathPrefixStrip: /grafana"
Grafana backend listen on /
So, I can contact http://example.com/grafana but I have a redirection to http://example.com/login which does not work. But http://example.com/grafana/login responding (without css, certainly because grafana seems to use relative url).
According to the documentation :
Use a *Strip matcher if your backend listens on the root path (/) but should be routeable on a specific prefix. For instance, PathPrefixStrip: /products would match /products but also /products/shoes and /products/shirts.
Since the path is stripped prior to forwarding, your backend is expected to listen on /.
If your backend is serving assets (e.g., images or Javascript files), chances are it must return properly constructed relative URLs.
Continuing on the example, the backend should return /products/shoes/image.png (and not /images.png which Traefik would likely not be able to associate with the same backend).
The X-Forwarded-Prefix header (available since Traefik 1.3) can be queried to build such URLs dynamically.
It seems that I have to use the X-Forwarded-Prefix header but I do not know how to use it (I did not see anything in the documentation). Maybe you can help me solve this problem ?
Regards
jmc
In fact, the problem does not come from traefik. I just forgot to specify the path in /etc/grafana.ini (root_url field). I thought it was not necessary since the incoming query does not contain the path /grafana (because we use PathPrefixStrip). But in fact, grafana needs it to indicate effective url to client.
Regards.
jmc
Trying to get shibboleth working on a Docker container, using Apache as a reverse proxy. Problems occur because I am using port 80 for the public Apache instance and port 8000 for the internal instance, which confuses shibboleth:
2017-10-03 07:34:23 ERROR OpenSAML.MessageDecoder.SAML2POST [5]: POST targeted at (https://dashboard.hpc.unimelb.edu.au/Shibboleth.sso/SAML2/POST), but delivered to (https://dashboard.hpc.unimelb.edu.au:8000/Shibboleth.sso/SAML2/POST)
The first URL is the external URL which the end user sees. The second URL is what the docker container sees when it gets the proxied request (with the HTTP host name forwarded).
Note I used "ShibURLScheme https" on the internal apache instance to ensure it believes https is being used, as the reverse proxy ensures all requests are https.
Is there anyway I call tell Shibboleth that this is OK, the URLs really are the same? Maybe by rewriting the URL shibboleth sees or something?
Thanks
There are two things I would check:
Make sure the ServerName directive in your Apache conf file is set to
https://dashboard.hpc.unimelb.edu.au:80. Notice the :80. Omitting
the port number completely may work too. You want Apache and vis-a-vis, shibd to see the ServerName that the client is using. You should also make sure you have a UseCanonicalName On directive as part of this.
This is likely less of a problem, but make sure your sp-metadata given to the IdP is correct. You should add entries for the FQDN(s) that the client sees. Please note that most of that documentation page isn't applicable to your scenario, but adding the correct metadata entries is vital.
It looks like your ServerName in Apache isn't correct, so I'd start there.
I built a personal server at home which is hosted at, let's say, example.org and I installed GitLab as a subdirectory so I can access to it at example.org/gitlab. As GitLab is the only one application I have so far, everything works smoothly.
Now I want to have a blog at root, so I enabled Apache default site to do some tests. I can see apache2 default page at example.org (which is where I want my blog) but GitLab won't work anymore at example.org/gitlab. All I have is a "page not found". GitLab will only work if I disable the default page at /.
I tried using Alias, I also read something about redirections but I haven't managed to make example.org and example.org/gitlab work together so far.
Any advice about where to look, please?
If you generate two virtualhosts both must have different ServerName, otherwise first match receives all requests and second virtualhost will be ignored.
I have a server with several services running. One of them is accessible through the domain name like "https://www.foo.bar". Two other services are running on specific ports. So they are accessible through "https://www.foo.bar:1234".
Is it able to configure an apache2 server in a specific way, so it uses always the port 443 but with a different URL like "https://www.foo.bar/service1"?
Try ProxyPass, what you describe is a special case of a setup called Reverse Proxy: your httpd forwards requests to the other service and returns the answers to the client. (The other service happens to run on the same machine in your case, but it needn't. A simple kind of backend load-balancing can also be done this way.)
<Location /service1>
ProxyPass https://localhost:1234
ProxyPassReverse https://localhost:1234
</Location>
Be careful that your other service needs some rudimentary support for this kind of setup: if it returns HTML pages with links in it, it can't assume anymore that https://www.foo.bar:1234/foo/bar.html is the correct URL to tell the client. httpd will not look into the returned content and rewrite it for you.
I've set up a host with apache to serve static pages and to use Tomcat to serve my web application (See this question). The static pages are server from
"http://myhost.com"
and the dynamic (tomcat) pages are server from
"http://myhost.com/myapp"
The mod_proxy makes sure the "http://myhost.com/myapp" are forwarded to tomcat server running on "http://myhost.com:8080".
The problem is that now you get the standard Tomcat introduction page on "http://myhost.com/myapp" but if you click on a local link (e.g. 'Status') on the left, it generates an URL
"http://myhost.com/manager/status" while it should generate: "http://myhost.com/myapp/manager/status"
(The same is true for webapps installed under tomcat)
What should be changed in my configuration (apache, tomcat?) to redirect my tomcat links to the right place?
Have you set the ProxyPassReverse setting in your httpd.conf. This will overwrite the HTTP Header an you'll get to the correct request on the side of tomcat.
Your URLs are mapped from:
http://myhost.com/myapp -> http://myhost.com:8080
This means that accessing the above URL will be mapped to the ROOT application in Tomcat. The ROOT application will generate pages that contain links from Tomcat's root context.
In other words, if you go to:
http://myhost.com:8080
you will get a page that contains links to
http://myhost.com:8080/manager/status
This link will work. However when that page is given back to a browser that requested it via Apache, the full URL then looks like: http://myhost.com/manager/status
I assume that you intend to deploy an application called 'myapp' to Tomcat? If that is the case the Tomcat URL for this app will be
http://myhost.com:8080/myapp
Which will also work be mapped correctly when accessed via Apache.
If you absolutely must access Tomcats root application in this way you'll have to rewrite the URLs it outputs in the pages it returns.
I've had the most success with mod_proxy_ajp. It requires mod_proxy, but works over ajp. Using it instead, your conf file looks similar
ProxyPass / ajp://localhost:8009/
See my similar question and also the answer to this question. The only fault in mod_proxy_ajp that I've found is that if I need to restart tomcat I have to force an apache restart too.