Gogs has the following server configuration parameters:
[server]
DOMAIN = 172.17.0.2
HTTP_PORT = 3000
ROOT_URL = http://172.17.0.2:3000/
So the ROOT_URL parameter could be constructed from the DOMAIN and the HTTP_PORT the way it is shown above. Is it used in scenarios where Gogs cannot derive it?
TIA,
Ole
So the ROOT_URL parameter could be constructed from the DOMAIN and the HTTP_PORT
That is not always true. The HTTP_PORT is the port gogs listens for incoming traffic, but this does not necessarily mean that you can reach gogs under that port.
For example, I let gogs listen on port 3000 on localhost, however gogs is available under git.example.com because my apache server, listening on port 80, acts as a proxy and redirects traffic for this subdomain to gogs. If you couldn't configure the ROOT_URL yourself and gogs would just take the DOMAIN and PORT to create the full URL, this wouldn't be possible because gogs would gegerate wrong links and wrong clone-urls.
Related
In front of my web servers and Docker applications I'm running Traefik to handle load balancing and reverse-proxy. In this specific case Magento 2 is running on another host in the same private network as the Traefik host.
Traefik: 192.168.1.30
Magento: 192.168.1.224
Traffic is coming into the firewall on port 80/443 and forwarded to Traefik which forwards the request based on the domain name (in this case exampleshop.com).
My Traefik configuration looks like this:
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
[backends]
[backends.backend-exampleshop]
[backends.backend-exampleshop.servers.server1]
url = "http://192.168.1.224:80
passHostHeader = true
[frontends]
[frontends.exampleshop]
backend = "backend-exampleshop"
[frontends.exampleshop.routes.hostname]
rule = "Host:exampleshop.com"
For regular websites above configuration always worked as expected (a working HTTPS connection with valid Let's Encrypt cert) but in this Magento 2 case it results in:
ERR_TOO_MANY_REDIRECTS
Therefore I'm unable to reach both my homepage as well as my admin page. Looking at the Database records I've configured both my unsecure as secure URL as https://exampleshop.com to avoid redirect errors.
Apache is listening fine on port 80, and when contacted directly (by changing my hosts file) the page gets displayed just fine over HTTP.
What am I missing here?
Command out below code solved this case OR
Enable ACME on your Traefik and switch SSL mode on Cloudflare to Full (if enabled)
[entryPoints.http.redirect]
entryPoint = "https"
I suppose that 192.168.1.224 is the IP (local) where Traefik is installed.
entryPoints.http : address = ":80" == address = "0.0.0.0:80"
https//exampleshop.com
entryPoints.https (because https == port 443)
frontends.example1 (because rule = "Host:exampleshop.com")
backend-example1: server = "http://192.168.1.224:80"
entryPoints.http because :80 == http://192.168.1.224:80
redirection to entryPoints.https
etc
Try to change the port of your local application.
Actually, the config was completely valid but Cloudflare's crypto/SSL settings were set to Flexible instead of Full; causing a loop.
I run into this as well, but I've found I have to add this:
ingress.kubernetes.io/ssl-proxy-headers: "X-Forwarded-Proto: https"
In our kubernetes ingress manifests and it fixes it.
I'm running traefik on an AWS instance with a rancher back-end. I am terminating SSL at the AWS load balancer, and am communicating on port 80 with the instance, which forwards the :80 traffic to the traefik container.
So the Load balancer currently has:
https:443 ==> http:80
http:80 ==> http:80
That means, if you type https://example.com, you get SSL, and if you type http://example.com, you just get an ordinary http connection.
The desire is to have an auto redirect via http 302 -- it would redirect http://example.com to https://example.com.
So far what I've unsuccessfully tried is the following:
** AWS Load balancer**
https:443 => http:80
http:80 => http:81
traefik.toml
------------
[entryPoints]
[entryPoints.http]
address = ":81"
[entryPoints.http.redirect]
regex = "^http://example.com/(.*)"
replacement = "https://example.com/$1"
address = ":80"
docker-compose.yml
------------------
API-Proxy:
container_name: api-proxy
image: traefik
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
- "$PWD/traefik.toml:/etc/traefik/traefik.toml"
command: "--web --rancher --docker.domain=rancher.localhost --logLevel=DEBUG"
cpu_shares: 128
restart: always
ports:
- 80:80/tcp
- 81:81/tcp
- 8100:8080/tcp
When I try accessing via port 80, there's a timeout. Traefik logs don't seem to be helpful.
Is this a silly approach? Or is it better to terminate SSL at the traefic container using Let's encrypt?
Try something like this in your Traefik config. Then forward both ports 443 and 80 on the LB to port 80 on Traefik.
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
regex = "^http://(.*)"
replacement = "https://$1"
I do this in Kubernetes on AWS currently. It's a little fiddly to get just right, but it is totally possible.
First you need to make sure that your ELB is listening for HTTP (not HTTPS) on port 80 and for HTTPS on port 443. If you have the ELB listening for HTTPS on port 80, you'll get very strange behavior by clients. Check that first. Note: this is the default behavior if you have deployed Traefik using Helm.
Use aws elb describe-load-balancers to print out all of your ELBs. You'll have to find the ELB in there (I don't know how to tell you which one it is) and look in the LoadBalancerDescriptions[].ListenerDescriptions[].Listener.Protocol and InstanceProtocol to make sure that they are HTTPS and HTTP, respectively.
Second, this is all you need in your config.toml:
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
regex = "^http://(.*)"
replacement = "https://$1"
[entryPoints.httpn]
address = ":8880"
compress = true
Explanation:
Listen on port 80
Set up a permanent redirect for any traffic on port 80 to port 8880
Listen on port 8880 with HTTP and enable gzip compression
The ELB should have port 80 mapped to port 80 and port 443 mapped to port 8880. Now all HTTP traffic will be automatically redirected (use curl -v -L http://example.com to test) to HTTPS and terminated at the ELB and forwarded as HTTP to Traefik.
I am still looking for a good way to specify the protocols for the ELB listeners on deploy but I haven't come up with a good solution other than manually changing them via the AWS console after I deploy Traefik.
I have a very cheap VPS with the IP 123.123.123.123 which listens on these ports: 7000, 7001, ... 7020. Apache listens on port 7010. Then I can access my website with http://123.123.123.123:7010.
As this is a shared IP, I cannot listen on port 80 myself with my VPS: I only have access to 7000 ... 7020.
I have registered a domain mydomain1.com by a domain provider and I'm using their nameservers.
How to set up the DNS records such that any user going on http://www.mydomain1.com will be transparantly directed to my website, with Apache ? (the browser will probably default to port 80, is that right?)
I initially thought about such a DNS record:
Name TTL Type Priority Content
*.mydomain1.com 3600 A 0 123.123.123.123
but then, I think I would have to access the website with http://www.mydomain1.com:7010 (which is not nice) and not http://www.mydomain1.com (which would be better).
Unfortunately you cannot specify ports on DNS records. The only way to make it work as you expect is to have a reverse proxy running elsewhere (nginx, haproxy), listening on port 80, and then forward traffic to your server.
Some useful information about HTTP proxying with nginx:
What is a reverse proxy?
Configuring nginx as a reverse proxy for apache
In order to test every possible solution to get Socket.io working with a parallel Apache installation, I have now installed HAproxy that listens on port 80. It proxies everything to Apache, unless the hostname equals io.server.com.
We have two IPs connected to our server: 1 is for SSL, the other for all the NON-SSL subdomains we have. I have created the io.server.com subdomain to point to that NON-SSL IP-address. However, the following this occurs:
A visit to regular_http.server.com results in Apache handling that sub domain (OK)
A visit to io.server.com results in "Welcome to Socket.io" (OK)
Next visit to regular_http.example.com results in "Welcome to Socket.io"
Why is HAproxy sending requests from a subdomain not configured to go to Socket.io, to Socket.io ?
Yes, the two sub domains share the IP, but is HAproxy really proxying the whole IP under one? What is then the point with setting up ACLs based on host name?
Here's my configuration:
global
daemon
maxconn 4096
user haproxy
group haproxy
defaults
log global
#this frontend interface receives the incoming http requests
frontend http-in
mode http
bind *:80
timeout client 86400000
#default behavior sends the requests to apache
default_backend www_backend
#when "io.test.tld" is matched, an acl I call arbitrarily
# "websocket" triggers
acl websocket hdr_end(host) -i io.server.com
use_backend node_backend if websocket
Thank you!
This problem was solved using the option http-server-close configuration value in HAproxy.
apache + ssl is configured using xampp on windows server 2003. http content has no problem by domain name, but https content can only be visited from localhost. "netstat -a" shows
Proto Local Address Remote Address State
...
TCP hostname:https hostname:0 Listening
...
How to config to enable https via domain name?
Found the reason. Another program take the 443 port so apache https failed. use "netstat -a -o -n" can get the detail.
I'm assuming you can already access apache using this domain name.
Take a look in your ports.conf, usually found at
/etc/apache2/ports.conf
It should contain a line like:
NameVirtualHost *:443
and also
Listen 8443 https