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

help-circle


  • Computer algorithms solve problems all over the world for companies already. I bet airlines already have teams of people using computer algorithms to figure crew management, flight routing, cost optimization, etc.

    The fact that they’re exploring quantum computers and non-classical algorithms just suggests that gate allocation is NP-Hard. Sure things go wrong when computers fail already, Look at Southwest or Delta’s recent meltdown, but to act like this a bad thing is just nonsense. This should be looked at as a good thing that airlines are working on.


  • Why do you think this is going to replace air traffic control work? It’s picking which gate to park the plane at. This was done by airline and airport operations teams, not ATC. Imagine if you could automatically pick gates to reduce the time a plane spends taxiing and/or minimize time passengers spend walking. That’s 100% a useful application for computer optimization algorithms. Humans aren’t going to do that better and it’s not a function of safety that tower or ground control needs to do.




  • There’s two main ways of doing geo-based load balancing:

    1. IP Any-casting - In this case, an IP address is “homed” in multiple spots and through the magic of IP routing, it arrives at the nearest location. This is exactly how 1.1.1.1 and 8.8.8.8 work. It works fine for stateless packets like DNS, however it has some risks for stateful traffic like HTTP.
    2. DNS based load balancing. A server receives a request for “google.com”, looks at the IP of the DNS server and/or the EDNS Client IP in the DNS query packet and returns an IP that’s near. The problem is that when you’re doing Wireguard, it goes phone -> pi-hole (source IP is some internal IP) -> the next hop (e.g. 1.1.1.1 or 8.8.8.8), which sees the packet is coming from your home/pi-hole’s public IP. Thus it gets confused and thinks you’re in a different location than you really are. Neither of these hops really knows your true location of your phone/mobile device.

    Of course, this doesn’t matter for companies that only have one data center.


  • Sorry, what do you mean route it directly? Maybe I didn’t clarify well enough.

    My DNS is routed over the VPN but Internet traffic is routed directly. The problem is the load balancing is done based on where the DNS server is so say Google even though the traffic egresses directly to the internet bypassing the VPN it still goes to a Google DC near my home. Not all websites do this so its not always an issue.



  • I have Wireguard and I forward DNS and my internal traffic from my phone over the VPN to my pi-hole at home. All other traffic goes directly over the Internet, not the VPN. So that means only DNS encounters higher latency.

    However, because a lot of companies do DNS based geo load balancing that means even if I’m on the east coast all my traffic gets sent to the West Coast because my DNS server is located there. That right there has the biggest impact on latency.

    It’s tolerable on the same continent, but once I start getting into other continents then it gets a bit slow.










  • It’s not generally a hardware problem. It’s a resourcing problem. Companies like GitHub will have complex software and architecture. IPv6 requires them to get a pool of IP addresses, come up with an IP address management strategy, make sure all hosts have IPv6 addresses meaning that now provisioning systems and tooling to management DNS has to plumb IPv6 addresses through too.

    Then the software stack has to support it. Maybe their fraud detection or auditing systems have to now support IPv6 which means changes to API schemas.

    None of this is a good reason why they shouldn’t do it, but I’ve had to make similar decisions at my job as a software engineer on what looks to be simple but actually requires changes across systems.


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