PHP 5.6 was first released back in 2014, with alpha 1 released in January 2014. Due to major performance improvements (phpng then merged into PHP 7), by December 2015 the PHP team started to encourage upgrading to PHP 7. Hailing it’s improvements such as being twice as fast, consistent 64-bit support, removal of old and unsupported SAPIs and extensions, improved fatal error resistance, etc.

Since then, we’ve had some movement on this front. PHP 7 now accounts for more than 15% of PHP versions in use. That’s up from 3% a year ago. PHP still holds about 80% market share of server-side programming languages for websites.

At the end of 2018 both PHP 5.6 and PHP 7.0 has reached EOL / support. Most webhosting company’s are still supporting these versions, but when will that end ? And are my scripts ready for PHP 7.2/7.3 ?

PHP 7.3 so far up to 25% faster than PHP 7.0

We are well aware that PHP 7 is at least 2x faster than PHP 5.6. However, have a look at the below Phoronix benchmark at just how much PHP 7 has improved since it’s first release at the end of 2015. PHP 7.3 is quite a bit faster than previous versions of PHP 7. PHP 7.3, so far, is up to 3x faster than PHP 5.6!

How to check if your PHP scripts are PHP 7.2 / 7.3 compatible

There are a few tools/scripts which automate the process of checking PHP 7.2 / 7.3 compatibility. Prior to writing this, I used php7cc (project no longer supported).There are however, a few other active projects:

  • php7mar – PHP 7 Migration Assistant Report (MAR). (Recommended)
  • phan – a static analyzer. PHP 7 checker.
  • phpstan – PHP Static Analysis and compatibility check.
  • There’s also PHPStorm for developers.

For example you run phan with something like:

phan --project-root-directory --progress-bar -o phan.out

or for php7mar:

php mar.php -f="/path/to/project/root/" -r="/path/to/output/"

During mayor upgrades on several systems I came along the bad situation with duplicate packages..

This helped me solve the issue of having duplicate packages installed. I only needed to add another flag to have:

rpm -e --justdb --nodeps <package-old_version>

Below you will find the steps to semi automate this, but beware, Your millage may vary, make sure you check the output that are put into the files.

Bottom of output from:

Warning: RPMDB altered outside of yum.
** Found 247 pre-existing rpmdb problem(s), 'yum check' output follows:
chkconfig-1.7.4-1.el7.x86_64 is a duplicate with chkconfig-1.7.2-1.el7.x86_64
1:gmp-6.0.0-15.el7.x86_64 is a duplicate with 1:gmp-6.0.0-12.el7_1.x86_64
gobject-introspection-1.50.0-1.el7.x86_64 is a duplicate with gobject-introspection-1.42.0-1.el7.x86_64
grep-2.20-3.el7.x86_64 is a duplicate with grep-2.20-2.el7.x86_64
gzip-1.5-9.el7.x86_64 is a duplicate with gzip-1.5-8.el7.x86_64
pcre-8.32-17.el7.x86_64 is a duplicate with pcre-8.32-15.el7_2.1.x86_64
4:perl-5.16.3-292.el7.x86_64 is a duplicate with 4:perl-5.16.3-291.el7.x86_64
4:perl-libs-5.16.3-292.el7.x86_64 is a duplicate with 4:perl-libs-5.16.3-291.el7.x86_64
4:perl-macros-5.16.3-292.el7.x86_64 is a duplicate with 4:perl-macros-5.16.3-291.el7.x86_64
shared-mime-info-1.8-3.el7.x86_64 is a duplicate with shared-mime-info-1.1-9.el7.x86_64
2:tar-1.26-32.el7.x86_64 is a duplicate with 2:tar-1.26-31.el7.x86_64

Put above package names (starting from packages listed) into:

vi yum-fix.txt

Suggested to run from yum, but doesn’t seem to help. maybe it does a bit..

yum-complete-transaction --cleanup-only
cat yum-fix.txt|grep "is a duplicate with" > yum-fix_dupe.txt
cat yum-fix.txt|grep -v "is a duplicate with" > yum-fix_manually.txt

Parse output of some packages that start with a number and colon:

cat yum-fix_dupe.txt |awk '{print $6}'|awk -F":" '{if ((length($1) != 1) && (length($1) != 2)) print $1}' > yum-fix_dupe2.txt
cat yum-fix_dupe.txt |awk '{print $6}'|awk -F":" '{if ((length($1) == 1) || (length($1) == 2)) print $2}' >> yum-fix_dupe2.txt

Remove old package version from rpm db:

for i in $(cat yum-fix_dupe2.txt);do rpm -e --justdb --nodeps $i;done

Remove last 2 columns from output, and put on same line:

cat yum-fix_dupe2.txt | awk -F"-[0-9]" '{print $1}' |tr '\n' ' ' > yum-fix_dupe2-reinstall.txt

Reinstall packages:

yum reinstall $(cat yum-fix_dupe2-reinstall.txt)

Don’t forget to go back and manually fix the non-duplicates above could have fixed them.. try yum upgrade to see if any more errors):

cat yum-fix_manually.txt
yum --assumeno upgrade

The following order is the correct PEM file order for HA-PROXY

  1. certificate.key
  2. certificate.crt
  3. certificate.bundle.crt

This bash script will do it for you with Let’s Encrypt

cat /usr/local/bin/


# move to the correct let's encrypt directory
cd /etc/letsencrypt/live/
cat fullchain.pem privkey.pem > /etc/haproxy/certs/

cd /etc/letsencrypt/live/
cat fullchain.pem privkey.pem > /etc/haproxy/certs/

# reload haproxy
service haproxy reload

Remove all stopped containers

docker rm -v $(docker ps -a | grep "Exited" | awk "{print $1}")

Remove all stopped containers v2

docker rm $(docker ps -a -q)

If you’ve ever rebuilt a server that you have connected to in the past, chances are you’ve received an error when trying to ssh back into it for the first time since the rebuild. If you’re getting a screen that says “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:xx RSA host key for myhost has changed and you have requested strict checking.
Host key verification failed.

Since we just rebuilt our server, this error is expected as the it is sending a new RSA key different than the one stored in /home/user/.ssh/known_hosts and now your computer’s ssh system is saying, “Hold on, this server you’re connecting to via this IP is not giving me the same ID. It could be that you just rebuilt the server, or it could be a man-in-the-middle attack!”

The workaround is actually quite simple, we have to remove the stored RSA key so we can add safely the new one. To do so, take a look at the last integer of the line that says “Offending ECDSA key,” because this integer is actually the line number inside your known_hosts file that’s throwing the error.


Then type in the following command, changing the number 2 to whatever matches your own error.

sed -i 'xxd' ~/.ssh/known_hosts

The offending RSA key can be also be removed with:

ssh-keygen -f "/home/user/.ssh/known_hosts" -R <server ip>