segfault - blog:2026:03

03_pihole_as_a_ntp_server

anonymous@undisclosed.example.com (Anonymous) — Tue, 03 Mar 2026 23:47:59 +0000

pihole as a NTP server

You have to wonder if it's intentional or not, but even the pihole documentation points out the problem: raspberry pis do not come with a RTC (real-time clock), so unless one gets one for the Pi your pihole-based NTP server always will have a problem if it was offline for longer than a few hours.

The problem is deliciously simple: a device with no RTC will keep the time it last switched off on until it synchronized with another NTP server. It cannot synchronize with any public NTP server because it can't establish a connection: the handshake fails because one of the devices believes it's days earlier than it actually is.

No connection, no sync. No sync, no valid DNS resolution. No valid DNS resolution, no connection.

How do we solve this?

Well, one way is to set your time manually.

Run

$ timedatectl set-ntp false

Then

$ timedatectl set-time 2026-03-04 02:00

Or whatever is right. Then

$ timedatectl set-ntp true

And while that does the job, I realized there's actually an easier way to handle the problem: you see, the issue comes because DNS resolution doesn't work, right? So why not, incidentally, just use the ip address of a nearby NTP server?

And presto, it's back to normal.

I actually used the server of the Polish Główny Urząd Miar (Central Office of Measures) as I'm located in Poland (their address is 194.146.251.100 btw) because I figured, well, isn't that likely one of the most accurate places around? In fact, why do we keep using clock servers by Google and Cloudflare and so on, when public scientific institutions everywhere provide the same service? Oh, well, besides the fact that it's free either way I guess?

ntp, pihole

05_my_irc_setup_i_chat_server_ngircd

anonymous@undisclosed.example.com (Anonymous) — Thu, 05 Mar 2026 08:45:14 +0000

My IRC setup I: Chat Server – ngircd

ngircd (Next-Generation IRC Daemon) is one of the simplest full-featured IRC clients around. It's similarly next generation as Star Trek: The Next Generation is to Star Trek though: it has been around for a long time. It originally came out in 2001 and has been in development ever since, but as the developer is basically just one person it's not like it was going to get earth-shattering new features.

What it promises is simplicity though: One can get it running incredibly fast, just install it from source or from your distro's package manager (on debian: apt install ngircd), fix up the configuration file (add a name, OPer user and password, and so on, the ngircd.conf file is amazingly self-explanatory if you ever looked at any of the other ircds) and you have a running IRC server you can connect to with a normal IRC client on port 6667. It's only slightly more complicated to get SSL running on port 6697 or do things like setting permanent channels.

Multi-server networks are also easy: you need to find another ngircd server willing to peer with you though, then add a few code snippets like this into your configuration:

[Server]
	  Name = example.org
	  Host = example.org
	  Port = 6667
	  MyPassword = supersecret
	  PeerPassword = secretsuper
	  SSLConnect = no

Your peer needs to add exactly the opposite passwords. Then reload ngircd and you have your own IRC network.

Notes: do watch out that the nicklength value is the same. That governs how long nicks can be in the network, and if it isn't the same on all servers it will refuse to connect. Ask me how I know.

We have a small network running via ngircd. You can connect to it via wilderland.ovh or campaignwiki.org, in both cases ports 6667 or 6697. It's mostly for ttrpg topics, but most of us are also into weird computer talk.

irc, chat, ngircd

09_tailscale_pi-hole_and_the_raspberry_pi_zero

anonymous@undisclosed.example.com (Anonymous) — Mon, 09 Mar 2026 13:00:00 +0000

Tailscale, Pi-Hole, and the Raspberry Pi Zero

As many other people do I also have a pihole running on a Raspberry Zero in my network to get around ads and other unwanted DNS requests (one of the most regular things trying to communicate home by the way is Windows on our laptops). It technically is a RPi Zero W, but I don't use the wireless function at all, having it connected via a USB-to Ethernet connector instead. And for the last few years it was working quite dependably, filtering out DNS requests, and even resolving actual requests via unbound. That is, until recently when I installed Tailscale on it. Tailscale, if you're not familiar, is an app that allows you to basically create your own VPN network and assign your devices to it. And it works quite brilliantly when it works. I originally added it to the pihole machine as a way to start other machines in my network when I was going abroad but my wife stayed home. And it worked. I was able to do stuff on my home server while I was in Germany, while my wife noticed only that the machines occasionally powered up and down. Oh, and internet became spotty. Why though? Well, it turns out tailscale is just a tiny sliver too demanding for unbound to do it's magic. In my experience whenever I used tailscale for anything all of a sudden DNS resolution with my pihole/unbound combination didn't work consistently (it started throwing SERVFAILs) Ok, it might also have been because I updated the Debian to the newest version.

So, what did I do about it? I could have replaced the pi zero with something beefier, but I do like it's otherwise VERY low demands. It also worked if I just switched to external resolvers. So if you have this issue and don't mind using external DNS servers that always is an option. Me, I of course made it more complicated: I installed a technitium docker container on my home server. Which to be fair is pretty stupid as that's basically a full-blown replacement for the pihole in the first place. Technitium is a full DNS server with adblocking capabilities. It's not sleek enough to run on a zero though, from what I've seen it needs at least a Pi 4. It's barely noticeable on my home server though. It's not quite ideal, but at least it works. The issue here is that, as I often work on my home server having it down without a replacement would mean DNS resolution is off in the whole network. So the zero keeps running with pihole and unbound, and while most DNS requests are done by technitium, if that machine is off it instantly goes back to the old pihole/unbound combo.

pihole, rpi, technitium, unbound