

the whole point of privacy extensions is that it replaces the MAC with a random something. the address is totally unrelated to the MAC
the whole point of privacy extensions is that it replaces the MAC with a random something. the address is totally unrelated to the MAC
if that’s true, I assume it is because they don’t know about the security consequences, nor about more secure ways. and for 99% that is the worst solution, because they won’t tighten security with a read only filesystem, DMZ and whatnot, worse, they won’t be patching their systems on schedule, but maybe in a year.
99% users should not expose any public services other than wireguard or something based on it. on a VPS the risk my be lower, but on a home network, hell no!
all of these run the database in a separate container, not inside the app container. the latter would be hard to fix, but the first is just that way to make documentation easier, to be able to give you a single compose file that is also functional in itself. none of them use their own builds of the database server (though lemmy with its postgres variant may be a bit of an outlier), so they are relatively easy to configure for an existing db server.
all I do in cases like this is look up the database initialization command (in the docker compose file), run that in my primary postgres container, create a new docker network and attach it to the postgres stack and the new app’s stack (stack: the container composition defindd by the docker compose file). and then I tell the app container, usually through envvars or command line parameters embedded in the compose file, that the database server is at xy hostname, and docker’s internal DNS server will know that for xy hostname it should return the IP address of the container that is named xy, through the appropriate docker network. and also the user and pass for connection. from then, from the app’s point of view, my database server in that other container is just like a dedicated physical postgres machine you put on the network with its own cable going to a switch.
unless very special circumstances, where the app needs a custom build of postgres, they can share a single instance just fine. but in that case you would have to run 2 postgres instances even without docker, or migrate to the modified postgres, which is an option with docker too.
I have very rarely ran into such issues. can you give an example of something that works like that? it sounds to be very half-assed by the developer. only pihole comes to mind right now (except for the db part, because I think it uses sqlite)
edit: I now see your examples
It’s not like it’s so hard to rebuild a container for the occasional services that needs it. but it’s still much better than needing to do it with every single service
most people want computers to be unnoticable and boring. I agree, we need more boring tech
professional UI designers don’t seem to agree. they always feel the urge to come up with the next worst design
my last experience with it was a half empty documentation, and a config structure that signaled to me that they dropped a lot of features for v2 release that they initially wanted to have, which has additionally made understanding their config structure harder. and that hasn’t improved for years.
The funnel exposes your local services to the public over https . Like what you want to accomplish with reverse proxy .
they did not say they want it public, and that’s an additional security burden they may not need
if you don’t want to rent a domain, but you run a local DNS server (pihole, technitium) for filtering or other reasons, you can register your own domain names in there, for free. but don’t use common TLDs to avoid conflicts, and leave “.local” alone too because that’s used by mdns/avahi. You may use .home, .lan, or a few others I don’t know without looking them up
tailscale is not the same as nginx or any reverse proxy, though. I don’t expose anything publicly, but I still wouldn’t stop using a reverse proxy
8 GB RAM or more. OS installed either to SSD, or a HDD that does not store service data (for performance). a modern CPU with at least 4 cores. modern means it has at least AES and AVX2 instruction sets to do math quickly, but probably you can just pick one made in the last 10 years, with less years generally meaning better energy efficiency.
what kind of services do you want to host on it? initial plans, perhaps longer term plans?
until a new high severity vulnerability gets discovered and some bot exploits it on your server, taking it over. and you won’t even know. if they were a bit smart, you won’t notice it ever either.
but there’s more! its not only the reverse proxy that can be exploited! over the past few years, jellyfin has patched a dozen vulnerabilities, some of which allowed execution of arbitrary system commands. one of the maintainers have expressed that nobody should be running those old versions anymore, because they are not safe even only on the LAN. and this was just jellyfin.