Both the Linux-laptop I name ‘Klystron’, and the server of this Web-site, this server being named ‘Phoenix’, received a major update this evening. On ‘Phoenix’, a total of 78 packages needed to be updated, including a Kernel-Update, and a Graphics-Driver Update. This collective update effectively converted both computers from Debian 8.7 to Debian 8.8 systems. And both updates appear to have succeeded, at first glance without breaking anything.
However, this was an update that required a reboot for ‘Phoenix’, even though this is my Web-server, and so my site was also down briefly, from approximately 20h40 until 20h50.
I am happy to say however, that ‘Phoenix’ had been running for 58 days straight, without requiring any reboot whatsoever until tonight.
Oh, but I must disappoint some of my readers with the fact that performing these updates also required I restart my ‘
memcached‘ service, which means that pages or postings the readers like to visit most often will be a bit slower to fetch, until this server-side caching is replenished.
One of the facts which I have written about before, is that my blog is set up in a slightly customized way, with core PHP files that come from the Debian package manager, and which do not have permission bits set, so that the Web-server can write to them, but also with add-ons – aka plugin-ins – with permission bits set so that the server can. This latter detail is a great convenience for me, because it allows me to install plug-ins from WordPress.org, as well as to install updates to those, via means that are simple for me to operate.
What I have also written, is that this makes my overall security good, but not perfect. Theoretically, there could be a corrupted plug-in available directly from WordPress.org – even though in general, they do their best to vet those – and which I could install to my blog, without knowing it. Further, even if the plug-in contains no dirty code visible to WordPress.org, the way some of them work might depend on a Web-service from their author, and then that URL could be running some sort of suspicious scripts, let us say on yet another server.
And so a reasonable question to ask might be, of what use WordFence can be in my case. One of the types of scans which this security add-on performs, is a check of all my core files, against what the versions are with WordPress.org, not with Debian. And then this scan reports 58 deviations to me, without analyzing them, just because Debian has slightly different core-file-versions. It also checks my entire plug-in directory, scans all the plug-ins, etc.. But in reality, WordFence never reported any kind of anomaly in my plug-ins, because those are the WordPress.org versions.
Continue reading WordFence
This evening, a very deep upgrade was pushed through the package repositories, affecting my computer. This update included 108 packages, included the core C libraries, and converted my Debian 8.6 system into a Debian 8.7 system. Such an update requires we do a reboot, even though we are using Linux.
Because I host my Web-site on my private server at home, this meant that my site and blog were offline from about 22h40 until 22h50. Further, even though my ‘WordPress’ blogging engine has a ‘Maintenance Mode’ window that in can display, this window requires that the Web-server be running to display, while maybe maintenance work could be underway on WordPress itself. Therefore, it was not an option for me to display this, because my whole Apache server was briefly offline.
I hope that this 10-minute interruption did not pose an inconvenience to any of my readers.
Having said all that, it looks on the surface as though the upgrade was a success, and was not botched in any way – thus only the very short reboot interval.
Oh yes. Because my caching daemon was also restarted, the Web-server aspect of this blog will be slightly slow for the next day or so.
I think it is a bit my own fault, for not explaining in a clear way, what the difference is between WordPress.com and WordPress.org .
WordPress.com is a specialized blog-hosting site, on which members can write their blogs, but which runs on professionally-maintained servers, by WordpRess.com .
But, the people behind this service have also made the PHP Scripts available for free, that run on the server, and that cause the HTML to be generated, which causes proper WordPress blogs to appear on the browser of the reader. People may download those, and may upload them to whatever Web-server they have access to, provided that that Web-hosting service, also supports the running of server-side scripts, by the Web-hosting service members. Some Web-hosting services put a lot of restrictions on what their members may publish, such as static HTML Pages only, or such as no access to any MySQL server, the latter of which WordPress.org uses actually to store the blogs.
And so, because this support-factor is the main part of the expenses incurred by WordPress.com, I will assume that sharing their core scripts poses no perceived threat to them. Their main expense is not, that core set of PHP Scripts. But, because an individual may have problems setting all this up as well, there is an associated Web-site, namely WordPress.org, where independently-hosted WordPress users can go for tech support, and to download plug-ins.
Continue reading I use WordPress.org, not WordPress.com, for most of what I subscribe to.