Apologies for the 16 hour server outage today. Note to self: if an installation manual doesn’t mention something important, then don’t try it out in production!

Loading

Apologies for the 16 hour server outage on my SAS-related blog site today. I was trying to install Jitsi Meet, an open-source alternative to Zoom, on my server:

  • While it is possible to organise moderated meeting using the hosted meet.jit.si servers, installing a self-hosted copy of the open-source Jitsi Meet software alongside WordPress seemed to me to be a good idea, so that SAS training could easily be held locally.
  • By default standard self-hosted Jitsi Meet uses Nginx, not Apache, web servers, and assumes a fully qualified hostname, e.g. meet.hollandnumerics.org.uk.
  • What I wanted to create was an installation of Jitsi Meet in a sub-folder on my existing Apache web site, e.g. hollandnumerics.org.uk/meet, which is also part of a Bitnami stack, where software is installed specifically for use by the web server. This use case was not mentioned anywhere in the installation manual, although I did find a number of web forums that described similar environments.
  • That is where the problems started:
    1. To move Jitsi Meet into a sub-folder I had to edit the existing web configuration, the web pages to display the meetings, and the scripts to start the software.
    2. I also had to generate a self-signed SSL certificate for localhost.
    3. I had to reboot the server and restart the web service several times.
    4. Finally I discovered that some of my changes were lost whenever the Jitsi Meet software was updated.
  • At no point did I ever get Jitsi Meet to a point where I could run a test meeting, so I uninstalled it all.
  • Having uninstalled Jitsi Meet, I then couldn’t restart the web server to access WordPress, because something was holding onto port 443 (the secure HTTP port). At this point it was fast approaching midnight, so I decided to sleep on it.
  • Finally, this morning, I found that, when Jitsi Meet had been installed, it had added “Listen 443” commands to the default Apache installation, which conflicted with my Bitnami stack Apache server. Once these were removed my WordPress site suddenly reappeared!

Lessons learned:

  • When installing software you don’t fully understand, if the installation instructions have no information explaining what you should do, don’t just do it anyway!

Thank you for your patience!

My internet service provider has changed and normal blog service has resumed!

Loading

My company’s internet service provider has now been changed from Plusnet to XLN, and I did get the expected disruption, but not quite in the ways I expected:

  • On 03Dec2020 Plusnet switched off the static IP address at 0416 on 03Dec2020, so the blog server could not be reached until XLN supplied a new static IP address at 1520 the same day.
  • However, the router XLN sent was faulty, so the Plusnet router continued to be used until a replacement router arrived on 05Dec2020.
  • Unfortunately I was a little too eager to replace the router, and forgot to update the network gateway in the server for that new router. I did not realise why no-one could access the server from the internet until 06Dec2020, and corrected the network gateway address.

So, as promised, after several days of head scratching, discussions with network engineers, network testing and updates, the blog server is open for normal business again!

I’m now looking forward to writing some SAS-related blog posts.

Thank you for your patience…………Phil

My internet service provider is changing on 03Dec2020, so I’m expecting some disruption

Loading

Our internet service provider is scheduled to change on 03Dec2020 (from Plusnet to XLN), so we’re expecting some disruption. We may be very lucky and the outage during the changeover is very short, but, as we can’t say when during the day it will be, it would be foolish to predict anything in advance. All we can say is that the site will be back after the changeover.

Thank you in advance for your patience…………Phil

Apologies for the blog #outage due to #Plusnet and #BT #OpenReach

Loading

Apologies for the blog outage due to Plusnet and BT OpenReach that shut my blog site down for nearly 2 days from 17Nov2020 until 19Nov2020. I created this blog site back in October 2016 and have had Plusnet as my broadband internet provider since then, but my broadband connection ceased at 1540 on 17Nov2020 due a “major local outage”. I contacted Plusnet immediately and they assured me that the problem was likely to be resolved overnight. The following morning the outage was still there, and Plusnet passed the problem over to the faults team at BT OpenReach, as Plusnet is owned by BT, and BT OpenReach maintains their broadband network. That was the last time I heard anything from Plusnet, and I’m still waiting to hear from BT OpenReach. I’m now looking for a replacement broadband internet provider, so that I can reliably:

  • work with my clients.
  • reconnect my blog site.
  • start using my “free” WiFi, instead of my mobile data allocation.

Stop Press: As you can now see, my broadband connection has just been restored after being disconnected for 42 hours, but I’m still investigating replacements!

If anyone asks me for a recommendation for internet and mobile phone contract providers, I can give them a growing list of “do not contact” companies:

  • Vodafone – they disconnected my mobile phone while I was discussing my phone contract with them on a landline, and you can wait for hours on their support lines.
  • Plusnet – while they will tell you that their customer service is wonderful, their broadband service depends heavily on BT OpenReach.
  • BT OpenReach – don’t use any company that relies on them, because they have one of the worst customer services in the UK!

SAS-related blog server report: Outage due to swap space failure

Loading

Please accept my apologies for the outage on my SAS-related blog server. Although I’ve not yet determined the exact cause, the outage itself affected the server’s swap space, which effectively prevented anyone, including myself, from accessing the blog site.

I’ve taken the opportunity, over the last few hours, to make a number of system updates, which I’m hoping will prevent a future occurrence of this problem.

Thank you for your patience and support!

Apologies for the 9 hour server outage today, but I now know more about Apache and PHP!

Loading

Apologies for the 9 hour server outage on my SAS-related blog site today, but I now know more about the relationships between Apache and PHP:

  1. The server’s Ubuntu operating system was upgraded from 16.04 to 18.04 on 18Aug2019.
  2. The Apache WordPress server was unaffected, but my Apache cloud server refused to start due to a PHP incompatibility.
  3. The cloud server software was then upgraded to use PHP7.2 instead of PHP7.0, but the server still refused to start.
  4. More PHP7.2 modules were downloaded and installed.
  5. The PHP configuration in the Apache cloud server was changed from PHP7.0 to PHP7.2, and it now started.
  6. At some point in the updates the listening ports on the Apache WordPress server were also updated, so, when it was automatically restarted at midnight, it immediately failed due to duplicate ports.
  7. Finally, this morning, I corrected the listening ports on the Apache WordPress server, which is how I’ve been able to write this blog post.

Thank you for your patience!