7 Aug 2025

Now available in onion flavor.

Short update on my experimentation in selfhosting: This blog is now available as an onion site via Tor.

I added my homepage to the darkwebz a while back, but never got around to creating an additional onion address for this blog. I just recently realized, however, that onion domains can utilize subdomains! It makes sense, but I suppose I just assumed that tor required unique domains for some reason. Anyway, adding the subdomain turned out to be as simple as it is on the clear web.

I added:
blog.uadt46c5yobuupuq52o3kumbkylh4k5olgftzlqjvzso7lx5qeotkdid.onion
to my nginx server block for this blog, and it just works.
I also added
add_header Onion-Location http://blog.uadt46c5yobuupuq52o3kumbkylh4k5olgftzlqjvzso7lx5qeotkdid.onion$request_uri;
to the location block, which tells tor clients (like Tor Browser) that the site they are visiting is available as an onion site, like so:

image showing that this site is available as an onion site

Pretty nifty!

20 Jul 2025

Update: Not a lot going on...

For the homelab: I've met a lot of my learning goals over the last two years, and I find myself wondering what to do next. For a little background, I don't work in IT. I don't need to learn any of this; it's just been a hobby of mine, mostly in pursuit of fun, knowledge, and control over my personal digital systems.
There's always more I could potentially learn, of course, but finding things that are practical and useful in my home environment is getting a bit tough.

My other hobbies are sort of going in the same direction. Ham radio is getting repetitive. There's a lot of things I can do, but they're all starting to feel a bit same-y. I think it might be different if I had a better antenna set-up and could experiment with a greater number of bands, but as it is, I'm mostly stuck with VHF, 10m, and 20m.
I do think that packet radio might be a fun space to play in, but without other folks in the area to play with, it's hard to find the motivation to do much with it. My initial thought was serving my gopher hole over the air, but the venn diagram of people who are interested in both packet radio and gopher, and live within VHF range of my station looks like mickey mouse. It's an unusual enough project that it might catch some interest on reddit, though, I suppose. Maybe I'll give it a shot and post the results.

If anyone want's to suggest a new project, feel free to message me on the fediverse @me@social.k3can.us or shoot me an email.

15 Jun 2025

It ain't dumb if it works

Sometimes I think I over-complicate things.

In fact, I know that I do. e.g. this blog. I really don't need this to be hosted in my homelab on a high-availability server cluster. I could just use Blogger or any other free, hosted blog solution.

Anyway, today's example is an oddity I noticed in my DNS logs. Well, actually, it started when I noticed that the RAM in my router was filled with files in /tmp. Like a whole GB of files. I traced it down to my DNS logs, which were occupying almost the entire /tmp mount. I found that I had apparently set the log retention to 90 days. I reduced it to something more reasonable and I think that should solve the problem. However, that also made me curious about what was in those logs...

I found that the majority of the DNS requests were for "0.10.0.5.1". Which sort of looks like an IP address, except for that extra 0 at the start. Since it's not a valid address, something was interpreting it as a hostname and trying to resolve it. I knew from the logs that it was originating from my webserver (the same server which hosts this blog), but I didn't know which application was actually making the requests. I was able to catch the outgoing port with lsof, but it was an ephemeral port and too short-lived for me to trace it back to an application.

I spent a while trying to catch it with auditctl rules, but I'm not very familiar with auditd and I wasn't making any progress. I google'd around and even tried a chat bot to come up with more ideas on how to catch this application; strace, bpftrace, and so on, without any success.

Finally, I decided to try doing it "the dumb way."

Instead of trying to outsmart this application and catch it in the act, I figured something must be configured to send requests to 0.10.0.5.86, so I just searched the entire /etc/ folder for that string via grep -Rnw '/etc/' -e '0\.10\.\0\.5\.1'.

And grep: /etc/systemd/timesyncd.conf:20:NTP=0.10.0.5.1

Well, crap. I had configured timesyncd months ago to use my router as its time server and apparently I accidentally added an extra 0 to the IP address. Oh well. A quick edit and systemctl restart systemd-timesyncd.service later, and the issue is fixed.

- page 1 of 7