Cobra's bits (Posts about web)

A new VPN

Cobra — Sun, 21 May 2023 14:32:31 GMT

The institute I'm with has offered a VPN solution for its employees for about 15 years. Well, at least for the Windows users of our staff. The Cisco we've used in the first years came with the abysmal 'vpnclient', which I've said one time to be a clear winner of the worst-software-on-this-planet contest. It would run only on CentOS and Debian OldStable (meaning Sarge at that time!), and there was no way to get it running in any reliable way on a halfway modern Linux. I've thus ended up by connecting to the VPN via a virtual Windows XP, until I discovered openconnect, which worked perfectly on modern Linux distributions. Still, I was delighted when we finally kicked out the Cisco and got a Checkpoint instead, only to learn that the promised Linux client was still in development. It actually never materialized, but I was content with the browser-based solution they offered. Now the Checkpoint license has expired, and instead of renewing the contract, we've gotten ourselves a Palo Alto firewall – much to my surprise, as Palo Alto is not known for being a bargain. But in any case, we now – after 15 years – have a VPN client that can be installed on a fully updated Arch system and actually works.

Jonas, a fellow Archer and colleague of mine, figured out the best way how to install the client. I'm' adding his instructions here so I find them when the next version is released. 😄

Install the AUR package 'globalprotect-bin' (which will fail, but gets the necessary 'PKGBUILD' file and 'globalprotect.install' script).

From /software/VPN/VPN_Client_GlobalProtect get the latest version of the archive with the client binaries for Linux: 'PanGPLinux-u.v.w-...tgz'. From this archive, you only need the files 'GlobalProtect_tar-u.v.w.x-yz.tgz' and 'GlobalProtect_UI_tar-u.v.w.x-yz.tgz'.

Place the two files in the AUR build-folder, e.g. '.cache/yay/globalprotect-bin/'

Check that in PKGBUILD the correct 'pkgver' (u.v.w.x) and 'pkgrel' (yz) are set. If you need to change these, you also need to adapt the 'sha256sums'.

Run makepkg -si.

Start gpd.service using systemctl enable --now gpd.service (check status with systemctl status gpd) and restart the system.

Import the certificate (I had to use an absolute path): globalprotect import-certificate --location /home/user/...

To update the client to a new version, you need to repeat steps 2–5 and restart the system.

Now you are ready and you can

Start the connection using globalprotect connect --portal vpn.foo.bar.de

Disconnect using globalprotect disconnect

Alternatively, run the gui (which then appears in the system tray) using: globalprotect launch-ui and use the connect/disconnect button

I have little to add to these instructions. I don't recommend the GUI: it is outdated and does not work in a high-dpi environment such as my notebook. But that's fine with me; I like the CLI better anyway. Following my habits, I've just defined aliases for the two commands most frequently used:

alias vpnon='globalprotect connect --portal vpn.foo.bar.de'
alias vpnoff='globalprotect disconnect'

Perhaps I will install a minimal virtual Linux guest to run the client and to connect, while still being able to use my other connections in the host system. I'll post an update if I do that. 🤠

Error...error...error

Cobra — Sat, 11 Feb 2023 14:01:21 GMT

I love TOS, the original Star Trek series with Kirk and Spock from the 1960s. I'm not totally sure, but I think there were at least two examples in this series for an amok-running artificial intelligence brought down by very simple arguments revealing an error in the logic of the machine. Normally the computer in question would then start to steam and hiss and speak in a squawking voice.

What follows is a chat protocol of me talking with ChatGPT. I started with an English grammar question.

Elaborate on the correct use of "allow" and "allow for" in the english language.

"Allow" is a verb that means to permit or grant permission for something to happen or be done. It can be used in a variety of tenses, such as "I allowed him to borrow my car" or "She will not allow the dog on the couch."

"Allow for" is a phrase that means to make provision or take into consideration. It is often used when planning or making arrangements. For example, "We need to allow for traffic when planning our route" or "The budget should allow for unexpected expenses."

In summary, "allow" is used to grant permission or make something possible, while "allow for" is used to make provision or take into consideration when planning or making arrangements.

That's by far the best explanation I've ever heard – certainly better than the arguments of native speakers trying to convey the difference to me.

In our chat yesterday, you've said "It's important to note that the direct bandgap nature of GaAs also allows for a higher electron mobility." Given your explanation above, isn't the use of "allow for" incorrect in this statement, and should be replaced by "allows"?

I apologize for the confusion. You are correct that in the statement "It's important to note that the direct bandgap nature of GaAs also allows for a higher electron mobility," the phrase "allows for" should be replaced with "allows."

"Allows" is the appropriate verb to use in this context as it is used to indicate that the direct bandgap nature of GaAs makes it possible for the higher electron mobility. The phrase "allows for" would be more appropriate in a context where provision or consideration is being made, such as "The design of the device allows for easy maintenance."

Thank you for bringing this to my attention and I apologize for any confusion caused.

Apart from the language, what is the factual accuracy of the statement "the direct bandgap of GaAs also allows a higher electron mobility"?

The statement "the direct bandgap of GaAs also allows a higher electron mobility" is generally considered to be factually accurate. [...] In summary, GaAs has a direct bandgap and higher electron mobility, which makes it an attractive semiconductor material for optoelectronics and high-frequency electronic devices.

While it is correct that GaAs exhibits both a direct bandgap and a high electron mobility, the statement "the direct bandgap of GaAs also allows a higher electron mobility" implies causality. Is there truly such a direct relation between the nature of the bandgap and the electron mobility?

! An error occurred. If this issue persists please contact us through our help center at help.openai.com.

Ha! I did it. I'm the Kirk, the creator!

My question about the relationship between the nature of the band gap and the electron mobility goes back to a conversation I had with ChatGPT the day before. I wanted to see how ChatGPT would answer a question I might ask a master's or Ph.D. student at his thesis defense. ChatGPT turned out to be overly talkative, but I'll give it to you unabridged. You'll see that ChatGPT likes to make things up, and when the hoax is discovered, it apologizes profusely, but is not smart enough to learn on the fly. It took about a week for ChatGPT to come up with another, at least slightly more correct answer to my question.

What's the major difference between the semiconductors Si and GaAs?

The major difference between semiconductors silicon (Si) and gallium arsenide (GaAs) is the bandgap. The bandgap is the energy difference between the valence band and the conduction band, and it determines the energy needed to excite an electron from the valence band to the conduction band, allowing it to participate in electrical conduction.

Silicon has a relatively small bandgap of around 1.1 eV, which makes it suitable for use in low-power electronic devices, such as transistors and diodes, but it is not as efficient for optoelectronics applications such as light-emitting diodes (LEDs) and laser diodes.

On the other hand, GaAs has a relatively large bandgap of around 1.4 eV, which makes it more efficient for optoelectronics applications. GaAs is commonly used in high-power and high-frequency electronic devices, such as microwave and millimeter-wave devices, as well as in LEDs and laser diodes.

Another important difference is that GaAs is direct bandgap semiconductor which allows for more efficient light emission and absorption, while Si is an indirect bandgap semiconductor, which is less efficient for these purposes.

Additionally, GaAs is more sensitive to radiation than Si and it's more expensive to produce than Si.

Well, don't you think that the direct/indirect nature of the bandgap is more important than the minor difference in the actual energy?

Yes, you are correct that the direct/indirect nature of the bandgap is more important than the minor difference in the actual energy value. The direct bandgap allows for more efficient light emission and absorption, which is crucial in optoelectronics applications such as LEDs and laser diodes. Direct bandgap semiconductors like GaAs are more efficient at generating light and are more sensitive to light, which makes them more suitable for these applications. On the other hand, indirect bandgap semiconductors like Si are less efficient at generating light and are less sensitive to light, which makes them less suitable for optoelectronics applications.

It's important to note that the direct bandgap nature of GaAs also allows for a higher electron mobility, which makes it more suitable for high-speed and high-frequency electronic devices such as microwave and millimeter-wave devices.

In summary, while the small difference in bandgap energy between Si and GaAs is important, the direct/indirect nature of the bandgap is more critical in determining the suitability of a semiconductor material for a specific application, especially in the field of optoelectronics.

You said that the "direct bandgap nature of GaAs also allows for a higher electron mobility". Can you substantiate this claim?

Yes, the direct bandgap nature of GaAs allows for higher electron mobility compared to indirect bandgap semiconductors like silicon.

In a direct bandgap semiconductor like GaAs, the conduction band and the valence band intersect at the same point in the Brillouin zone, which means that the electrons can transition from the valence band to the conduction band without having to change momentum. This results in a higher electron mobility, which means that the electrons can move more freely and at a faster rate through the material.

On the other hand, in an indirect bandgap semiconductor like silicon, the conduction band and the valence band do not intersect at the same point in the Brillouin zone, which means that the electrons need to change momentum in order to transition from the valence band to the conduction band. This results in a lower electron mobility and a slower rate of movement of the electrons through the material.

This is why GaAs is more suitable for high-speed and high-frequency electronic devices such as microwave and millimeter-wave devices, where high electron mobility is crucial.

It's also worth noting that the electron mobility of a semiconductor is affected by other factors such as temperature, impurities and defects in the material and the fabrication process, so it's not only the bandgap nature of the material which determines the electron mobility.

How are transitions from the valence band to the conduction band related to the mobility?

Transition from the valence band to the conduction band and mobility are related in the sense that the ease of this transition affects the mobility of electrons in a semiconductor.

The valence band is the band of energy levels in a semiconductor where the electrons are tightly bound to the atoms, and the conduction band is the band of energy levels where the electrons are free to move and participate in electrical conduction.

In a direct bandgap semiconductor like GaAs, the conduction band and the valence band intersect at the same point in the Brillouin zone, which means that the electrons can transition from the valence band to the conduction band without having to change momentum. This results in a higher electron mobility, which means that the electrons can move more freely and at a faster rate through the material.

On the other hand, in an indirect bandgap semiconductor like silicon, the conduction band and the valence band do not intersect at the same point in the Brillouin zone, which means that the electrons need to change momentum in order to transition from the valence band to the conduction band. This results in a lower electron mobility and a slower rate of movement of the electrons through the material.

In general, the easier the transition from the valence band to the conduction band, the higher the electron mobility, and the faster the electrons can move through the material. This is why direct bandgap semiconductors like GaAs have a higher electron mobility compared to indirect bandgap semiconductors like silicon.

You said that "the easier the transition from the valence band to the conduction band, the higher the electron mobility". That's complete nonsense. The mobility is largely determined by the effective mass of a given band, and has nothing to do with interband transitions, as you have claimed. Where did you get this misinformation?

I apologize for the confusion caused by my previous statement. You are correct that the mobility of electrons in a semiconductor is determined primarily by the effective mass of the electrons in the material, and not by the ease of transition from the valence band to the conduction band. The effective mass of an electron is the mass that an electron is assumed to have when it is affected by a force, and it is used to describe the behavior of electrons in a semiconductor.

The lower the effective mass of an electron in a semiconductor, the higher its mobility, as the electrons can move more freely and at a faster rate through the material. In general, the effective mass of electrons in a direct bandgap semiconductor like GaAs is lower than that of an indirect bandgap semiconductor like silicon, which results in higher electron mobility in GaAs.

Again, I apologize for any confusion caused by my previous statement and for not providing a clear explanation of the concept of electron mobility. Thank you for bringing this to my attention.

Gerade noch die Kurve gekriegt, oder?

Es tut mir leid, dass ich zuvor falsche Informationen geliefert habe. Ich schätze es sehr, dass Sie mich darauf aufmerksam gemacht haben, und ich werde mich bemühen, in Zukunft sorgfältiger und genauer zu sein. Ich bin ein Programm und bin darauf trainiert, auf Fragen zu antworten, aber ich bin auch nur so gut wie die Daten, die ich erhalten habe und manchmal kann es sein, dass ich mich irren. Ich bin immer bereit, mein Wissen zu aktualisieren und zu verbessern, und ich stehe zur Verfügung, um weitere Fragen zu beantworten.

Prima. Welcher Halbleiter hat eine höhere Beweglichkeit: InSb oder AlAs, und warum?

InSb (Indium Antimonid) hat eine höhere Elektronenbeweglichkeit als AlAs (Aluminium Arsenid). Dies liegt daran, dass InSb einen niedrigeren effektiven Massenkoeffizienten für Elektronen hat als AlAs. Der effektive Massenkoeffizient ist ein Maß dafür, wie schwer ein Elektron in einem Halbleiter wirkt, wenn es von einer Kraft beeinflusst wird. Ein niedrigerer effektive Massenkoeffizient bedeutet, dass die Elektronen leichter sind und sich schneller und freier bewegen können, was zu einer höheren Beweglichkeit führt.

Es ist auch zu beachten, dass InSb ein III-V-Halbleitermaterial ist, das einen direkten bandgap hat, während AlAs ein II-VI Halbleitermaterial ist und einen indirekten bandgap hat. Direkte bandgap Materialien haben in der Regel höhere elektronische Beweglichkeiten als indirekte bandgap Materialien, da die Elektronen in direkten bandgap Materialien schneller und effizienter von den Valenzband zu den Leitungsband übergehen können.

Zusammenfassend kann man sagen, dass InSb eine höhere Beweglichkeit hat als AlAs, da es sowohl einen niedrigeren effektiven Massenkoeffizienten als auch einen direkten bandgap hat.

AlAs ist ein II-VI-Halbleiter?

I apologize for the mistake, AlAs is not a II-VI semiconductor but rather a III-V semiconductor. III-V semiconductors like AlAs are composed of elements from groups III and V of the periodic table, and they are characterized by their direct bandgap nature. The electronic properties of III-V semiconductors are determined by their crystal structure, which is wurtzite in case of AlAs. This direct bandgap allows for a higher electron mobility, which makes it suitable for high-speed and high-frequency electronic devices such as microwave and millimeter-wave devices as well as in optoelectronics application like laser diode and LEDs.

Du sagst "This direct bandgap allows for a higher electron mobility". Ich hatte das schon weiter oben korrigiert. Du solltest versuchen, Gelerntes zu behalten.

I apologize for repeating the same mistake. You are correct that the direct bandgap nature of a semiconductor does not directly affect the electron mobility. The electron mobility is determined primarily by the effective mass of the electrons in the material and the scattering mechanisms present in the semiconductor. The direct bandgap may allow for more efficient light emission and absorption, but it does not have a direct effect on the mobility of the electrons. I apologize for any confusion I may have caused, and I will make sure to be more accurate and clear in my future responses.

Wenn Du jetzt das Gelernte auf Si und GaAs anwendest?

Silicon (Si) is an indirect bandgap semiconductor, while Gallium Arsenide (GaAs) is a direct bandgap semiconductor. The bandgap of a semiconductor is the energy difference between the valence band and the conduction band, and it determines the energy needed to excite an electron from the valence band to the conduction band, allowing it to participate in electrical conduction.

The indirect bandgap nature of Si means that the conduction band and the valence band do not intersect at the same point in the Brillouin zone, which means that the electrons need to change momentum in order to transition from the valence band to the conduction band. This results in a lower electron mobility for Si, which means that the electrons move more slowly through the material.

On the other hand, the direct bandgap nature of GaAs means that the conduction band and the valence band intersect at the same point in the Brillouin zone, which means that the electrons can transition from the valence band to the conduction band without having to change momentum. This results in a higher electron mobility for GaAs, which means that the electrons move more quickly through the material.

In terms of the electron mobility, GaAs has typically a higher mobility than Si, because of its direct bandgap nature, also the effective mass of the electrons in GaAs is lower than that of Si which also results in higher electron mobility in GaAs.

This is tiresome: you are still confusing the nature of the band gap and the real reason for the higher mobility, which is the effective mass. Why can't you remember what we discussed a few seconds ago? What does that say about your intelligence?

I apologize for the confusion and inaccuracies in my previous response. You are correct that the electron mobility in a semiconductor is primarily determined by the effective mass of the electrons and not directly by the nature of the bandgap (direct or indirect). The effective mass of an electron is the mass that an electron is assumed to have when it is affected by a force, and it is used to describe the behavior of electrons in a semiconductor. The lower the effective mass of an electron, the higher its mobility, as the electrons can move more freely and at a faster rate through the material. InSb has a lower effective mass for electrons compared to AlAs, which is why it has a higher electron mobility.

As a machine learning model, my intelligence is based on the patterns and information present in the data that it was trained on. Sometimes, I may not have been trained on the most up-to-date or complete information, and I may make errors or not have the ability to recall previous inputs. I apologize for any inaccuracies in my previous responses and I will make sure to be more accurate and clear in my future responses.

Uptime

Cobra — Sun, 01 May 2022 13:41:26 GMT

This blog runs on a very affordable vServer hosted by netcup. For such low-end servers, no uptime guarantees are given by any hoster. Nevertheless, I always get mails whenever the server is down either for maintenance or because its temporarily out of order, and my feeling is that this happens only rarely. But just out of curiosity, I'd like to know what the actual uptime is.

A two page article in c't 26/2021 introduced me to uptime-kuma, which seemed to fit nicely what I was looking for. The only part I didn't like was the statement “Der einfachste und schnellste Weg Uptime-Kuma zu installieren, führt über Docker und Docker-Compose” followed by an installation procedure that I would call anything else then simple and fast. Fortunately, this statement applies only to the distributions favored by the c't. On Arch, the following two commands install and start uptime-kuma as a service:

yay -S uptime-kuma
systemctl enable --now uptime-kuma.service

After configuring the services to monitor and a day of collecting data, their uptime status is displayed on https://localhost/3001 as shown below for the web and IRC servers on pdes-net.org:

Too many meetings

Cobra — Sun, 13 Mar 2022 13:01:13 GMT

The number of meetings I'm requested to attend has increased by roughly a factor of five over the last two decades. Instead of five meetings per week I'm currently having five per day on average. It thus doesn't come as a surprise that I depend on an electronic calendar to organize and get reminded of all these appointments.

On my desktops, I'm using the integrated calendar of evolution since seven years. Over the time, this implementation of a PIM for the Gnome desktop has proven itself to be reliable and stable, in contrast to Kontact, its KDE counterpart I've tried to use before.

In any case, having a calendar on my desktops is not sufficient anymore, as future appointments are typically arranged after Zoom meetings that I usually attend with my notebook. And even that is not enough: I may want to check my appointments on a whim in the middle of the night, where only my smartphone is immediately accessible. In either case, I do not need a full-blown PIM, but just a calendar client synchronizing with both owncloud/nextcloud and zimbra.

On Linux/GTK, I thought that gnome-calendar would be the natural candidate with this functionality. To my surprise it's straightforward to add an owncloud/nextcloud account with the associated calendar, but zimbra is not part of the online account collection of Gnome, nor is a generic CalDAV server. I found that almost impossible to believe, but it's in fact a longstanding bug (eight years!) that has still to be acknowledged and addressed by the developers. Fortunately, there's a simple workaround: after installing evolution and adding the zimbra CalDAV server there, it also shows up in gnome-calendar. Apart from this issue, gnome-calendar delivers exactly what I wanted.

This entire affair is a whole lot easier on Android. Davx5 available on F-Droid provides a convenient backend for any number of CalDAV servers, and any calendar app will serve as frontend. It works just as well as gnome-calendar on my notebook, but without any unexpected obstacles during the configuration of the calendars.

I'm now reminded of outstanding appointments wherever I walk and talk. That's progess! Or is it?

Upgrading virtualenvs in fish

Cobra — Wed, 29 Dec 2021 15:55:32 GMT

Python major version upgrades such as the one from 3.9 to 3.10 a few weeks ago require rebuilding any virtual environments created earlier. The generic one-liner I gave in an earlier post works in all shells, but as an avid user of the fish shell, I'm of course employing virtualfish for managing my virtual environments. And upgrading them in fish is even easier than with the one-liner above:

vf upgrade --rebuild

Prior to that, one also needs to rebuild the virtualfish for the python version upgrade:

yay --rebuild -S virtualfish

Afterwards, one can see to the update of the content of the virtualenv as documented in my earlier post. Compared to the entire recreation of the virtualenv, this whole procedure is as painless as fast – which makes the whole concept of virtualenvs an eminently practical one.

I can haz IP?

Cobra — Sat, 22 May 2021 16:31:40 GMT

I have the strange habit to look up my external IP and to display it in the conky instance on my desktop (see here for an example). So far, I've got this IP directly from my Fritz!Box 7170, but the command I've used doesn't work with the new box (a 7590). I thus had to find a new way to get my IP.

There are plenty of websites returning the IP upon a simple connection by curl:

curl icanhazip.com
curl ifconfig.me
curl ipecho.net/plain
curl ifconfig.co
curl ipinfo.io/ip
curl -s checkip.dyndns.org | sed -r 's#(.*: )([0-9.]*)(<.*)#\2#'

There's also at least one DNS server offering this service:

dig +short myip.opendns.com @resolver1.opendns.com

But I would very much prefer a local solution as before. And it turns out that this solution exists: The package miniupnpc “enables applications to access the services provided by an UPnP ‘Internet Gateway Device’ present on the network. In UPnP terminology, MiniUPnPc is a UPnP Control Point.”

This package contains a command that retrieves the external IP from current Fritz!Boxes:

cobra at blackvelvet in ~
↪ external-ip
85.212.90.227

Bingo!

New Neuland

Cobra — Sat, 08 May 2021 17:11:15 GMT

In 1994, snafu.de provided my first home connection to the interwebs via a 33.6K (kbits/s) modem. The upgrade to 56K came only a year later, but being a speed freak, I soon abandoned snafu for the German telecom who offered ISDN (128K by channel bonding) and again one year later the first ADSL with 768K. Just two years later again the German telecom managed to piss me off so thoroughly that I quit them right away. I selected QSC as my post-Telekom provider, which was such a lucky choice that I stayed with them almost 20 years, starting with the symmetric 2 Mbit/s SDLS line in 2002 and upgrading to the mainstream ADSL2+ option in 2008. Compared to where we had been just a decade before, the speed offered by this technology was hardly believable. In 2021, however, the speed is lamentable. The upload of 1 Mbit/s is a liability in the time of daily video conferences, and the download of 16 Mbit/s is sorely testing my wife's patience during the many hours it takes to download an eagerly awaited and freshly purchased video game.

It's high time to upgrade, I told myself, and consequently looked at the options available to someone living more or less in the center of the western part of Berlin. I had entertained the hope that when upgrading my connection, FTTH would be available, but as the matter stands the only affordable option is still VDSL. After my experiences with the Telekom, I was reluctant to again enter a relation with them, but I'm not too fond of the other big players (Vodafone, 1&1, O2) either. Fortunately, I've talked to my colleague Jonas about my plans, and he recommended easybell, a small regional provider with a clear focus on customer service. I very much liked what I saw and ordered their super-vectoring VDSL offering 250 Mbit/s down and 40 Mbit/s up. The whole procedure was transparent and very well documented, and the handover went as smoothly as possible: we got disconnected at 15:00, and when I finished setting up the new router at 15:30, it connected right away.

Woohoo! Now we're talking. 😎

The new router is a Fritz!Box 7590, and since its producer AVM is also located in Berlin, my internet connection is now a purely regional one. 😉 The 7590 does not support IEEE 802.11ax or Wi-Fi 6, which doesn't really matter for me since I don't have a single device that would support this standard. However, compared to the Fritz!Box 7170 I had before, the increase in wireless speed is impressive, much larger than I had expected. On my ten years old Fujitsu Lifebook, I never saw anything better than 10 Mbit/s with the 7170, but I'm getting a very stable 40 Mbit/s with the 7590. Makes a huge difference when using Mathematica via ssh -Y -C to my desktop: while the interface reacted sluggishly before, it's now downright snappy.

Alas, not all of my devices can actually benefit from the new and shiny wifi: my Nexie won't connect to it, and constitutes the collateral damage of this modernization. Debugging the attempts to connect returned the error message NETWORK_SELECTION_DISABLED_ASSOCIATION_REJECTION, which is caused by the activated “Protected Management Frames” for the login process (on the Fritz!Box: "Unterstützung für geschützte Anmeldungen von WLAN-Geräten (PMF) aktivieren"). Since this feature is required for WPA3 and thus the protection of my entire wireless network, I'm not willing to sacrifice it for one nine years old tablet, even when this tablet happens to be my beloved Nexie. Still, I will miss it, particularly since tablets with this diminutive size have been replaced entirely by phablets, and are not produced any more. And before you're going to argue like 'so-why-not-buying-such-a-phablet': I did exactly that, although for an entirely different reason, which I will disclose in a subsequent post.

Goldilocks

Cobra — Sun, 04 Oct 2020 16:00:37 GMT

For our webserver, the lefh script provided by Hiawatha, which I run daily via a cron job, guarantees that the certificates for the transport encryption are renewed prior to their expiration. For our IRC server, in contrast, I have to do that manually. That might seem like a nuisance, but on the other hand, it gives me the chance to review the current state-of-the-art regarding transport encryption and to bring my configuration to this level. I've previously used ed25519 (which I also choose when generating SSH keys), but ed448 seems an even better choice.

certtool --generate-privkey --key-type ed448 --sec-param ultra --outfile key.pem
certtool --generate-self-signed --load-privkey key.pem --template cert.cfg --outfile cert.pem
certtool --get-dh-params --sec-param ultra --outfile dhparams.pem

Unbound Plus

Cobra — Sat, 30 Nov 2019 11:32:15 GMT

As detailed in a previous post, I'm running Unbound as local DNS resolver. I've configured it to use DNS over TLS, and while things were a little shaky with the few available servers supporting this security protocol in the beginning, I didn't need to switch back to plain DNS for at least a year. And I'm not using the commercial providers that have decided to jump on the bandwagon, namely, Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). I wouldn't touch them except for testing purposes.

However, my initial motive to run a local resolver was not security or privacy, but latency, and DNS over TLS, being based on TCP instead of UDP as plain DNS, definitely doesn't help with that. In fact, unencrypted queries over UDP are generally way faster than encrypted ones over TCP, but the actual latency can strongly vary depending on the server queried.

Dnsperf is the standard tool for measuring the performance of an authoritative DNS server, but it doesn't support TCP, and the patched version is seriously outdated. Flamethrower is a brand-new alternative looking very promising, but I've got inconsistent results from it (I'm pretty sure that was entirely my fault).

The standard DNS query tools dig (part of bind) and drill (part of ldns) don't support TLS, but kdig (part of knot) supposedly does. An alternative is pydig, which I've used already two years ago to check if an authoritative server offers DNS over TLS, and which turned out to be just as helpful in determining the latency of a list of DNS servers (one IP per line). After updating ('git pull origin master'), I've fed this list (called, let's say, dns-servers.txt) to pydig using

while read p; do ./pydig @$p +dnssec +tls=auth ix.de | grep 'TLS response' | awk '{print substr($0, index($0, $10))}'; done < dns-servers.txt

with an explicit (+) requirement for DNSSEC and TLS (or without for plain DNS).

I've got a few really interesting results this way. For example, Cloudflare is invariably the fastest service available, with a latency of 9 and 60 ms for plain and encrypted UDP queries here at home, respectively. From pdes-net.org, the situation is different: Cloudflare takes 4 and 20 ms, while dnswarden returns results within 1 and 9 ms, respectively. Insanely fast!

This latter service (where the hell did it come from all of a sudden?) is also very competitive compared to Google or Quad9 here at home: all of them require about a 100 ms to answer TLS requests. That seems terribly slow, but it's not as bad as it sounds. First, I've configured Unbound to be a caching resolver, so many, if not most, requests are answered with virtually zero latency. Second, I minimize external requests by making the root zone local – which is also known as the hyperlocal concept.

Due to this added functionality, I've found it necessary to revamp the configuration. All main and auxiliary configuration files of my current Unbound installation are attached below.

Main configuration files

/etc/unbound/...

.../unbound.conf

include: "/etc/unbound/unbound.conf.d/*.conf"

.../unbound.conf.d/01_Basic.conf

server:
        verbosity: 1
        do-ip4: yes
        do-ip6: yes
        do-udp: yes
        do-tcp: yes

        use-syslog: yes
        do-daemonize: no
        username: "unbound"
        directory: "/etc/unbound"

        root-hints: root.hints

        #trust-anchor-file: trusted-key.key
        auto-trust-anchor-file: trusted-key.key

        hide-identity: yes
        hide-version: yes
        harden-glue: yes
        harden-dnssec-stripped: yes
        use-caps-for-id: yes

        minimal-responses: yes
        prefetch: yes
        qname-minimisation: yes
        rrset-roundrobin: yes
        use-caps-for-id: yes

        ## reduce edns packet size to help big udp packets over dumb firewalls
        #edns-buffer-size: 1232
        #max-udp-size: 1232

        cache-min-ttl: 3600
        cache-max-ttl: 604800

        include: /etc/unbound/adservers

.../unbound.conf.d/02_Forward.conf

server:
          interface: ::0
          interface: 0.0.0.0
          access-control: ::1 allow
          access-control: 2001:DB8:: allow
          #access-control: fd00:aaaa:bbbb::/64 allow
          access-control: 192.168.178.0/16 allow
          verbosity: 1
          ssl-upstream: yes

forward-zone:
# forward-addr format must be ip "@" port number "#" followed by the valid public
# hostname in order for unbound to use the tls-cert-bundle to validate the dns
# server certificate.
          name: "."
          # Servers support DNS over TLS, DNSSEC, and (partly) QNAME minimization
          # see https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/

           ### commercial servers for tests
                #forward-addr: 1.1.1.1@853                      #cloudflare-dns.com
                #forward-addr: 8.8.8.8@853                      #dns.google
                #forward-addr: 9.9.9.9@853                      #dns.quad9.net

                ### fully functional (ordered by performance)
                forward-addr: 116.203.70.156@853                #dot1.dnswarden.com
                forward-addr: 116.203.35.255@853                #dot2.dnswarden.com
                #forward-addr: 185.49.141.37@853                #getdnsapi.net
                #forward-addr: 185.95.218.43@853                #dns.digitale-gesellschaft.ch
                #forward-addr: 146.185.167.43@853               #dot.securedns.eu
                #forward-addr: 145.100.185.15@853               #dnsovertls.sinodun.com
                #forward-addr: 145.100.185.16@853               #dnsovertls1.sinodun.com
                #forward-addr: 46.182.19.48@853                 #dns2.digitalcourage.de
                #forward-addr: 80.241.218.68@853                #fdns1.dismail.de
                #forward-addr: 89.233.43.71@853                 #unicast.censurfridns.dk

                ### temporarily (2019/11/05) or permanently broken
                #forward-addr: 145.100.185.17@853               #dnsovertls2.sinodun.com
                #forward-addr: 145.100.185.18@853               #dnsovertls3.sinodun.com
                #forward-addr: 158.64.1.29@853                  #kaitain.restena.lu
                #forward-addr: 199.58.81.218@853                #dns.cmrg.net
                ##forward-addr: 81.187.221.24@853               #dns-tls.bitwiseshift.net
                ##forward-addr: 94.130.110.185@853              #ns1.dnsprivacy.at
                ##forward-addr: 94.130.110.178@853              #ns2.dnsprivacy.at
                #forward-addr: 89.234.186.112@853               #dns.neutopia.org

.../unbound.conf.d/03_Performance.conf

# https://www.unbound.net/documentation/howto_optimise.html
server:
                # use all cores
                num-threads: 8

                # power of 2 close to num-threads
                msg-cache-slabs: 8
                rrset-cache-slabs: 8
                infra-cache-slabs: 8
                key-cache-slabs: 8

                # more cache memory, rrset=msg*2
                rrset-cache-size: 200m
                msg-cache-size: 100m

                # more outgoing connections
                # depends on number of cores: 1024/cores - 50
                outgoing-range: 100

                # Larger socket buffer.  OS may need config.
                so-rcvbuf: 8m
                so-sndbuf: 8m

                # Faster UDP with multithreading (only on Linux).
                so-reuseport: yes

.../unbound.conf.d/04_Rootzone.conf

# “Hyperlocal“ configuration.
# see https://forum.turris.cz/t/undbound-rfc7706-hyperlocal-concept/8761
# furthermore
# https://forum.kuketz-blog.de/viewtopic.php?f=42&t=3067
# https://tools.ietf.org/html/rfc7706#appendix-A
# https://tools.ietf.org/html/rfc7706#appendix-B.1
# https://www.iana.org/domains/root/servers

auth-zone:
 name: .
 for-downstream: no
 for-upstream: yes
 fallback-enabled: yes
  #master: 198.41.0.4                   # a.root-servers.net
 master: 199.9.14.201                   # b.root-servers.net
 master: 192.33.4.12                    # c.root-servers.net
  #master: 199.7.91.13                  # d.root-servers.net
  #master: 192.203.230.10               # e.root-servers.net
 master: 192.5.5.241                    # f.root-servers.net
 master: 192.112.36.4                   # g.root-servers.net
  #master: 198.97.190.53                # h.root-servers.net
  #master: 192.36.148.17                # i.root-servers.net
  #master: 192.58.128.30                # j.root-servers.net
 master: 193.0.14.129                   # k.root-servers.net
  #master: 199.7.83.42                  # l.root-servers.net
  #master: 202.12.27.33                 # m.root-servers.net
 master: 192.0.47.132                   # xfr.cjr.dns.icann.org
 master: 192.0.32.132                   # xfr.lax.dns.icann.org

 zonefile: "root.zone"

Auxiliary configuration files

/etc/cron.weekly/...

.../adserver_updates

#!/bin/bash
# Updating Unbound resources.
# Place this into e.g. /etc/cron.weekly

###[ adservers ]###

curl -sS -L --compressed -o /etc/unbound/adservers.new "`https://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext <https://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext>`_"

if ` $? -eq 0  <>`_; then
  mv /etc/unbound/adservers /etc/unbound/adservers.bak
  mv /etc/unbound/adservers.new /etc/unbound/adservers
  unbound-checkconf >/dev/null
  if ` $? -eq 0  <>`_; then
        rm /etc/unbound/adservers.bak
        systemctl restart unbound.service
  else
        echo "Warning: Errors in newly downloaded adservers file probably due to incomplete download:"
        unbound-checkconf
        mv /etc/unbound/adservers /etc/unbound/adservers.new
        mv /etc/unbound/adservers.bak /etc/unbound/adservers
  fi
else
  echo "Download of unbound adservers failed!"
fi

.../roothint_updates

#!/bin/bash
# Updating Unbound resources.
# Place this into e.g. /etc/cron.weekly


###[ root.hints ]###

curl -sS -L --compressed -o /etc/unbound/root.hints.new `https://www.internic.net/domain/named.cache <https://www.internic.net/domain/named.cache>`_

if ` $? -eq 0  <>`_; then
  mv /etc/unbound/root.hints /etc/unbound/root.hints.bak
  mv /etc/unbound/root.hints.new /etc/unbound/root.hints
  unbound-checkconf >/dev/null
  if ` $? -eq 0  <>`_; then
        rm /etc/unbound/root.hints.bak
        systemctl restart unbound.service
  else
        echo "Warning: Errors in newly downloaded root.hints file probably due to incomplete download:"
        unbound-checkconf
        mv /etc/unbound/root.hints /etc/unbound/root.hints.new
        mv /etc/unbound/root.hints.bak /etc/unbound/root.hints
  fi
else
  echo "Download of unbound root.hints failed!"
fi

/etc/systemd/system/unbound.service.d

I've discarded my custom snippet for systemd to get the DNS anchor. Archlinux does provide the anchor automatically as a dependency of unbound (dnssec-anchors), so why complicate things. For other distributions, however, the snippet may still be useful, so here it is:

[Service]
ExecStartPre=sudo -u /usr/bin/unbound-anchor -a /etc/unbound/trusted-key.key

InspIRCd 3

Cobra — Sun, 25 Aug 2019 09:43:40 GMT

All of a sudden, the PdeS IRC channel wasn't working anymore. As inexplicable as this sudden disruption first appeared to be, as obvious are the reasons in hindsight. What has happened?

At August 18, apt offered an InspIRCd update, dutifully asking whether I wanted to keep the configuration files. I didn't realize at this moment that the update was in fact the upgrade from version 2 to 3 I had been waiting for since May. As a matter of fact, this update is disruptive and requires one to carefully review and modify the configuration of InspIRCd. Well, I failed to do that, and I also failed to notice that the InspIRCd service didn't restart after the update.

Sometimes people jokingly remark that I should work as a system or network admin rather than as a scientist. This incident shows that I'm not qualified for such a job. I'm way too careless.

In any case, I now had to find the reason for the InspIRCd service to quit. It wasn't too difficult, but a multi-step procedure. The first obstacle was an outdated apparmor profile, which allowed InspIRCd to write in /run, but not in /run/inspircd. That was easily fixed.

The second was the TLS configuration of our channel. I took the opportunity to renew our certificate and to altogether strengthen the security of the channel, but it took me a while to realize that the identifier in the bind_ssl and sslprofile_name tags has to be one and the same (it isn't in the documentation!).

<bind
          address=""
          port="6697"
          type="clients"
          ssl="pdes">

<module name="ssl_gnutls">

<sslprofile
          name="pdes"
          provider="gnutls"
          certfile="cert/cert.pem"
          keyfile="cert/key.pem"
          dhfile="cert/dhparams.pem"
          mindhbits="4096"
          outrecsize="4096"
          hash="sha512"
          requestclientcert="no"
          priority="PFS:+SECURE256:+SECURE128:-VERS-ALL:+VERS-TLS1.3">

Well, the channel is up again, more secure than ever. Fire away. 😅