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.

Amazing work!

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.

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

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!

I have Lemmy running on my homelab behind Cloudflare, though I’m using a reverse proxy setup. I made some minor modifications to the provided docker-compose.yml to get everything working with my existing reverse proxy setup.

As for backups, I want to say so long as you back up the postgres database and import the backup on your new server you should be good. I believe there’s a section in the Lemmy docs on how exactly to do that process.

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!

Cloudflare tunnels are great but OP may not want to have to authenticate each user to their services.

Cloudflare free tier + a reverse proxy will set you straight. You can add subdomains for your services as A records in Cloudflare off of your root domain, i.e. lemmy.yourdomain.tld, personalsite.yourdomain.tld, images.yourdomain.tld.

When doing this, enable the Cloudflare DNS proxy which will route DNS requests to your origin service through Cloudflares’s CDN. This essentially “hides” your public IP as anyone doing a nslookup lemmy.yourdomain.tld will get Cloudflares’s IPs back as a response.

Once you’ve done this, you can break everything back out to it’s respective backend via a reverse proxy. For example, lemmy.yourdomain.tld gets passed to 192.168.0.10, personalsite.yourdomain.tld gets passed to 192.168.0.20, etc.