## Routine PHP Update This Morning

This morning, the computer that hosts my Web-site received a routine update to its PHP 5 interpreter – i.e. to some of the modules of its PHP 5 system – which also triggered a routine restart of the Apache server processes. This has taken place without causing the slightest disruption to my site.

What most Linux-based services do, during a log-rotation, is also to restart, so that after the log-files have been renamed, the services obtain a new file-handle as well, and so that the actual writing of log data resumes with a newly-created log-file. Apache tends to be atypical, in that one of its available commands is to reload its configuration and/or its log-files. Thus, usually, the main Apache service just keeps running.

Technically, this morning, the Apache server was gone for two seconds. But, if an average reader was to find that this interfered with his browsing, he would have been able to fix that, just by clicking on the same URL a second time.

Also, my blog consists of PHP scripts, which every HTTP request executes independently of the other requests. Persistence is achieved by browser-scripts, and by a MySQL database which the server-scripts access. So there is also no loss of persistence, of my site, arising from an Apache server restart.

Dirk

## Routine MySQL Update Successful Today

I use a system for updating my packages, which is named ‘unattended-upgrades’, and which I have blogged about before Here.

This morning, that system updated my MySQL server, which is also important to this blog, because these blog entries are in fact stored in a MySQL database. The way my blog generally works, each HTTP request causes a PHP script to be executed independently on the Apache server, and the PHP extensions I have installed, include a MySQL client. This part of the PHP scripts fetches the blog content, while other parts of the scripts format it as HTML, according to the Theme which I have chosen to install some time ago.

The individual blog entries do not actually form separate files or folders on my Web-site.

Also, it is an explicit WordPress Plug-In, which tries to retrieve the already-formed HTML from my server cache, If the HTML being requested has been cached. That Plug-In is named ‘Memcached Is Your Friend‘.

The fact that my blog still displays properly, indicates that the MySQL database is operating normally. After the upgrade, the scripts also restarted this server briefly. And, the fact that this server has been restarted, does not affect the cache, nor the speed of the blog, because the ‘memcached’ daemon is a separate process which did not receive any update or restart.

Dirk

## An Oddity which greets me, When I Log In to my Blog Each Morning

One of the facts which I have written about at length, is that I take the somewhat unconventional approach, of hosting my own site, on my own server at home.

And while my site has different parts to it, one important part to it is this ‘WordPress.org’ blog.

One of the facts which I have learned about WordPress.org, is that it serves requested pages using PHP Scripts, that run synchronously. Thus, if the script was to stall in its effort to return a value – a quantity of HTML – then the user / client could be staring at a browser, with a spinning wheel that says it is waiting for the page to be fetched – for quite a long time.

But I am still quite comfortable in the idea, that this only affects my blog in unimportant ways. For example, if the blog-engine is looking specifically for updates to any of its plug-ins, then it is waiting for the site of every plug-in author, to report back to it, whether one plug-in has an update pending.

Since my instance of WordPress.org has about 20 plug-ins installed, the probability that one plug-in author could not be responding, is not equal to zero. Yet, the PHP Script that is looking for any updates, is still running synchronously.

What some people might think, is that in such a situation, all they would need to do is contact the same site again, from the same browser, and thus force a new thread to serve them. But this is actually in error, because my Apache server is set up, to delegate one session, to one Apache sub-process. Thus, my server will recognize, in this case, that the IP address connecting is ‘127.0.0.1’, and it will send further requests for the page, back to the same sub-process, which was given the task to serve one session. This server is session-aware and optimized to be so.

Also, when I want to look at my WordPress.org Dashboard, the first time I do so in the morning, the server thread responsible for ‘127.0.0.1’ also includes a new search for plug-in updates. So I can sometimes wait for a while. After that, all my access-requests to my Administrative Dashboard, become fast as easy again.

I am confident that this mainly affects my ability to fetch certain pages as the Administrative Identity, and that this has not yet affected clients / browsers, who simply want a page of my blog served out. If it was to affect them, there would be a more-serious problem for me to address.

If this has affected You, I recommend you tell me about it, by leaving a Comment.

Dirk

## A New Solution, To Independent Web-masters Wanting SSL Certificates

One of the subjects which I have written about, was that it was difficult for small-time Web-masters to obtain SSL certificates, responsible for giving httpS:// URLs, and for allowing secure connections to the server. And this seemed to be true entirely for reasons of profit, ironically even though the Internet today is focused strongly on wanting to provide security and privacy, via httpS:// specifically.

In my own, past efforts to obtain such a certificate, which is based on Public Key Cryptography, I turned to the Certificate Authority named ‘‘. But one drawback in using their free services, is the fact that their acceptance is not bundled with most browsers, and the official reason for that is, apparent audit failures in the past.

This meant that whatever httpS:// URLs I did have, would only display error messages in the browsers of other people, unless steps were taken to install their manually. And this can wreck the entire purpose of having a Web-site.

Well there is a new game in town, which I have started to subscribe to, named ““. The premise of this provider is, that they can carry out all the authentication steps via automated robots and clients, yet satisfy all the requirements – and Oh Yes, They Are Free.

Since I have started using , you may notice that all the URLs which I had offered as http:// in the past, now also have an httpS:// version. You can try to access the following link via SSL below:

Mini-Showcase

I must warn you though, that if instead, you would like to open this blog using SSL, you will get an icon warning you that certain objects in this part of my site are non-secure. This message appears because I have many URLs, including images, embedded into my blog as the older http:// variety, and know of no fast way to convert all of those into httpS:// URLs. Hence, by its nature my blog will continue to display this mixed content, partially SSL and partially not, and for that reason I see no benefit to you, of accessing it via SSL.

Also please note that at the time I am writing this, there is no site. This may change in the future, but for now remains absent.

In This Preceding Posting, I wrote about a bizarre error, according to which the domain name did not resolve properly to my real IP address. As far as I can tell by now, this error was of limited scope. But even as such, it seems like such an unlikely error, that I feel I may be missing some obscure explanation of what happened. However, to the suggestion that the whole resolution of what the command


host dirkmittler.homeip.net



produced, was merely a trick which my sleep-deprived mind was playing on me, does not wash, and the reason is the fact that this error actually prevented the authentication bots associated with from authenticating my site, simply because the server of this root CA, acting as a client, was unable to connect to my server, under the IP-address which was given.

Yet, I do wonder whether somehow, having installed the authentication robots / clients on my machine, might have made this error local, entirely to my machine, temporary as the error was…

And so the question can crop up, as to what, exactly, the purpose of is supposed to be for my server. And the answer is, that I wanted from the beginning to be able to embed my Mini-Showcase into my Facebook Page, which I and most other people access via httpS://, and into which I can therefore only embed that refer to httpS:// URLs of my own. And, which average Facebook members are supposed to be configured, to open easily.