Nginx

Nos, az nginx is felkerült az "én sosem akartam ezzel a szoftverrel foglalkozni, de tényleg" listára. Történet:

2020. augusztus 10.

Elindítottam egy gépen egy nginx-et:

[ec2-user@ip-10-84-140-12 ~]$ ps aux |egrep "nginx\:\ master"
root      3713  0.0  0.0 125616 12124 ?        Ss   Aug10   0:00 nginx: master process /usr/sbin/nginx

2020. augusztus 17.

Írtam egy ilyen nginx konfigot:

[ec2-user@ip-10-84-140-12 ~]$ ls -l /etc/nginx/sites/revproxy.conf
-rw-r--r-- 1 root root 312 Aug 17 12:00 /etc/nginx/sites/revproxy.conf
[ec2-user@ip-10-84-140-12 ~]$ cat /etc/nginx/sites/revproxy.conf
server {
  listen 127.0.0.2:443 ssl;
  server_name egyik-tokmindegy.az;
  ssl_certificate_key /etc/nginx/certs/egyik-tokmindegy.az.key;
  ssl_certificate /etc/nginx/certs/egyik-tokmindegy.az.pem;

  location / {
    proxy_pass https://masik-tokmindegy.az;
    proxy_ssl_server_name on;
  }
}

Faék egyszerűségű reverse proxy. Nincs benne semmi extra látnivaló.

2020. augusztus 18.

Reload-oltam az nginx konfigját:

[ec2-user@ip-10-84-140-12 nginx]$ ps aux |egrep "nginx\:\ (master|worker)"
root      3713  0.0  0.0 125564 11988 ?        Ss   Aug10   0:00 nginx: master process /usr/sbin/nginx
ec2-user 16375  0.0  0.0 125632  9636 ?        S    Aug18  13:12 nginx: worker process
ec2-user 16376  0.0  0.0 125568  9260 ?        S    Aug18   0:13 nginx: worker process
ec2-user 16377  0.0  0.0 125568  7576 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16378  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16379  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16380  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16381  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16382  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process

Innentől élt a reverse proxy, boldogan használta mindenki.

2020. szeptember 3.

(Mindegy, hogy miért, nincs köze a problémához) módosítottam a masik-tokmindegy.az DNS bejegyzéseit, töröltem a hozzá tartozó AAAA rekordokat (hogy ne lehessen IPv6-on elérni).

2020. szeptember 17.

Elmúlik a reverse proxy boldog használata, a következő hibaüzenettel:

2020/09/17 15:39:49 [error] 16375#0: *2899915 connect() to [3a03:26f0:fb::5e62:9958]:443 failed (101: Network is unreachable) while connecting to upstream, client: 127.0.0.1, server: egyik-tokmindegy.az, request: "GET /x.jpg HTTP/1.0", upstream: "https://[3a03:26f0:fb::5e62:9958]:443/x.jpg", host: "egyik-tokmindegy.az"

Na, mi lehet a hiba oka? (Átírtam pár karaktert az IPv6-os IP-címben a logüzenetben, de a hiba nem ez.)

 

Hát persze, hogy az nginx a teljes FQDN-ként megadott proxy_pass direktívát restartkor, illetve reloadkor pontosan egyszer megpróbálja feloldani, és onnantól a következő restarting/reloadig a feloldott IP-ket cache-eli. A DNS TTL meg smafu. Meg az IP-cím váltás a target hoston is.

Ez nagyon béna.

Ráadásul a workaroundok (legyen egy változóként megadva az FQDN a proxy_pass-nak) is bénák, ugyanis csak akkor működnek, ha expliciten megadok resolver-t a konfigban, akkor viszont a /etc/hosts-ot nem használja az nginx a névfeloldásra, nekem meg az is kellene.

Ez nagyon-nagyon béna.

 

Na mindegy, régen írtam ide, csak ki akartam próbálni igazából az új editor, de nem tetszik :-)

Hozzászólások

Szerkesztve: 2020. 09. 17., cs - 20:40

resolver 8.8.8.8 ipv6=off; 

a "/" lokacioba

Maskent nem valoszinu, hogy menni fog.

 

Edit: lokalisan egy dnsmasq megoldhatja a problemaidat.

Error: nmcli terminated by signal Félbeszakítás (2)

Szerkesztve: 2020. 09. 18., p - 03:00

törölve :)

// Happy debugging, suckers
#define true (rand() > 10)

nem nagy ügy. /etc/nginx/resolver.conf -ot update-elje ugyanaz a mechanizmus mint az /etc/resolv.conf -ot. ha az /etc/hosts is kell, akkor szerintem is a dnsmasq a nyerő.

Nyilván csináltam rá workaroundot, az igazi bajom két másik dologgal van. Az egyik, hogy ez a működés borzasztóan nem intuitív. A másik, hogy ez a működés nem jól dokumentált, minimum nagybetűs piros villogó feliratot várnék az nginx doksijában, ha ennyire eltérnek attól, ami logikusnak tűnik.

el van dugva a doksiban, ezt aláírom. 

szerintem azért nem tulajdonítottak neki nagy jelentőséget, mert javarészt olyan "házon belüli" reverse proxy-zársa szánták, ahol nem jellemző a ip váltás, meg a performanszra nagyon rá vannak tapadva, úgyhogy meg vannak spórolva a dns query-k.

ami engem jobban bánt az az hogy ha (re)startkor nem tudja feloldani a nevet akkor nem késlelteti azt az egyszeri névfeloldást hanem elszáll mintha invalid lenne a config.

bebaszna ha minden ttl lejartakor egy adag* dns kerest inditana. bar valoban nincs jol doksizva, de a static/dynamic feloldasra is van _egyszeru_ megoldas.

* ugye otthoni szervernel ahol 1 req/sec a speed, nemgond. de amikor beesik 10msec alatt X keres, es pont lejar a ttl, akkor kenytelen mindegyik dns resolvolni, amig vegre a dns megadja a valaszt.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

En ebben nem latom a problemat. A programok nagy resze igy mukodik, a DNS lekeresek eredmenyei altalaban halalra vannak cachelve. Raadasul a DNS lekeres akar koltseges is lehet, jobb ez igy.

Ha nagyon kell a hosts fajl alapu megoldas, akkor ahogy fentebb is javasoltak, a dnsmasq kepes ezt az elmenyt nyujtani, illetve a systemd-resolved is kezeli a DNS resolvingot + hosts file, szoval ha amugy systemd alapu a rendszer, konfigurald be, hogy resolver 127.0.0.53 es koszonjuk. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Én azért tudok olyat, amikor a forever cache az default.

https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/d…

networkaddress.cache.ttl (default: see below)
Value is an integer corresponding to the number of seconds successful name lookups will be kept in the cache. A value of -1, or any other negative value for that matter, indicates a “cache forever” policy, while a value of 0 (zero) means no caching. The default value is -1 (forever) if a security manager is installed, and implementation-specific when no security manager is installed.

 

Tudom, ez ritka dolog, kevesen használnak JVM-et security managerrel, de jó tudni erről.

Egynek ügyes, de ha már default, akkor az is default, hogy a security manager ki van kapcsolva. Akkor meg undef, hogy mi történik: "The default value is -1 (forever) if a security manager is installed, and implementation-specific when no security manager is installed."

De legyen ez 1, a JVM, bizonyos körülmények között.

És azért van itt más is: ha már DNS lookup, akkor Java EE-ben szépen ezt JNDI-jal illik csinálni.

És például az IBM WebSphere esetén a JDNI lookupok cache-ltek.

Az alapértelmezett beállítás szerint végtelen ideig:

https://www.ibm.com/support/knowledgecenter/SS7K4U_8.5.5/com.ibm.websph…

Igen.

Van az a dolog, hogy az IT 99%-át úgy tolom, hogy tudom, hogy hogy kéne működnie a dolgoknak általában, és feltételezem, hogy a szoftverek fejlesztői nem hülyék, és pont úgy csinálták meg a szoftverüket, ahogy általában működniük kellene, illetve ha ettől eltértek, akkor azt nagy, piros, aláhúzott, villogó betűkkel dokumentálják, hogy "heló, ez nem úgy fog működni, ahogy arra számítanál". Itt az nginx-eseknek egyiket se sikerült megcsinálniuk, ezért nem szeretem őket.

A komplett .NET platform bugos alapbeállításban:

https://github.com/dotnet/runtime/issues/23652

https://github.com/dotnet/runtime/issues/18348

A megoldás ennek a propertynek az átállítása a defaultról:

https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepoint.con…

ez azért kicsit sántít, az iptables feloldja, átdobja az ip-ket a kernelnek és kilép. tehát nem használja újra ttl idő lejárta után az ip-t, mivel akkorra már kilépett. az meg hogy a kernel nem veszi figyelembe a ttl-t az nyilvánvaló mertmivelhogy nem dns névvel dolgozik hanem ip-vel, a dns információ elveszlik az userspace-kernelspace közt.