Interesting solution! Thanks for the info. Seems like Nginx Proxy Manager doesn’t support Proxy Protocol. Lmao, the world seems to be constantly pushing me towards Traefik all the time 🤣
Interesting solution! Thanks for the info. Seems like Nginx Proxy Manager doesn’t support Proxy Protocol. Lmao, the world seems to be constantly pushing me towards Traefik all the time 🤣
I think there was some bad vibes when they got bought by a less than reputable company a while back. I know a lot of people, myself included switched to Mullvad. I am on Proton now though for the port forwarding.
I see. And the rest of your services are all exposed on localhost? Hmm, darn, it really looks like there’s no way to use user-defined networks.
I am guessing you’re not running Caddy itself in a container? Otherwise you’ll run into the same real IP issue.
I see! So I am assuming you had to configure Nginx specifically to support this? Problem is I love using Nginx Proxy Manager and I am not sure how to change that to use socket activation. Thanks for the info though!
Man, I often wonder whether I should ditch docker-compose. Problem is there’s just so many compose files out there and its super convenient to use those instead of converting them into systemd unit files every time.
Yeah, I thought about exposing ports on localhost for all my services just to get around this issue as well, but I lose the network separation, which I find incredibly useful. Thanks for chiming in though!
Pasta is the default, so I am already using it. It seems like for bridge networks, rootlesskit is always used alongside pasta and that’s the source of the problem.
All of this is still irrelevant. If given the same hardware, one OS performs better than another, then one OS is obviously more optimized…
You’re saying a lot of words but it all just boils down to “throw more hardware at the problem”.
How is this relevant? If an OS performs better on old hardware, it’s still an indication that it is more optimized.
Oh come on, that camera bar sticks out so much. I am so tired of this design gimmick. Every Pixel phone with a case already looks ridiculously thick just so that the stupid bar is protected. With how thick it looks on the Pixel 9, the whole phone is just going to be a chonker by the time someone slaps a case on it.
All this coming at a time when my perfectly fine Pixel 5 just got EOLed is demoralizing.
Man, I have GOT to try Truenas Scale one of these days. I see it recommended so often, but I was just too used to a standard Linux ecosystem to bother learning something new. I am assuming it gets you closer to the feel of a pre-built NAS during administration tasks compared to Cockpit and a SSH session lmao.
I think I am just always afraid of being locked into a specific way of doing things by a vendor. I feel like I would get annoyed if something that I could do easily on standard Linux was harder to do on Truenas Scale.
I have zero trust in QNAP. QNAP knowingly sold several NASes with a known clock-drift defect in their Intel J1900 CPUs and then refused to provide any support. A bunch of community members had to figure out how to solder a resistor to temporarily revive their bricked NASes in order to retrieve their data. https://forum.qnap.com/viewtopic.php?t=135089
I had a TS-453 Pro and my friend had a TS-451. Both mine and his exhibited this issue and refused to boot. After this debacle and the extreme apathy from their support, I vowed to never buy a pre-built NAS.
You shouldn’t trust ANY brand’s pre-installed OS when it comes to your personal data to be honest.
The preloaded spyware OS
Nowhere in that video did it say this. I am all for DIY NAS and I have an Arch-based one at home, but saying this while implying that that’s what the source video you linked said is a bit disingenuous.
To be honest, nothing about this UGREEN is any different from any of the other off-the-shelf NAS solutions out there like QNAP, Synology, etc. If you don’t trust the UGREEN pre-installed OS, you shouldn’t trust any of the other ones either. I am not saying you should, but my point is that this pretty par for the course as far as pre-built NASes go.
Most companies do not provide support if you install a custom OS. That isn’t a sign of vendor lock-in, just a matter of keeping support feasible in the long-term, especially since they’re relatively new at this. If you want a custom OS, it is far easier and cheaper to just build your own.
My main issue with it is that it is way too thick. Most lopsided camera bumps somehow are more compact and thinner. You’d think with the amount of real estate that visor takes up they’d be able to make it flush with the rest of the back somehow, or at least match the thickness of phone cameras
I really wish they’d ditch that stupid camera bar. Every phone case attempts to hide it and it just makes the whole thing needlessly thick.
I use podman with the podman-docker compatibility layer and native docker-compose. Podman + podman-docker is a drop-in replacement for actual docker. You can run all the regular docker commands and it will work. If you run it as rootful, it behaves in exactly the same way. Docker-compose will work right on top of it.
I prefer this over native Docker because I get the best of both worlds. All the tutorials and guides for Docker work just fine, but at the same time I can explore Podman’s rootless containers. Plus I enjoy it’s integration with Cockpit.
Cockpit definitely has the ability to create bridge devices. I haven’t found a tutorial specifically for cockpit, but you can follow something like this and apply the same principles to the “Add Bridge” dialog in Cockpit’s network settings.
Your containers show up in Cockpit under the “Podman containers” section and you can view logs, type commands into their consoles, etc. You can even start up containers, manage images, etc.
Are there any tutorials on how to do this from Cockpit?
I have not done this personally, but I would assume you need to create a bridge device in Network Manager or via Cockpit and then tell your VM to use that. Keep in mind, bridge devices only work over Ethernet.
Yeah, it’s amazing how upvoted the previous comment is. Just a bunch of idiots jumping on the web-hate bandwagon when even basic media players like Kodi have a tough time playing back video on the Pi.
It just isn’t a very optimized device for video playback. The Pi 5 is actually a step backwards as well, providing only H265 hardware video decode which the web doesn’t even use.