• 0 Posts
  • 12 Comments
Joined 2 years ago
cake
Cake day: July 11th, 2023

help-circle
  • Opening a port doesn’t mean you are opening your whole home network just the specific services you want.

    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.



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







  • 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