apache – Holland Numerics: Blog and Forums

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!

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!

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

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:

The server’s Ubuntu operating system was upgraded from 16.04 to 18.04 on 18Aug2019.
The Apache WordPress server was unaffected, but my Apache cloud server refused to start due to a PHP incompatibility.
The cloud server software was then upgraded to use PHP7.2 instead of PHP7.0, but the server still refused to start.
More PHP7.2 modules were downloaded and installed.
The PHP configuration in the Apache cloud server was changed from PHP7.0 to PHP7.2, and it now started.
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.
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!

Scheduled blog server maintenance in the evening of 17Jul2018 (UK time)

My blog server runs WordPress software, which I can update hourly while the server is running, if necessary. However, the underlying Apache, PHP and MySQL software requires server downtime to update, so I have scheduled their updating to take place in the evening (UK time) of Tuesday 17 July 2018. I am hoping it will only take 1-2 hours to complete, but, having never done this big an update before, I can’t be more precise.