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.

Debating with a compiler

I’m always delighted by the light touch and stillness of early programming languages. Not much text;
a lot gets done. Old programs read like quiet conversations between a well-spoken researcher and a well-studied mechanical colleague, not as a debate with a compiler. Who’d have guessed sophistication bought such noise?

– Dick Gabriel

Ref.: OSCON 2010: Rob Pike, “Public Static Void”, https://youtu.be/5kj5ApnhPAE?t=41

Upgrading PostgreSQL from 9.5.7 to 9.6.3

All commands were done as the root user unless indicated.

This time it was necessary to create a new ZFS hierarchy of filesystems rooted at /var/db/postgres/data96. Also, the new PostgreSQL DBMS runs as the postgres user, not the pgsql user.

# Dump the current database cluster.
su -l pgsql
pg_dumpall | bzip2 -9c > all-db-9.5.7-2017-05-15.sql.bz2
chmod 0400 all-db-9.5.7-2017-05-15.sql.bz2
exit

# Stop the DBMS.
/usr/local/etc/rc.d/postgresql stop

# Configure the new versions.
make -C /usr/ports/databases/postgresql96-server config-recursive

# Upgrade the components using portupgrade.
portupgrade -fpvo databases/postgresql96-client databases/postgresql95-client
portupgrade -fpvo databases/postgresql96-server databases/postgresql95-server
portupgrade -fpvo databases/postgresql96-contrib databases/postgresql95-contrib

# Upgrade everything depending on databases/postgresql96-client.
# Omit the components upgraded in the previous step.
portupgrade -fprv -x databases/postgresql96-client -x databases/postgresql96-server -x databases/postgresql96-contrib databases/postgresql96-client

# Create the new hierarchy.
zfs create zdata/var/db/postgres
zfs create zdata/var/db/postgres/data96
zfs create zdata/var/db/postgres/data96/base
zfs create zdata/var/db/postgres/data96/pg_xlog
zfs set logbias=throughput zdata/var/db/postgres/data96/base
zfs set logbias=throughput zdata/var/db/postgres/data96/pg_xlog
zfs set primarycache=metadata zdata/var/db/postgres/data96/base
zfs set primarycache=metadata zdata/var/db/postgres/data96/pg_xlog
zfs set recordsize=8K zdata/var/db/postgres/data96/base
zfs set recordsize=8K zdata/var/db/postgres/data96/pg_xlog
zfs set redundant_metadata=most zdata/var/db/postgres/data96/base
zfs set redundant_metadata=most zdata/var/db/postgres/data96/pg_xlog
chown -R postgres:postgres /var/db/postgres
chmod -R 0700 /var/db/postgres/data96

# Hide the base and pg_xlog filesystems for now.
zfs unmount zdata/var/db/postgres/data96/base
zfs unmount zdata/var/db/postgres/data96/pg_xlog

# Edit /etc/rc.conf, if necessary, and change postgresql_data to "/var/db/postgres/data96"

# Create the initial database cluster.
/usr/local/etc/rc.d/postgresql initdb

# Rename /var/db/postgres/data96/base and /var/db/postgres/data96/pg_xlog.
mv /var/db/postgres/data96/base /var/db/postgres/data96/base-old
mv /var/db/postgres/data96/pg_xlog /var/db/postgres/data96/pg_xlog-old

# Unhide the two special filesystems.
zfs mount zdata/var/db/postgres/data96/base
zfs mount zdata/var/db/postgres/data96/pg_xlog

# Copy the contents of /var/db/postgres/data96/base-old and /var/db/postgres/data96/pg_xlog-old.
cp -Rp /var/db/postgres/data96/base-old /var/db/postgres/data96/base
cp -Rp /var/db/postgres/data96/pg_xlog-old /var/db/postgres/data96/pg_xlog

# Delete /var/db/postgres/data96/base-old and /var/db/postgres/data96/pg_xlog-old.
rm -R /var/db/postgres/data96/base-old /var/db/postgres/data96/pg_xlog-old

# Start the DBMS.
/usr/local/etc/rc.d/postgresql start

# Copy the old DB dump and change the ownership.
cp -p ~pgsql/all-db-9.5.7-2017-05-15.sql.bz2 ~postgres
chown postgres:postgres ~postgres/all-db-9.5.7-2017-05-15.sql.bz2

# Recreate the old database cluster.
su -l postgres
bzcat all-db-9.5.7-2017-05-15.sql.bz2 | psql -f - template1

# Set a password for the postgres user/role within the database cluster.
psql template1
alter user postgres with password 'somethingsomething';
\q
exit

# Transfer all relevant settings from /usr/local/pgsql/data to /var/db/postgres/data96 for pg_hba.conf and postgresql.conf

# Restart the DBMS.
/usr/local/etc/rc.d/postgresql restart

# Create a new dump of the database cluster.
su -l postgres
pg_dumpall | bzip2 -9c > all-db-9.6.3-2017-05-15.sql.bz2
chmod 0400 all-db-9.6.3-2017-05-15.sql.bz2
exit

# You may now remove the old PostgreSQL hierarchy rooted at /usr/local/pgsql.

Yet another technical oriented blog, more or less