The Downtime Project is a pretty interesting podcast that covers some large outages and discusses their post-mortem analysises. Worth a listen IMO, very interesting stuff and some good lessons to learn.

Crashing and burning (in a non-production environment) is an excellent motivator to develop necessary skills; being unafraid to break things and fix them when they inevitably break helps you get a deeper understanding of how the systems work, for what it’s worth.

Trying to get started with reverse engineering and binary exploitation by following this guy. My brain hurts, but in a good way!

Running an RKE cluster as VMs on my ceph+proxmox cluster. Using Rook and external ceph as my storage backend and loving it. I haven’t fully migrated all of my services, but thus far it’s working well enough for me!

Good bot

I don’t know how I feel about this personally. On the one hand, I feel like this is a privacy win for those who want it: no watch history means no algorithmic recommendations and (presumably) less data collection for those users. On the other hand, I personally really enjoy the recommendations that YouTube makes for me. Maybe it is the wide variety of content that I watch, but I’m honestly very pleased with the recommendations that YouTube provides. That being said, I feel like the opt-in to algorithmic recommendations is a good thing overall, however I am personally going to leave my watch history enabled.

Back when COVID was in its prime, I was contributing CPU/GPU cycles to Folding@Home for protein folding simulations and working on a vaccine. Since then, I’ve reimaged my desktop twice. I should probably reinstall the BOINC client to contribute again…

Thanks for the info. That seems quite heavy handed.

I’m out of the loop, what is France trying to do with regard to DNS?

Here’s the link to the study: https://doi.org/10.3390/s23136205

A modern classic IMO 🤣

Hello fellow domain hoarder 🤣

Hello from onlylans.io

Very frustrating to hear. I’ve been slowly migrating away from RHEL-based distros after they shifted CentOS to be upstream from RHEL. This is another nail in the coffin in my books.

I’m posting currently from the PWA after I enabled 2FA on my account (not currently working with Jerboa). It’s nice and works well, but I prefer the more compact list view present in Jerboa. Other than that, no complaints!

We use wiki.js at work and it is great. A nice benefit is you can track your articles in a git repository for granular change tracking.

Oh weird, that sucks lol

I actually setup SES for my Lemmy instance. I was evaluating SendGrid but less than 24 hours after signing up they closed my account with zero explanation so…yeah lol.

I was sandboxed in SES initially but I created a support ticket asking for production access and I was good to go. No issues with SES thus far.

Cloudflare tunnels or a reverse proxy with Cloudflare DNS would be much easier to manage IMO. What you’re doing will work but it seems like you have a lot of moving parts in your setup which can lead to errors creeping in.

With both proposed setups you should be able to pass non web-based traffic to their respective backends. In nginx that would look something like the following:

server {
        listen 443 ssl http2;
        server_name service.yoursite.tld;

        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host:$proxy_port;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass http://<IP of your service>:<port>;
        }
}

With Cloudflare tunnels you can setup a VM as your tunnel termination point and configure ingress rules to pass traffic where it needs to go, similar to this:

tunnel: <Tunnel UUID>
credentials-file: /root/.cloudflared/<Tunnel credentials>.json

ingress:
  - hostname: service1.yourdomain.tld
    service: http://192.168.0.10:80
  - hostname: service2.yourdomain.tld
    service: ssh://192.168.0.20:22
  - service: http_status:404 # This is a catch-all rule to handle unmatched ingress traffic

One thing you can do for your public IP is use something like inadyn to update cloudflare with your public IP when it changes. Inadyn is super lightweight and will make sure, +/- 5 minutes, that your public IP is up-to-date with Cloudflare.

True, in that case CF tunnels may be easier to manage due to fewer moving parts to configure. Good point!