News archive January 2019 - Koos van den Hout

I have "always" been running amanda for backups on linux. Or rather, I can't find any indication when I started doing that several homeserver versions ago, it's just still running.

Or it was running, but first I had to tackle a hardware problem: all SCSI controllers I have are PCI and the newest homeserver has no PCI slots. So I searched for a solution. The first solution was to try using the desktop system for the tapedrive, but the powersupply in that system has no 4-lead Molex connectors so I can't connect the tapedrive.

For now I use an old 'test' system with some software upgrades to run amanda and shut it down when all backups are done and flushed to tape. But amanda had a serious problem writing stuff to tape. With some debugging this turned out to be caused by the variable blocksize I used on the previous systems, with

# mt -f /dev/nst0 setblk 0

and I can't even find out why this seemed like a good idea years ago. But now amanda really wants to use 32768 byte blocks and filled a DDS-3 tape (12 Gb without compression) with about 1.8 Gb of data before reaching the end of the tape.

Why this default has changed isn't clear to me, but I found a way to re-initialize the tapes so the backups fit again. Based on block size mismatch - backup central I created a script to do this. I did not get the error about the blocksize, but I searched specifically for 'amanda 3.3.6 blocksize'.

#!/bin/sh

if [ "$1" = "" ]; then
        echo "Usage: $0 <tapename>"
fi

mt -f /dev/nst0 setblk 32768
mt -f /dev/nst0 compression 1
mt -f /dev/nst0 rewind
dd if=/dev/zero of=/dev/nst0 bs=32768 count=200
mt -f /dev/nst0 setblk 32768
mt -f /dev/nst0 compression 1
mt -f /dev/nst0 rewind
amlabel -f kzdoos $1

And now normal amounts of data fit on a tape again. I just have to initialize every tape before using it for the first time in this setup.

This weekend I participated in the BARTG (British Amateur Radio Teledata Group) RTTY Sprint Contest.

I went into this contest with the idea of maybe getting some contacts and things turned out somewhat better than that: I made 82 contacts. No new countries or anything else special. The one that got away was PJ4P, Bonaire. I saw that station calling and I kept answering but the contact did not happen.

I used the topendfed antenna outside and the amplifier. So I entered in the high power category.

As with other recent contests the propagation wasn't cooperating very well. When I started in HF at home (October 2014) I would switch from 10 to 20 meters after it got dark because of the changing propagation. Now I change from 20 to 40 meters as soon as it starts to get a bit dark.

Like in 2015, 2016, 2017 and 2018 I participated in the UBA PSK63 Prefix Contest in the past weekend. Before I really dove into the contest I first mounted a new end-fed 10/20/40 antenna which can handle more power and tested it.

It took a few tries to get the antenna tuned on the 40 meter band. I tested this with the amplifier which has proven to be really precise about the SWR of the antenna in the 40 meter band, as noted in my post about the ARRL RTTY roundup 2019. I had planned to get this antenna up and running before that contest but that did not work out.

After testing I switched back to 50 watts power without the amplifier because the rules of the UBA PSK63 prefix contest limit the power.

I made a total of 69 contacts as single operator 40 meter. I had a short look at PSK63 activity in the 20 meter band during daylight but it was completely none.

After the contest I tried some FT8 contacts on the 40 meter band with the amplifier active. The amplifier did not like this and went into SWR protection. I must have tuned it perfectly for 7.040 - 7.050 MHz but the SWR is already outside the limits for the amplifier at 7.074 MHz.

I received a "complaint" that a very old site on the webserver wasn't working anymore. I am not a person to just stop something without planning that so this was an oversight. It was one of the userdirs on idefix.net: Ivo van der Wijk who hasn't updated the page sinds 1994. No, really, not even the broken links.

In restoring this one and the others I found that php in userdirs is disabled by default nowadays, found via PHP not working in userdir (public_html) - devPlant. Maybe a good idea, but I only enable php on virtualhosts where I want it, so I disabled that rule. I hadn't missed it on my own webspace yet, but a site like Het online dagboek van hester (Renate) in Australie (en daar in de buurt) depend on PHP completely.

While I was looking for the reason the php failed I also noticed that /etc/apache2/mods-available/userdir.conf also has some configuration I do not appreciate, it enables userdirs globally when the module is loaded:

<IfModule mod_userdir.c>
        UserDir public_html
        UserDir disabled root

        <Directory /home/*/public_html>
                AllowOverride FileInfo AuthConfig Limit Indexes
                Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
                Require method GET POST OPTIONS
        </Directory>
</IfModule>

I disabled that part: I only want the userdir to work on specific virtual hosts.

The last time I did those was in 2017: Reviewing my 2016 amateur radio resolutions, and the new ones for 2017 and the hindsight results for 2017/2018 are:

• Improve the holiday/portable setup with solar power and a lightweight multiband inverted V
  No solar power (due to costs) but the portable setup is improved and tested: the fiber mast I bought for playing radio from several locations including amateur radio from a local park. Now to find more time to actually use it.
• Keep doing the digimode contests
  That part went better in 2017 and I had less time and/or energy for contests in 2018. Also in 2018 the interference situation got worse. So my net results in contests improved in 2017 and got worse in 2018.
• Maybe those satellites
  I tried at least receiving them a few times, but no contacts yet.
• Get a 2m/70cm vertical antenna on the roof of the dormer
  It's there, it has already been upgraded to a bigger antenna with higher gain and it's mostly used for 2 meter FT8. But also for actual talking to other radio amateurs sometimes.

The Sotabeams newsletter had an item "Setting your targets for 2019" which had some nice ideas and which triggered me to write this post. Things I want to try :

• Keep learning morse!
• Get more countries on more HF bands in the log
• Moonbounce on 2 meter
• Those digimode contests, and maybe a few phone contests
• Operate HF outside
• At least one satellite contact

Today I tried to follow a link to http://www.independentri.com/ but I got an error message:

451: Unavailable due to legal reasons

We recognize you are attempting to access this website from a country belonging to the European Economic Area (EEA) including the EU which enforces the General Data Protection Regulation (GDPR) and therefore access cannot be granted at this time

And indeed in the headers:

$ lynx -head -dump http://www.independentri.com/
HTTP/1.1 451 Unavailable For Legal Reasons

I see the real reason as 'not wanting to comply with European consumer protection laws'. I have no idea how many visitors the site is missing due to this regionblock but since it's a regional weekly newspaper in the United States of America: probably not a lot of the intended audience.

De spammers hebben geen goede voornemens, of voornemens die ik niet als goed zou benoemen, want ook in 2019 gaan ze vrolijk door. Nog steeds spam die gericht is aan een belgisch bedrijf op een .nl adres.

Hetzelfde patroon, nu van Ticket Restaurant Belgie. De advertentietekst is allemaal in het nederlands, de standaard leugens dat ik me geabonneerd zou hebben en dat ik me zo kan uitschrijven zijn in het frans en verwijzen naar NeoPro.

En ook van onlinevisa.eu krijg ik spam, zelfs met de naam "Maes-Swerts/A." er weer eens in. Die had ik een tijd niet gezien!

Ook King Oak VOF gebruikt blijkbaar het zelfde bestand om te spammen. Dat bestand is minstens 7 jaar oud.

Eerder, eerder, eerder, eerder, eerder, eerder.

As planned I participated in the ARRL RTTY Roundup contest this weekend. It was possible to participate in FT8 mode but since I had not prepared for that and had no duplicate checking between FT8 and RTTY I decided to use the mode I am familiair with for this contest: RTTY.

I operated on the 40 meter band Saturday and Sunday evening, and on the 20 meter band during the daylight hours of Sunday. Everything was search and pounce, no responses to calling CQ. I used the power amplifier on the 20 meter band which did help in getting the contacts to almost every station I could decode. The amplifier does not like the SWR from the antenna on 40 meters so I ran without the amplifier on that band.

I made 115 contacts. A number of US stations, already the first new US state confirmed via LoTW. Two more new US states in the log, hope I can get those confirmed too.

In between a few other not too far FT8 contacts I suddenly had a contact with 9M2TO in West Malaysia, a new country for me in amateur radio. I had seen the call before but I did not expect the contact to happen.

And it's already confirmed via Logbook of The World too.

More than a year after I started migrating from homeserver greenblatt to the new homeserver conway the last migration is done and the old server is switched off. The new server is in a good position in the rack, and the old server is still taking up space in there too. It has taken a lot of time, I decided to stop some websites and other unused services in the process and my energy levels haven't always been that great. I have improved several things in the process, which also caused delays.

One thing hasn't changed (which I did expect to change): the power usage of the new server isn't lower! The UPS tells me the output load is about the same. Ok, the new hardware has a lot more CPU power, a lot more memory and faster storage, but I expected the poweruse to go down a bit.

The new hardware for the homeserver has no external serial ports, so I could not use the old serial / 1-wire interface that has been doing the home monitoring for years. But I had a spare USB DS2490 interface. So I plugged this into the server and wanted to forward the USB device to the guest VM that runs all the monitoring.

First I had to blacklist all the loaded drivers to have the device available to kvm as-is. In /etc/modprobe.d/local-config.conf:

blacklist w1_smem
blacklist ds2490
blacklist wire

Next step was to attach the device to the right vm. I followed the hints at How to auto-hotplug usb devices to libvirt VMs (Update 1) and edited the definition for the vm to get the host device like:

    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x04fa'/>
        <product id='0x2490'/>
      </source>
    </hostdev>

But that did not get the usb device attached to the running VM and I did not feel like rebooting it. So I created an extra file with the above and did a

root@conway:~# virsh attach-device --live gosper /tmp/onewire.xml 
Device attached successfully

And then I had to do the same blacklisting as above in the virtual machine. After doing that I detached and attached it from the VM without touching it with simply:

root@conway:~# virsh detach-device --live gosper /tmp/onewire.xml 
Device detached successfully

root@conway:~# virsh attach-device --live gosper /tmp/onewire.xml 
Device attached successfully

After that I had to set up rules for the telemetry user to have enough access to the USB device:

#
SUBSYSTEMS=="usb", GOTO="usb_w1_start"
GOTO="usb_w1_end"
LABEL="usb_w1_start"
ATTRS{idVendor}=="04fa", ATTRS{idProduct}=="2490", GROUP="telemetry", MODE="0666"
LABEL="usb_w1_end"

And now it all works:

telemetry@gosper:~$ digitemp_DS2490 -a
DigiTemp v3.7.1 Copyright 1996-2015 by Brian C. Lane
GNU General Public License v2.0 - http://www.digitemp.com
Found DS2490 device #1 at 002/003
Jan 01 21:53:11 Sensor 10A8B16B0108005D C: 9.500000
Jan 01 21:53:12 Sensor 28627F560200002F C: 17.062500
Jan 01 21:53:14 Sensor 10BC428A010800F4 C: 19.562500
Jan 01 21:53:15 Sensor 1011756B010800F1 C: 11.937500
Jan 01 21:53:16 Sensor 10B59F6B01080016 C: 16.312500
Jan 01 21:53:17 Sensor 1073B06B010800AC C: 18.687500
Jan 01 21:53:18 Sensor 102B2E8A010800F0 C: 29.250000
Jan 01 21:53:20 Sensor 28EF71560200002D C: 16.687500

Working house temperatures again!