gregscott
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: Updates time out…or there could be some ugly browser cache things going on. I just looked at it from a different device. A few hours ago, the installed X theme was 10.6.3, with 10.6.4 ready to install. No matter what I tried, I could never get it to tell me that it updated to 10.6.4. But now, from this different device, I see the installed X theme is 10.6.4.
Maybe it performs updates as expected but never gets back to the browser client, making me think it never applied the update. Maybe that’s what’s going on. Maybe the timeout is between the site and the browser after the update finishes.
I’m on Chrome as I compose this comment with that website open in another tab. I was on Firefox earlier.
I’ll wait for the next plugin update and see what happens.
Forum: Fixing WordPress
In reply to: Updates time outThanks – but it’s not just X theme updates. It’s all plugin and theme updates. All updates to everything from the WordPress dashboard act badly. An X theme update was waiting this morning, but others act the same way.
Forum: Fixing WordPress
In reply to: Filling disks with gobs of gigabytes of Mariadb log messages@steven – thanks – looks like “mysql_upgrade” did the trick.
- Greg
Forum: Fixing WordPress
In reply to: Filling disks with gobs of gigabytes of Mariadb log messagesThanks @samuel. I am pretty much the hosting team. Looking at the error messages, it seems that the database is set up differently than WordPress expects. The only database work on any of these sites came from initial setup years ago and automated WordPress upgrades. The log files exploded after the latest upgrade to 6.6.1. Surely we can find better guidance than just “repair the database.” Repair it how?
Forum: Fixing WordPress
In reply to: Filling disks with gobs of gigabytes of Mariadb log messagesThanks – that will work around my disk space issue, but how do we attack the error at the root of the problem?
Long story short – the problem was a Divi theme bug with Divi 4.14.3. Other people had similar problems. The 4.14.4 update fixed it.
I checked my backups and found I updated to Divi 4.14.3 on Dec. 16 2021 at 8:49 PM. My website logs show the problem started at 20:54:02, or roughly 5 minutes later. After I learned how to reproduce the problem at will, the problem stopped immediately after I updated to Divi 4.14.4. For an attacker to introduce something malicious, they would need to do it within 5 minutes of my update, and dated the offending file the exact same as all the other files in the themes/Divi directory tree.
I posted this in a Facebook group named “Divi Theme Users” and before the admins of that group deleted my post, several people commented they had similar problems with Divi 4.14.3.
So this one turned out to be a theme thing.
Maybe I fixed it. Details below.
I found a way to reproduce the problem at will – in a browser window, go to blog –> Phishy emnails. In another terminal window, do tail -f /etc/httpd/logs/access_log
Every time I clicked on “Phishy emails”, my tail -f went nuts with zillions of
fe80::65dc:5d0e:b7eb:47ae%ens3 - - [18/Dec/2021:18:18:28 -0600] "GET /category/phishy-emails/ HTTP/1.1" 200 27106 "https://www.dgregscott.com/category/phishy-emails/" "WordPress/5.8.2; https://www.dgregscott.com" fe80::65dc:5d0e:b7eb:47ae%ens3 - - [18/Dec/2021:18:18:34 -0600] "GET /wp-content/uploads/2021/11/KamalaBackdoorSpam-1024x924.png HTTP/1.1" 200 269366 "https://www.dgregscott.com/wp-content/uploads/2021/11/KamalaBackdoorSpam-1024x924.png" "WordPress/5.8.2; https://www.dgregscott.com"In a third window, I did
systemctl restart httpd.service
and the machine-gunned log entries stopped.With more testing, I found I could reproduce the problem by clicking on **any** blog post in the “Phishy emails” category.
Clicking other posts and pages did not trigger the behavior; just “Phishy email” posts or the category.
Maybe somebody injected a malicious .htaccess or other config file? I didn’t see any.
And then I noticed a brand new pending update. It was the Divi theme, updating from 4.14.3 to 4.14.4. I applied the update and the problem stopped.
So…
looks like it was either a Divi theme bug or somebody inserted something hostile into the theme directory. I also updated Divi a few days ago, so it could be either. I’ll keep an eye on it for a while.
Resolved the original problem. That health check plugin is a nice tool. It led to the solution. Thanks James!
But first, a little more on the loopback thing. I don’t like hard-coding my public IP Address in my config file. One more thing to remember if I ever change IP Addresses. Right now, the key line is
require ip [public IP address]
I have a hunch there’s a way to use a Require line with a DNS name instead of IP Address. I’ll need to look in the apache documentation and find it.
And on the original problem, it was a Fedora RPM packaging issue. The cure was to upgrade from the wordpress-5.1.1-1.fc29.noarch RPM to wordpress-5.1.1-4.fc29.noarch.
Those files were missing or modified in the health check because they don’t comply with Fedora packaging guidelines.
I’ll paste in the overnight bugzilla commments with more detail.
*******************
> The file integrity report should run cleanly.
No, the file are patched or removed to comply to Fedora Packaging Guildelines
> Whenever I try to edit a Classic block with my problem website, the block displays an error message, “This block has encountered an error and cannot be previewed.”
See a duplicate of bug #1691524
Please try 5.1.1-4 from updates-testing
Private Comment 2 Greg Scott 2019-03-29 06:22:46 UTC
Wow.Before upgrading:
[root@dgregscott2019 ~]# rpm -qa | grep wordpress
wordpress-5.1.1-1.fc29.noarchAfter upgrading:
[root@dgregscott2019 ~]# rpm -qa | grep wordpress
wordpress-5.1.1-4.fc29.noarch
[root@dgregscott2019 ~]#And now I can edit a classic block!
Private Comment 3 Remi Collet 2019-03-29 06:46:07 UTC
Feel free to give karma on
https://bodhi.fedoraproject.org/updates/FEDORA-2019-4825f7896cStatus: NEW → CLOSED
Resolution: — → ERRATA
Last Closed: 2019-03-29 06:46:07
Private Comment 4 Greg Scott 2019-03-29 11:28:03 UTC
May I ask one more question?
> No, the file are patched or removed to comply to Fedora Packaging GuildelinesHow did they not comply? Is there a way to feed that info back to the WordPress community so they can make appropriate changes?
*******************
Here’s a link to the Red Hat bugzilla entry with the fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1691524And a link to the errata with how to install the update, at least until it makes its way into the normal Fedora update stream:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-4825f7896cAnd how to apply the update:
sudo dnf upgrade –enablerepo=updates-testing –advisory=FEDORA-2019-4825f7896cthanks
– Greg
- This reply was modified 7 years, 2 months ago by gregscott.
More on the loopback thing, which is a distraction from the original problem, but might be useful if anyone else sees the behavior.
The VM hosting my website has a private IP Address and it’s NATed behind my firewall. I’ll bet that loopback test tries to touch http://www.dgregscott.com, which translates to a public IP Address. And so the loopback goes out to the firewall and right back in again. But my config file doesn’t have anything granting the public IP Address. As I write this up, it occurs to me, this should be easy to fix.
Yup – now that loopback test works just fine. Here’s what the wp-admin section of my conf file looks like now.
<Directory /usr/share/wordpress/wp-admin> ## AllowOverride Options AllowOverride All <IfModule mod_authz_core.c> # Apache 2.4 ##Require local Require ip 10.10.10 Require ip 216.160.2.133 ##Require all granted </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from All Allow from 127.0.0.1 Allow from ::1 Allow from 10.10.10 Allow from 216.160.2.133 </IfModule> <Files "admin-ajax.php"> <IfModule mod_authz_core.c> # Apache 2.4 Require all granted </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Allow from All </IfModule> </Files> </Directory>Oh – yes – I figured out what was going on with that loopback behavior. It was a configuration thing, not a plugin, and a dead-end for the block problem. This was the root cause, in /etc/httpd/conf.d/dgregscott.conf
<Directory /usr/share/wordpress/wp-admin> ## AllowOverride Options AllowOverride All <IfModule mod_authz_core.c> # Apache 2.4 ##Require local Require ip 10.10.10 ##Require all granted </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from All Allow from 127.0.0.1 Allow from ::1 Allow from 10.10.10 </IfModule> <Files "admin-ajax.php"> <IfModule mod_authz_core.c> # Apache 2.4 Require all granted </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Allow from All </IfModule> </Files> </Directory>I don’t want anyone from the outside world touching my wp-admin directory. When I temporarily changed it to:
##Require ip 10.10.10 Require all grantedThe loopback worked just fine, but the original problem didn’t change.
Since this looks like it might be a Fedora packaging problem, I filed a bug with Red Hat. Here is a link:
Well this is ugly. Digging deeper into that Healthcheck plugin, when I look at the troubleshooting tab and check file integrity, I see a boatload of files missing or changed.
I’m using the Red Hat WordPress RPM that goes with Fedora instead of the download direct from WordPress. I wonder if the Red Hat WordPress updates have a problem.
On my good website, the file integrity check works without error.
/usr/share/wordpress/readme.html File not found
/usr/share/wordpress/license.txt File not found
/usr/share/wordpress/wp-includes/SimplePie/Parser.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Sanitize.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Core.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Decode/HTML/Entities.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Category.php File not found
/usr/share/wordpress/wp-includes/SimplePie/gzdecode.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Locator.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Parse/Date.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Author.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache.php File not found
/usr/share/wordpress/wp-includes/SimplePie/IRI.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Credit.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Content/Type/Sniffer.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Restriction.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Item.php File not found
/usr/share/wordpress/wp-includes/SimplePie/XML/Declaration/Parser.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/Base.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/MySQL.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/Memcache.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/DB.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/File.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Source.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Registry.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Rating.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Copyright.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Exception.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Misc.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Caption.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Net/IPv6.php File not found
/usr/share/wordpress/wp-includes/SimplePie/File.php File not found
/usr/share/wordpress/wp-includes/SimplePie/HTTP/Parser.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Enclosure.php File not found
/usr/share/wordpress/wp-includes/class-smtp.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/class-simplepie.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/script-loader.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/certificates/ca-bundle.crt Content changed (View Diff)
/usr/share/wordpress/wp-includes/ID3/module.tag.lyrics3.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.dts.php File not found
/usr/share/wordpress/wp-includes/ID3/module.tag.id3v1.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.flac.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.mp3.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.matroska.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.quicktime.php File not found
/usr/share/wordpress/wp-includes/ID3/module.tag.apetag.php File not found
/usr/share/wordpress/wp-includes/ID3/getid3.lib.php File not found
/usr/share/wordpress/wp-includes/ID3/license.commercial.txt File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.ac3.php File not found
/usr/share/wordpress/wp-includes/ID3/getid3.php File not found
/usr/share/wordpress/wp-includes/ID3/license.txt File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.flv.php File not found
/usr/share/wordpress/wp-includes/ID3/readme.txt File not found
/usr/share/wordpress/wp-includes/ID3/module.tag.id3v2.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.ogg.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.riff.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.asf.php File not found
/usr/share/wordpress/wp-includes/update.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/load.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/tinymce/wp-tinymce.js File not found
/usr/share/wordpress/wp-includes/js/tinymce/plugins/media/plugin.min.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/tinymce/plugins/media/plugin.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement-and-player.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement.min.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement-and-player.min.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/swfupload/handlers.js File not found
/usr/share/wordpress/wp-includes/js/swfupload/handlers.min.js File not found
/usr/share/wordpress/wp-includes/js/swfupload/license.txt File not found
/usr/share/wordpress/wp-includes/js/swfupload/swfupload.js File not found
/usr/share/wordpress/wp-includes/class-phpmailer.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/admin-filters.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/media.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/update.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/class-core-upgrader.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/class-wp-automatic-updater.php Content changed (View Diff)Hmmm…
I just installed the healthcheck plugin on my known good website. The last line of the Dashboard…Healthckeck report looks like:
Loopback request The loopback request to your site completed successfully.
But on the problem website, the last line looks like:
Loopback request The loopback request returned an unexpected status code, 403, this may affect tools such as WP_Cron, or theme and plugin editors.
This feels like it might be important.
Is this significant? I’m running a current version of Red Hat Fedora, and so I update WordPress via Red Hat updates instead of direct from WordPress.
PHP Extensions
The optional module, bcmath, is not installer, or has been disabled.
The optional module, libsodium, is not installer, or has been disabled.
The optional module, imagick, is not installer, or has been disabled.Oh – sorry – there it is. Thanks. Pasting in the REST API availability line:
REST API availability The REST API is available.