Chances are you couldn’t use CGNAT for self-hosting, so you’d be out to an actual IP address that’s forwarding the traffic via something like Cloudflared, but your point stands.
Chances are you couldn’t use CGNAT for self-hosting, so you’d be out to an actual IP address that’s forwarding the traffic via something like Cloudflared, but your point stands.
So I have it running on about 20 phones for customers of mine that use Blue Iris with it. But these are all Apple devices, I’m the only one with Android. I’ve never had a complaint except one person that couldn’t get on at all, and we found that for some reason the Blue Iris app was blacklisted in the network settings from using the VPN. But that’s the closest I’ve seen to your problem.
I wonder if you set up a ping every 15 seconds from the device to the server if that would keep the tunnel active and prevent the disconnect. I don’t think tailscale has a keepalive function like a wireguard connection. If that’s too much of a pain, you might want to just implement Wireguard yourself since you can set a KeepAlive value and the tunnel won’t go idle. Tailscale is probably wanting to reduce their overhead so they don’t include a keepalive.
Tailscale is completely transparent on any devices I’ve used it on. Install, set up, and never look at it again because unless it gets turned off, it’s always on.
So I started out with a bugreport to BoxBuddy because that’s where I first found it. Then they said it was just running a distrobox create --clone yaddayadda
so I then went to distrobox issues. Then when I tried it in a dualboot on that same machine of Fedora 41 and it worked, I went searching for the Aurora issues tracker with no luck, and then I got on with my life.
I’m curious enough, but this seemed like it was going to be hard to track down a way to fix it, and I needed that laptop working for other things, and Aurora was being really flakey in other ways as well so I just nuked it.
I’m happy to burn time debugging an issue for a project, but when I tried to track down a way to bugreport to Aurora, I didn’t find anything easily. And this promised to turn into a fingerpointing issue, so I moved on.
I’m well aware of how inline environment variables work, but that is one helldammer of a name for one, and I rarely see anyone use actual spaces in .env file variable, let alone translate a space to SPACE
in a variable name.
It’s about predictable troubleshooting for a bug, not about whether you can install it. No doubt you can, but now the dev has to figure out what particular feature in your OS is causing the issue.
I had this recently, installed Distrobox, which is just a set of scripts, on Aurora. Could not --clone a container, no how. Blow the OS out and install Fedora 41 which is what Aurora is derived from except it’s rpm-ostree, and not a problem cloning a Distrobox. Closed the bug as there was no point trying to figure out what went on there for some weird edge case of using a specific distro.
I had some numpty telling me that installing an application on whatever dog’s breakfast distro someone happened to put on an LXC was functionally the same as a shipped docker container for troubleshooting.
Those are quite the environment variable names there.
I’ve been using a wildcard accept rule on my main domain, and every once in a while one of the made up addresses gets out of hand, I just go in and blackhole it on my email server. I then send a nasty email to the admin of whoever got hacked or sold the address (sending from another bullshit address), as I use unique addresses per signup and keep track of them in my password manager. It seems to have kept my inbox fairly clean since anything to those addresses goes into a side folder.
Been doing it for 20 years, seems like a good strategy so far.
I’ve been self-hosting email for so long (and ran/consulted on corporate email systems for a long time), I’m pretty sure my original domain (25 years) lends it’s respectability to new domains I host at the same address. The hell of it is I host on a resi IP address and have never had a single blacklist event. I don’t even know how that’s possible other than the fact that I’ve done it for so long with no incidents that I think I’m on a whitelist or something.
If you think running some curl-bash script against whatever mess someone has set up in an LXC or other one-off install is functionally the same than CIing a known distro and version and making an image that people then can use and bug report against, then I don’t see that this conversation is going anywhere.
A dockerfile has a bunch of built-in functionality that’s way easier than running scripts, and very amenable to CI. Its a standardized way of building repeatable and troubleshootable environments which is nothing you’d get in a one-off LXC, so developers love it.
I didn’t like docker for the longest time, installed everything on VMs and LXCs manually with Ansible, and when I did get looking into containers I realized how utterly wrongheaded I had been, especially when it came to deploying a solution I could trust behaves consistently.
And did you just downvote my comment because I dared disagree with you like pretty much the entire development community does? If so, that’s pathetic and weird.
I get how momentum keeps you on a path, and he admits that he’d rather use OPNsense in the wiki, but dammit, now he’s got a bunch of other people going down the same pfSense road to the rugpull. And man, Wireguard is so much less confusing and difficult than OpenVPN, but because of the drama the pfSense weirdos made with Donnenfeld over the kernel patches for WG, there’s precious little support for WG in the pfSense environment. Wireguard is definitely more noob friendly.
And if you’re watching this because you need this level of help to selfhost, you definitely should not be hosting email yourself. Love Mailcow, used it for years, but I’m a veteran of the spam wars from way back and know how to deal with the current landscape. He is too, so he should know better.
The issue with LXC is that it doesn’t set the software up for you. You’re pretty much in the same situation as a VM or bare metal, you have to figure out how to install it or use scripts/Ansible to do it. A docker is a distribution method for the software, not the operating system. I know there’s things that you can do to ship a configured LXC, but that’s never gained traction.
So docker is far and away the easiest choice for developers looking to get their software used in a predictable manner.
I’d bet on racoons or some primate. They aren’t going to get far though until there’s enough continental subduction to reveal fresh metal and fossil fuel deposits, and that could take a very, very long time.
I love me some opensource applications, but nothing compares to Blue Iris in the software NVR space. It isn’t as much as a halfway decent camera, and if you don’t renew it after one year, you just lose access to updates, and you can catch up if you renew before that major version goes away. I run BI on a Dockur Windows container on a Linux server, and use Deepstack in another container to supply the AI object recognition to BI, it’s much lighter weight than the included Code Project AI they ship with it.
As for cameras, you want something that specifically says they’re ONVIF capable. Everything else will be some shitty chinese spyware you have to install. And get wired cameras that have 802.11af/at specced POE. There’s a lot of trash out there that says it’s POE and it’s some bastardized thing that’s not compatible with most POE switch voltages.
This is the way.