2021-03-06 Digging for more entropy 3 months ago
Looking at the newest graphs I created with grafana of system statistics I noticed the available entropy was still getting dangerously low from time to time on the system that runs the home server. For some reason this system has no available hardware random number generator. Even after the earlier changes to add more sources of randomness it was sometimes dropping low, especially during dnssec signing operations. This does mean that the encryption processes for TLS in the webservers may also get delayed. Which is really not what I want. Time to update settings on randomsound and haveged: I want a minimum of 2048 bits of available entropy. Sofar, this seems to have the desired effect.
2021-03-01 Updating my statistics gathering 3 months ago
For years and years I have been using rrdtool to gather and graph statistics at home. I started gathering home temperatures around 2008 but I see NTP statistics gathering from 2003 and my last mrtg graphs were created in October 2002. So that suggests I've been using rrdtool since that date. Anyway, I'm looking at newer options. After some asking around I installed influxdb and started gathering data. I adjusted some of my data gathering scripts around rrdtool to also put the data in influxdb. The easiest data to gather and graph was the load average, available entropy and number of processes for a number of systems at home. So that dashboard has been built and allows selection of the wanted computer. My first conclusion is just collecting data and thinking what kind of graphs to create later is a lot easier with influxdb. With rrdtool the round robin database is designed around the graphs you want. In this case I just start gathering data and when data has come in start playing with possible graphs from that data. The next challenge is to set the rules for maintaining the old data. One of the triggers to look at other options was that I was at the end of a nearly 11-year cycle of stored temperatures in rrdtool, and I wanted to keep that history if possible. I don't have to keep every measurement forever, but with storage being cheap I think I will keep daily averages forever when this is 'production'.
2021-02-08 Checking certificates for expiry time left to determine renewal 4 months ago
I recently almost had an expired certificate for a public service because I did some fiddling with the file and ended up with a file modified time which had no relationship to the certificate request time. Time to use the -checkend option I noticed in openssl x509 to test the actual certificates for upcoming expiry. So I redid the cronjob around dehydrated to do just that and had a cleanup. A candidate list of certificates to renew is created from certificates that are about to expire, certificates that have a changed certificate signing request and certificates for which there is only a signing request. That list is sorted and deduplicated and fed to calls to dehydrated. It's now one script for both certificates that are renewed via the http-01 method and for certificates that are renewed via dns-01. By now both methods work fine for me, it depends on the use of the name which is fitting.Read the rest of Checking certificates for expiry time left to determine renewal
2021-01-20 Playing with DUDE-Star and actually hearing audio 4 months ago
I recently noticed the DUDE-Star software which allows access to D-Star, DMR, YSF, NXDN, P25, M17. For those who read here and got dazzled by these abbreviations: These are radio systems where voice data can be transported both via radio signals and via Internet data streams. In all of these systems there are ways to connect radio / network interfaces together to make contacts over longer distances possible. This software allows access to all these interfaces and will do the audio encoding/decoding so it will use a microphone and loudspeaker. I haven't had any luck in hearing D-Star audio yet which may be due to not being a registered D-Star user or due to not selecting busy reflectors (the computer systems that allow linked radios and networks to have the same audio data: an audio chatroom). I browsed around other systems and found busy talkgroups in YSF where I heard chatter in Dutch and English last night. It is nice to see software like this making it all accessible without investing in hardware. The codecs used have a serious influence on the audio quality, and I was warned the quality from DUDE-Star isn't as good as from the actual radios. From what I heard some of the digital audio modes the quality isn't very good (to leave lots of room for error correction).
2021-01-15 Fiber to the shed: testing the fiber optic transceivers 5 months ago
I wanted to get an idea whether the network over the fiber optic transceivers is reliable. So at the moment our dining room table looks like a network lab. For testing networks there is iperf. I found out the Raspberry Pi 3B+ can't keep up with 100 Mbit/second UDP packets, so I searched for a speed where the Pi performs ok. This turns out to be 30 mbit, at higher speeds there is packet loss. I also had to reduce packet size to avoid fragmentation which costs CPU. I use IPv6 because that's what I'm used to. It turned out later the maximum speed without loss is higher with IPv4 than with IPv6. Server on the raspberry pi:koos@raspberrypi:~ $ iperf --version iperf version 2.0.9 (1 June 2016) pthreads koos@raspberrypi:~ $ iperf -s -V -u ------------------------------------------------------------ Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 160 KByte (default) ------------------------------------------------------------Test without fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - raspberry pikoos@wozniak:~$ iperf --version iperf version 2.0.9 (1 June 2016) pthreads koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c .. ------------------------------------------------------------ Client connecting to .., UDP port 5001 Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ .. [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec [ 3] Sent 321430 datagrams [ 3] Server Report: [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec 0.004 ms 0/321430 (0%)Test with fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - fiber optic transceiver - fiber - fiber optic transceiver - utp - raspberry pikoos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c .. ------------------------------------------------------------ Client connecting to .., UDP port 5001 Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec [ 3] Sent 321430 datagrams [ 3] Server Report: [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec 0.007 ms 0/321430 (0%)Trying with IPv4 shows that packet loss starts to occur above 45 mbit. This is an interesting difference. But the important conclusion is that there is no packet loss over the fiber path. There may be a bit more latency, but that's not a surprise. As a last test I looked at purely ping traffic using IPv6. Without fiber in the path:koos@wozniak:~$ ping -c 100 -i 0.2 -q .. PING ..(.. (2001:xxxx)) 56 data bytes --- .. ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20192ms rtt min/avg/max/mdev = 0.567/0.680/0.866/0.063 msWith fiber in the path:koos@wozniak:~$ ping -c 100 -i 0.2 -q .. PING ..(.. (2001:xxxx)) 56 data bytes --- .. ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20191ms rtt min/avg/max/mdev = 0.625/0.738/0.828/0.046 msThis also shows a bit more latency over fiber. The extra latency is probably due to the fiber optic transceivers containing a network switch.
2020-12-23 A bluetooth speaker that is also a serial port 5 months ago
I acquired a Blaupunkt BLP6100 Bluetooth speaker. Which turns out to support the following services via bluetooth:
That last one I did not expect. I have tried opening the port with minicom and it will say carrier detect but sofar trying to wake it at 115200 or 9600 hasn't resulted in anything. As a linux audio device it works fine. Or as a bluetooth speaker for my phone so I can listen to podcasts while walking around at home. But the serial port makes me wonder!
- Headset (audio for phone calls)
- Handsfree operation (use buttons to accept, hangup or reject calls)
- Audio sink (the main function of a bluetooth speaker)
- Serial port
2020-12-13 Makefile logic not working perfectly 6 months ago
I noticed the certificate for idefix.net was expired according to my webbrowser. I dug up the reason and found out the scripts to maintain the ocsp files managed to confuse the Makefile to keep the haproxy certificates updated. The ocsp responses have more updates than the certificates, but a certificate update needs to be processed anyway. So I updated the Makefile in the previous post. The dependency is now certificate-stamp depends on installed certificates, installed certificates depend on copied certificates. And installing the certificate also updates the ocsp response.
2020-12-05 Playing with a fully programmable LED strip 6 months ago
At work there is a sort-of competition for the best christmas decorations in the office. At the end of last year I considered doing something with programmable LEDs to 'participate' in this competition in 2020. This year turned out somewhat different, but slowly my son is also somewhat interested in electronics, soldering and making the computer do something. So I set out to find fully programmable LED strips. I found a good comparison of LED strips in a Youtube video: LED Strips, what's the difference? WS2811, WS2812B, 2812Eco, WS2813, WS2815, SK6812, SK9822. which compares the several available types and their pros and cons. After viewing this video and for my limited experiment I thought the WS2812B based LED strip would be the best choice. The next hurdle was controlling it and I found Connect and Control WS2812 RGB LED Strips via Raspberry Pi which has pointers to the right code. I am not following the advice on that page about working with mains power cables. That looks dangerous. I ordered a WS2812B based LED strip and a matching power supply for 5V 40Watt from a Dutch webshop and got it in a few days later. I was amused by the warning the webshop gave that a LED strip like this is for advanced users only because you have to add a controlling device and do all the programming. That is exactly what I intended to do! Programming is in Python3, and I haven't written any Python code before. But with a lot of google searches and looking at samples I got the idea right. I now have the LED strip blinking in exactly the patterns I want, including a nice pattern for a christmas tree. And it blinks 'MERRY CHRISTMAS' in morse code, because why not!
2020-12-04 Using a snapshot for an upgrade so I can roll back 6 months ago
This evening I upgraded the production webserver from Devuan ascii to Devuan beowulf and to have the option available to roll back everything I created a snapshot and left that running until I was satisfied with the new configuration and everything worked. The steps were simple, found via Commit or revert a Linux LVM snapshot? - serverfault: Before starting the upgrade, create a snapshot:# lvcreate -L 10G -s -n turing_upgrade /dev/conway_ssd/turing_rootDo all the upgrade stuff, reboot, make sure everything works again. The usage of the snapshot went up to 22.38 percent:# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert turing_root conway_ssd owi-aos--- 30.00g turing_upgrade conway_ssd swi-a-s--- 10.00g turing_root 13.17After everything worked, remove the snapshot:# lvremove /dev/conway_ssd/turing_upgrade
2020-10-26 Speeding up TLS connections for Apache with OCSP 7 months agoItems with tag linux before 2020-10-26
I have one Apache server exposed to the outside world for IPv6 clients (because of a history in hostnames going back to the 20th century). So after enabling OCSP for haproxy I decided to have a look at OCSP stapling for Apache 2.4. That's even easier than haproxy since Apache 2.4 will fetch the ocsp data itself. I followed Apache 2.4 SSL/TLS Strong Encryption: How-To OCSP Stapling and it works. So now the current score at the Qualys SSL server test for koos.idefix.net is A+ both via IPv4 and IPv6.