Month: August 2019

A minor issue
made the blogs inaccessible: one of the PHP logicals wasn’t defined properly because the scrip that sets them didn’t run with elevated privileges – as it should. So I did this just now :).

The assumption that I could block unwanted URLs at the firewall proved wrong. It works only on the way out, not the way in. so the current setting, where any Hyperreader access that is so highly abused, seems the only way to block them. Not what I wanted but it works.

More on connection problems
Found another issue that worked before – without a problem: rss feeds fail:

[22/Aug/2019:08:55:42 +0000] "GET /sysblog/?feed=rss2&cat=3 HTTP/1.1" 0 0

and today, that kept showing up for minutes – and the blog was not accessible – timed out – until I stopped the PHPWASD program running RSS Feeds – I could then access the blog again, and rss nicely gave the requested data. It might be a matter of PHP 7.2 – but also on the database; previously, I would get a message that connection was lost, now it is merely that the Publish button is disabled – just happened but came back again.
Since the WordPress code wasn’t changed, nor the database engine, it’s something with PHP or PHP.INI parameters…
More on HyperReader
Found out why HyperReader is so popular.
The referrer – the part like
&referer=https%3a//pbase.com/profile/coinmaster
is executed on the CLOSE button: That now links to the site mentioned: in this case “pbase.com/profile/coinmaster”, potentially bypassing securtity, of faking the caller (perhaps using this site?). So it has been a good idea to block this, at the most early stage possible – but that stopped all external access yesterday – asked the supplier how to do this.
Yet another issue
the BIND resolver on the system seemed to be lost – wasn’t setup properly – so I re-did this and restarted the name service. Hopefully that solves the early-morning-problems where none of the site-names could be translated – because there was no resolver other than itself
Update on connectivity
Put the question on the appropriate WordPress support forum: the higher version of PHP, the more strict coding should be: where 5.2 was quite forgiving, since 5.4 the tolerance lowered and since 7 it is even stricter. It might be that plugins and themes contain code that this PHP version doesn’t like. I knoiw that there are updates for both themes that I use, so I updated them using the latest version on the site: for 2017 – on this blog, that is 2.2, for 2015, used in the Trips, Tracks and Travels blog, it’s 2.5. But still, wp-admin-ajax keeps showing problems, now (as this post is done) keeps spewing
POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 400 0
in the access log – and is keeping stating “Saving Draft”….

As suggested in the reply on my question, switched do 2019 theme, it should work. But since the issues I have are not related to themes (wp-admin-ajax and rss-feeds – I have my doubt whether it will help.

It doesn’t

So revert to 5.2.13

Still connectivity issues
There is still a problem with access to the secured sites – quite often the server cannot be located, according the browser – where the non-secured sites have no issues at that time. One possible option is the huge amount of HyperReader accesses at times, which could render the webserver too busy to handle, of it consumes the number of connections, even when I blocked access completely in the configuration:
fail /HyperReader/*
that will return 403 error code. But because this still is handled by the server, it occupies a channel…

So now I placed the block in the router, so the requests won’t even get to the server – as long it’s not my own IP address. So ANYONE trying to access HyperReader – no matter in what URL – will find the gate closed. Access log shows no more entries after I did this, so it works.

Still, at times connections still fail, but retry will at some point show the page I requested, and at times almost immediately on click. So there is something causing this: again, this happens with the TLS connections (all versions are possible ); even linking to pages within the same environment fail/ However, Edge shows connection, waiting for response and finally states it cannot connect.
SSL? Might also be domain checker that checks the site’s certificate against Let’sEncrypt, that al;so explains why the standard page has no issues on this.
Except fro the blogs – but that has to do with PHP 7.2 that is now enabled: Would that also open a number of connections with WASD causing problems?
One thing I found now is that one particular script runs every 15 seconds – saving draft is kept showing, but I cannot publish the post….
Trying to refresh the page will fail, I’m sure… Killing that process solves a hang here on refresh of the page (probably post is not reentered??)
Something to investigate here: and I found something in the WASD access log:

[22/Aug/2019:17:02:29 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 760
[22/Aug/2019:17:02:35 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 828
[22/Aug/2019:17:02:44 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 715
[22/Aug/2019:17:02:59 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 715
[22/Aug/2019:17:03:15 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 714
[22/Aug/2019:17:03:30 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 714
[22/Aug/2019:17:03:45 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 761
[22/Aug/2019:17:04:00 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 715
[22/Aug/2019:17:04:15 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 714
[22/Aug/2019:17:04:30 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 715
[22/Aug/2019:17:04:45 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 715
[22/Aug/2019:17:05:00 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 759
[22/Aug/2019:17:05:15 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 714
[22/Aug/2019:17:05:30 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 200 715
[22/Aug/2019:17:05:45 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 500 288
[22/Aug/2019:17:06:00 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 502 921
[22/Aug/2019:17:06:15 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 0 0
[22/Aug/2019:17:06:15 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 0 0
[22/Aug/2019:17:06:15 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 0 0

And that goes on – every 15 seconds this request is started, sometimes up to 5 times. once in a while there is a line

[22/Aug/2019:17:07:45 +0000] "POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1" 400 0

located the code: status 0 is the default code; 400 is signalled on a number of places, but no identication which ones here.

so where come these 500 and 502 errors? that must be from a script that is called – and there are some. Though unlikely (since this is not a secured site), if any of these run into the same connection issues, this could well be the reason. But bad programming practice anyway, that no information is given of the real cause of the error, or a reset.

Connection to server gone
Had to add an extra power outlet on the other side of the attic, I had to move the WIFI access point ad connect it to a longer cable. After the work was done, the TV setup-box (which is on the moved outlet) had te be restarted – and that failed. ANY access to the internet! Hoever, there was nothing wrong with the router and Internet access downstairs (directly on the WIFI channels of the router) had no problem either/ But the VMS box could not be reached.
First attempt was to stop and start TCPIP – stopping was no problem but startup failed because the Internet driver wasn’t loaded.???? There was nothing wrong with the configuration and the connection between the system and the Ethernet switch that connects all VMS boxes, was fine: All lights were on. Reboot didn’t change it either..
Got a brainwave: Since I’ve been handling cables on the switch on entrance of the machine room, it was possible that the cable connecting that to the VMS-boxes, wasn’t seated well – known problem and should be fixed (second cable that does stick is already there but needs to be rerouted) – and indeed, once seated well connection was restored.

Cleaned up a bit too much
Startup yesterday turned out to be incomplete: the database didn’t start – so the blogs were not accessible. But why?
Checking startup log of MariaDB stated:
%DCL-E-NOCMDPROC, error opening captive command procedure - access denied
This is weird, so I checked the command procedure, but there was nothing special to be noted.
But it was clear it had to do with the login procedure of user that runs the databaseserver: MYSQL051_SRV. So it may have been the path to the login procedure of this user, according SYSUAF:

Username: MYSQL051_SRV Owner:
Account: MYSQL051 UIC: [37775,1] ([MYSQL051,MYSQL051_SRV])
CLI: DCL Tables: DCLTABLES
Default: MYSQL051_ROOT:[MYSQL_SERVER]
LGICMD: MYSQL051_ROOT:[VMS.MYSQL]LOGIN_SERVER.COM

but I did some cleaning on this user: Removed all I think was obsolete. What was left was $116$dka100:[web.mysql.mysql051] – that is wat MYSQL051_ROOT refers to. But all beyond was gone. Since the only thing that I needed was MYSQL051_ROOT:[VMS.MYSQL]LOGIN_SERVER.COM, it was sufficient to recreate that directory and command procedure (a copy of MYSQL055_SRV’s LOGIN.COM file) to get the database server running again.

but still the blogs didn’t start; even worse, connectivity to any webservice was interrupted time after time again: At times I could get in, but getting deeper into the same site failed – No connection could be made: Site was not reachable. looked at access log, there was a constant flow of calls to HyperRead – more precise: “/HyperReader/download/FREEWAREV40/BLISS/4359PRO.DECW$BOOK” with a lot of extra’s; Well, FREEWAREV40 had already been blocked, so all these give status 404, but also, a lot of calls to other freeware locations.
So I disabled all HELP content in the ‘open’ site – including Hyperread.
Now the site signals Server error (500) on hyperread calls – due to a loop somewhere: Access log now shows: “/HyperReader/HyperReader/HyperReader/HyperReader/HyperReader/HyperReader/HyperReader/download/FREEWAREV40/BLISS/4359PRO.DECW$BOOK…”. If this is inside the server (likely, otherwise I wouldn’t get the 500 error) it might be better to handle this in the configuration (return some error).
Anyway: it caused the server to be far more responsive.

But still the blogs didn’t work. Looking on what is started, I noted PHP 7.2 has been activated – I forgot to reverse the change in startup to use an older version. I got “Nonconformant response” – meaning the application gave some error, the server signalled something unexpected, according WATCH output: it could not locate a file: got the system status FNF (File Not Found). However, SYSBLOG is defined and its content present, as is TRACKS. But checking the logicals, I noted both reference the older 4.9.8 version of WordPress, where only the new one (5.2.2) was defined. Therefore, the server could not locate the base code of WordPress – causing Fine_Not_Found. After I added the right logical, this problem too was solved.

I keep PHP 7.2 running for now. It no problems occur, I’ll disable older versions.

Update on server mapping
HyperReader (and all help) has been disabled on the site (I still can use it via another) but is still an issue with this: WASD will continue processing the request until it had enough.
There might be an issue with PHP7.2 as well, since adding this update, I couldn’t since the UPDATE button was disabled, reloading the page failed again, I had to clear the cache before I got the page (and revisions) back and could update the post

Update2 on server mapping
Having asked Mark on the issue, I have now changed the mapping so access to HyperReader is now blocked completely (you get a 403 error) except when requested from my own IP address – so I can use it at my workstation). If needed this can be extended with whatever I deem necessary. Simply a matter of adapting one configuration file and reload the mapping.
It is now a matter of checking regularly whether this solves the connection – and perhaps performance – issues. Sometimes, PHPWASD returns status 000, and ik looks like this happens if the RTE is still in memory and waiting for requests. Once it returns this status, it will keep doing so: therefore this happens so fast: Nothing is done. One the RTE’s are stopped or the server is restarted, all is well – for the time being.

Another (minor) issue
The Trips, Travels and Travels blog didn’t show either, again due it’s definition that refers to WP5.2.2: No page, just empty header and body – no content between the tags. So reversed that to 4.9.8 and the pages show up.

So WordPress 5.2.2 is no doubt something to dig deeper into.