I mean, anybody can post anything anywhere, and it will get synced. Many communities aren’t even modded. But removing vile stuff is a burden to put on people to begin with, and I think most Lemmy instances are poorly equipped to deal with this automatically.

I keep seeing “escape the container” mentioned like it’s a very common occurance. Is it really? I’ve looked up escape CVE’s and they seem to be few and far apart, they’re usually tricky to pull off, and when one comes out it’s a big deal and they get fixed right away (obv).

Actually my issue isn’t “do escape CVE’s exist”, it’s more like, should I really waste my time planning for it? It’s like planning for file permissions not to work, or logins to be bypassed.

I get that shit happens and why defense in depth is a thing but how do you defend from something so fundamental? If you operate under the assumption that containerization can be by bypassed, and virtualization can be bypassed, where do you draw the line and what do you do, run each app on a standalone physical box?

They can also look for older R models, used. I have an R2 Arc Mini that can do 6 drives and it’s not too big.

If you think you might need more, get one with more slots up-front. Trying to add more HDD to a case that wasn’t designed for them sucks.

In Docker’s case is a non-issue because they were careful to use completely different names for all their packages. It’s only when the external repo uses the same names as the core that the dependency resolver can get confused.

Rant:

apt should either completely forbid external repos from using core package names (like Arch does), or look at both the package name and repo URL when deciding if a package is the same, not just package name.

I’m guessing that letting external repos “hijack” a package name was once upon a time seen as a feature and then they never got around to fixing it.

You say that but sometimes they come up with stuff that’s really useful and it can be very annoying to not have it. Like when they integrated compose into the main.

Also, if you later decide to switch to the official version you’ll have to handle the upgrade carefully or you risk wiping out all your images, containers, networks, volumes etc. Which can be fine if you have backups of all the relevant functional definitions and the volumes and so on, but obviously a huge pain if it catches you unprepared.

Mind you, this can also happen by tinkering with stuff in /etc/docker/daemon.json, which is how I originally learned to back up my shit.

Debian’s versions lag badly behind Docker’s. You’d always be missing the latest features. Docker introduces them at a steady pace and it can get annoying to see people talking about a new useful improvement and then months passing before it gets to you.

If you already know Debian that’s a big point in its favor. Nothing beats a distro you’re familiar with. (And I’d make the same argument if you were used to Ubuntu.)

I’ve used both Debian and Ubuntu Server on my home servers and I ended up returning to Debian.

• Debian embodies and follows the most essential Linux values. It’s open, it’s run by an open organization, it avoids proprietary stuff.
• Debian is long-lived. It’s been around for 30 years, it’s mature, self-sustaining, community-run project, and it will be around 30 years from now. Whereas I wouldn’t bet on Canonical being around in 30 years.
• The upgrade path for Debian is better than for Ubuntu Server LTS.(1) You can upgrade it in-place between major versions a lot more reliably and painlessly than Ubuntu.
• Debian is dedicated to being stable. (Please run stable, btw.)
• Debian is a lot more resource-friendly than Ubuntu Server.

I’ve ended up concluding that Ubuntu Server is Debian, just with more quirks. It offers nothing essential that you can’t do on Debian, and it will just complicate your life when the LTS support period eventually runs out (and even during LTS, when you have to jump through hoops like Ubuntu One to keep updates coming.)

(1) You can fuck up both Ubuntu and Debian’s upgrades by adding a lot of 3rd-party repos because apt doesn’t safeguard against external repos interfering with the core repos’ dependency graph.

So the trick is to keep the OS minimal, install only Docker from its repo and install anything else in Docker containers. That way you benefit the most from Debian being stable and very little from Ubuntu Server.

If you also need to run system containers and virtual machines you can add Incus later to the mix alongside Docker and still keep your host OS lean and simple.

You can also consider completely migrating to Proxmox later, which is also Debian under the hood but it’s a more turnkey solution. I wouldn’t recommend jumping straight into Proxmox unless you’re fairly sure that you’d need to run VMs. (If you’re unsure stick to plain Debian for now.)

I would recommend reconsidering how you obtain LE certs. I ended up on Certbot too because it lets you own what is a critical part of your selfhosted identity. Plus Certbot works well and it’s maintained by the EFF who also see it as a critical project. As a local script (basically) sky’s the limit regarding automation.

This is personal preference but I strongly prefer to locally control critical automations about my setup (certs, DDNS etc.)

The certs produced by Certbot are portable and you can use them with CF, local reverse proxies, or whatever other infrastructure you may need. Just need to get a copy to the proper place (securely).

I guess in the bigger scheme of things the question is whether you’re ok being tied to a particular service (like CF). I don’t, and I also don’t want to depend on the LE implementation of any particular reverse proxy (or their plugins).

PS: Oh and another tip: if you do end up using a CLI tool for certs, stick to Certbot. I’ve tried pretty much everything else and they all suck. It’s actually unbelievable how much they suck. Arcane and opaque, the lot of them, which is not something you want from a critical tool.

That’s a good point… was just looking into how I’d go about backing up my post+comment history and the only answer is basically “you need to use a special tool that pretends to be a lemmy client and fetches your history item by item”. I guess “host your own instance and migrate to that” is another one.

Which is surprisingly silly for what was supposed to be a more open platform than others. Heck, I can submit a GDPR request to Reddit and get a full dump of my account within the hour.

Does it have any particular benefits over using a random public instance? All I’ve heard is mostly needing heaps of bandwidth and storage.

It’s an interface for requesting stuff from the *arr stack.

I’ve just started using GarminDB to fetch .fit and .json files from my Garmin account.

Can I simply tell Dreeve to watch the directory where GarminDB dumps the files and it will pick them up?

Does Dreeve do something with the Garmin .json files too? Sleep data for example is in those kind of files, but since Dreeve has a Strava background I suspect it only deals with sports activities?

I’ve just stumbled across this post and it’s serendipitous because I just finished setting up GarminDB in a Docker container. It’s a Python CLI app you can use to download your Garmin stuff locally (which happens to be a bunch of FIT and JSON files).

You don’t have to use Docker ofc, you can also use a venv/pip to set it up somewhere and automate the backup command in any way you want.

It’s a happy coincidence because I was now wondering how to visualize the files. GarminDB also has some --import and --analyze options that parse the data into SQLite but they’re a bit buggy. Then you can use Jupyter notebook templates to produce something you can look at, but Dreeve might also be interesting (especially if it can monitor the folder where GarminDB dumps the files in read-only mode).

Last time I looked at Paperless-NGX it insisted on taking the source files and moving/renaming them so it could manage them itself. In fact IIRC the only way to add files was to give them to the app (or upload via web UI) so it could take them over.

Does it still do that?

I don’t like tools that demand to take over the original files. I’d prefer it if it could watch a read-only folder for new files. Immich for example or Jellyfin can do that.

You can use imapsync to sync all you mails from GMail to your new email provider

Or sync to a local directory and slap Dovecot+Roundcube on top, and you have your own private searchable email archive you can use indefinitely/securely/remotely. Just update imapsync to pull from the new provider when you switch.

I never understood why they don’t support the subsonic protocol.

I mean… you might as well ask why the DLNA plugin has been broken for years. Or why they don’t add a custom HTTP header to the client app so people can lock access in their reverse proxy.

As usual it’s a mix of not enough developer manpower and “I don’t use that so it’s not a priority” i.e. the whimsies of FOSS.

I think the confusion is that this isn’t a CalDAV concern. A CalDAV server only hosts event/task definitions. It doesn’t do anything with them, only offers an API for managing them.

It’s the client apps that use those definitions to work out occurances, do notifications, send emails etc.

So what you want is a capable calendar app with CalDAV support and email support, that can send email invites using different email addresses for different calendars.

Yes, and also by trying common subdomains under the main domain (like jellyfin., home. etc.) (They also scan the entire IPv4 address space, all TCP ports, over and over, but that’s a different discussion.)

If you’re using DDNS you have to also be careful where you put the A and AAAA records. Some people put them on the main domain and then do a wildcard CNAME pointing to it for all the subdomains, or individual subdomain CNAMEs. But since the main domain is known from TLS cert logs it’s trivial for bots to also check to see if there’s A/AAAA records on it.

It’s better to put the A/AAAA on a dedicated subdomain, obfuscate the name beyond trivial guesses (eg. maybe don’t use ip.), and make an individual CNAME for each services that points to the IP subdomain, and obfuscate those service subdomains similarly.

For those who aren’t familiar with DNS, the information in it is publicly available to anybody who can name a [sub]domain and record type explicitly, but they refuse to do “list all the records for all the subdomains of this domain”. So bots are limited to asking for the most commonly used record types on the main domain but can’t get to records on subdomain names unless they can name the subdomain. (For completion, asking for a list of all records is possible, but nowadays due to abuse that function is restricted on all the public servers to just the known IPs of their fellow redundant servers.)

A similar limitation applies to reverse proxies, bots can’t get to a service behind it unless they can correctly name the FQDN that the proxy uses for that service. (But please note that a reverse proxy works independently of DNS. If the proxy has foo.example.com defined to reach a service, it will work even if that domain isn’t in DNS or doesn’t exist.)

Even after taking these measures you have to keep in mind that this is not security, it’s obscurity. It cuts down on bot scans which is great but don’t assume it means nobody knows your service domains. Your ISP probably knows them, there are DNS servers out there that know them, your mobile carrier can see them, and if you ever connect to WiFi when away from home the owners of those WiFi can see them (think hotels, airports, coffee shops etc.) It’s not out of the question for a coffee shop WiFi to have been compromised and to collect URLs and attempt attacks against them. Use VPN or a SSH tunnel to connect to services whenever possible, rather than exposing them publicly, and if you must expose them publicly then use mTLS or at the very least a custom header key.

In the Yggdrasil network any node can act as relay for other nodes. So you can get to unreachable nodes via reachable nodes, as long as there’s a possible path through the network graph.

The community also maintains a few nodes with static public addresses, specifically so they can be used as entry points into the network.

Each node has two addresses, one used for communications inside the network and one used for peering. The inner address is IPv6 allocated randomly from the reserved 0200::/7 range and never changes (unless you wipe and re-configure the node). The peering address needs to be public and static, yes, but can be either IPv4 or IPv6 fwiw.

You only need to peer with one such public and static address to be able to reach other nodes, as long as there’s a path to them among all the peers in the graph. If you’re taking advantage of the larger Yggdrasil network that is taken care of by the public community nodes. If you want to set up your own separate network then you need to set up at least one node with a public static address. But you can also use a domain name and do DDNS for example.