• 1 Post
  • 14 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle







  • Will I still need to consider multicast DNS if my DNS server is on-prem (Pi-Hole + Unbound)

    Multicast DNS is separate from DNS, so even if you have Pi-Hole, you’d still have devices using mDNS. It’s possible to route mDNS across separate IP networks seeing as how there’s mDNS relays across VLANs which would suggest Wireguard could support Multicast. Other things use Broadcast (e.g. WoL) which is a bit more challenging to forward across IP networks.

    I’m not familiar with GRE so I couldn’t comment on whether it’s possible or not. I guess it all depends on how confident you are with your networking skills. If you get it working, you should definitely document it and share with others.

    I didn’t quite do what you did, but I ran HA in a Kubernetes cluster which was logically a separate IP network. I had to setup the container with multiple network interfaces and specially craft the route table to forward broadcasts + multicast traffic to the correct network.






  • If I create a secondary config as you are suggesting, wouldn’t it create a conflict with the server blocks of default.conf

    No, you can have multiple server blocks with the same listen directive. They just need to differ by their server_name and only one server block can contain default_server; Reference

    NGINX will use the server_name directives to differentiate the different backend services. This is a class virtual host configuration model.


  • chaospatterns@lemmy.worldtoSelfhosted@lemmy.worldDefeated by NGINX
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 year ago

    There was an uncaught exception to boot gunicorn workers

    That’s odd that it didn’t cause the Docker container to immediately exit.

    What now? So now that it looks like everything is working. What is the best practice for the nginx.conf? Leave it all in /etc/nginx/nginx.conf (with user as root), reestablish the out box nginx.conf and /etc/nginx/conf.d/default.conf

    My suggestion would be to create /etc/nginx/conf.d/mycooldjangoapp.conf. Compared to conf.d/default.conf, this is more intuitive if you start hosting multiple apps. Keep it out of the nginx.conf because apt-get or other package managers will usually patch that with new version changes and again it gets confusing if you have multiple apps.