Display static error page while site is down

[piffy]

What I want to do is serve a page saying “this site is under maintenance” when it goes offline during, for instance, the rebuilding process.

Add an offline page to display when Discourse is rebuilding or starting up

This guide is intended for advanced users, who are already using nginx outside the docker container. By following this guide you make your setup more complicated and will loose some speed benefits like HTTP2 if you’re not running Ubuntu 16.04 or later. Proceed with caution! When Discourse is rebuilding or starting up, your users will usually either see an error message from their browser… [image] …or a not-so-nice 502 error message from Nginx: [image] If you’re a perfectionist l…

This topic is basically what I’d like to do but seems to require a nonstandard setup. Is there an easier way to do this for a standard installation? Thanks!

[Falco]

@piffy

Is there an easier way to do this for a standard installation?

No, there is not anything like that at the moment.

[Alexander (Alexander Barrios)]

In reality, this procedure uses what is considered a “standard installation” (i.e. using the official Discourse Docker guide), to which Nginx is redeployed outside of the container.

The procedure seems scary at first, but it really isn’t, I can help you if you want.

[piffy]

@Falco

No, there is not anything like that at the moment.

Not the answer I wanted to hear, but I appreciate the unambiguous answer nonetheless

@Alexander

In reality, this procedure uses what is considered a “standard installation” (i.e. using the official Discourse Docker guide), to which Nginx is redeployed outside of the container.

The procedure seems scary at first, but it really isn’t, I can help you if you want.

I am not too worried about the process, moreso whether this setup will require any additional considerations when doing simple things in the future like installing a new plugin. Or is it mostly something that once it’s set up I don’t have to think about it again?

[ClawdiaWolf (Claudia)]

@piffy

Or is it mostly something that once it’s set up I don’t have to think about it again?

Since I added NGINX for this back in 2020 I’ve had to edit the config twice. Both times it was adjust settings related to uploading large files after updating the limit in Discourse.

Using the external NGINX to provide the static page and act as a reverse proxy for Discourse normally doesn’t require changes once you have it setup properly.

[mcdanlj]

Note that the external nginx brings something else valuable besides the static error page: Correct attribution of source IP addresses for IPv6 users. If your forum is accessible via IPv6, and you do not use the external nginx configuration, everyone accessing your site via IPv6 will show up as coming from a 172.x.y.z local address. This doesn’t help when you are trying to deal with malicious site users like spammers!

@piffy

I am not too worried about the process, moreso whether this setup will require any additional considerations when doing simple things in the future like installing a new plugin. Or is it mostly something that once it’s set up I don’t have to think about it again?

It’s exactly the same for adding new plugins.

I think that it makes it easier to update because you know that your users will be made aware of maintenance and just wait for it to finish.

The one thing I can think of that you want to be sure of is that you have certbot correctly renewing your certificates. That’s built into the default configuration that doesn’t use external nginx, but if you use external nginx, you also have to use external certbot and have to make sure it is set up to renew your certificate. And not all ways of installing certbot handle this.

Note that the documentation you asked about says:

If you installed certbot from your package repository, renewals usually happen automatically. Otherwise, set a reminder to run letsencrypt renew && systemctl reload nginx.service before your certificate expires!

Setting a reminder is not a good way to do this, though. You’ll inevitably forget, and if you miss an email from letsencrypt warning you about the expiring certificate your site will quit working. Fortunately, this is easy to work around.

If automatic renewals aren’t set up, here’s how to do it.

Create the file /etc/systemd/system/certbot.service with these contents:

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

Create the file /etc/systemd/system/certbot.timer with these contents:

[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

Then tell systemd about the new files.

# systemctl daemon-reload
# systemctl enable --now certbot.timer

[pfaffman (Jay Pfaffman)]

If you use a two container setup the down time is under a minute and you don’t really need such a page.

[Jagster (Jakke Lehtonen)]

After some searches here it is quite clear that maintenance of two containers is way more demanding job than Nginx. At my level of skills anyway.

[pfaffman (Jay Pfaffman)]

Ah. I see. From my perspective it’s almost the she except you do have to pay attention to when the dates container needs to get updated, which is infrequent, but you do have to pay attention. And when that happens, the site is down for a while.

[Jagster (Jakke Lehtonen)]

That’s true too. It is always trade off — the time how long a forum will be down because of updates/upgrades vs. the time that maintenance of separate containers craves (and specially when you (read: I) mess up everything and start trying to find some fixes and forum is down same time )