I haven't written about new countries I had contacts with via amateur radio for a while, but today I finally got New Zealand in the log, which has been on my wishlist for a while. Indeed all countries that I don't have in the log yet are on that wishlist, but ranked according to Clublog New Zealand should be the 'easiest' for me.

This morning I had a contact using the FT8 mode with ZL4AS on the 40 meter amateur band. This means a contact over a distance of 18726 kilometers. And by the time I write this the contact is already confirmed via Logbook of The World.

The previous new country was Taiwan, last Wednesday using FT8 on the 20 meter band. That contact was with amateur station BU2FF who also confirmed very fast.

And a while ago I had a contact with a station in Trinidad & Tobago but I haven't seen confirmation yet.

So I am still going strong with contacts on amateur radio, sometimes finding that rare opportunity for a new country.

I always noticed that I had to plug in the USB cable for the remote radio with the radio switched off, otherwise the Kenwood TS480 would switch into transmit mode and stay there until I powered the radio off.

Annoying, and I thought it was something in the serial initialization. Recently I was thinking about this and remembered something about query sequences on serial devices triggering weird behaviour in other devices. From what I read about the Kenwood serial protocol the chance of a few stray characters changing something in the radio is quite possible.

So I considered what Linux software could do a query as soon as a serial port is added to the system. Well, modemmanager was the ideal candidate for this:

Package: modemmanager
[..]
Description-en: D-Bus service for managing modems
 ModemManager is a DBus-activated daemon which controls mobile broadband
 (2G/3G/4G) devices and connections. Whether built-in devices, USB dongles,
 Bluetooth-paired telephones or professional RS232/USB devices with external
 power supplies, ModemManager is able to prepare and configure the modems and
 setup connections with them.

And indeed, simply removing modemmanager made the problem go away. I can now plug in the USB cable when the radio is on and nothing happens.

After starting the collection of a lot of the system data I wanted with telegraf/influxdb/grafana one small part was missing: the temperature sensors. I like these, so I had a look and found the inputs.temp plugin in telegraf which is normally disabled.

Enabling it on hosts that have actual hardware to measure worked ok. On the Raspberry Pi systems it gives one temperature:

> SHOW TAG VALUES ON "telegraf" WITH key="sensor" WHERE host='joy'
name: temp
key    value
---    -----
sensor cpu_thermal_input

On the home server conway it gives quite a lot of temperatures:

> SHOW TAG VALUES ON "telegraf" WITH key="sensor" WHERE host='conway'
name: temp
key    value
---    -----
sensor coretemp_core0_crit
sensor coretemp_core0_critalarm
sensor coretemp_core0_input
sensor coretemp_core0_max
sensor coretemp_core1_crit
sensor coretemp_core1_critalarm
sensor coretemp_core1_input
sensor coretemp_core1_max
sensor coretemp_core2_crit
sensor coretemp_core2_critalarm
sensor coretemp_core2_input
sensor coretemp_core2_max
sensor coretemp_core3_crit
sensor coretemp_core3_critalarm
sensor coretemp_core3_input
sensor coretemp_core3_max
sensor coretemp_core4_crit
sensor coretemp_core4_critalarm
sensor coretemp_core4_input
sensor coretemp_core4_max
sensor coretemp_core5_crit
sensor coretemp_core5_critalarm
sensor coretemp_core5_input
sensor coretemp_core5_max
sensor coretemp_physicalid0_crit
sensor coretemp_physicalid0_critalarm
sensor coretemp_physicalid0_input
sensor coretemp_physicalid0_max

For the dashboard showing all relevant temperatures for a system this is a bit overkill and makes the dashboard hard to read. Solution: go for all the temperature sensors that end in 'input', with the variable in the dashboard defined as 'ending in input':

> SHOW TAG VALUES ON "telegraf"  WITH key="sensor" WHERE host='conway' AND sensor=~/input$/
name: temp
key    value
---    -----
sensor coretemp_core0_input
sensor coretemp_core1_input
sensor coretemp_core2_input
sensor coretemp_core3_input
sensor coretemp_core4_input
sensor coretemp_core5_input
sensor coretemp_physicalid0_input

So far this works with all physical systems.

Grafana host dashboard with telegraf data including entropy. The dip in entropy is caused by the dnssec-signzone process

I have been collecting certain system data for ages with rrdtool, but now I see what is possible with Telegraf collecting agent and after some initial attempts I'm all in favour and data is flowing.

All the data I collected is already standard in telegraf, including entropy! Other data is also collected that is good to keep an eye on for performance.

I made some tweaks to the standard telegraf configuration: collect every 5 minutes, not exactly on the clock since I read The mystery of load average spikes which reminded me of my own experience Be very careful of what you measure. I also avoid gathering data on nfs filesystems (which come and go thanks to autofs).

I rolled out telegraf over all systems at home, and now there is a nice 'System info' dashboard in Grafana.

I continued my slow migration of statistics to Influxdb/Grafana and added the network traffic. I've been gathering this for ages in rrdtool, my earlier view was that I've been using rrdtool for network and other statistics since October 2002 so it is a bit of a change.

I updated the perl scripts that fetch network traffic statistics over SNMP to also add the data to influxdb. And it was simple to create a dashboard with that data. The overview pages with data for all interfaces for one measured host also link to detail pages per interface which also show the number of errors.

I'm personally not a huge fan of wildcard TLS certificates (risks with reuse of the private key) so I didn't try those yet, but based on my experiences with certificates with multiple names with zerossl I got a response: Stephen Harris on Twitter: Do they support wildcards and I just had to try. And it works! I requested a certificate:

        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:gosper.idefix.net, DNS:*.gosper.idefix.net

And indeed it worked:

        Issuer: C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
        Validity
            Not Before: Sep  1 00:00:00 2021 GMT
            Not After : Nov 30 23:59:59 2021 GMT
        Subject: CN = gosper.idefix.net
[..]
            X509v3 Subject Alternative Name: 
                DNS:gosper.idefix.net, DNS:*.gosper.idefix.net

So that works too! The choice for gosper.idefix.net is because I already had dns records setup for dns-01 based verification of that name.

I assumed the free tier of zerossl doesn't allow for certificates with multiple names but I guess I assumed wrong, because I just got issued a certificate with multiple names.

After debugging my earlier issues with zerossl and finding out I forgot the CAA record this time I tried a certificate with the subjectAltName extension in use with more than one name.

$ openssl req -in httprenewable/webserver-devvirtualbookcase.csr -noout -text
[..]
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:developer.virtualbookcase.com, DNS:perl.virtualbookcase.com

And the certificate dance went fine with dehydrated:

$ ./dehydrated/dehydrated --config /etc/dehydrated/config.zerossl -s httprenewable/webserver-devvirtualbookcase.csr > tmp/certificate.crt
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for developer.virtualbookcase.com
 + Handling authorization for perl.virtualbookcase.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for developer.virtualbookcase.com authorization...
 + Challenge is valid!
 + Responding to challenge for perl.virtualbookcase.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
 + Checking certificate...
 + Done!
$ openssl x509 -in tmp/certificate.crt -noout -text | less
[..]
            X509v3 Subject Alternative Name:
                DNS:developer.virtualbookcase.com, DNS:perl.virtualbookcase.com

The /etc/dehydrated/config.zerossl has the EAB_KID and EAB_HMAC_KEY values set to the ones associated with my account.

This means zerossl works as a complete secondary certificate issuer and I could switch over completely in case LetsEncrypt isn't available. Choice is good!