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.
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.
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?
dokuwiki as a blog engine (via podman)
I originally intended this to be a writefreely blog, before actually trying it out and realizing writefreely didn't quite do what I wanted. Then I had a Wordpress blog on here and found it too unwieldy. Then I gave up on the fediverse integration I had originally intended as a main feature, and went through a few smaller blog engines that I didn't care for at all. Funnily enough in the end I installed dokuwiki on my local network as a wiki engine, when I realized you could easily use that one for blogging as well.
It's not quite what I originally intended, but my original goal was to have a place mostly for notes about computer things that I learned, and for that it should be alright.
dokuwiki is, as the name would suggest, originally intended as a lightweight wiki engine for documentation (german: dokumentation). This is exactly why I installed it on my local network. But it also is easy to setup and configure, and can be extended via plugins. This installation is running over podman with no issues. Normally I would prefer using the packaged version from the debian sources, but I found a warning that this might interfere with some of the plugins I intended to install, as the version in the debian sources was using some non-standard paths.
I do prefer podman for a use like this, as it doesn't require root rights to run. Although I lately have found docker to be easier to use in general.
Here is the command I used to get it started:
podman run -d -p 8080:8080 -v /path/to/storage:/storage docker.io/dokuwiki/dokuwiki:stable
This should get you up and running without any issues. Once that is done go to localhost/install.php where it will ask for a few more values (e.g. the title of the wiki/blog, and setting up your username and password).
Afterwards follow the article on how to set up dokuwiki as a blog on the dokuwiki wiki.
Small issue: trying to use the Avatar plugin with the Discussion plugin throws an error for me. The discussion plugin is marked as depending on the Avatar plugin, but it's really only for showing gravatar icons and so it can easily be switched off.