I work for a company which has its own web server they are due to have a complete power blackout over the weekend, meaning their servers will be down.
Does anyone know a way we could present a down status on a maintenance page or some kind of redirect so we can at least inform our users that the site is down for maintenance and not just missing/broken?
The best way is probably setting up a redirection to dummy server on your load balancer or border routers. If you have no such thing, then you can either try asking your provider about the options, or temporarily change the DNS record, provided that you reduce DNS cache timeouts before and after the change, so it takes effect immediately.
Set up a server on another location and point their domains DNS record to that server during the blackout.
The redirect has to be carried out by the web server. No web server, no redirect. What you can do is to get another web site by a web hosting company (which will not be subject to your blackout), and configure it to route requests from your main dns to the temp site with just a plain notice html page, then remove it once power is restored. This can be done if you have the dns info from the primary site. You could also mirror the site this way, and then shut down the mirror and no one will be the wiser. Try http://siteground.com I have used them for years.
If you are using a load balancer, see if it supports a "Sorry Server" page. Most of them have this feature built in.
Related
I have a domain which I am forwarding. I have updated the DNS successfully and the redirect seems to work, however if the url is accessed via a google search it still goes to the old site and ignores redirect
Can anyone help me understand what might be going on here?
First of all google search database takes some time... even days to update. So if you have changed domain name recently wait for some time/days until google crawls your site again.
For now you may use redirect... for that you should keep your server reachable with old domain. Also adjust/change old server config so that it should accept request and then redirect to the new site.
If google feels end user is being redirected to another site... google.com may think something is fishy and it will stop redirecting.
So in your old site
load the page as expected.
then prompt the end user... Site has been changed/updated, your request is being redirected to the new site. Sorry for inconvenience
After redirect... user will be happy to see site.
Are you sure that your DNS request isn't cached? You should flush your DNS cache:
https://superuser.com/a/547218/129262
After that use a terminal on your PC an ping your domain. Is the returned IP the new or old one?
And finally do a search in Google through an inkognito tab of your browser as your browser caches redirects as well (or delete the browser cache).
I have searched for this and found answers that do not work in my case. I would appreciate some thoughts on this
I have set up a github page at: https://ir-ischool-uos.github.io/mwpd/
Some users reported that when they visit the page, an error about security is displayed, like this on Chrome:
- However, many users say it works ok for them.
I have found some sources say that this only happens if your link contains 'https' instead of 'http', but tested on two computers, one mobile phone and one tablet they both work fine. I also found source that say I should use GitHub page's https support, and I checked my setting this already is ticked.
Is there anything I can do to fix this for every user?
Thanks
This error could happen because of numerous of reasons. For example:
The server certificate (or at least one of the certificates in the chain of trust) is not among the trusted certificates that the browser/system maintains (maybe an outdated list?). Try to update the browser/system.
The date/time on the system is not configured correctly.
The connection is being intercepted (by an attacker?) and the certificate is manipulated, hence the SSL connection handshake process could not complete.
Your connection is not private error appears on websites using the SSL / HTTPs protocol when a browser is unable to validate the SSL certificate issued by the website.
Basically, any website using SSL / HTTPs protocol sends a security certificate information to users browsers upon each visit. Browsers then try to validate the certificate using the public key accompanying the certificate.
If it checks out, then users browser encrypts the data using the private key sent by your website. This encryption secures the data transfer between a user’s browser and your website.
I have checked it accross 3 different connections and they all worked just fine.
I believe the problem could be from the users. They may need to clear their cache, check if their clock is set correctly, their antivirus could be stopping it. And their browsers may be outdated.
What I will advice is just (https://support.github.com/contact). They could check to verify if this is an issue from the server or not.
But from what am looking at, this may be an issue with the user's device.
Also here are a few links you could refer and see if all settings on your own part are rightly set;
[1] https://github.com/docsifyjs/docsify/issues/236
[2] https://help.github.com/en/github/working-with-github-pages/securing-your-github-pages-site-with-https
[3] https://help.github.com/en/github/working-with-github-pages/troubleshooting-custom-domains-and-github-pages#https-errors
I hope this helps. Let me know!
If you are using a school/college wifi, most probably someone has your credentials and he/she is using it at the same time as you so basically when he/she is using the web you'll get this message, you should probably change your password or switch on VPN.
If the WiFi/other network used to access the website in question is a school or public network, some 3rd-party software used by it's administrator might be trying to prevent or override the connection to your website.
That might happen in order to display an error message (e.g. "Website access prohibited"), a captive portal (network login window), or just to watch the data being sent around.
Since you're using HTTPS it was prevented when the certificate check failed, because with HTTPS in place that software has no way of presenting it's own page or eavesdropping, other than creating it's own certificate with your website name in it on the fly. Which, of course, was rejected by the browser, since either the user didn't expect it, or, if it's indeed a school/company network, the PC wasn't properly enrolled for use on the said network.
Either way, there is no problem with your webpage itself. Because Github manages the server for your Pages, chances you could create something causing that problem yourself are pretty much zero.
Sometimes it happens because of the wrong IP/DNS settings. Checking the below places might help resolve the issue:
Make sure you are using a common public DNS server. How to check the DNS server you are using depends on your operating system. Moreover, if you are using a VPN client and it has a DNS configuration, check that setting too.
Check if there is an IP address associated with GitHub in the system's hosts file. In Linux and macOS you may use sudo vi /etc/hosts. If there is one, turn that line into a comment by adding # at the beginning of the line. Save, exit, and check if you see that error again. Do step 3 only if you are still getting the same error.
Go to https://www.ipaddress.com, search for github.io, and add its IP address at the bottom of /etc/hosts file like this example: 140.82.114.4 github.io.
Hope this helps.
My domain wheelofnames.com used to point to a web app hosted on Google App Engine. I made the app a Progressive Web App (PWA) using Workbox. Two days ago I moved the app to Firebase Hosting, which meant I had to update the DNS record for my domain.
Today, users visiting wheelofnames.com from a web browser get their content served from Firebase Hosting. This is as expected, as the DNS record for that domain points to Firebase Hosting. Perfect!
But before the DNS update, I installed the PWA version of the app on my Android device. When I open that PWA today, it requests content from App Engine, even though the DNS record for wheelofnames.com doesn't point there any more. Checking the App Engine log, I see other users having the same experience.
How does one get the PWA to follow the DNS record and request content from the new environment instead of the old? Do PWAs cache DNS data somehow?
The Cache Storage API (which Workbox uses under the hood) uses request URLs as keys, and Response objects as values.
While DNS resolution is important when making the requests to populate the caches initially, once a Response has been saved, reading the response and using it later on happens without regard to DNS resolution.
It sounds like you might need to kick off a new build for your web app and give Workbox's precaching a chance to pick up the changes to any updated files, which would be the case any time you make changes to precached content, irrespective of what host is used "under the hood". Also not that because precached content is shown in a cache-first manner, you may end up seeing previously cached content immediately when you revisit a site, and it's not until the next visit (after all tabs have been closed) that you'd see the fresh content.
There are UX patterns that can allow users to opt-in to seeing new content immediately, as described in this recipe.
I have an existing COM domain with TTL 24 hours. I will be re-pointing the COM domain (A and CNAME records only) to a new website within a few hours.
The new website is already functioning with a NET domain, so it's live online. I'm leaving the COM domain DNS with the old hosting as we have email there.
To handle the 24 hour lag, can I use DNS URL redirects to send visitors to pages on the new, until propagation is complete?
Or can I use a simple HTML redirect to do similar job?
I think the DNS URL redirect is easier for me to set up but will it work, considering the COM will already have been changed?
First off, it's important to plan ahead. If you have a 24 hour TTL, lower it at least 24 hours in advance of the changeover. This would avoid your dilemma (or rather, shorten it to your new, lowered TTL)
From the description, it sounds like the .com and .net sites are identical. Since you didn't mention any database, I assume these are static sites that don't save data to a database. If so, you really could just leave the sites alone and not worry about a redirect. If you want to get people onto the new server asap, use a temporary HTTP redirect or an HTML-based one.
If you do persist data to a database, are you also migrating that at the same time or are the two sites using the same database server? Migrating database servers is a complicated affair, beyond what we can answer here.
(n.b. There is no "DNS URL" redirect. That's just a service that some DNS providers offer, built on top of HTTP and DNS. Setting it up would suffer from the same TTL lag time you're trying to avoid)
We are in the process of building a Multi-Tenant, SaaS type web app. Everything is set to go on the application part but when it comes to email there is a problem.
Each tenant/user of the application has a subdomain based account. However, there will be the option for that tenant to associate a top level domain to their account. Here is where the problem comes for us.
Basically, if the user sets up their DNS to point to our SaaS web app everything works good on the app front except that it now makes us responsible for handling their Email as well. Incoming and Outgoing.
What is the best way to handle this? I really was hoping their is a 3rd party site that handles outgoing and incoming email for multiple top level domains under one company name but am unsure.
There is always the option of doing our own SMTP/POP service, but we would really like to steer away from the responsibilities of email.
Thanks everyone,
~kvq
Can't they just setup an A record or a CNAME to point to your servers?
If they did an A record it would allow just webapp.theirdomain.com to go to your severs and everything else can just stay on their DNS.
The other option and maybe a better option is for them to setup a CNAME. Then you can just setup companyA.yourdomain.com and then they can just setup a CNAME that points webapp.theirdomain.com to companyA.yourdomain.com
You really do not want to be responsible for all of their DNS. They can keep their DNS where ever they want and keep their MX records the way they are.
I hope this helps