This is not a new thing, it has been going on for years since WordPress versions in the middle 3.xx-es.  It’s not a WordPress “bug” – it’s because PHP v5.3.xx went End Of Life almost 2 years ago (on 14 Aug 2014 – see: http://php.net/eol.php ).  And, see: https://wordpress.org/support/topic/wp-35-is-not-compatible-with-php-53-please-read

Now, here’s the deal.  Computers are [supposedly] cheap these days.  Supposedly.  So, [supposedly] you just buy some awesome new quad-this-or-that x64 with at least 128GB RAM and some number of TBs of storage to… host your 20-30 MB WordPress sites.  Because images, that’s why.  Oh yeah, then manually migrate 100 or so websites, databases, all the associated “stuff” and spend “a few minutes each” changing all of the myriad of things you had to do to those sites and config files to make it work a couple-few years ago.

Or: keep what you’ve got and deal with it until the new V-Lab-Super-Box is online and your “team” starts pushing things around in their spare time.  Right.

If you did google-bar the above image issue you’ll have discovered that it has gotten progressively worse the more versions away from good olde EOL PHP 5.3.xx WordPress has gotten.  We experienced this.  This page is being written in WordPress 4.2.8, the site that went to pot today auto-magic-ly updated itself to 4.5.2.  That site was having dreaded the “http Error” problem with images for over a year.  Now, today, kaput!  No images, no PDFs, no nothing through the [Add Media] [Upload] section.  We finally got a PDF to upload and link in a page by angrily clicking refresh and doing the same thing over and over (Add media, library, upload… select… repeat).  Once upon a time we could size images to “web friendly” sizes and do the Angry-Repeat click-ery – no more.  Kaput!

“Well,” says google-bar, “didn’t you know about the Media From FTP plugin?”  https://wordpress.org/plugins/media-from-ftp/  “No,” says us.  So, we give it a try and when you click [Activate] it happily tells you:  Only works with PHP version 5.4 or higher.

Then it happened, just before give-up-time, because: (1) had already uploaded via ftp the problem image; (2) had looked at the [Insert From URL] button hundreds of times today.  [Insert From Url] clicked, http://domainname.com/wp-content/uploads/2016/05/PictureName.jpg…  BAM! Done.

Now it doesn’t show up in the Library but it shows up in the page – and in Edit mode there’s the alignment stuff, room for a title and a caption, and the ability to make it a link to itself (full sized).  The only hang-up: it inserts the image with width and height set to it’s “real” values (giant in this case).  Last trick, get some server-side resizing done (on the fly stuff) and…  BAM! Done.

So, at long last, here is the long way around work-around for Great New WordPress on Great Olde Server[s] with incompatible PHP (and other things) versions.

• ftp upload your image (keep the WordPress method of folder naming in case you ever “migrate” the site to Great New Server[s])
• In the page or post: [Add Media] and [Insert From URL]
• In the page or post: [Edit] the image, make it a link to itself, add a caption, title and alignment if you wish.
• [Preview changes] and use whatever you use to see the on-screen height-width numbers you need to stop the server from sending the full-sized image to that thumbnail-sized box.  (We did Print-Screen, Paint, Select on a Windows computer.)
• Switch your WordPress Editor to [Text] (underlying HTML) and change the width and height properties of your IMG tag.  (We changed – width=”2592″ height=”1944″ – to – width=”662″ height=”496″.)

Finally, [Save] the page or post, and go shake that piggy-bank and see about that new high-speed quad or oct thing with all the latest of everything (including PHP).  Test runs on many devices and browsers: invisible server-side image resize and send (thanks, Apache) and post complete.  Not very “reflexive” but “good enough” for now.

Now that that is taken care of… a test… of WordPress 4.2.8

This file would not upload.

Above: try again, pig headed try again, try again… error, error, long slow progress bar – worked !  Not worth the trouble.

Last notes and link:  Thanks to WordPress ( http://www.wordpress.org ) for not updating us to death.  The new Quad is actually in place and in QA Testing mode – but, migration is not going to happen until a lot more testing is done.  Known bugs are better than unknown ones.

It was a backdraft. Or the eye of the Zombie-Nado-Cane. When the bad-bots got some air around August 5th – hak4umz.net DDoS or DNS Amplification – fail2ban (and the servers) got burned.

Even the “eye-dee-keff-kuh-may” (TammyBelle’s God Mode Code for DOOM][ ) cheat didn’t help.  fail2ban got clobbered… ‘already banned’ every one second in the log and no more bans happening because 100s or 1000s of times per second from 100s or thousands of bots: bad requests.

Here is the Serious! problem when you put the fail2ban -vs- the entire globe death match together:

2013-08-13 12:40:37,730 fail2ban.actions: INFO   [named-flood] <ip> already banned
2013-08-13 12:40:38,732 fail2ban.actions: INFO   [named-flood] <ip> already banned

almost exactly one second apart, hundreds of times, and no new banning going on.
Q: Why?
A: fail2ban appears to have a “one second pulse/parse” clock built in to it.

Q: So?
A: So, when 4,000 log entries appear in a log that fail2ban is reading within that one second, fail2ban ‘queues’ (or spools or fifo’s) those 4,000 entries into an internal list and tries to de-queue them one-per-second.

Easier math: (“let’s say”) there are 10 ‘fail regex’ entries pouring into your log per second. Trying to de-queue the messages from the first second takes fail2ban 9 seconds.  By the time it gets done, there are 90 more messages/fails waiting.  So every second that goes by (in this low number scenario) the problem gets 10-to-the-10th-power worse.  The problem being fail2ban over-run by those headless bomb-toting zombies.  The “real world” explanation: fail2ban lags out and becomes combat ineffective.  In cop-talk the radio call from Officer fail2ban would be: “Extended”

Now, a “server admin” must consider – besides ‘shutdown -h now’ – is there a solution to the problem? First part of that: what – exactly – is the problem.  More Q/A (logic/reasoning):
Q: Problem?
A: fail2ban says ‘already banned’ and is ‘lagged out'; can’t fight the good fight.

Q: Why?
A: Too many log entries per second.  fail2ban reads logs and ‘actions’ based on log entries.

Q: So, why don’t you server admins just limit the number of log entries? (Instead of trying to hyper-tune fail2ban, just give it less to do? Remember the old-old server used to say ‘…the previous message repeated ### times…’)
A: Why didn’t I think of that.

The old-old server was a Gentoo box dragged across the millennium boundary by makes and make-installs.  It finally wore out (it still runs, it was just retired because it had done it’s duty) this year.  A little searching about ‘the previous message repeated’ and was reminded that that is called: rate-limit-ing.  A modern Centos-6-x86_64 install (not a bunch of custom compiled stuff on a 32-bit Gentoo) uses an ‘out of the box’ rsyslog and doesn’t say things like ‘…the previous message…’  The new stuff says:
imuxsock begins to drop messages from pid 1228 due to rate-limiting

Very little more searching finds:
http://www.rsyslog.com/tag/rate-limiting/

The docs are a ‘little dated’ (2010) but the essentials are there to solve the problem (problem being ‘too many log entries for poor old fail2ban’).

vim /etc/rsyslog.conf (and add as the 2nd and 3rd uncommented lines):

#### 8.12.13 - try to slow the message floods so fail2ban won't die so much ####
$SystemLogRateLimitInterval 1
$SystemLogRateLimitBurst 5

[Esc]:wq (write and quit)

Now do a /etc/init.d/rsyslog restart or service rsyslog restart (reload does not work, I tried it) and…

Tah-dah!  fail2ban can keep up with the log.  Some of the abusers (firey screaming zombies with tater-bombs) get by for a few seconds until the rate-limit/fail2ban get Serious!; but, real-world they were getting by by the hundres-of-thousands before this fix (while poor old fail2ban was over-run or lag-back-buffered).

It may not be ‘iddqd’ (god/degreelessness mode in ‘that other great fps’), but $SystemLogRateLimitInterval/$SystemLogRateLimitBurst is very close to TammyBelle’s “eye-dee-keff-kuh-may” (megaarmor, weapons and keys) for fail2ban.

Almost as good as Tangy-Bells for break-shishst.
Very happy, ammo added.

*** A minor success/victory ***
49 hours later… fail2ban chugging along ban/unban-ing, much smaller log files, no other services lagged out because of the packet attacks on port 53….