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

 

A design anachronism within WordPress.

This blog is being hosted by the “WordPress.org” Content Management System (configured for one user) (:1). Yesterday I lost a night’s sleep, trying to figure out why this software was having problems. Tonight, it’s still a little early, for my night’s sleep to start.

Here’s the problem. If we follow the documentation to set up this software, it tries to create a configuration by which the personal contents of a Blog are stored in Linux folder ‘/srv/www’ .  This is a tad confusing, because according to other documentation, it could be setting this up in folder ‘/var/lib/wordpress/wp-content’. At the same time, the components of the page which display, that belong to WordPress and its CGI scripts, are set up in ‘/usr/share/wordpress’. The user is given rough guidelines, as to how he can set up his Apache server, to have an Alias according to his configuration file, which points to the General Location from a URL, which is a Parent URL to the one, whose Alias points to the Personal Folders on the hard drive, the latter located under ‘/srv/www’ when the initial confusion is solved.

What can happen next is that the page seems to display in a not-so-neat way, until the owner tries to upload a photo or something, at which point he finds that his browser can no longer even view that file, getting a ‘403-Forbidden’ error. What’s confusing about this situation, is that the user is likely to look very intensely at the configuration file which defines the Virtual Host, or which defines this set of URL-Aliases, as the probable cause fw Apache is not giving access to the browser, to the content folder. This turns into a waste of time, because aside from some semantic quibbles, there’s really no error there.

What happens is that in the Apache configuration folder, there is  a Main Configuration File named ‘/etc/apache2/apache2.conf’ .  It’s located right next to the files, which tell Apache to create the aliases specific to each Web-site the user has. Under modern versions of Apache, this main config file allows the server – and thus all the pages – to access anything under ‘/usr/share’ and under ‘/var/www’ by default, but explicitly forbids any of the other config files, from accessing other folders, especially ‘/srv’ .  This has been put as a security measure, to prevent hijacked Web-sites from doing extensive damage on the host machine. That same config file can easily be edited, to include ‘/srv’ as one of the allowed folders.

But, because none of the troubleshooting attention goes there, it can take time to find this problem. As I wrote, I lost a night’s sleep over this mere annoyance. Once access has been granted to all Apache’s hosted sites, to access ‘/srv’ as well potentially – still according to their own config files – we also see that the page itself displays in its full style and splendor, and that uploaded photos now download to the browser.

There’s a deeper problem with this sort of bug. It can undermine the confidence the user has, in the ability of the provider of the software to program well. I have in fact heard of WordPress, and yet initially, based on the errors I was getting, was not getting a good first impression of it. And the fact that the Style which my Blog displays in, has elements of my personal preferences in it, which were not accessible at first, also made the pages ‘look ugly’ at first, again undermining how well WordPress might be programmed, according to my first experience with it.

This happens often in computing.

And, it also happened too often in my past, that I eventually solved such issues, but that I never left a detailed account to myself, about how I had solved them. Now that I have a micro-Blog, I can rectify this last point.

BTW, Finally WordPress does come across as good software, very functional. And the fact that the software is very functional is confirmed more strongly, by the fact that it was at first even able to display my Blog partially, in spite of not being able to access half its folders.

It’s deprecated under Linux, to store Web content under ‘/srv/www’ !

Dirk

Edit 01/18/2016  1:)  It was only after having installed WordPress.org, and having started my Blog, that I also learned that this package is different from WordPress.com .  But this initial gap in my knowledge is of course also tied to the fact, that with the .org product, users “need to get their hands dirty, to make it work”.