The router is unable to route the requests to any service in openshift origin ( v1.1.4) When troubleshooting I see
oc get pods --all-namespaces --selector=router --template='{{range .items}}HostIP: {{.status.hostIP}} PodIP: {{.status.podIP}}{{end}}{{"\n"}}'
HostIP: 10.12.10.5 PodIP: 10.12.10.5
Maybe this is the problem since the router is not on the pod network and cannot route requests ?
There are a number of types of routers. A HAProxy router is the most commonly used router. I'd imagine that is the kind you are using because you have it in a pod.
The router by itself will do very little. Again, I'm assuming you are using the Openshift web app and you are clicking on the link that is created. In order for this to resolve, you need to set up a Wildcard DNS (check this Wildcard DNS article out). Once you have that set up and you have the router resolve to the correct node and given you have the router and routers configured correctly, the link should work.
Related
I have been using vagrant + ansible to deploy and update my dns on cloudflare. Lately I have lost that ability, I was using this module
https://github.com/bocoup/learn-ssh/blob/master/instructor/ansible/library/cloudflare_domain.py
But this is old and its url is pointing to the old one. Ever since cloudflare changed it to v4 not only the url has changed but also how it is used. Simply changing the url does not fix it, does anyone have any link on an updated module that I can use so I can replace the existin one?
here is my setup. I have 4 servers
ARR
Node1
Node2
Node3
I have set the nodes up to use a shared configuration and have set the ARR box up to have a central certificate store ( followed the docs on msdn ). On the ARR box there is a DefaultWebsite as per the standard IIS installation. It has a binding that matches all HTTP traffic ( ie no domain specified ). There is also a ARR rule ( set up by default ) that points all requests to my server farm. Everything is working perfectly for normal HTTP traffic, but when I try HTTPS the requests fail ( browser gives ERR_CONNECTION ). I have stuck to all the defaults an no joy. I have multiple sites with multiple certificates, so I have made sure that all HTTPS bindings on the node are set to use SNI and the CCS. Still HTTPS does not work. However, if I add the HTTPS binding on the ARR box, then the requests go through correctly.
Surely that behavior is not correct? I can't manage https bindings on the ARR box and then all other bindings through a shared config setup? I was under the impression that the ARR box should not even need to have a single site configured, it should simply pick up the request, match the ARR rule and then delegate off to one of the nodes?
Am I missing something here, any help would be greatly appreciated
I think it might have something to do with SSL offloading. When I disable that, I get an error 502 response.
Could it have something to do with compression? I zip all responses using a filter, but surely then even http traffic would fail?
so things always look better in the morning. After a couple hours of googling and several re-installs of IIS I finally found the issue. I had deleted the "Default Website". Then in order to get ARR back up I added back a default website. This allowed all wildcard HTTP traffic through to the server farm. When I tried to add a default HTTPS binding however, the IIS config management console forces you to put in a domain name, which doesn't work if you want a "default" implementation.
So to get around this, I simple manually edited the applicationHost.config file and removed the domain name from the binding entry :
<binding protocol="https" bindingInformation="*:443:" sslFlags="3" />
and that's it....happiness!
I had that error too while migrating a single proxy configuration with multi-sites to a ccs + shared config server.
It happens that the default web site configuration did not import correctly and the https binding did not have a certificate assigned.
I assigned a certificate and the error went away.
I'm trying to set up https on my backend app on heroku as a subdomain like this (for example):
https://api.mydomain.com
and I'm really confused by all the conflicting online docs I've found. Also, I'm rather green on all this SSL stuff. This app will be a backend for just data serving. My front end right now is https on OpenShift under my domain and it's working fine. Here is what I've done:
I have a "hobby" dyno ($7/month) on my heroku app, which I read that I need to
enable this stuff.
I have a cloudflare account which serves up my domain for the openshift front-end on https.
I bought my domain from GoDaddy -- so right now it simply points to the cloudflare name servers.
I setup the subdomain: api.mydomain.com on heroku (settings tab). It came back and said that my "DNS Target" is api.mydomain.com.herokudns.com. It also says "Domain: Your app can be found at http://api.mydomain.com".
I clicked "Configure SSL" > "Automatically configure using Automated Certificate Management" and it comes back saying to:
"update your DNS settings to our secure domain"
Not really sure what that means, to be honest. I tried to go back to cloudflare and add a DNS Record (DNS tab). Like so:
Type: CNAME
Name: api <--is this right?
Value: api.mydomain.com.herokudns.com <-- what do I put here?
But this doesn't work. How do I know? I type
heroku certs:auto and it comes back 'failing'. Also tried value: mydomain.com.herokudns.com without the 'api' in front. I'm really confused and the docs aren't much help. Can anybody help me?
I have found a simpler solution. The fix was mentionned in Cloudflare's tutorial.
The trick is to take your standard heroku app address (ex: myapp.herokuapp.com) INSTEAD of the xxx.herokudns.com displayed in heroku's SSL interface
Then, to make your custom subdomain (ex: api.foodomain.com) point to it, simply add a CNAME record in Cloudflare's DNS
CNAME api myapp.herokuapp.com
And it should work (it did for my case).
OK, in case some other poor tired programmer comes here.
Cloudflare and Heroku don't get along. Use your SSL from cloudflare. Here's how:
disable automatic certification on heroku: heroku
certs:auto:disable
Delete your domain on heroku and start over
Add the (sub) domain again on heroku
type heroku domains to see what the REAL domain is now -- without ACM enabled it will probably go back to ...herokuapp.com instead of ...herokudns.com
Set that one up in cloudflare (DNS tab) under CNAME like so:
CNAME | yoursubdomainname | yourdomainname.com.herokuapp.com
set up Page Rules in cloudflare to be like so:
http://yourdomainname.com/ => Always use https
on Crypto tab use Full SSL.
Wait an hour or so to make sure these all take effect.
Hope that helps someone.
I am trying to set custom domain for my Firebase app.
Firebase hosted url : https://inventory-app-726af.firebaseapp.com/
Custom Domain: inv.agsft.com
I have followed all instructions as part of setting custom domain but after verification step when I click on finish button, status will always be "Needs Setup".
I am managing DNS through cloudflare (https://www.cloudflare.com/) and I am following Quick setup option.
Any pointers to resolve it?
I had the same problem, I was able to resolve it by toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records
It started working right away.
The proper solution, ie without disabling Cloudflare for the site, is to use Full SSL for your domain/subdomain.
You can either choose Full SSL for all your domain entries, or set up a Page Rule for a specific subdomain, in your case, use "inv.agsft.com/*"
Source: https://community.cloudflare.com/t/flexible-ssl-redirect-loop-with-google-firebase/2063/3, which in turn points to https://support.cloudflare.com/hc/en-us/articles/115000219871-Why-does-Flexible-SSL-cause-a-redirect-loop-
Had the same issue and this solved the redirect issue. Firebase will however still report the domain as "Needs setup", for that I have no solution, but it does not affect the functionality of the hosting.
For the people that is using Namecheap, This configuration worked for me.
To avoid any kind of ssl issues when using firebase hosting and cloudflare you have to check to following points:
You don't need to toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records unless you don't want the cloudflare ssl certificates and want to just use the firebase ssl certificates (look to this carefully because you will loose the protection that cloudflare provides to your site in case you decide to use only the clouflare DNS)
If you "keep the cloud orange" it will not causes any problem to your firebase hosting.
Add the firebase IP's to cloudflare following the instructions provided by firebase hosting and remove any other A record from your domain/subdomain that you are setting up
To ensure you have a end-to-end encryption (using both firebase ssl as well as cloudflare ssl), make sure that your cloudflare crypto options is set to "Full":
Use a page rule likes in case that you want your root domain to receive all trafic:
In your firebase hosting setup, do the same:
p.s: Look that the message "Needs setup" is still there but the app is running without any problem.
p.s2: the majority problems regarding cloudflare and firebase is that firebase ssl can take several hours to start to work and you keep seeing a message like "your connection is not private". It happens not beucase cloudflare is messing our proxy out but because firebase ssl is still not fully propagated.
I hope it help others :)
In my case I did the same that Brennen did:
toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records.
But just start working when I:
Delete the domain from firebase. (click on the : points select delete domain)
refresh the firebase site
Added again in Quick Setup. I already had the A record added in Cloudflare so I didn't added again.
After that automatically the status added was connected.
Remember: Before testing, clean your browser cache.
When I run dig -t txt +noall +answer inv.agsft.com there are no TXT records showing. Since those are required to verify your ownership of the domain, Firebase Hosting will not continue the setup beyond step one.
Update: since the next step requires you to map A records to the IP addresses of Firebase hosting, I ran the relevant dig too:
$ dig -t a +noall +answer inv.agsft.com
inv.agsft.com. 299 IN A 104.18.56.240
inv.agsft.com. 299 IN A 104.18.57.240
Those are not the addresses I'd expect for Firebase Hosting, so it looks like either you haven't correctly entered the A records, or they have't propagated yet.
When I change my setting like below, it started to work again.
Redirect loop fixed:
For GoDaddy this adding the following solved it for me:
TYPE:A
NAME:#
VALUE: your ip_1
TYPE:A
NAME:#
VALUE: your ip_2
June 2020
Just wanted to share what was successful for me. It was a combination Brennen and Lisbel's answer.
Step 1: Toggle off your DNS status to get a grey cloud (as shown in the earlier answer)
Step 2: Delete the domain from firebase
Step 3: Add it back with Quick Steup
It should be connected after these steps!
I had the same issue. Here's how I fixed it:
1) Cick the View button on the problematic domain (in the Hosting section next to where it says Needs Setup).
2) Change the 'Setup mode' from Quick Setup to Advanced and follow the 3 steps
2a) Open your domain provider's settings (I'm using Google Domains) and add the TXT record it's giving you.
2b) Wait about 4-12 hours for verification
2c) Add the provided A records into your domain provider's settings
This is not a quick process, but it should be working about 5 minutes after you complete step 2c.
Toggling DNS mode didn't work for me. So I tried following approach and it worked for me.
Add CNAME record pointing to {firebase-project}.firebaseapp.com or {firebase-project}.web.app, you could add A record and try.
ADD TXT record as firebase ask you
Verify from firebase (this will show as needs setup, also it didn't go away although this worked)
If new domain/subdomain doesn't works check your browser developer tools network tab. If there are lots of 301 happening then go to cloudflare page rules. Add newdomain.com/* or subdomain.newdomain.com/* then add settings select SSL and set it to full as follows.
Then it will work as expected.
Working as of 11st May 2022 without need to toggle DNS and HTTP Proxy (CDN).
Steps:
Go to Cloudflare Dashboard.
Select SSL/TLS.
Select Overview.
Select Full option for SSL/TLS encryption mode.
After that, refresh your website that previously have issue to access.
Now the website can access successfully.
I'm trying to use Heroku's Automatic Certificate Management to set up SSL for my site. My app is on heroku at myapp.herokuapp.com, and I currently have Subdomain Forwarding set up so that http://www.myapp.com properly shows my app.
What I want is to have my site hosted at https://myapp.com.
I ran heroku certs:auto:enable, but it shows:
=== Automatic Certificate Management is enabled on myapp
Domain Status
───────────────── ───────────
www.myapp.com Failing
Running heroku domains shows:
=== myapp Heroku Domain
myapp.herokuapp.com
=== myapp Custom Domains
Domain Name DNS Target
───────────────── ───────────────────────────────
www.myapp.com www.myapp.com.herokudns.com
Right now, in Google Domains, I have a Subdomain Forward from #.myapp.com to http://www.myapp.com. I also have a Custom Resource Record with the name www, type CNAME, and data myapp.herokuapp.com..
What do I need to change in my setup so that I can host my site at https://myapp.com?
Unfortunately, Google Domains does not support the ANAME or ALIAS record. You must use one of these for your apex domain. Here's the full list supported by Google Domains.
https://support.google.com/domains/answer/3290350
Heroku has a list of DNS providers that support the ALIAS or ANAME records here: https://devcenter.heroku.com/articles/custom-domains#add-a-custom-root-domain Personally, I use DNSimple and have had great success with them.
The CNAME target needs to be www.myapp.com.herokudns.com. In your question above you only have the apex record in your DNS in myapp.com.herokudns.com. If this is not the case can you share the domain so I can dig the record for more information?
I've had the same problem with Heroku and other PaaS providers over and over: depending who provides and manages the DNS for your domain you may or may not able to use a CNAME or ALIAS record on the naked domain. That's why we've created a simple service to solve this by applying a simple SSL redirection from the naked domain to the "www" under SSL, without changing your DNS management provider: NakedSSL will give you an IP and will create and host an SSL certificate for your naked domain (https://yourdomain.com), redirecting it to the HTTPS URL that you want (most likely "https://www.yourdomain.com").
Disclaimer: I'm obviously part of the team that created NakedSSL. I hope you don't take this as self-promotion (anyway we offer it for free for 1 domain, which totally fits the needs of 95% of developers/hobbyist out there), but as a way to deal with this annoying situation in an easy way.