I had the same considerations when I self-hosted headscale as the controller for accessing my VPS. However, I figured that it shouldn’t be a big deal, and there’s no chance of someone registering rogue devices on your mesh, because, even though any device can request enrollment to Tailscale, ultimately you need to execute a command in your headscale server to confirm the enrollment/account creation, so there shouldn’t be that much of a problem leaving the web server exposed.

One more question, how did you manage to get the reverse proxy to proxy your pods? I just added two containers to one, and I cannot access the containers anymore by their names. Do I need to expose their ports on the pod configuration?

Personally, I would avoid host network mode as you expose those containers to the world (good if you want that, bad if you don’t)… possibly the same with using the public IP address of your instance.

My instance is only exposing the HTTP/HTTPS ports, those are the only ports enabled in the firewall.

It seems simple. Does it use pasta as the default networking backend? Also, I guess separating each app into their own network is added security, right? So if anything happens to one app, it cannot move laterally to the other apps unless it manages to gain access to the reverse proxy, which then it would be a huge problem.

I maintain the DNS plugin for Vultr and I can say that it’s “safe”, but if you’re worried you should check their source code.

I believe it’s easier to have a vulnerability in the external provider’s API (for example, caddy-dns/vultr uses govultr) than Caddy. But I wouldn’t take things for granted if I was skeptical about these plugins.

I have a k3s cluster for fun and I can admit that k8s is way too complicated.

I don’t want to dig hours through documentation to find what I’m looking for. The docs sometimes feel like they were written for software devs and you should figure part of the solution yourself.

I have a ExternalName service that keeps fucking up my cluster everytime it restarts, bringing down my ingresses, because for some reason it doesn’t work and I have no idea where to look at to figure out why it doesn’t work - I just end up killing the service and reapplying the yaml file and it works.

I had to diagnose why my SSL certificates would get stuck in “issuing” in cert-manager, had to dig through 4 or 5 different resources until I got to an actual, descriptive error message telling me that I configured my ClusterIssuer wrongly.

I wanted a k3s cluster to learn but every time I have issues with it I realize it’s a terrible idea.

I wish I had podman + compose but it does seem like a docker-compose is more complicated. Also, I wish I could do ansible but I have no idea where to start (nor how it works).

EDIT: oh yeah I also lost IPv6 support because k3s by default doesn’t enable v6 and I was planning on using Hetzner CCM to have a 2 node cluster until I realized Hetzner Networks don’t support v6.

Can you use CrowdSec to track logs from a k8s pod? Say I have my website and some other services hosted on a k3s cluster, do I need to spin up a new pod for CrowdSec or should it be installed on the host?

where?

I guess Wifi 6 doesn’t work in 5GHz band?

The VPN bandwidth doesn’t need to be that good, I was checking the GL iNet models and 200 Mbps on WireGuard is enough for me.

I found Tailscale/Headacale way more difficult to setup than Wireguard.

I tried 5 different credit cards to setup my account and none of them worked for the free tier. Contacted customer support, they simply said “well we can’t do anything about it, it’s clearly a problem in your end and not ours even though you tried 5 different credit cards to pay for the service”.

My issues with Samsung nowadays is that they offer a very low TBW warranty compared to other brands like Kingston.

I wanted to buy a 1TB storage for my games and I couldn’t decide between Samsung and Kingston. Samsung had a 600TBW warranty for the 1TB model, Kingston had 800. I ended up choosing the KC3000 from Kingston.

It’s still not an excuse to just ignore the security update because you might not be a target for hackers.

Just check your logs, there’s probably a dozen or more requests trying to access wordpress pages on your server, or login via SSH. They want to take over your server so it can be part of a botnet.

I think so, but if you check the official image you can definitely find out how to include custom plugins in it. I think the documentation might mention a thing or two about it too.

You can install the log transformer plugin for Caddy and have it produce a readable log format for fail2ban: https://github.com/caddyserver/transform-encoder

I had this setup on my VPS before I moved to a k3s setup. I will take a look at how to migrate my fail2ban setup to the new server.

The only thing I see they did wrong was to disclose the vulnerability before waiting for a comment from the software company.

I’d recommend Forgejo/Gitea as others have mentioned or https://sourcehut.org (instance available at https://sr.ht/)

If you own a domain name you can use the DNS-01 challenge instead of hosting a web server to serve the challenge response.

With DNS-01 it will add a TXT record to your DNS zones and check if the record exists to verify that you own the domain and then issue the certificate.

Depending on which tool you use, they usually support DuckDNS and some other free DDNS providers. If you have your domain on a registrar, chances are that it’s also supported.

Thanks for the suggestions!

I ended up configuring my CI pipeline to build a Caddy docker image that ships with my website files. The pipeline is also publishing the container image to the Codeberg registry and I apply the new image repo and tag to the Caddy Helm chart I found on ArtifactHub.

The only thing that’s left is to setup the CI to automatically restart the pod when a new image is pushed, so it will always have the latest version.

It was easier than expected and I had a few issues like my stylesheets not being applied and image files not rendering, but it was solved by changing the pathType field on the ingress configuration to Prefix.