lemmyvore

Tagged VLANs would be needed regardless, because I have only one server with one physical connection and I wanted to have processes on it on 2 different networks.

Docker is neither here nor there, you’re right it’s not needed for the solution. I was using it anyway, I know lots of selfhosters do, and it does make it easy to create an ipvlan and put an app on it.

Docker is not the only way to achieve containerization but I do appreciate and use containerization (and virtualization). It lets the host OS stay simpler and cleaner and prevents the various apps from messing with it. It makes it easy to control each app’s environment. You can do app containers, system containers or VMs as needed. It makes it easy to back up, restore and reproduce an app and its state, independently of the host OS or any other app.

Abstractions help… they empower you to do more. You invest some time into learning, sure, but it pays off later in time saved managing and the ability to do more complex stuff faster.

Troubleshooting is what it is. Nothing’s perfect, you’re going to end up troubleshooting something sometime not matter what you use.

I’m not an expert so take this with a grain of salt, but it seemed to me that the driver approach is the more useful abstraction and also the more modern, and that the old one will get eventually phased out (or stay there under the hood, out of the way).

I did initially do it with the firewall alone. I created a “br-nvr” device, moved lan1 from br-lan to it, and used br-nvr as the device for the NVR interface and firewall zone, then selectively let my phone and the NVR app from the LAN zone access the camera ports with traffic rules.

Everything else about the interface and zone stayed the same as they are now. (That’s what’s great about the OpenWRT abstractions. )

The one major issue with that approach was that the NVR app is outside the NVR zone and I wanted it in there.

• It makes broadcasting a non-issue, (I I really don’t want to have to learn how to do cross-network broadcasts and I understand they’re fraught with problems anyway).
• Better security with less complexity. A single camera can have like 3 ports that need to be made accessible, and different cameras will have different ports. Making and maintaining traffic rules for multiple cameras would rapidly turn into a nightmare.

With the NVR app in the same isolated network as the cameras they can do whatever they want in there without needing explicit rules.

But I couldn’t put the NVR docker container into the NVR network, because it lives on a machine on the LAN network, and you can’t have the host machine on one network and a app on it in another network, with a single physical cable… unless you use tagged VLANs.

There are also some potential annoyances in the future if I ever want to move cables around the ports or make more complex setups, the VLAN abstraction makes things easier.

In this particular case it wasn’t Docker that gave me the headaches, it was OpenWRT and wrapping my head around tagged VLANs.

Once you have the VLANs working on the router and the tagged interfaces up on the server, pointing a Docker network or an LXC at the eth0.100 interface is equally easy.

Now, when I first got the camera I was considering adding a PCI network card to the server and plugging the camera into that, so it would be directly hardwired into the machine running the NVR. If I had done that I was given to understand that taking ownership of a physical NIC would have been much easier with LXC than with Docker.

(We’ll never know because I couldn’t find the PCI network card.)

Hetzner + a HDD backup would basically get you to 3-2-1.

As a rule of thumb I’d keep the SSDs for live data and HDDs for backup.

Hetzner supports multiple good backup tools so you have options, and their prices are decent.

But please stick to Restic (or Borg) because they’re actually designed for backup and have built-in encryption, compression, deduplication, integrity, recovery etc. Don’t use “sync” tools like rsync.

Please, please, please assume that any of the SSDs and HDDs and cloud storage can dissapear at any time. Sit down and run some scenarios on paper, see what you’d do in each case.

Also a good idea is to sit down and categorize all your data on a scale of “how much my life would be over if I lost this”.

If you need an extra form of backup media for ultra-essential data, Blu Ray optical discs are still an option. They are specifically designed for this and an USB optical writer is cheap.

Last but not least, store your “cold” backups in proper storage enclosures. For HDDs I like Orico padded boxes, for Blu Ray’s use a “CD wallet”.

Put a reverse proxy in front of it. It will do SSO, mTLS or whatever you want. DAVx5 supports mTLS.

Some extra options you might want to consider:

• Having the device act like a DLNA renderer. You still need it to run a graphical stack and a DLNA app, but you can control it with a DLNA controller app on your phone, and tell it to fetch content from your Jellyfin server if you activate the DLNA plugin so it will act like a DLNA server. DLNA needs network broadcast so it will work if the stick/phone/server all all on local LAN but typically can’t cross VLANs.
• Having the device run a Tailscale client alongside Kodi or connecting to Jellyfin with a browser or client. If you also put Tailscale on the server you will be able to securely connect to it even on vacations (hotel TV for example).

Lol I don’t know, I’ll have to try. If that works it’s definitely not intuitive.

I recommend taking a look at the new Tailscale access controls > policies. Much easier to understand than their old ACLs. You can quickly draw up rules that only let specific devices access specific nodes and even only specific ports.

There’s one small potential point of confusion, in that you can’t use node names directly in the rules. You have to go to access controls > definitions > hosts and make up a name there assigned to the node IP address, and then you can use that name in a policy.

So if you have a tailnode called “nas” you can’t just say “nas” in a policy, you have to go to hosts, define one called “nas” that points to that tailnode’s IP, and then you can use “nas” in the policy… 🤪

I understand the logic, which is that hosts and definitions in general are much more powerful and can define IP netmasks and IP groups and then you can use those groups in policies… but boy, the redundancy when you have to do this for single nodes that are already assigned a name and an IP is rubbing me wrong.

It’s very easy to make a custom CA and issue certs. Here’s a good tutorial.

Unfortunately in practice It depends greatly on what’s on the other side (the client app). Some examples:

• DAVx5 on Android works perfectly fine and uses the client cert from the system store. 10/10, this is how all apps should work.
• Ntfy on Android works perfectly fine but wants the client cert file loaded in the app, it doesn’t use the one loaded in the system store. This sucks because instead of loading a cert into the system store once and then deleting it you have to keep the cert file around for this kind of apps, in Android shared storage, which is accessible to all apps.
• Same for Immich, wants the cert loaded in the app. Also, it will randomly lose it (on both iOS and Android). Yes, you heard that right. So it’s basically useless and I had to resort instead to a key in a custom HTTP header; which isn’t exactly the same as mTLS, but helps secure the service at reverse proxy level so it’s better than nothing.
• Firefox on Android will use the cert from the system store, and then it will crash. Again, useless.

It’s also not exactly straightforward to use mTLS with reverse proxies.

Let’s take for example Caddy and say you want unconditional mTLS for all reverse proxy hosts. Easy enough:

tls /path/to/domain-cert/fullchain.pem /path/to/domain-cert/privkey.pem {
  client_auth {
    mode required
    trust_pool file /path/to/custom/ca.pem
  }
}

But suppose you don’t want unconditional mTLS, you’d like to let clients in if they have mTLS or a custom header, or do different things depending if the client has valid mTLS or not. Does Caddy offer a built-in conditional to act on mTLS status? Nope!

As a workaround I’m setting the client_auth mode to verify_if_given and then using a DIY conditional that checks if the variable http.request.tls.client.certificate_der_base64 is empty or not. But it’s undocumented so who knows if it may break at any point.

For reference, how you handle both custom headers and mTLS at once (after setting the mode as I’ve mentioned):

@immich host "whatever.example.com"
handle @immich {
  @not_authorized {
    not header X-Custom-Pass "LONGRANDOMKEY01" # jim
    not header X-Custom-Pass "LONGRANDOMKEY02" # bob
    vars_regexp {http.request.tls.client.certificate_der_base64} ^$
  }
  error @not_authorized 403
  reverse_proxy http://immich.lan:port
}

The nested “not not” is required because Caddy can only do logical AND in group conditionals, so to do logical OR you basically have to do NOT (NOT a AND NOT b).

Yeah it’s a very good rule of thumb to always bind to explicit IPs.

Another issue with 0.0.0.0 is that it will bind to basically everything, including whatever bridge or tunnel interfaces you may have up on that machine. And that’s how you end up with random services exposed through VPNs and God knows what, when you thought it was a “private” service that only lives on your LAN.

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?

Might try for older R models. 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.)

I’m prepared to state that Ubuntu 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.

(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.

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 guess subdomain names. (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.)

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.

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.

f you’re using ipv6 supposedly you don’t need to forward ports.

You don’t need to forward ports but you still need to maintain network rules for each port so you can get through the firewall. And those rules need to know IPs. And if your public IPv6 prefix changes you need to update the rules.

So, really, there’s no advantage over forwarding, on the contrary, since forwarding uses private IPs which you can make static so they never change.

Some router software like OpenWRT attempts to work around this issue by using a special “minus netmask” shorthand syntax for the network rules, for example ::2/-64 means you want to reach [whatever the dynamic prefix is right now]::2. Which assumes you’ve set things up so that a certain machine always gets static suffix ::2, which means that machine does not do MAC anonymization and can use DHCPv6, which excludes all Android and iOS devices. So it can be used with Linux servers for example but with a lot of caveats.