And Now, Memcached Contributes to This Site Again!

According to this earlier posting, I had just uninstalled a WordPress plugin from my server, which uses the ‘memcached‘ daemon as a back-end, to cache blog content, namely, content most-frequently requested by readers. My reason for uninstalling that one, was the warning from my WordFence security suite, that that plugin had been abandoned by its author.

Well, it’s not as if everything was a monopoly. Since then, I have found another caching plugin, that again uses the ‘memcached‘ daemon. It is now up and running.

(Screenshot Updated 06/19/2017 : )

memcached_7

One valid question which readers might ask would be, ‘Why does memcached waste a certain amount of memory, and then allocate more, even if all the allocated memory is not being used?’

(Posting Updated 06/21/2017 … )

Continue reading And Now, Memcached Contributes to This Site Again!

Memcached no longer contributes, to how this site works… For the moment.

One of the facts which I had mentioned some time ago, was that on my Web-server I have a daemon running, which acts as a caching mechanism to any client-programs, that have the API to connect to it, and that daemon is called ‘memcached‘.

And, in order for this daemon to speed up the retrieval of blog-entries specifically, that reside in this blog, and that by default, need to be retrieved from a MySQL database, I had also installed a WordPress.org plugin named “MemcacheD Is Your Friend”. This WordPress plugin added a PHP script, to the PHP scrips that generally generate my HTML, but this plugin accelerated doing so in certain cases, by avoiding the MySQL database look-up.

In general, ‘memcached‘ is a process which I can install at will, because my server is my own computer, and which stores Key-Value pairs. Certain keys belong to WordPress look-ups by name, so that the most recent values, resulting from those keys, were being cached on my server (not on your browser), which in turn could make the retrieval of the most-commonly-asked-for postings – faster, for readers and their browsers.

Well, just this morning, my WordFence security suite reported the sad news to me, that this WordPress plugin has been “Abandoned” by its developer, who for some time was doing no maintenance or updates to it, and the use of which is now advised against.

If the plugin has in fact been abandoned in this way, it becomes a mistake for me to keep using it for two reasons:

  1. Updates to the core files of WordPress could create compatibility issues, which only the upkeep of the plugin by its developer could remedy.
  2. Eventually, security flaws can exist in its use, which hackers find, but which the original developer fails to patch.

And so I have now disabled this plugin, from my WordPress blog. My doing so could affect how quickly readers can retrieve certain postings, but should leave the retrieval time uniform for all postings, since WordPress can function fine without any caching, thank you.

memcached_1

Dirk

 

WordPress Debian Update Today

I use a version of WordPress to host my blog, which is very similar to the versions offered by WordPress.org, but which have been tweaked by Debian Developers, to add security, as well as to increase compatibility with Debian Linux.

But, it’s my personal habit to operate this platform with the ability to install plugins and Themes from the WordPress.org site. Making this available involves some trickery with symlinks and with directory ownership. Yet, WordPress itself is designed with flexibility in mind, when it comes to local configurations. So it tolerates this as a platform.

But from time to time, Debian Maintainers push through an update to their core version of WordPress – which I am using. I happen to have my core files installed in ‘/usr/share/wordpress‘, while I have my extensions installed in ‘/var/lib/wordpress/wp-content‘. The permissions and ownership for these two directories, as well as their subdirectories, involves two different settings in my configuration. One directory, with all its subdirectories, is not writable by the Web-server, while the other is.

When Debian Team pushes through one of these updates, it can break how my personal localization works, because Debian Team is inherently unaware of how any systems may be configured, which are not Debian. This is a bit like how Microsoft programmers inherently don’t understand anything which is not Microsoft.

Sometimes I have installed the update to the core files, without any issues, but sometimes, some additional, manual work is required on my part, to ease the update.

This afternoon, the core files installed fine, and left me with a working blog. But there exist some Themes and plugins which need to be installed from the package manager, to ensure a working site, but of which I usually have the latest versions, from WordPress.org instead. The packaged versions of these Themes and plugins generally tend to lag behind, the most up-to-date versions from WordPress.org.

This means that after one of the core updates, I typically need to reinstall the update, to whatever Themes and plugins the package-manager update has rolled back.

This morning, that added step in my procedure ran into some trouble. But, I was able to resolve the issue in little time, and my blog seems to be at 100% again.

Now, I do have a plugin which puts up a Maintenance Mode page, for as long as I like. But generally, I find that this plugin only hinders me. For one thing, if some type of mess results on my hard drive, having this page enabled could prevent me from disabling it again, and from fixing the issue. Secondly, whatever maintenance I do, is generally finished within 15 minutes or so. So I generally don’t use this plugin.

This afternoon, I began by allowing the core update to take place around 13h30, at which point the blog was still displaying fine. But I ran into issues getting the “TwentyFifteen” Theme back up-to-date, which would have caused any readers to see artifacts when trying to view my page, which were all gone and repaired by 13h45.

So for 15 minutes, readers might have seen some artifacts. If you did, I truly apologize. If I had used the Maintenance Mode plug-in, then doing so would have made my manual procedure more complicated, so that you might have seen the Maintenance Mode page instead, all the way until 14h00. In other words, the task could have taken twice as long to complete than it did.

My official WordPress version is now ‘4.1+dfsg-1+deb8u14‘. And it works again.

Dirk

(Edit: There exists a phenomenon in Human Psychology, with a name I forget. Essentially it amounts to stubbing one’s toe on a table-leg, and due to the unexpected or even inconvenient timing of the pain, blaming the table-leg for the accident. In retrospect, now that this pain is gone, I’d say this SNAFU was entirely my own fault.

Continue reading WordPress Debian Update Today

Malware Alert to all my Readers!

Even though my Blog is hosted on a supposedly-secure Linux machine, on which the core WordPress Files have permissions set such, that the Web-server cannot write to them, there is always some slight danger, that an infection can make its way onto my blog, through plug-ins which I have installed, which come from the WordPress site, but which are not under the scrutiny of the Debian software team, who created my WordPress core files. My Web-server can also self-install updates to those plug-ins, from their respective owners, because the write-permissions of the plug-ins directory are such that it can. ( :1 )

The reader may have noticed that there used to be an icon in the bottom of my postings, which allowed him either to Print the posting, to Save it as a PDF, or to Email it elsewhere. This icon was due to the ‘PrintFriendly Plug-In‘.

This plug-in did not even install any suspicious code on my server, but is cloud-based, in that any use made of it will redirect to the Web-site and servers, belonging to PrintFriendly. Not only that, but the icon itself can contain links to their site.

Well today I did notice, that my Web-browser, when pointed at my own site, tried running scripts from a site called ‘kxcdn.com’, and which my own browser had the installed extensions to block. This raised an alarm-bell in my head, and I went into action, looking for any contagion.

The PrintFriendly plug-in, or more correctly, their site it pointed to, was the source of that contagion. Deactivating that plug-in has now taken away the capability of the readers, to Print, to PDF or to Email my postings. But it has also removed any of the malicious attempts to redirect to ‘kxcdn.com’. The threat has effectively been neutralized on my server.

But, If You Did open that site, it would possibly have led you to This Situation. If it did, I hope you did not fall for their ploy. I apologize profusely if this happened to you, and do my best to control such problems from the first moment I notice them.

I have now installed the WordPress-security-extension ‘WordFence‘, and hope that this will reduce any vulnerabilities in the future.

Dirk

1: ) Actually, before my WordPress instance can update its plug-ins, I need to authorize the event. However, this safeguard only determines at what time updates can take place in practice, and just might make me aware of some suspicious activities that have yet to happen. It does not actually control, what code is inserted in the update.

However, as of now WordFence does control this, and has given me a clean bill of health!

wordfence_1