Apart from the other things people mentioned here, I recently deployed pinchflat-ngx: it subscribes to youtube channels and produces an RSS feed of videos it downloaded. I had issues with the using the RSS feed from youtube directly - it appears to break more often than not. That pinchflat feed I use in my miniflux instance.

I have HTTP(s) exposed, plus a wireguard port. HTTP points at a traefik gateway running in a kubernetes environment, based on hardened talos and using cilium network policies to isolate and direct traffic. I know that I am not super safe, but given this weeks news I think the only way to be truly safe in terms of cybersecurity is to use paper notebooks, snail mail and a subscription to the local print newspaper and no digital services whatsoever. In other words: how certain can we be that tailscale, or wireguard in general, or any other securit tool isn‘t suddenly at risk? Can we live with that risk? There always was a trade-off you had to make. Unfortunately „just use lets-encrypt, fail2ban and key-auth for ssh“ isn‘t really cutting it anymore.

The easier explanation would just be counting vehicles for traffic statistics and management.

I tried both voidauth and authelia and found that I really like that you can (actually must, as far as I’ve seen) configure authelias OIDC clients as configuration files. That fits a gitops style approach much better when paired with e.g. sealed secrets. It was a real pain to figure out that authelia configuration, hard agree on that… The official helm chart felt way too over-parametrized and is badly documented. The project website has a lot of basically-copy-paste configs for all kinds if self hosted software though.

This is about Doom 3, which was definitely more down the horror alley than the Doom installations after the reboot 2016.

There are certainly different kinds of developers writing different types of tests. I usually only write the tests first if I‘m adding a critical functionality to some method or function already present. However having automated tests can help you when you can‘t easily understand the code or when you want to refactor that code to make sure you‘re not breaking existing functionality.

What you‘re describing with external devs often happens when these devs can‘t access the real data - plus you often want these tests to be automated, which usually brings with it the requirement of atomicity, i.e. you want one test run running in parallel with another not effecting each other. That usually doesn‘t work well with a real database (unless you really take your test engineering to the overengineered tier).

I think its you device‘s path, i.e. on Android - otherwise the error would look different I presume.

Yes, /emulated/0/my-smb-mount or similar looks about right.

Are you potentially trying to mount a SMB share to the root folder on your client (i.e. / )? The error looks like the client is attempting to do something it itself is not allowed on its machine. Try specifing a path to mount to which is writable - e.g. /tmp/mount (not that you should keep mounting there if it works).

Another point to keep in mind - many distros now ship Podman instead of Docker, with Fedora being at the forefront of that change. If you‘re currently running Docker, you might want to check if your setup is drop-in compatible with Podman as some images will not work (usually related to permission or user switching, privileged ports).

Ingress controllers usually use the standard k8s services. In fact metal-lb allows workloads (like the nginx ingress controller) in the cluster to use services of type LoadBalancer, which is the default configuration. This results in an actual IP being made available to your ingress controller.

To get nginx ingress to use the external clients IP, you can configure the ingress controllers traffic policy. Using the helm chart, I used these values:

controller:
          service:
            # this has a bunch of downsides, but allows source-ip based access white/deny listing.
            externalTrafficPolicy: Local

For the ingress IP, I configured metal-lb to receive traffic on a static IP (using IP4AddressPool and L2Advertisement CRDs from metal-lb), which is then used for the port forwarding. I’ve never tested it because I only have a single worker node, but I expect the metal-lb controller will continue receiving traffic to that same static IP if a node goes down.