After looking around a little I couldn’t find any zigbee thermostat which met all my needs (mostly, I couldn’t find any which switches high voltage and has a wireless sensor that can stay in a different room).

so I went for the fully custom setup: a normal zigbee switch connected to home assistant and controlled by their software implementation of a thermostat. The temperature sensor is a template sensor which takes the temperature of the living room during daytime and the bedroom during nighttime. I have automation to change the target temperature during day, night and when the house is empty.

pro: fully customizable by software, dead cheap con: the heating needs your server to work correctly

Some failure modes I found and their workaround:

• The temperature sensor goes offline. I have automation to turn off the heating and send a notification
• the server goes offline: I left the old dumb thermostat wired in parallel, it can guarantee the home will not go too cold.

the only failure mode I’m still concerned is if the server goes offline while heating is on. In this case there is nothing to turn it off again. I was looking for zigbee switches with a timer to switch off automatically but I couldn’t find any. So if I’m out of home for more than one day I disable it and revert to the dumb thermostat.

my suggestion here is: whatever solution you choose, be sure to have a plan b in case whatever smartness you have stops working (cloud service or local home assistant offline)

Could it be that the domain name has both IPv4 and IPv6 and depending on the network you try to reach one or another? Wireguard can work on both protocols, but from my experience it doesn’t try both to see which one works (like browsers do). So if at the first try the dns resolves the “wrong” IP version, wireguard cannot connect and doesn’t fallback trying the alternative.

QNAP sells extensions unit https://www.qnap.com/en/product/tr-004

They usually connect with USB (at least for home grade devices), but my understanding is that they are not seen as block devices so the nas has access to all the single drives like they were internal.

Back to the days I was fixing a lot of computers of friends and relatives, my Swiss army knife of Linux was https://www.system-rescue.org/

Very lightweight but with a full set of recovery tools. I’ve tried it recently and I still find it up to the expectations.

I’ve also used a fair amount of https://clonezilla.org/ to (re)store images of freshly installed OSes (mostly windows XP and 7 to give you an idea of the timeframe) for people who I know would have messed up faster.

A lot of technical aspects here, but IMHO the biggest drawback is liability. Do you offer free storage connected to internet to a group of “random tech nerds”. Do you trust all of them to use it properly? Are you really sure that none of them will store and distribute illegal stuff with it? Do you know them in person so you can forward the police to them in case they came knocking at your door?

Yes, you can do it on your server with a simple iptable rule.

I’m a little rusted, but something like this should work.

iptables -t nat -A PREROUTING -d [your IP] -p tcp --dport 11500 -j DNAT --to-destination [your IP:443]

You can find more information searching for “iptables dnat”. What you are saying here is: in the prerouting table (ie: before we decide what to do with this packet) tcp connections to my IP at the port 11500 must be forwarded to my IP at port 443.

For automatically unlock encrypted drives I followed the approach described in https://michael.stapelberg.ch/posts/2023-10-25-my-all-flash-zfs-network-storage-build/#auto-crypto-unlock

The password is split half in the server itself and half in a file on the web. During boot the server retrieves the second half via http, concatenates the two halves and use the result to unlock the drive. In this way I can always remove the online key and block the automatic decryption.

Another approach that I’ve considered was to store the decryption keys on a USB drive connected with a long extension cable. The idea is that if someone will steal your server likely won’t bother to get the cables too.

TPM is a different beast I didn’t study yet, but my understand is that it protects you in case someone steals your drives or tries to read them from another computer. But as long as they are on your server it will always decrypt them automatically. Therefore you delegate the safety of your data to all the software that starts on boot: your photos may still be fully encrypted at rest so a thief cannot get them out from the disk directly, but if you have an open smb share they can just boot your stolen server and get them out from there

Not anymore, it supports txt records now

You can use the flag

–add-host myname=host-gateway

in your container “myname” will resolve as the IP of your host.

documentation at: https://docs.docker.com/reference/cli/docker/container/run/#add-host>

I tried a few and eventually settled on commafeed. It has categories, can be executed from a single docker image (in other words, can run without the hassle of an external database), and the responsive UI works well both on pc and phone.

I use backblaze and rclone to encrypt and sync. It was the cheapest and most flexible solution when I checked a few years ago and I didn’t find any reason to change it so far

I use rclone, which is essentially rsync for cloud services. It supports encrypion out of the box.

I use https://mycorrhiza.wiki/ it is not very fancy but it is a single executable file and stores pages in a git repository, so no database is needed and doing the export is as simple as reading some files.

Yes, you are right, I already use DNS validation. But it is just it is easier to request a single wildcard certificate for my domain and have all the subdomains that I use for the local services defined only in my local DNS. I cannot fully automate the certificate renewal because namecheap requires to allowlist the IP that can call its API, and my ip is dynamic. So renewing a single certificate saves me time. Also, the wildcard certificate is installed on a single machine, so it is not the I increase a lot the attack surface by not having different certificates for each virtual host.

The advantage of wildcard certificates is that you don’t have to expose each single subdomain over internet. Which is great if you want to have https on local only subdomains.

https://shadowsocks.org/ should be a good option, easy to install, encrypted, and password protected

For a simple dynamic DNS, I have been using https://www.duckdns.org/ for a few years and been happy so far

The main storage is a Nas that is mounted in read only most of the time and has two drives in raid mirror. Plus rclone to push a remote and client side encrypted backup to backblaze.