lemmyvore

Yeah install a reverse proxy at home and reach it through a service like Netbird or Tailscale. No VPS needed. And it’s probably a better idea to do it this way because a local reverse proxy would be 100% self-reliant. Hosting Pangolin on VPS would always make you dependent on the VPS.

NPM (Nginx Proxy Manager) is an Nginx distribution with a friendly UI and it includes certbot so you can get/renew certs automatically and use https://service.yourdomain.com/ URLs if you want.

You will need a DNS provider for that btw, DeSEC.io is free and committed to privacy.

You should be using them depending on your needs. There’s a difference between app containers (single app per container), system containers (multiple apps in the same container) and VMs (OS + whatever, virtualized rather than containerized).

You probably need app containers most of the time so docker or podman is a good fit. But sometimes you might feel more confortable with another level of abstraction. Tools like Proxmox or Incus make it easy to manage “system”-level abstractions like system containers (with LXC) or VMs (with KVM) and give you a unified management approach.

You don’t have to give up app containers either. You can run docker or podman inside an LXC system container and have the best of both worlds.

Deciding when to take advantage of the system abstraction is the hard part. A simple rule of thumb is to do it when you’d like to manage the “machine” that holds the stack in a way that’s different from the host. Maybe you want to run a different Linux distro; maybe it’s the same distro as the host but you want to organize it differently; maybe you need to run a non-Linux OS.

I would argue that’s a bit of a perversion 😃 but on the other hand if it can serve my static page… I’ll have to reconsider HAProxy for my stuff. Thanks!

unlike stoat which requires to apply to be able to contribute which is suspicious for a supposed open source software.

They’re doing it because they require a Developer Certificate of Origin from contributors in order to mitigate legal liability. Which is probably smart, it’s good to cover your bases when you take on the likes of Discord, who would love to be given an opening to sue and/or obtain a cease & desist on copyright grounds.

FWIW I’ve tried all the major CLI tools for cert renewal (certbot, lego, acme.sh) and certbot was by far the easiest to use. The others were various shades of horrible – bad documentation, obscure error messages, you name it. Wish I had tried certbot first and not wasted my time.

You can find the magical incantations online and coax them to work eventually but they made me wonder if that’s the kind of tool I want to trust with my cert renewal.

The dirs are subdirs of /srv/letsencrypt. I like to take advantage of explicit dir assignment if the software allows it, so I don’t have any surprises if the defaults change.

ROOT=/srv/letsencrypt
SECDIR="${ROOT}/secrets"
CFGDIR="${ROOT}/config"
LOGDIR="${ROOT}/logs"
TMPDIR="${ROOT}/tmp"

for DIR in "$SECDIR" "$CFGDIR" "$LOGDIR" "$TMPDIR"; do
        mkdir -p "$DIR"
done

cd "$ROOT"

Just keep in mind that HAProxy is only a proxy (technically a performance-oriented load-balancer). It’s not a web server.

I mention it because some of us also rely on our reverse proxy to serve small static webpages for various purposes (I serve a small status page generated by a cron script, for example).

I’m also using Certbot with DeSEC. I simply run it daily with anacron. If it doesn’t need to renew the certs yet it will say so and stop. That’s basically it.

I think it’s a very good idea for your LE renewal to be independent of whatever reverse proxy or web server you’re using.

Please keep in mind that Certbot is a Python app so you can manage it with venv. Here’s how I install it in a dedicated dir (let’s say /srv/letsencrypt because using /etc is not appropriate and it bugs me 😆):

#!/bin/bash
set -e
apt install python3-venv
/usr/bin/python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install --upgrade certbot certbot-dns-desec

And to update it:

#!/bin/bash
set -e
source .venv/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install --upgrade certbot certbot-dns-desec

As for renewing certs (the script is longer, I’m making sure to create dirs and so on but this is the gist of it):

source .venv/bin/activate

./.venv/bin/certbot \
--config-dir "$CFGDIR" \
--logs-dir "$LOGDIR" \
--work-dir "$TMPDIR" \
--domain "*.${DOMAIN}" \
--domain "*.${DOMAIN}" \
--authenticator dns-desec \
--dns-desec-credentials "${SECDIR}/${DOMAIN}.ini" \
--non-interactive --agree-tos \
--email "$EMAIL" \
certonly

openssl x509 -text -in "${CFGDIR}/live/${DOMAIN}/fullchain.pem" |\
grep -e 'Not Before' -e 'Not After'

For DeSEC you need secrets/${DOMAIN}.ini to contain:

dns_desec_token = YOURTOKENHERE

Please note that DeSEC lets you restrict what the token can do, but setting the rights on the token has to be done through their API so you need a separate token for the API 😅.

To use the certs from Caddy, point it at the files under the config/live/${DOMAIN}/ dir (which are symlinks that are maintained by Certbot), NOT the ones under archive/.

tls /path/to/certbot/config/live/example.com/fullchain.pem /path/to/certbot/config/live/example.com/privkey.pem

Or, if you want to also add mTLS to the mix:

tls /path/to/certbot/config/live/example.com/fullchain.pem /path/to/certbot/config/live/example.com/privkey.pem {
    client_auth {
        mode verify_if_given # or whatever access mode you want
        trust_pool file /path/to/custom/ca.pem
    }
}

Let me know if you have questions.

you do not want a DE for your server

While that’s technically true, in some cases you might want a graphics stack after all. For example if there’s a TV nearby you can get some cool benefits from being able to output directly to it.

But I agree that starting with a desktop distro is probably not the way to achieve it.

The main limitation in a 1U chassis is the size of the heatsink + fan. They’re typically 80x80mm width/length, and the height is very small. You get 45mm for the whole case so you have to work with a slim (15mm) 80x80 fan and a tiny heatsink that’s 10mm or so. So they have to work at 5000rpm and put out 60dB of noise but even so they’re typically only rated for 80-100W.

I other words I really don’t think it’s worth bothering for a 250W draw. If you can get a 2U space yeah, that gives you much better cooling options.

Don’t even suggest it to the datacenter people. They will laugh at you.

If you have good IPv6 connectivity both at home and away you can look into the Yggdrasil network. It facilitates node-to-node encrypted communications, but it’s decentralized and community-run. Unlike Tailscale, each node can do both communication and relay.

You run the Y client on each device you want to use and if you want to keep things completely private (and you have at least one device that’s not behind CGNAT) you can only add your own devices as peers. If you need to bypass CGNAT you can use one of the community-supplied nodes to act as relays, or set up your own node on a VPS.

The cool feature of Y is that if you’re trying to communicate between nodes A and B and there isn’t a single node that’s peered with both A and B, you can still communicate as long as there are nodes somewhere in the network that know them both. The network will search for you and calculate the optimal relay path. Ofc like I said this is irrelevant if you decide to stick to your own devices, basically you will have your own personal mini Y network completely separate from the main public network.

Even when using the public network there’s no privacy issue, relay nodes cannot snoop on communications only facilitate the connection or not, and once relay to a node has been accomplished the nodes will communicate directly thanks to ICE+STUN, if possible, like Tailscale does.

Please note that nodes are identified by 2001:: random addresses. While the 2001:: address space is huge it’s still only obscurity not security. You still need to have a decent firewall setup on each node, Y does not enforce ACLs or anything like that.

If your services are private they should be behind access authorization or completely private access. Scanning should be a non-issue.

You can further mitigate scanning by getting wildcard certs, putting A/AAAA records on an obfuscated sub-domain rather than the base domain, and not using wildcard CNAME’s.

If they services are public you should be using a CDN anyway. If you don’t like the way Cloudflare does things they’re not the only CDN around, but some of the privacy issue is moot when running a public service.

crowdsec has always struck me as a really odd approach to security. You give out your logs to strangers and block IPs based on their say-so.

The cause and effect are so far removed that I can’t wrap my head about how it’s supposed to be efficient. It’s been proven in real-world tests that it lags badly behind the first waves of new vulnerabilities and by the time it starts blocking IPs that were related to those attacks the attackers have moved on and there are also patches available.

The “thousands of IPs blocked” image reminds me of that WWII airplane bullet-holes image.

It’s popular because it works. You don’t get a lot of choice in the NVR area, most of the other projects are kind of ass too.

I also don’t think many people care about the security that much. Either that or they run the container like I do in a VLAN with the cameras. Honestly, if it wasn’t for the obscene amounts of RAM, CPU and storage it wastes for no good reason I wouldn’t care that much about the security either.

hoe come the developers are not improving the image?

Lots of developers are clueless about Docker. They are used to running their stuff on the metal and piling everything together and they don’t even consider they should clean things up before they ship a docker image.

Gramps Web for example is another humongous image, and it’s humongous because apparently the developer can’t be arsed to separate the building stage from the production stage in their Dockerfile, so they’re shipping all the build toolchains. People have pointed this out to them and they’re like “eh whatever”.

This camera (Reolink E330) doesn’t have HTTP (80 or 443), just RTSP (554), ONVIF (8000) and the proprietary interface that their own app uses (9000).

Yeah Frigate devs claim it can’t be done, but it works in other projects like Shinobi.

They don’t need to be actual users. When they’re trying to start Tailscale on a new device have them pass the authorization link to you and open it on your account. This way their devices are registered as devices for your user. You can tag the devices and write ACLs for them to determine what they can access.

I’ve tried LazyNVR but I couldn’t figure out how to make it work with my cameras. There seem to be no real instructions. I don’t even get how it’s supposed to find the cameras, there’s no place to put an IP.

The Frigate docker image is generally nasty. It’s huge (5.5 GB), bundles and runs a ton of different things whether you use them or not, uses s6 as init and supervisor which is a piece of crap, and it cannot be secured – it won’t run as a non-privileged user, it won’t drop caps, you can’t make it read-only because some genius configured nginx to put temporary files in with the app files, it conveniently includes apt so the attacker can install anything they might want inside the container, and in fact recommends running in privileged mode(!).

I think it’s the most security-hostile docker image I have ever seen.

If you ask AI to do all the work, including the smallest little things, I imagine you can burn through a lot of tokens very quickly.

I want to have a device (the server) present in multiple networks (and multiple different firewall zones) at the same time. I was given to understand I need tagged VLANs for this.

I think Pangolin would be massively overkill for this. It’s designed to be a CDN layer orchestrator and it’s primarily a HTTP reverse proxy. You can do it with Pangolin but it complicates things and you’d need more resources too.

All you really need on the VPS is to run a tunnel (WG or OpenVPN) and forward whatever ports the games need from the VPS public IP into the tunnel. Maybe a DDNS tool/script if the public IP is dynamic.

According to its Github page seems to be a container-oriented Linux distro, like Flatcar / Fedore CoreOS / Talos Linux.

The linked website is AI-generated so ofc it doesn’t say anything useful up front.

It’s fairly safe as long as you add a strong enough form of access control. For example if you put it behind a VPN, or a SSH tunnel, or require mTLS. Even a key in a custom HTTP header or Basic HTTP auth can be good enough if the key is strong enough.

You can further decrease the probability of drive-by bots reaching a publicly exposed service by merely scanning IPs and ports if you use a reverse proxy and hide your service FQDNs and IP.

You can do this by using TLS certs on wildcard domains rather than explicit domains, using explicit CNAMEs for the service subdomains rather than a wildcard domain, and keeping the A/AAAA records on an obfuscated subdomain rather than the base domain. If the bots can’t figure out a FQDN they’re not getting past the reverse proxy even if they find the IP and port.

This is obfuscation not real security but it cuts down tremendously on bot hits.

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