Problem with the main website

Hi Guys,
I don’t know if it’s just me, but it appears the root of the website and in particular the downloads page is completely blank.

https://ubuntubudgie.org/downloads/

For some reason all I’m getting back is an empty response, despite not visiting the page previously. Hard reload has no effect. Anyone know what I’m doing wrong?

If I try in curl I get;

$ curl -i https://ubuntubudgie.org/downloads/
HTTP/2 200 
access-control-allow-headers: Content-Type, Authorization
access-control-allow-methods: GET,POST
cache-control: private, must-revalidate
content-encoding: gzip
content-security-policy: upgrade-insecure-requests;
content-type: text/html; charset=UTF-8
cross-origin-embedder-policy: unsafe-none; report-to='default'
cross-origin-embedder-policy-report-only: unsafe-none; report-to='default'
cross-origin-opener-policy: unsafe-none
cross-origin-opener-policy-report-only: unsafe-none; report-to='default'
cross-origin-resource-policy: cross-origin
date: Fri, 12 Jul 2024 14:42:59 GMT
expires: Tue, 10 Sep 2024 14:42:59 GMT
last-modified: Thu, 11 Jul 2024 23:36:03 GMT
permissions-policy: accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(self), encrypted-media=(), fullscreen=*, geolocation=(self), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=*, picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), xr-spatial-tracking=(), gamepad=(), serial=()
referrer-policy: strict-origin-when-cross-origin
server: Apache/2.4.56 (Debian)
strict-transport-security: max-age=63072000
wpo-cache-status: cached
x-content-security-policy: default-src 'self'; img-src *; media-src * data:;
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-xss-protection: 1; mode=block
content-length: 0

I made an account just now to report his very issue. You’re not alone in this issue.

This should be fixed now. Empty the cache and the page should be visible.

2 Likes

Cool … works :slight_smile: , although I did need a shift+reload for each page to make them appear. Just as a matter of interest (as someone who has to maintain a bunch of online stuff) can I ask what the problem was?

The issue was mostly with logs eating the disk space, and not being auto deleted, thus growing in space until there was no more space, causing the website to not load.

ahh, Ok, just wondered if I was missing some new exotic CF caching issue or some such :slight_smile:

Incidentally, it looks like you might be using Wordpress (?) , we also use Wordpress and have always had problems from time to time (whether disk space, incompatible plugins or ddos attempts).

We’re now running a plugin that creates a static version of the site in GitLab, which then automatically deploys to CloudFlare pages (free tier). Then when you update the site, it creates a delta followed by an auto-commit and PR. Free, very quick, and never (yet?) goes down … it means an extra click when you want to publish a new version of the site (and maybe a couple of minutes delay) but it does mean not having to rely on Wordpress staying up.

I’d like to say that as a result I get more sleep, but I’m sure there’s a saying along the lines of “computer problems expand to fill all available time” … :wink:

2 Likes

That is exactly what we are planning to do. It looks like you are reading my mind. Basically the idea is to use the static version for the website that will be updated only when there are major changes done to the website.

Most of the reasons why the WordPress dies in this case is due to docker file writing or MySQL being overwhelmed.

Is the plugin maybe called Simply Static? This is the one I am currently testing.

1 Like

Erm, yeah, no I tried that one too … unfortunately, for various reasons it wouldn’t work for me. Size and time was a bit of an issue, I kinda needed something that was completely automatic and reasonably timely. I also needed an automatic an A+B testing function given static generation is always subject to oddities esp. with some JS plugins.

It looks like you are reading my mind

:slight_smile: I run a few WP sites and come the beginning of this year, despite help from the likes of CF, concluded that many WP users must be in the same boat re; up-time and maintenance and in 2024 we should really have access to “fire and forget” web publishing.

The plugin I’m using is currently in the WP approval queue, so it’s not available in the directory yet, but hopefully it will be within the next month or so. Their backlog seems to be around 35 days and it’s been in the queue 3 weeks or so.

I have around 4000 assets (~ 2500 pages) many of which are interlinked, so categories, associated articles etc, so one change typically ripples to “many” changes pages / posts. The Wordpress site is running on my desk on a Raspberry Pi5, inside an Incus container, running a Debian Bookwork cloud image. Live site is published on CF pages … so the previous dedicated DO instance is no more. A “full sync” after a few days worth of changes typically takes ~ 10 mins, then maybe 30 seconds for CF to detect the change and re-deploy.

So I now publish to “test.domain” to make sure it’s all good, then directly to “domain” when I’m happy.

I’m not sure what the forums rules are so I won’t post any links, but feel free to DM me if you want more detail or something to test … :slight_smile:

1 Like

Yeah understandable. Feel free to send me DM. Would love to have it automated to be honest.

1 Like

Hmm, I made some assumptions based on my experience with Discourse, however it would seem I don’t have access to DM’s here (?!). Not sure if I’m too “new” or if they are disabled site-wide … do you have a point of contact I could use? If not, if you could head over to our forums at “linuxforums.org.uk” you can DM me there as “madpenguin”. (or if you prefer, “chat.linux.co.uk”)

1 Like

Try now. It is probably due to your account being new. It should be fixed now.

1 Like