WordPress.org needs to be adapted to Debian.

I guess that when many people blog, they may go directly to a (paid) hosting service for blogs. WordPress.com would be an example of that. But the assumption that seems to come next, is that people have a Web-hosting service already, with the privileges to FTP files up to it, and privileges to run (server-side) CGI scripts written in PHP. One type of software which they can then upload to this service, can be WordPress.org.

Hence, a lot of the assumptions made in the packaging of WordPress.org, are relevant to this usage scenario, including perhaps the need that can come up to solve technical issues, by tolerating possible configuration changes on the part of the blogger.

What I’m doing is a bit more out of the ordinary, to host my site on my own server, including to host WordPress.org. The way this Web-application is set up by default, it has a root or base directory, plus a content directory that underlies the root. Because many people simply upload this package to their Web-host, and then tinker with it until it works, it’s not an urgent need as seen by the WordPress.org devs, to fend off the root directory as having a username different from the username of the content directory.

But in my setup that’s how it is. And so, entirely because I, too, was tinkering with my setup, I did trigger an attempted core update, which would have rewritten the contents of my root directory. But, because this site’s root has different permissions set on my computer, the WordPress version I use was also unable to give itself a complete update. This is a good thing, because mine was initially installed via my (Debian / Linux) package manager, and I need to keep it compatible with any future updates the package-manager might give it. OTOH, sub-directories of my content directory are supposed to contain more-personalized information.

My enforcement of this was such, that the WordPress.org Web-application was unable to put the site into “Maintenance Mode”, in order to do its core-update. But the fact remains, that even if the site wanted only to update plug-ins or the theme that I happen to be using, this Web-application would still need to put the site into maintenance mode first, which by default it can’t. So by default, even updates to plug-ins would fail.

But my past practice, of just deleting a plug-in from the content directory, and of copying the new version into that content directory – which might be called ‘a manual update’ – will no longer continue to serve me well. From now on, I’ll want to run my updates in-place. And this required some further modification – I.e. some more fiddling on my part, to prepare.

As it stands an attempted in-place update even just for a plug-in, will still fail harmlessly, unless I now do something specific with my root password first. And I’m not going to be more specific than that. I did post some questions on the WordPress.org forums about the issue that I ran in to before, but then just posted my own answer to this issue. It’s just that since nobody did reply to my questions within a few hours of my posting them – until I marked my own issue as Resolved – I also feel that I shouldn’t be wasting their time with more of my details. And without these details, they may not be confident that I really do understand this subject. It’s just that nobody over there even bothered to follow up on that thought, let’s say with any questions of their own.

Dirk

 

There has been a Dist-Upgrade on my Server.

This server is hosted on a Debian / Jessie (Linux) computer which I own and run myself. Under Debian – Linux systems, the most thorough kind of update which can be carried out is called a ‘dist-upgrade’ or a ‘d-u’ for short. Just this evening, I saw that suddenly there were 93 software packages, which all did need an upgrade, and saw, that I could not just leave this type of upgrade to the usual, automated services. Therefore, I decided to administer the 93 package-upgrades given, via a dist-upgrade command. This can be stressful, or exciting, or both, because it can give a Linux user an improvement, or it can in some cases actually cripple our systems. I’m glad to say that this Linux box I name ‘Phoenix’ did not get crippled. It’s still fully bootable.

But due to this procedure, the Web-server was also down, from 20h15 through until 20h40 or so. I see that my blog is still here though, after the d-u .

I think that most software updates can be fun and games. But this particular upgrade also chose to include my graphics driver, which I was particularly fussy about. The past version of the graphics driver on this box was extremely stable, and I was trying to avoid doing any sort of upgrade to it, but now doing so was the only way to keep my box compatible with future upgrades.

It has sometimes happened to me, that the screen might just freeze – even though it’s a Linux computer – due to stability problems with other graphics drivers – especially with the ‘mesa’ driver, which tries to software-render an OpenGL equivalent. But what has been most stable for me in recent months, was the ‘GLX’ driver, which does full hardware, OpenGL rendering as it’s supposed to, and which under modern Linux systems is even capable of a ‘TDR’ equivalent, a Timeout Detection and Recovery, which will restart a crashed GPU without harming the active session.

If in the near future I find that my screen does freeze, or that there are TDR issues, a sinking feeling will go through my heart, because that would signal that a completely stable graphics driver has been replaced unnecessarily, with an unstable one. And in the act of doing so, all my package-management scripts even recompiled the DKMS kernel module for the graphics driver in question, because that is the correct way to install it.

Oh Yes, I see that the Apache Web-server software, which my machine hosts, has been given an upgrade as well. But as I see it, this was the least likely set of packages, for the maintainers to have botched. So it’s my full assumption that Web-server activity will continue without error.

Dirk

 

Living in a World of both New And Old Computers

One of the ironies that I notice in my life, is that even though I own both modern Android devices, and older Linux devices, I still get a lot of satisfaction out of ‘tinkering’ with my Linux devices.

I’d say that for most purposes, the more modern – or post-modern – mobile devices truly have become more useful on a practical level. But there are still certain types of tasks which need to be left to the older technologies. And one of the latter would be, to dedicate a machine to act as the host for server-programs, i.e. to use a machine as a server.

Further, even though I’ve had an intense interest in the past in CGI – in Computer Generated Images – I would not say I’m avidly into computer-gaming. I do hold a few player-licenses to video games. But if I was intensely into playing video games, then the Windows machines would start to become indispensable.

Linux just seems to be an ideal platform for servers, but is also surprisingly efficient at multimedia work. And, Linux can be a powerful platform to run CGI. It’s just that Linux gaming is not up to par, mainly for financial reasons. Firstly, the way Debian Linux works tends not to play well, with DRM. And games are after all sold for profit. Secondly, there isn’t a sufficiently high percentage of users based on Linux, really to make it worth the while of major gaming companies.

There have been various ways to integrate some DRM’ed software with Linux constraints, even though Linux is better-associated with its open-source background.

Dirk