News items for tag linux - Koos van den Hout

2020-03-03 Adding contact e-mail addresses to letsencrypt accounts via dehydrated 7 months ago
Encrypt all the things meme I noticed the news about LetsEncrypt revoking a lot of certificates on 4 March 2020 and did some checking to find out eventually that one of my certificates is in that set. Users have been notified of this problem... when their account had a contact e-mail address. By default dehydrated doesn't set an e-mail address so none of my instances used one. I do like to get informed so I searched how to update the contact info. The data is in /etc/dehydrated/config field CONTACT_EMAIL but I needed some searching before I found the method to get the update passed on to LetsEncrypt.

Some searching later found Update registration email address - Issue #425 dehydrated which shows that a simple dehydrated --account does the magic.

Tags: , ,
2020-02-17 Tweaking the SSL cipher settings for 2020 8 months ago
Encrypt all the things meme A few days ago I changed the configuration of haproxy to stop accepting TLSv1.0 and TLSv1.1. With the upcoming deprecation of TLSv1.0 and TLSv1.1 this seemed the right SSL configuration. Today I remembered there is one directly reachable Apache server, so I had a look at the settings there and checked the results with the Qualys SSL Labs SSL Server test where I noticed some ciphers listed as 'weak'. And seeing different results between my haproxy and apache servers, which I did not expect as I used the same settings for SSLCipherSuite in Apache and ssl-default-bind-ciphers in haproxy.

The last issue was caused by the fact that Apache2.4.25 in Devuan ascii uses libssl 1.0.2 and haproxy 1.7.5 uses libssl 1.1.0. I'm not sure that's an ideal configuration but it's what I work with.

With the output of openssl ciphers -v I get a list of cipher names. But this is with libssl1.1.0 so the output lists ciphers that Apache doesn't have access to (yet). The good part is that Apache ignores ciphers that aren't available, so the net result is a running and working configuration.

The current result is for Apache 2.4.25:
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256
And for haproxy 1.7.5:
ssl-default-bind-options force-tlsv12 no-tls-tickets
ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256
The fun part is that I can test the SSL negotiation with sslscan locally but sslscan is linked against openssl 1.0.2 so it misses some of the newer options. And I also test with the Qualys SSL Labs ssl test but that takes a while.

The too long; didn't read version of finding the right configuration options

And later I found I could have saved a lot of time researching options using the Mozilla SSL Configuration Generator. I don't completely agree with the suggestions there because I want to generate my own dhparams. Using 'well-known Diffie-Hellman paramaters' has security risks. But otherwise all the suggestions for ciphers are very usable and save me a lot of time.

Tags: , , ,
2020-02-10 Getting with the times and limiting the webserver to TLSv1.2 8 months ago
In 2020 the support for TLSv1.0 and TLSv1.1 will end so the famous qualys SSL test is giving capped grades. I decided to get with the times and limit my outside web ports to TLSv1.2 so now I am back at an A+ grade.

Eventually this will start to cause problems as Devuan stable doesn't have an openssl with TLSv1.3 support yet.

Tags: , , ,
2020-01-30 Backup to a remote webdav server, first success! 8 months ago
I found a completely different option for transferring files from linux to a remote webdav filesystem: fusedav. Mounting the remote 'cloud' disk with fusedav and synchronizing files with rsync is starting to work.

I decided to split my backups into two categories: first there are file collections that usually only grow, like digital camera pictures and audio project files. This takes the most diskspace and doesn't really need versioning.

The second category is configuration files, homedirs, mail and other things that change and where I may need an older version. This is where backups based on amanda work better.

I mount the filesystem with:
$ fusedav -u koos -p topsecret https://webdav.cloudprovider/remote.php/webdav/ /home/koos/webdavmount/
And the rsync command to backup to this mount:
$ rsync -av --progress --bwlimit=512K --size-only --timeout=30 /camera/2003/ webdavmount/camera/2003/
This looks scriptable so it can run on a regular basis with just a status update to me.

Update:
Reliability is still an issue. I added the --timeout=30 parameter to make rsync abort when the bytes stop flowing.
Read the rest of Backup to a remote webdav server, first success!

Tags: , ,
2020-01-24 Longest matching IPv6 address selection biting me 9 months ago
Trying to get devuan updates, I see:
Err:5 http://nl.mirror.devuan.org/merged ascii Release
  404  Not Found [IP: 2001:878:346::116 80]
Err:6 http://nl.mirror.devuan.org/merged ascii-security Release
  404  Not Found [IP: 2001:878:346::116 80]
Err:7 http://nl.mirror.devuan.org/merged ascii-updates Release
  404  Not Found [IP: 2001:878:346::116 80]
While nl.mirror.devuan.org has no shortage of IPv6 and IPv4 addresses:
;; ANSWER SECTION:
nl.mirror.devuan.org.   78083   IN      CNAME   deb.devuan.org.
deb.devuan.org.         78083   IN      CNAME   deb.roundr.devuan.org.
deb.roundr.devuan.org.  845     IN      AAAA    2001:638:a000:1021:21::1
deb.roundr.devuan.org.  845     IN      AAAA    2a01:4f8:140:1102:2b76:955d:b48f:bdf3
deb.roundr.devuan.org.  845     IN      AAAA    2001:878:346::116
deb.roundr.devuan.org.  845     IN      AAAA    2a01:4f8:162:7293::14
deb.roundr.devuan.org.  845     IN      AAAA    2800:a8:c001::a
deb.roundr.devuan.org.  845     IN      AAAA    2a01:4f9:2a:fa9::2
deb.roundr.devuan.org.  845     IN      AAAA    2001:590:3803::31:151
deb.roundr.devuan.org.  845     IN      AAAA    2001:4ca0:4300::1:19
deb.roundr.devuan.org.  845     IN      AAAA    2a02:2a38:1:400:422a:422a:422a:422a
deb.roundr.devuan.org.  845     IN      AAAA    2a0a:e5c0:2:2:400:c8ff:fe68:bef3

;; ANSWER SECTION:
nl.mirror.devuan.org.   78063   IN      CNAME   deb.devuan.org.
deb.devuan.org.         78063   IN      CNAME   deb.roundr.devuan.org.
deb.roundr.devuan.org.  824     IN      A       46.4.50.2
deb.roundr.devuan.org.  824     IN      A       130.225.254.116
deb.roundr.devuan.org.  824     IN      A       190.64.49.124
deb.roundr.devuan.org.  824     IN      A       31.220.0.151
deb.roundr.devuan.org.  824     IN      A       200.236.31.1
deb.roundr.devuan.org.  824     IN      A       131.188.12.211
deb.roundr.devuan.org.  824     IN      A       141.84.43.19
deb.roundr.devuan.org.  824     IN      A       37.187.111.86
deb.roundr.devuan.org.  824     IN      A       5.196.38.18
deb.roundr.devuan.org.  824     IN      A       95.216.15.86
deb.roundr.devuan.org.  824     IN      A       185.38.15.81
I always get the error for 2001:878:346::116 when connecting. This site seems to have a problem with the devuan mirror at the moment, so I'd like to use another one, but apt keeps going back to the same source. This has to do with IPv6 address destination selection (RFC 3484 / RFC 6724).

A good explanation at IPv6 Destination Address Selection – what, why, how - Karl Auer with:
Rule 9, “use longest matching prefix“, will prefer the candidate destination address that shares the greatest number of contiguous leading bits with the source address that would be chosen for it. Such an address is likely to be topologically closer to the source address.
Indeed that address is close to my home network addresses:
2001:0878:0346:0000:0000:0000:0000:0116
2001:0980:14ca:0001::/64
So the "roundr" round robin isn't very round for IPv6 users.

Workaround: reject the address that is giving me problems:
# ip -6 route add unreachable 2001:878:346::116
# apt update
Get:1 http://nl.mirror.devuan.org/merged ascii InRelease [25.6 kB]
Get:2 http://nl.mirror.devuan.org/merged ascii-security InRelease [25.6 kB]
Get:3 http://nl.mirror.devuan.org/merged ascii-updates InRelease [25.6 kB]
Get:5 http://nl.mirror.devuan.org/merged ascii-security/main Sources [185 kB]
Hit:4 http://packages.roundr.devuan.org/merged ascii InRelease
Get:6 http://nl.mirror.devuan.org/merged ascii-security/main amd64 Packages [480 kB]

Tags: , ,
2020-01-21 Suricata and ppp: restart of suricata needed after ppp down/up 9 months ago
Suricata is running and detecting attacks, but it was causing a 100% cpu load after a restart of the ppp connection (the DSL here uses PPP over Ethernet).

The errors point at the problem starting when the ppp connection restarts:
21/1/2020 -- 00:59:36 - <Error> - [ERRCODE: SC_ERR_AFP_READ(191)] - Error reading data from iface 'ppp0': (100u) Network is down
21/1/2020 -- 00:59:37 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't set fanout mode, error Invalid argument
Which also starts to fill the system log with:
Jan 21 00:59:42 xxxxxxxx kernel: [11347441.726755] device ppp0 left promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.055712] device ppp0 entered promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.071533] device ppp0 left promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.091653] device ppp0 entered promiscuous mode
The interesting part is that this causes higher power usage about five and a half hours later.

Solution: restart suricata in an /etc/ppp/ip-up.d/ script.

Tags: , , ,
2019-12-01 Better audio for learning morse 10 months ago
I installed xcwcp from the unixcw packages on a different system and noticed it did not use PulseAudio. It said it could not find PulseAudio and skipped to ALSA. The downside of ALSA in xcwcp is that it pushes audio 10 characters ahead, with PulseAudio the buffer is smaller.

Some searching using strace found that xcwcp tries to open libpulse-simple.so which wasn't found on that system. It is available on my laptop, as part of:
$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so
libpulse-dev:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so
while the files linked to a part of the runtime package:
$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0
libpulse0:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0
$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.1
libpulse0:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.1
But I don't have package libpulse-dev on that other system.

Solution: make the symlink by hand in /usr/lib/x86_64-linux-gnu with:
user@system:/usr/lib/x86_64-linux-gnu$ sudo ln -sf libpulse-simple.so.0 libpulse-simple.so
And I reported it as a bug for ubuntu: Bug #1854630: xcwcp doesn't use pulseaudio but given the list of bugs in Ubuntu I reported or commented on before with a lot of 'undecided' and not a lot of progress I'm not sure anything will happen.

Back to practising morse after this diversion!

Tags: , ,
2019-11-21 First setup of the remoterig interfaces 11 months ago
The remoterig set I ordered arrived.

At first I found the box somewhat empty: no manuals. But the entire manual can be found on-line: User manuals - RemoteRig. The manual is about 200 pages so printing it would be a bad idea. The remoterig site is somewhat slow so I downloaded the PDF manual to my computer.

Most of the setup is done via a webinterface, but the initial network setup needs either the right IP addresses hardcoded or a USB connection and the Microbit setup software which is only available for Windows. I did try to see whether one of the four com-ports via USB that showed up would allow me to do a minimal setup via a terminal program but that wasn't true. So I booted Windows to change the units to DHCP. For the radio-side I made an address allocation in the DHCP server, for the client side it is fine to have any usable address.

And for my next minor issue: they only use IPv4. So my inner linux and networking geek is a bit dissapointed, but my inner radio geek will do just fine.

After that bit I went back to Linux, the rest of the software setup is via a webbrowser. For the hardware setup, which is how it connects to the radio (which pin has audio, which pin has power) it needs a number of internal jumpers and jumper wires connected.

Tags: , , ,
2019-10-25 Slow(ish) syn floods getting more complicated to filter 1 year ago
Cybercriminal I'm seeing lots of sockets in state SYN_RECV again and noticed this time my earlier iptables rules to not respond to tcp syn packets that don't build up a connection aren't working. Between two syn packets from the same source there is 5 minutes, so my system responds to all of them. Ranges of addresses in the same block are used as source IPv4 addresses. For one address the traffic is very minimal:
22:40:51.600077 IP 112.175.120.39.58275 > 82.95.196.202.22: Flags [S], seq 720891004, win 29200, length 0
22:40:51.600392 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:52.612035 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:54.628048 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:58.660031 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:41:06.851865 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:41:22.980000 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:45:18.565999 IP 112.175.120.39.41767 > 82.95.196.202.465: Flags [S], seq 910623633, win 29200, length 0
22:45:18.566415 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:19.588000 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:21.604022 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:25.667936 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:33.860000 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:49.987965 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
But multiply this with several source IPs in the same IPv4 /24 block and a lot of open servers in the world and suddenly you get a lot of return traffic.

Tags: , ,
2019-10-16 The signatures for the first DNSSEC signed zone expired, and I signed the rest 1 year ago
Today I was reminded of the first zone I signed with DNSSEC and did the check again with DNSViz. And I saw a lot of error messages. Some searching found that I let all the signatures expire (after the default time of 30 days).

Solution: re-sign the zone and have a careful look at when I need to sign the zones again. Officially just in time for expiry time of the signature (default 30 days) minus TTL of the record.

Obviously this process has to be automated. In the first go I decided to force new signatures after 21 days. But I tested some things later and decided to go for more regular checks of the ages of the signatures and refresh the signatures that are about to expire. This is usually reserved for 'big' zones with lots of resolvers querying them but I decided to implement this myself to avoid problems, and learn more about DNSSEC.

The magic signing command is now:
-zone-signedserial:
    named-checkzone $* $^
    ./SOA.pl $^
    dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -e +2592000 -i 604800 -j 86400 -o $* $^
    rndc reload $*
    touch $@
The expiry is set with -e at 30 days, the checkinterval with -i at 7 days and the jitter factor with -j at 1 day.

Now there is a special part in the Makefile to be called from cron on a regular basis. It won't produce any output when there is nothing to update.
agecheck:
    @for zone in $(SIGNEDZONES); do if [ `find $${zone}-signedserial -mtime +7 -print` ]; then touch $${zone}-zone ; $(MAKE) --no-print-directory $${zone}-signedserial; fi ;done
The Make variable SIGNEDZONES is filled with the zonenames of the zones that have to be kept DNSSEC signed. File structure for each forward zone is as listed in first zone with valid DNSSEC signatures.

So now almost all my domains are DNSSEC signed. A learning experience and a good level of security.

Tags: , , ,
2019-09-11 First zone with valid DNSSEC signatures 1 year ago
My previous test with DNSSEC zone signing showed a problem with entropy in virtual machines. Today I had time to reboot the home server running the virtual machines including the virtual machine with the nameserver, based on bind9.

Now I can create DNSSEC signatures for zonefiles at high speed (0.028 seconds) with enough entropy available. My first test is with camp-wireless.com which is a domainname for redirecting to Camp Wireless but since that variant was mentioned somewhere I had to generate the redirects to the right version.

The next step was to upload the DS records for the zone to my registrar and get them entered into the top level domain. This failed on the first attempt, the DS records have to be entered very carefully at the registrar.

I tested the result with dnsviz for camp-wireless.com and found an error in the first try: I updated the serial after signing the zone. So the soa record wasn't signed correctly anymore.

I updated my zonefile Makefile to do the steps in the right order:
-zone-signedserial:
        named-checkzone $* $^
        ./SOA.pl $^
        dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -o $* $^
        rndc reload $*
        touch $@
For the zone camp-wireless.com the original data is in camp-wireless.com-zone, the DNSSEC signatures in camp-wireless.com-zone.signed. And make will abort when one of the commands gives an error level, so it will for example stop completely when I make a typo in the zonefile which will make named-checkzone fail. The -D option creates a file to be used with $INCLUDE in the original zonefile. This does create a circular dependency: named-checkzone will fail when the -signedserial file isn't available on the first run. So the first run will have to be manually.

So now the zone is signed correctly. The next developments will be to find out how to monitor this extensively so I won't be surprised by problems and to redo the signing from time to time to make DNSSEC zone walking very hard.

And when I trust all of this I will implement it on other domain names that I manage.
Read the rest of First zone with valid DNSSEC signatures

Tags: , , ,
2019-09-08 A thumbs up for robust scripts 1 year ago
Encrypt all the things meme Today some of the letsencrypt certificates were older than 60 days, so the renewal script started to kick in. Last year I completely automated the certificate renewal of letsencrypt certificates with dehydrated and wrote some scripts around the renewal process with hopefully enough error handling.

Today some of the error handling got tested, one renewal gave an error:
  + ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/new-order (Status 500)
And indeed the dehydrated script gave an error level, the resulting (empty!) .crt file wasn't copied and nothing happened. On the next run of the renewal script this certificate will still be older than 60 days and therefore the renewal will be tried again.

Tags: , , ,
2019-09-06 The morse keyer is working with cqrlog 1 year ago
Next step was linking the morse keyer with the Linux radio logging and operating software cqrlog. A simple search gave me Nanokeyer with cqrlog - CQRLOG and indeed the suggested option 'WinKeyer USB' works. The option 'K3NG keyer' always stopped after a few characters of morse.

Now to get other software like fldigi and tlf working. And not have conflicts with both of them running.

Update: In the tlf manual I found a link to N0NB/winkeydaemon on github which works great too. I changed the default port /dev/ttyUSB0 to /dev/ttywinkey because USB0 is where my radio CAT control usually ends up, and two applications trying to use that serial port confuses the radio. The /dev/ttywinkey link is maintained by udev, with a rule in /etc/udev/rules.d/99-usb-serial.rules :
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttywinkey"
I can't select on a serial number or anything more specific so devices with a QinHeng Electronics HL-340 USB-Serial adapter will probably all try to get a symlink to /dev/winkeyer.

I tested the result with cqrlog (selecting the cwdaemon option in cqrlog cw settings) and it works fine too. Next step will be to test with tlf.

Tags: , ,
2019-09-06 The nanoKeyer morse keyer is working 1 year ago
nanoKeyer morse keyer and morse paddle key
The nanoKeyer and the morse paddle key. Connections to the nanoKeyer from left to right: cw to radio, input from paddle and usb to the computer
After a few hours of thoroughly soldering and checking the results the nanoKeyer is done. I did find an error in my work so I had to get out the desoldering iron to fix it: I put the wrong resistor in one place.

Next step was to get the arduino that is the core of the nanoKeyer tested. There was an arduino nano included with the kit preprogrammed with the nanoKeyer software, but it still needed the print headers soldered: two rows of 15 pins and very secure soldering work. I did put the small tip on my soldering station for this work and used a magnifying glass to check my results. It seemed to work fine but I noticed soon the speed control potentiometer and the menu buttons gave no response. Both those functions use an analog input of the Arduino in the nanoKeyer. I had bought an arduino at a previous radio parts market so I tried that one. This one already had the print headers installed so there was less chance of causing a defect.

That one had to be programmed first, so I dove into getting the Arduino integrated development environment installed. After a few tries it seemed the only way to have working USB communications is to run the whole Arduino IDE as root (using sudo). Not very secure but at least I could continue my work. The right settings were made according to the nanoKeyer Firmware Upload Guide 2 and the Arduino nano I bought myself works fine. The result: sending morse code, changing settings with the menu button all worked fine.

The ultimate step was to get software controlled CW generation working. I soon found Winkey USB works in Linux - OK1RR which has a driver binary (no source unfortunately) which communicates fine with the nanoKeyer. The network UDP protocol is somewhat very binary so I used one of the cwdaemon test programs to get actual morse code sent from the computer.

Now for the (for me) hard part: making the right holes in the case. I'll try to find some help at my radio club.

Earlier steps: starting with the nanoKeyer kit.

Tags: , , ,
2019-08-21 Comparing yfktest and tlf for linux-based amateur radio contesting 1 year ago
Episode 295 of Linux in the Ham Shack is about the TLF Contest Logger. I wrote to Linux in the Ham Shack about my experiences with both programs. In 2017 I participated in the IARU-HF contest using yfktest and in 2019 I participated in the IARU-HF contest using TLF.
My opionion about both is clearly formed by my style of contesting. Phone contesting is rare for me, and I am a very casual contester. I operate in search and pounce mode, where I search for other stations calling CQ.

My experiences:

Both are textmode programs, which try to mimic DOS-based contest programs. No dragging around windows, you'll have to deal with how the makers decided to set up the screen. Also, on a graphical system, try to find the biggest and baddest monospace font to fill as much of your screen with the contesting software as possible.

The role of contest logging software is making it easier to log contacts in a contest. It does this by automating a lot of the tasks in a CW contest, by keeping the log and showing the outgoing serial number (if needed). It's a plus when contest logger can keep the live claimed score in the contest and when it can connect to a DX-cluster and show possible contacts being spotted. Both packages can do the basic contesting and scorekeeping, tlf is the only one that supports DX clusters

yfktest is written in Perl, tlf in C. For adding a new contest to yfktest you will soon have to do some programming in perl to handle the score calculations. For a new contest in tlf you may have to do some C programming.

yfktest has no cluster support, but tlf does have it. This is a huge difference to me. With tlf I could open a cluster window showing me where new calls were spotted and on what frequencies recent contacts were, so I could hunt for interesting new calls and multipliers

Specific to the IARU-HF contest and my use of the packages: yfktest supports the IARU-HF contest out of the box, so it gets the multipliers right. When I did the IARU-HF contest with tlf, I asked about it on the list and someone shared a configuration right at the beginning of the contest so it worked. Mostly: It did not count the multipliers correctly, so I had no idea of the claimed score during the contest.

Both are open source and welcome any additions. Looking at the commit history tlf is somewhat more active recently.

If you want to really add a contest to either of them you'll probably have to start thinking about that months before the contest and take your time to debug your rules/scoring configuration if you want good scoring during the contest.

I will probably stick with tlf because of the cluster support.
Linux in the Ham Shack took my shallow dive a lot further and went into a deep dive with installing, configuring and running TLF. Awesome episode, I really enjoyed it!

Links to all the stuff: Show Notes #295: TLF Contest Logger Deep Dive - Linux in the Ham Shack
yfktest linux based ham radio contest logger, TLF, a linux based ham radio contest logger.

Tags: , , ,
2019-08-13 Decompiling zonefiles 1 year ago
The authoritive nameserver on the homeserver 2017 is using bind9 version 9.10.3 (from Devuan packages). I wanted to look up something in a secondary zonefile and noticed it was a binary file.

Using 'file' to determine what to do next wasn't much help:
$ file secondary.domain-zone
secondary.domain-zone: data
But a search found an explanation at Reading a binary zone file from Bind - The Linux Page. With named-compilezone a zonefile can be 'uncompiled' to a readable file.
$ /usr/sbin/named-compilezone -f raw -F text -o /tmp/secondary.domain-zone.txt secondary.domain secondary.domain-zone
zone secondary.domain/IN: loaded serial 2018122523
dump zone to /tmp/secondary.domain-zone.txt...done
OK
$ file /tmp/secondary.domain-zone.txt
/tmp/secondary.domain-zone.txt: ASCII text
Which is a readable zonefile.

Tags: ,
2019-07-05 I tested the randomness setup 1 year ago
Doing some more reading on haveged made me decide to test the actual randomness of my setup with haveged and randomsound which I created to fix the lack of entropy for dnssec signing operations so I booted the same testing virtual machine which can tap from the host /dev/random. I ran rngtest until it was time to shut down the laptop which was showing the output. The result:
$ rngtest < /dev/random 
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
^Crngtest: bits received from input: 4999640
rngtest: FIPS 140-2 successes: 249
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=303.011; avg=543.701; max=5684.774)bits/s
rngtest: FIPS tests speed: (min=43.251; avg=64.587; max=84.771)Mibits/s
rngtest: Program run time: 9194254192 microseconds
I ratelimited the virtio-rng-pci driver from the host, so the test took a really long time. Given earlier tries with dnssec-signzone this is fast enough.

No need to buy a hardware random generator, although they are way cool and it would be an idea to have a source of correctness (NTP) next to a source of randomness.

Update: I ran rngtest on /dev/urandom and I had to ask for a really big load of blocks to get failures. The first test with 249 blocks gave the same result as above, just a lot higher bit rate. So now I know less about the correct randomness of my setup but at least the test shows that I can safely run dnssec-signzone which was the original idea.

Tags: , , ,
2019-07-04 First tests with dnssec show a serious lack of entropy 1 year ago
I was looking at the options for implementing DNSSEC on the domains I have, and started doing this on a domain name that is just used for web redirects, so I won't break anything serious when I make an error. And I am looking at monitoring options at the same time.

Looking for usable documentation I found DNSSEC signatures in BIND named - sidn.nl which shows and explains a lot of the options for doing this with bind9, including full automation. I want to take steps I understand, so I will start with careful minimal automation on a domain name that I can 'break'.

Following that documentation I created a key-signing key (KSK) and a zone-signing key (ZSK). I used the /etc/bind/keys directory which is the standard location.

The first dnssec-signzone action took 54 minutes. After waiting for a bit I started wondering what was happening and it turned out to be a problem with entropy: the signing uses a lot of data from /dev/random. I have the virtio-rng module loaded but the host wasn't making randomness available to the guest operating system. The host server does run randomsound to get more entropy since there is no hardware random number generator available.

Documentation on how to 'forward' randomness from the host to the client virtual machine: Random number generator device - Domain XML format

So I did some tests with a test virtual machine with a similar configuration. The results:
  • Just software kernel rng in the virtual machine: 54 minutes.
  • Offering virtio-rng randomness from the host from /dev/urandom running randomsound: less than 1 second.
  • Offering virtio-rng randomness from the host from /dev/random running randomsound: 11 minutes 10 seconds.
  • Offering virtio-rng randomness from the host from /dev/random running randomsound and haveged: less than 1 second.
Installing haveged which gathers entropy from hardware processes fixes the whole problem.

Now to implement the same settings for the virtual machine running the production nameserver and I'll be able to take the next step.

Tags: , , ,
2019-07-03 Unix printing isn't what it used to be 1 year ago
My wife bought a new inkjet printer because the previous one was failing. The new one is a HP deskjet 2630, and it has wifi support. Out of the box it was playing access-point on the busy 2.4 GHz band making it even more crowded so I asked her to disable the wifi. She used the printer nicely with the USB cable and asked me to look into putting it on the network so it can be in a different room and not in the way.

Today I had a look into that. I hoped it could be a wifi client. Yes it can. The first two explanations on how to set that up started with 'using the windows HP software'. The third one had 'press and hold the wifi button to connect using wps'.

So I enabled wps on the wifi network, did the wps mating and saw arpwatch note the new IPv4 addres in use.

For a laugh I tried whether it has an IPP server running. It has. So adding it under linux should not be completely impossible. Search for 'linux hp deskjet 2630' and notice it needs the hplip package. Which is already installed in my recent Ubuntu.

So I just opened the cups printer browser, saw the HP deskjet show up, selected that and printed a test page. Which came out correctly.

Typing this took longer than the actual steps I took, and searching websites with explanations took most of the time.

I'm still in the "what just happened?" stage, remembering long fights with printer drivers, network printing and losing everything at upgrades.

Update: Adding the printer in Windows 10 was harder, we needed to use the HP software to add it which tried to sell us "HP instant ink" service before allowing the printer to be used in Windows.

Tags: , ,
2019-06-19 Looking at the wrong side of a mirrored disk 1 year ago
Due to recent kernel updates I rebooted the home server and ran into only older kernels available. Some searching later I found out it booted from another disk than the disk the update manager was maintaining /boot on.

The solution was to mirror the /boot partition by hand and change the EFI boot setup to try a boot from both disks, so the machine will still boot when one half of the mirror is completely unavailable. I did buy mirrored disks to have the machine available with one disk unavailable.

Changing the EFI boot setup with efibootmgr was somewhat complicated, but I got it all done. How to add a second disk found via Partitioning EFI machine with two SSD disks in mirror - Unix & Linux stackexchange and understanding the numbers in the efibootmgr -v output via "efibootmgr -v" output question.

The ideal solution would be to have /boot and /boot/efi on mirrored partitions without metadata (so they are readable too from the efi loader as an unmirrored partition). According to what I read this is possible in Linux with devicemapper but there is not a lot of experience shared.

Tags: , ,
⇐ Newer news items for tag linux  Older news items for tag linux ⇒
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews