Upgrading PHP from 7.0.22 to 7.1.9

I created a shell script which began its simple life as

#!/bin/sh

# Use on first run
FLAGS=-ncfpvo

# Use on subsequent runs
#FLAGS=-fpvo

portupgrade ${FLAGS} lang/php71 lang/php70 || exit

portupgrade ${FLAGS} textproc/php71-ctype      textproc/php70-ctype      || exit
portupgrade ${FLAGS} ftp/php71-curl            ftp/php70-curl            || exit
portupgrade ${FLAGS} textproc/php71-dom        textproc/php70-dom        || exit
portupgrade ${FLAGS} graphics/php71-gd         graphics/php70-gd         || exit
portupgrade ${FLAGS} devel/php71-gettext       devel/php70-gettext       || exit
portupgrade ${FLAGS} security/php71-hash       security/php70-hash       || exit
portupgrade ${FLAGS} converters/php71-iconv    converters/php70-iconv    || exit
portupgrade ${FLAGS} devel/php71-json          devel/php70-json          || exit
portupgrade ${FLAGS} net/php71-ldap            net/php70-ldap            || exit
portupgrade ${FLAGS} converters/php71-mbstring converters/php70-mbstring || exit
portupgrade ${FLAGS} security/php71-mcrypt     security/php70-mcrypt     || exit
portupgrade ${FLAGS} databases/php71-memcache  databases/php70-memcache  || exit
portupgrade ${FLAGS} www/php71-opcache         www/php70-opcache         || exit
portupgrade ${FLAGS} security/php71-openssl    security/php70-openssl    || exit
portupgrade ${FLAGS} databases/php71-pdo       databases/php70-pdo       || exit
portupgrade ${FLAGS} databases/php71-pdo_pgsql databases/php70-pdo_pgsql || exit
portupgrade ${FLAGS} databases/php71-pgsql     databases/php70-pgsql     || exit
portupgrade ${FLAGS} www/php71-session         www/php70-session         || exit
portupgrade ${FLAGS} textproc/php71-simplexml  textproc/php70-simplexml  || exit
portupgrade ${FLAGS} net/php71-soap            net/php70-soap            || exit
portupgrade ${FLAGS} net/php71-sockets         net/php70-sockets         || exit
portupgrade ${FLAGS} databases/php71-sqlite3   databases/php70-sqlite3   || exit
portupgrade ${FLAGS} textproc/php71-wddx       textproc/php70-wddx       || exit
portupgrade ${FLAGS} textproc/php71-xml        textproc/php70-xml        || exit
portupgrade ${FLAGS} archivers/php71-zlib      archivers/php70-zlib      || exit

portupgrade ${FLAGS} www/mod_php71 www/mod_php70 || exit

After running the script for a second time and a third time, etc, the script was successively changed to:

#!/bin/sh

# Use on first run
#FLAGS=-ncfpvo

# Use on subsequent runs
FLAGS=-fpvo

#portupgrade ${FLAGS} lang/php71 lang/php70 || exit

#portupgrade ${FLAGS} textproc/php71-ctype      textproc/php70-ctype      || exit
#portupgrade ${FLAGS} ftp/php71-curl            ftp/php70-curl            || exit
#portupgrade ${FLAGS} textproc/php71-dom        textproc/php70-dom        || exit
#portupgrade ${FLAGS} graphics/php71-gd         graphics/php70-gd         || exit
#portupgrade ${FLAGS} devel/php71-gettext       devel/php70-gettext       || exit
#portupgrade ${FLAGS} security/php71-hash       security/php70-hash       || exit
#portupgrade ${FLAGS} converters/php71-iconv    converters/php70-iconv    || exit
#portupgrade ${FLAGS} devel/php71-json          devel/php70-json          || exit
#portupgrade ${FLAGS} net/php71-ldap            net/php70-ldap            || exit
#portupgrade ${FLAGS} converters/php71-mbstring converters/php70-mbstring || exit
#portupgrade ${FLAGS} security/php71-mcrypt     security/php70-mcrypt     || exit

#portupgrade ${FLAGS} www/php71-session         www/php70-session         || exit
#portupgrade ${FLAGS} archivers/php71-zlib      archivers/php70-zlib      || exit
#portupgrade ${FLAGS} databases/php71-memcache  databases/php70-memcache  || exit

#portupgrade ${FLAGS} www/php71-opcache         www/php70-opcache         || exit
#portupgrade ${FLAGS} security/php71-openssl    security/php70-openssl    || exit
#portupgrade ${FLAGS} databases/php71-pdo       databases/php70-pdo       || exit
#portupgrade ${FLAGS} databases/php71-pdo_pgsql databases/php70-pdo_pgsql || exit
#portupgrade ${FLAGS} databases/php71-pgsql     databases/php70-pgsql     || exit
#portupgrade ${FLAGS} textproc/php71-simplexml  textproc/php70-simplexml  || exit
#portupgrade ${FLAGS} net/php71-soap            net/php70-soap            || exit
#portupgrade ${FLAGS} net/php71-sockets         net/php70-sockets         || exit
#portupgrade ${FLAGS} databases/php71-sqlite3   databases/php70-sqlite3   || exit

portupgrade ${FLAGS} textproc/php71-xml        textproc/php70-xml        || exit
portupgrade ${FLAGS} textproc/php71-wddx       textproc/php70-wddx       || exit

portupgrade ${FLAGS} www/mod_php71 www/mod_php70 || exit

Restart Apache using service apache24 restart.

In the end, PHP 7.0.22 got upgraded to PHP 7.1.9. All is well.

Revit 2018.1 and Licensing System Error 1

A student experienced Revit 2018.1 giving him this rather useless error message:

Licensing System Error 1

After Googling for a solution, we installed/repaired all the Visual C++ runtimes we could find in 3rdParty\x64\VCRedist and in 3rdParty\x86\VCRedist from the Revit 2018 distribution.

Success!

Shame on lazy developers not willing to code reasonable error messages explaning what the program attemped to do with what.

GNU style error messages is a lot better than nonsense words. E.g.:

sourcefile.c: lineno: open("/some/file") = -1, errno = 2 (No such file or directory)


Update 2017-09-05:

Today I had the opportunity to examine another case of “Licensing System Error 1”. This time I installed 3rdParty\x86\VCRedist\2005\vcredist_x86.exe only. As far as I can tell, Visual C++ 2005 Runtime x86 wasn’t installed at all prior to my actions.

Revit 2018.1 and GeForce GTX 1050 Ti

Yesterday, a student installed Autodesk Revit 2018 on his Windows 10 x64 laptop. He then upgraded to Revit 2018.1. After entering the licensing details, Revit crashed. Installing the latest drivers from nVidia, currently at version 385.41, and rebooting the laptop saved us from any more grief.

Pässler PRTG 17.3.32.2478

I’ve been exploring Pässler PRTG on Microsoft Windows Server 2016 (Microsoft Imagine Premium) for the past couple of days. While the system is impressive and on the border of being overwhelming, it lacks complete IPv6 support.

The web interface is IPv4 only, and the NetFlow v9 collector only understands IPv4. PRTG can do PING, SNMP, etc, over IPv6, but you can only specify whether PRTG should contact a device using IPv4 or IPv6, not both. For as long as our networks remain dual-stack it makes sense to explore both network protocols simultaneously, in the same manner we can do with Icinga and Nagios, i.e. specify IPv4 and IPv6 addresses where applicable. A workaround is to register a device twice, once for IPv4 and again for IPv6. Be careful not to create too many duplicate sensors.

I wish PRTG would ask me if I wanted to run autodiscovery after installing it. PRTG detected our core switch as the DHCP (relay) service, duplicating all the sensors it could find.

Neither SNMP nor PRTG are ZFS aware, and in many cases it’s utterly pointless to monitor a lot of ZFS filesystems. Instead we should monitor ZFS pools, if only that were possible.

SNMP doesn’t convey whether a filesystem is diskbased or not, so I had to remove sensors for mountpoints such as /dev, /dev/fd, /proc, /usr/compat/linux/proc, /var/Named/dev, etc.

Patch for math/py-matplotlib

Without this patch, python2.7 will crash when the loop in setup.py reaches setupext.BackendGtk3Cairo().

--- setup.py.orig       2016-09-09 04:50:50.000000000 +0200
+++ setup.py    2017-08-03 17:50:19.742905000 +0200
@@ -98,7 +98,7 @@
     setupext.BackendQt5(),
     setupext.BackendQt4(),
     setupext.BackendGtk3Agg(),
-    setupext.BackendGtk3Cairo(),
+    #setupext.BackendGtk3Cairo(),
     setupext.BackendGtkAgg(),
     setupext.BackendTkAgg(),
     setupext.BackendWxAgg(),

Adventures on ESET NOD32

I decided to upgrade ESET NOD32 from 10.0.390.0 to 10.1.219.1 using the dashboard. Huge mistake! My computer lost network connectivity and only a few programs ran successfully. Even uninstalling NOD32 was partially successful. Prior to 10.0.390.0, I ran NOD32 9.0.386.0.

I was able to download a removal utility and a new installer. I booted into safe mode to run the removal utility. I ensured nothing remained in C:\Program Files\ESET. I rebooted to normal mode and let Malwarebyte’s Antimalware do a one-off scan, just to be safe. (No, I don’t run MBAM on a regular basis.)

A fresh installation of NOD32 10.1.219.1 was successful in the end, and finally my life can go on.

Strange mSATA SSD behaviour on Dell Latitude E7240

One of our Dell Latitude E7240 exhibited strange mSATA SSD behaviour. Disk requests didn’t complete on time. This computer ran the A13 firmware.

The case was eventually solved by upgrading to the A21 firmware executed from an USB stick as the mSATA SSD was unreliable at this point. Apparently, the A18 firmware corrected some mSATA port settings. Also, this was a good opportunity to rid us of Intel’s SA-00075.

This isn’t the first case where disk behaviour suddenly changes to the worst on Latitude E-series laptops, only to be rectified by a firmware upgrade.

AMANDA 3.3.9 as of r441897

misc/amanda-{client,server} as of r441897 fails to create the directory /usr/local/etc/amanda and an empty file named /usr/local/etc/amanda/security.conf. The client will fail during client checks and backup runs claiming:

failed: planner: [Can't get realpath of the security file '/usr/local/etc/amanda/security.conf': No such file or directory]

Here’s the remedy in the short run:

mkdir -p /usr/local/etc/amanda
touch /usr/local/etc/amanda/security.conf

There is one additional issue, pkg-plist claims:

%%SERVER_ONLY%%%%ETCDIR%%/amanda-security.conf

while Makefile says:

--with-security-file=${ETCDIR}/security.conf

This file is needed on each client and the filenames must match.

Due to historical reasons, or is that hysterical raisins(?), /usr/ports/misc/amanda-server/Makefile.local contains

CONFIGURE_ARGS+=	--sysconfdir=/home

Watch PRs 219665 and 219850 for more development on this issue.

Yet another technical oriented blog, more or less