Not anymore, it supports txt records now
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 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.
I’ve used https://www.bestheating.ie/btu-calculator to decide the power of my new boiler, so far it is working well. But as other said, this is likely a very rough approximation.
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.
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