From dcardon at tranquil.it Mon Dec 2 09:55:09 2019 From: dcardon at tranquil.it (Denis Cardon) Date: Mon, 2 Dec 2019 10:55:09 +0100 Subject: ssl_client_fingerprint and sha256 Message-ID: <3d65fe2c-f92f-d71d-63de-913e8a610d48@tranquil.it> Hi everyone, this is my first post on this mailing list, so bear with me :-) Sorry if my question is silly, but I haven't found any way to use a sha256 fingerprint for client certificate validation in Nginx. Sha1 fingerprints work fine but we are slowly going toward sha256 as hashing function by default. The ngx_http_ssl_module documentation explicitly specify only sha1 [1]. I have seen in the Trac that there is a issue open about that [2]. Perhaps there a good reason for not having it currently. I'll be glad to hear from you all. We are using ssl client auth for WAPT project [3] which automates Windows workstation software install and update. Cheers, Denis [1] http://nginx.org/en/docs/http/ngx_http_ssl_module.html [2] https://trac.nginx.org/nginx/ticket/1302 [3] https://doc.wapt.fr -- Denis Cardon Tranquil IT 12 avenue Jules Verne (Bat. A) 44230 Saint S?bastien sur Loire (FRANCE) tel : +33 (0) 240 975 755 http://www.tranquil.it Tranquil IT recrute! https://www.tranquil.it/nous-rejoindre/ Samba install wiki for Frenchies : https://dev.tranquil.it WAPT, software deployment made easy : https://wapt.fr From mdounin at mdounin.ru Mon Dec 2 14:40:07 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 2 Dec 2019 17:40:07 +0300 Subject: ssl_client_fingerprint and sha256 In-Reply-To: <3d65fe2c-f92f-d71d-63de-913e8a610d48@tranquil.it> References: <3d65fe2c-f92f-d71d-63de-913e8a610d48@tranquil.it> Message-ID: <20191202144007.GU12894@mdounin.ru> Hello! On Mon, Dec 02, 2019 at 10:55:09AM +0100, Denis Cardon wrote: > Hi everyone, > > this is my first post on this mailing list, so bear with me :-) > > Sorry if my question is silly, but I haven't found any way to use a > sha256 fingerprint for client certificate validation in Nginx. Sha1 > fingerprints work fine but we are slowly going toward sha256 as hashing > function by default. The ngx_http_ssl_module documentation explicitly > specify only sha1 [1]. > > I have seen in the Trac that there is a issue open about that [2]. > Perhaps there a good reason for not having it currently. I'll be glad to > hear from you all. We are using ssl client auth for WAPT project [3] > which automates Windows workstation software install and update. The $ssl_client_fingerprint variable represents a fingerprint of a certificate which is already verified based on trusted CA certificates listed in the ssl_client_certificate directive. As such, from security point of view using SHA-1 hash function shouldn't be a problem, as it merely identifies one of the certificates previously signed (and validated). If you are trying to use $ssl_client_fingerprint literally "for client certificate validation", you are probably doing it wrong. In some setups it might be more convenient to use SHA-256 instead of SHA-1, though for now we haven't seen such requests. -- Maxim Dounin http://mdounin.ru/ From dcardon at tranquil.it Mon Dec 2 15:44:52 2019 From: dcardon at tranquil.it (Denis Cardon) Date: Mon, 2 Dec 2019 16:44:52 +0100 Subject: ssl_client_fingerprint and sha256 In-Reply-To: <20191202144007.GU12894@mdounin.ru> References: <3d65fe2c-f92f-d71d-63de-913e8a610d48@tranquil.it> <20191202144007.GU12894@mdounin.ru> Message-ID: <4e74c12d-3e06-6135-93bb-fe8eae82e866@tranquil.it> Priviet! > > On Mon, Dec 02, 2019 at 10:55:09AM +0100, Denis Cardon wrote: > >> Hi everyone, >> >> this is my first post on this mailing list, so bear with me :-) >> >> Sorry if my question is silly, but I haven't found any way to use a >> sha256 fingerprint for client certificate validation in Nginx. Sha1 >> fingerprints work fine but we are slowly going toward sha256 as hashing >> function by default. The ngx_http_ssl_module documentation explicitly >> specify only sha1 [1]. >> >> I have seen in the Trac that there is a issue open about that [2]. >> Perhaps there a good reason for not having it currently. I'll be glad to >> hear from you all. We are using ssl client auth for WAPT project [3] >> which automates Windows workstation software install and update. > > The $ssl_client_fingerprint variable represents a fingerprint of > a certificate which is already verified based on trusted CA > certificates listed in the ssl_client_certificate directive. As > such, from security point of view using SHA-1 hash function > shouldn't be a problem, as it merely identifies one of the > certificates previously signed (and validated). > > If you are trying to use $ssl_client_fingerprint literally "for > client certificate validation", you are probably doing it wrong. > > In some setups it might be more convenient to use SHA-256 instead > of SHA-1, though for now we haven't seen such requests. Actually it is the last case : it is more for convenience of not storing both SHA-1 and SHA-256 fingerprints on the server... As you say it is not a security issue, but when having security audit (we will have to renew our CSPN [1] certification on WAPT next year), one has to explain why using older cryptography is not an issue in the specific use case. So we will just do the explanation. Spasibo a lot for your explanations! Denis [1] https://www.ssi.gouv.fr/en/security-visa/ -- Denis Cardon Tranquil IT 12 avenue Jules Verne (Bat. A) 44230 Saint S?bastien sur Loire (FRANCE) tel : +33 (0) 240 975 755 http://www.tranquil.it Tranquil IT recrute! https://www.tranquil.it/nous-rejoindre/ Samba install wiki for Frenchies : https://dev.tranquil.it WAPT, software deployment made easy : https://wapt.fr From nginx-forum at forum.nginx.org Tue Dec 3 09:48:23 2019 From: nginx-forum at forum.nginx.org (jacks) Date: Tue, 03 Dec 2019 04:48:23 -0500 Subject: proxy_pass in post_action location does not send any http request Message-ID: Hi I am trying to configure NGINX to send another http request after successful completion of the original proxied request, in order to count statistics etc' I am using post_action with proxy_pass as following: location / { proxy_http_version 1.1; proxy_set_header HOST $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port 1061; proxy_set_header X-Forwarded-Host $host:1061; proxy_set_header X-Forwarded-Server $host:1061; proxy_read_timeout 86400; proxy_max_temp_file_size 0; proxy_set_header Connection ""; set $backend rack-storage-radosgw:8802; proxy_pass http://$backend; post_action /send_event; } location /send_event { proxy_method POST; set $s3_proxy_request s3-proxy-manager:8946/internal/api/v3/s3proxies/actions/raise_event; proxy_pass http://$s3_proxy_request; } The request in location / is sent to rack-storage-radosgw.service.strato and is completed successfully, but the request to s3-proxy-manager is not sent at all. I used tcpdump to capture any traffic on port 8946 and no traffic arrived. I also checked that send_event location is entered by code, and it does ( using rewrite_by_lua_block). What am i doing wrong? Thanks Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286384,286384#msg-286384 From nginx-forum at forum.nginx.org Tue Dec 3 10:28:32 2019 From: nginx-forum at forum.nginx.org (chewiesw) Date: Tue, 03 Dec 2019 05:28:32 -0500 Subject: 'Lost' the default config location Message-ID: Noob here , so please bear with me. I have a reverse proxy working so if I https://mysite.com/footyscore the page will launch. However if I browse to http or https://mysite.com the default welcome to nginx page loads. I want to change this (change the root) so that my roundcube webmail will launch. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286385,286385#msg-286385 From francis at daoine.org Wed Dec 4 12:06:19 2019 From: francis at daoine.org (Francis Daly) Date: Wed, 4 Dec 2019 12:06:19 +0000 Subject: 'Lost' the default config location In-Reply-To: References: Message-ID: <20191204120619.GL26683@daoine.org> On Tue, Dec 03, 2019 at 05:28:32AM -0500, chewiesw wrote: Hi there, > Noob here , so please bear with me. I have a reverse proxy working so if I > https://mysite.com/footyscore the page will launch. However if I browse to > http or https://mysite.com the default welcome to nginx page loads. I want > to change this (change the root) so that my roundcube webmail will launch. It might be that just adding location = / { return 301 /footyscore/; } to your config will work -- that should cause any request to https://mysite.com/ to be invited to make a new request for https://mysite.com/footyscore/, which should then work as it currently does. Good luck with it, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Wed Dec 4 17:31:23 2019 From: nginx-forum at forum.nginx.org (ramirezc) Date: Wed, 04 Dec 2019 12:31:23 -0500 Subject: OCSP stapling for client certificates In-Reply-To: References: <20150705234326.GA1656@mdounin.ru> Message-ID: I have the same question ast itplayer: Other than CRL, any other alternative way we can do OCSP validation in the pipeline? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,252893,286405#msg-286405 From gfrankliu at gmail.com Wed Dec 4 17:54:50 2019 From: gfrankliu at gmail.com (Frank Liu) Date: Wed, 4 Dec 2019 09:54:50 -0800 Subject: OCSP stapling for client certificates In-Reply-To: References: Message-ID: <12EA5D41-A08C-4825-98D4-27F2249E655A@gmail.com> https://trac.nginx.org/nginx/ticket/1534 > On Dec 4, 2019, at 9:31 AM, ramirezc wrote: > > ?I have the same question ast itplayer: Other than CRL, any other alternative > way we can do OCSP validation in the pipeline? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?2,252893,286405#msg-286405 > > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tschweikle at gmail.com Wed Dec 4 18:08:52 2019 From: tschweikle at gmail.com (Thomas Schweikle) Date: Wed, 4 Dec 2019 19:08:52 +0100 Subject: Serving a subdirectory Message-ID: Hi! I'm a little bit lost now, since various configurations tried just dont work. None of them. I have: server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name nc409.my.domain; root /var/www; index index.sh index.html; location /chrony { try_files $uri $uri/ $uri/ index.sh; } location ~ "index\.sh"$ { gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $request_filename; } } With https://nc409.my.domain/ it gives an empty page (this is intended). With https://nc409.my.domain/chrony it gives 404-not found. With https://nc409.my.domain/chrony/ it gives 404-not found. With https://nc409.my.domain/chrony/index.sh it gives 403 Forbidden. If i am looking at the debug logs all seems OK: nginx feeds /var/www/chrony/index.sh to fcgiwraper. /var/www/chrony/index.sh is allowed to be executed by all. group is root, owner is root. Only the owner is allowed to write the file. All others are allowed to execute it. My first question: why doesn't nginx: https://nc409.my.domain/chrony -> https://nc409.my.domain/chrony/index.sh https://nc409.my.domain/chrony/ -> https://nc409.my.domain/chrony/index.sh https://nc409.my.domain/chrony/index.sh -> https://nc409.my.domain/chrony/index.sh https://nc409.my.domain/chrony/index.css -> https://nc409.my.domain/chrony/index.css feeding index.sh to fcgiwraper and delivering index.css directly? And how do I have to set up this thing to do exactly that? -- Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Thu Dec 5 11:51:17 2019 From: nginx-forum at forum.nginx.org (lucaprete) Date: Thu, 05 Dec 2019 06:51:17 -0500 Subject: Various errors while configuring nginx for certificate-based client auth Message-ID: <0c7349b4a1a55d6b3698a8c443d9beea.NginxMailingListEnglish@forum.nginx.org> Hi guys, I'm using nginx in form of container (docker.io/nginx), version 1.17.3-alpine I'm trying to setup my nginx to do TLS auth and then forward packets to another host in the network. As part of this I also have to support some probes that continuously monitor a secondary location, same server, same port. This is my configuration ``` server { listen 443 ssl; server_name mydomain.com; ssl_certificate /etc/nginx/certs/tls.crt; ssl_certificate_key /etc/nginx/certs/tls.key; ssl_client_certificate /etc/nginx/ca_certs/ca.crt; ssl_verify_client optional; ssl_verify_depth 2; location = /healthz { return 200 'the app is alive!'; } location = / { if ($ssl_client_verify != SUCCESS) { return 403; } proxy_pass http://other-host:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header SSL_Client $ssl_client_s_dn; proxy_set_header SSL_Client_Verify $ssl_client_verify; } } ``` First of all, as soon as I load the configuration I get the following error: ``` 2019/12/05 10:22:35 [emerg] 1#1: invalid condition "!=" in /etc/nginx/conf.d/mydomain.conf:36 nginx: [emerg] invalid condition "!=" in /etc/nginx/conf.d/mydomain.conf:36 ``` I find this if directive on any possible tutorial. I'm really not sure what's wrong here... Also, even if I remove the if clause (just to see if otherwise it would work) I get another error: ``` 2019/12/05 11:10:20 [emerg] 1#1: invalid number of arguments in "proxy_set_header" directive in /etc/nginx/conf.d/mydomain.conf:41 nginx: [emerg] invalid number of arguments in "proxy_set_header" directive in /etc/nginx/conf.d/mydomain.conf:41 ``` Even after removing all the entire `location = /` block (to see if at least the container starts and /healtz return 200), I still get the following error: ``` 2019/12/05 11:43:30 [error] 8#8: *90 open() "/etc/nginx/html/healtz" failed (2: No such file or directory), client: 172.16.0.158, server: , request: "GET /healtz HTTP/1.1", host: "mydomain.com" 172.16.0.158 - - [05/Dec/2019:11:43:30 +0000] "GET /healtz HTTP/1.1" 404 153 "-" "Wget" "-" 172.16.56.6 - - [05/Dec/2019:11:43:40 +0000] "GET / HTTP/1.1" 404 153 "-" "-" "-" ``` Shouldn't the return directive (as written) simply return a 200 and the message, even if a page is not present? Sorry if I posted in the same thread three different issues... I just thought it would have made sense to post them together. Thank you, -Luca Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286413,286413#msg-286413 From mdounin at mdounin.ru Thu Dec 5 13:01:02 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 5 Dec 2019 16:01:02 +0300 Subject: Various errors while configuring nginx for certificate-based client auth In-Reply-To: <0c7349b4a1a55d6b3698a8c443d9beea.NginxMailingListEnglish@forum.nginx.org> References: <0c7349b4a1a55d6b3698a8c443d9beea.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191205130102.GA12894@mdounin.ru> Hello! On Thu, Dec 05, 2019 at 06:51:17AM -0500, lucaprete wrote: > I'm using nginx in form of container (docker.io/nginx), version > 1.17.3-alpine > I'm trying to setup my nginx to do TLS auth and then forward packets to > another host in the network. > As part of this I also have to support some probes that continuously monitor > a secondary location, same server, same port. > > This is my configuration > > ``` > server { > listen 443 ssl; > server_name mydomain.com; > > ssl_certificate /etc/nginx/certs/tls.crt; > ssl_certificate_key /etc/nginx/certs/tls.key; > > ssl_client_certificate /etc/nginx/ca_certs/ca.crt; > ssl_verify_client optional; > ssl_verify_depth 2; > > location = /healthz { > return 200 'the app is alive!'; > } > > location = / { > if ($ssl_client_verify != SUCCESS) { > return 403; > } > > proxy_pass http://other-host:8080; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header SSL_Client $ssl_client_s_dn; > proxy_set_header SSL_Client_Verify $ssl_client_verify; > } > } > ``` > > First of all, as soon as I load the configuration I get the following > error: > > ``` > 2019/12/05 10:22:35 [emerg] 1#1: invalid condition "!=" in > /etc/nginx/conf.d/mydomain.conf:36 > nginx: [emerg] invalid condition "!=" in /etc/nginx/conf.d/mydomain.conf:36 > ``` > > I find this if directive on any possible tutorial. I'm really not sure > what's wrong here... > > Also, even if I remove the if clause (just to see if otherwise it would > work) I get another error: > > ``` > 2019/12/05 11:10:20 [emerg] 1#1: invalid number of arguments in > "proxy_set_header" directive in /etc/nginx/conf.d/mydomain.conf:41 > nginx: [emerg] invalid number of arguments in "proxy_set_header" directive > in /etc/nginx/conf.d/mydomain.conf:41 > ``` It looks like the configuration you are trying to put is passed through shell variable expansion, resulting in a completely broken configuration as seen by nginx. That is, > if ($ssl_client_verify != SUCCESS) { becomes if ( != SUCCESS) { which would result in the error message you see, and > proxy_set_header Host $host; results in proxy_set_header Host ; which obviously have invalid number of aguments. You have to find where the configuration is broken and fix it. [...] > Sorry if I posted in the same thread three different issues... I just > thought it would have made sense to post them together. Sure. Clearly this is just one issue with configuration deployment. -- Maxim Dounin http://mdounin.ru/ From nginx-forum at forum.nginx.org Thu Dec 5 14:35:09 2019 From: nginx-forum at forum.nginx.org (lucaprete) Date: Thu, 05 Dec 2019 09:35:09 -0500 Subject: Various errors while configuring nginx for certificate-based client auth In-Reply-To: <20191205130102.GA12894@mdounin.ru> References: <20191205130102.GA12894@mdounin.ru> Message-ID: <341072f02844ebdda0733bc603e6a393.NginxMailingListEnglish@forum.nginx.org> You got it! :) Some steps before I was using envsubst, which was also trying to substitute the nginx variables. Specifying what variables to substitute (i.e. envsubst '$ONLY_THIS_VAR' < mydomain.com.conf) solved the issue. Thank you! Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286413,286416#msg-286416 From francis at daoine.org Thu Dec 5 15:02:00 2019 From: francis at daoine.org (Francis Daly) Date: Thu, 5 Dec 2019 15:02:00 +0000 Subject: Serving a subdirectory In-Reply-To: References: Message-ID: <20191205150200.GM26683@daoine.org> On Wed, Dec 04, 2019 at 07:08:52PM +0100, Thomas Schweikle wrote: Hi there, > I'm a little bit lost now, since various configurations tried just dont > work. None of them. I'm not quite clear on what specifically you want your nginx to do. If it matters -- could you describe that? > location /chrony { > try_files $uri $uri/ $uri/ index.sh; > } > > location ~ "index\.sh"$ { I suspect that some of this was re-typed from the config, rather than having been copy-pasted. The "$ probably should be $"; and I'm not sure if the space before the index.sh is intended or not. > fastcgi_param SCRIPT_FILENAME $request_filename; For testing, you could try to put return 200 "in index.sh - $request_filename\n"; in this location{}. It will *not* invoke fastcgi, but it will show you want filename nginx writes in the matching variable. > If i am looking at the debug logs all seems OK: nginx feeds > /var/www/chrony/index.sh to fcgiwraper. /var/www/chrony/index.sh is allowed > to be executed by all. group is root, owner is root. Only the owner is > allowed to write the file. All others are allowed to execute it. I do not know if it is the same version that you are using, but the code at https://github.com/gnosek/fcgiwrap/blob/master/fcgiwrap.c looks like it includes a "reason" message with a 403 code. That message might indicate why the system thinks there is a problem. > My first question: why doesn't nginx: If you can show the config you are using, it may be clear why nginx does what it does. If what you want is "serve dir/index.sh when the request is for dir/", then it might be enough to remove the try_files block, and fix the index.sh line. Good luck with it, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Thu Dec 5 17:59:57 2019 From: nginx-forum at forum.nginx.org (stmx38) Date: Thu, 05 Dec 2019 12:59:57 -0500 Subject: proxy_set_header on HTTP or Server level In-Reply-To: <20190830202511.7ijnxejkmpatftio@daoine.org> References: <20190830202511.7ijnxejkmpatftio@daoine.org> Message-ID: Francis, Basically, the issue was with the 'proxy_set_header' directives. In such cases, when we define at least one in the location, we should also define all the rests headers. >From your reply, I understand that with the 'proxy_read_timeout/proxy_send_timeout' we should not have such situations. Thank you for your reply and explanation! Posted at Nginx Forum: https://forum.nginx.org/read.php?2,285462,286420#msg-286420 From nginx-forum at forum.nginx.org Thu Dec 5 18:12:07 2019 From: nginx-forum at forum.nginx.org (stmx38) Date: Thu, 05 Dec 2019 13:12:07 -0500 Subject: Nginx map - use variable multiple times or use multiple variables Message-ID: <95e1c0956e0a4d10e309d4c455217e6c.NginxMailingListEnglish@forum.nginx.org> Hello, We use Nginx map module to sent traffic to different upstreams based on the HTTP header: map $http_flow $flow_upstream { default "http://flow-dev"; prod "http://flow-prod"; test "http://flow-test"; dev "http://flow-dev"; } location / { proxy_read_timeout 5s; proxy_pass $flow_upstream; } Now, we want to define a different timeouts to different flows: map $http_flow $read_timeout { default 15s; prod 5s; test 10s; dev 15s; } location / { proxy_read_timeout $read_timeout; proxy_pass $flow_upstream; } Bunt Nginx config test show the error here: nginx -t nginx: [emerg] "proxy_send_timeout" directive invalid value in /etc/nginx/conf.d/flow.conf:19 nginx: configuration file /etc/nginx/nginx.conf test failed Can we use map in such a way? Or maybe something like this: map $http_flow $flow_upstream $read_timeout { default "http://flow-dev" "15s"; prod "http://flow-prod" "5s"; test "http://flow-test" "10s"; dev "http://flow-dev" "15s"; } Thank you! Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286421,286421#msg-286421 From mdounin at mdounin.ru Thu Dec 5 18:27:01 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 5 Dec 2019 21:27:01 +0300 Subject: Nginx map - use variable multiple times or use multiple variables In-Reply-To: <95e1c0956e0a4d10e309d4c455217e6c.NginxMailingListEnglish@forum.nginx.org> References: <95e1c0956e0a4d10e309d4c455217e6c.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191205182701.GC12894@mdounin.ru> Hello! On Thu, Dec 05, 2019 at 01:12:07PM -0500, stmx38 wrote: > Hello, > > We use Nginx map module to sent traffic to different upstreams based on the > HTTP header: > > map $http_flow $flow_upstream { > default "http://flow-dev"; > prod "http://flow-prod"; > test "http://flow-test"; > dev "http://flow-dev"; > } > > location / { > proxy_read_timeout 5s; > proxy_pass $flow_upstream; > } > > Now, we want to define a different timeouts to different flows: > > map $http_flow $read_timeout { > default 15s; > prod 5s; > test 10s; > dev 15s; > } > > location / { > proxy_read_timeout $read_timeout; > proxy_pass $flow_upstream; > } > > Bunt Nginx config test show the error here: > nginx -t > nginx: [emerg] "proxy_send_timeout" directive invalid value in > /etc/nginx/conf.d/flow.conf:19 > nginx: configuration file /etc/nginx/nginx.conf test failed The proxy_send_timeout does not support variables. Note that if a particular directive supports variables, this is explicitly said in the documentation. Instead, consider handling requests in different locations if you want to use different configurations for them. For example: map $http_flow $flow { default dev; test test; } location / { rewrite (.*) /$flow/$1 last; } location /dev/ { proxy_pass http://flow-dev/; proxy_send_timeout 15s; } location /test/ { proxy_pass http://flow-test/; proxy_send_timeout 10s; } (Untested, and might require additional configuration to work properly, such as switching off proxy_redirect.) -- Maxim Dounin http://mdounin.ru/ From nginx-forum at forum.nginx.org Thu Dec 5 19:32:37 2019 From: nginx-forum at forum.nginx.org (stmx38) Date: Thu, 05 Dec 2019 14:32:37 -0500 Subject: Nginx map - use variable multiple times or use multiple variables In-Reply-To: <20191205182701.GC12894@mdounin.ru> References: <20191205182701.GC12894@mdounin.ru> Message-ID: <3daf73d33253f2ec399b1c1f3e2be813.NginxMailingListEnglish@forum.nginx.org> Maxim, Different locations solved the issue. Thank you for the help! Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286421,286423#msg-286423 From tschweikle at gmail.com Fri Dec 6 11:39:59 2019 From: tschweikle at gmail.com (Thomas Schweikle) Date: Fri, 6 Dec 2019 12:39:59 +0100 Subject: Serving a subdirectory In-Reply-To: <20191205150200.GM26683@daoine.org> References: <20191205150200.GM26683@daoine.org> Message-ID: Configuration /etc/nginx/sites-available: chrony default /etc/nginx/sites-available/chrony: server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name ; root /var/www/chrony; index index.sh index.html; location /chrony { try_files $uri $uri/ $uri/index.sh; } location ~ "index\.sh"$ { gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $request_filename; } } /etc/nginx/sites-available/default: server { listen 80 default_server; listen [::]:80 default_server; root /var/www/html; index index.html index.htm index.nginx-debian.html; server_name _; location / { try_files $uri $uri/ =404; } } /etc/nginx/nginx.conf: user www-data; worker_processes auto; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf; events { worker_connections 768; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } Filesystem: /var/www/html/index.nginx-debian.html /var/www/chrony/index.sh /var/www/chrony/chrony.css For https:///: nginx default site delivered ok. For https:///chrony: 404 - Not found. Versions: ii fcgiwrap 1.1.0-9 armhf simple server to run CGI applications over FastCGI ii libfcgi-bin 2.4.0-8.4 armhf FastCGI bridge from CGI ii libfcgi0ldbl:armhf 2.4.0-8.4 armhf Shared library of FastCGI ii libnginx-mod-http-auth-pam 1.10.3-1+deb9u3 armhf PAM authentication module for Nginx ii libnginx-mod-http-dav-ext 1.10.3-1+deb9u3 armhf WebDAV missing commands support for Nginx ii libnginx-mod-http-echo 1.10.3-1+deb9u3 armhf Bring echo and more shell style goodies to Nginx ii libnginx-mod-http-geoip 1.10.3-1+deb9u3 armhf GeoIP HTTP module for Nginx ii libnginx-mod-http-image-filter 1.10.3-1+deb9u3 armhf HTTP image filter module for Nginx ii libnginx-mod-http-subs-filter 1.10.3-1+deb9u3 armhf Substitution filter module for Nginx ii libnginx-mod-http-upstream-fair 1.10.3-1+deb9u3 armhf Nginx Upstream Fair Proxy Load Balancer ii libnginx-mod-http-xslt-filter 1.10.3-1+deb9u3 armhf XSLT Transformation module for Nginx ii libnginx-mod-mail 1.10.3-1+deb9u3 armhf Mail module for Nginx ii libnginx-mod-stream 1.10.3-1+deb9u3 armhf Stream module for Nginx ii nginx 1.10.3-1+deb9u3 all small, powerful, scalable web/proxy server ii nginx-common 1.10.3-1+deb9u3 all small, powerful, scalable web/proxy server - common files ii nginx-full 1.10.3-1+deb9u3 armhf nginx web/proxy server (standard version) On Thu, Dec 5, 2019 at 4:02 PM Francis Daly wrote: > On Wed, Dec 04, 2019 at 07:08:52PM +0100, Thomas Schweikle wrote: > > Hi there, > > > I'm a little bit lost now, since various configurations tried just dont > > work. None of them. > > I'm not quite clear on what specifically you want your nginx to do. > > If it matters -- could you describe that? > > > location /chrony { > > try_files $uri $uri/ $uri/ index.sh; > > } > > > > location ~ "index\.sh"$ { > > I suspect that some of this was re-typed from the config, rather than > having been copy-pasted. > > The "$ probably should be $"; and I'm not sure if the space before > the index.sh is intended or not. > > > fastcgi_param SCRIPT_FILENAME $request_filename; > > For testing, you could try to put > > return 200 "in index.sh - $request_filename\n"; > > in this location{}. It will *not* invoke fastcgi, but it will show you > want filename nginx writes in the matching variable. > > > If i am looking at the debug logs all seems OK: nginx feeds > > /var/www/chrony/index.sh to fcgiwraper. /var/www/chrony/index.sh is > allowed > > to be executed by all. group is root, owner is root. Only the owner is > > allowed to write the file. All others are allowed to execute it. > > I do not know if it is the same version that you are using, but the > code at https://github.com/gnosek/fcgiwrap/blob/master/fcgiwrap.c looks > like it includes a "reason" message with a 403 code. That message might > indicate why the system thinks there is a problem. > > > My first question: why doesn't nginx: > > If you can show the config you are using, it may be clear why nginx does > what it does. > > If what you want is "serve dir/index.sh when the request is for dir/", > then it might be enough to remove the try_files block, and fix the > index.sh line. > > Good luck with it, > > f > -- > Francis Daly francis at daoine.org > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -- Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis at daoine.org Fri Dec 6 12:29:45 2019 From: francis at daoine.org (Francis Daly) Date: Fri, 6 Dec 2019 12:29:45 +0000 Subject: Serving a subdirectory In-Reply-To: References: <20191205150200.GM26683@daoine.org> Message-ID: <20191206122945.GN26683@daoine.org> On Fri, Dec 06, 2019 at 12:39:59PM +0100, Thomas Schweikle wrote: Hi there, This config fails to run for me. So, unless something very strange is happening, this is not the config that your running nginx is actually using. > location ~ "index\.sh"$ { $ sbin/nginx -t nginx: [emerg] unexpected "$" in /usr/local/nginx/conf/nginx.conf:19 nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed $ sed -n 19p /usr/local/nginx/conf/nginx.conf location ~ "index\.sh"$ { Changing that line to be location ~ "index\.sh$" { allows it to run. > For https:///: > nginx default site delivered ok. Your provided config says that that should serve something from /var/www/chrony. You seem to report that it is serving something from /var/www/html. > For https:///chrony: > 404 - Not found. Your provided config says that that should serve something from /var/www/chrony/chrony, which I think you show does not exist, so 404 is correct. But I suspect that your actual running config is trying to serve something from /var/www/html/chrony, which also does not exist, so 404 is created. I think that you will need to identify the actual running config, because that will make it easier to make the changes that you want. Cheers, f -- Francis Daly francis at daoine.org From tschweikle at gmail.com Fri Dec 6 15:47:08 2019 From: tschweikle at gmail.com (Thomas Schweikle) Date: Fri, 6 Dec 2019 16:47:08 +0100 Subject: Serving a subdirectory In-Reply-To: <20191206122945.GN26683@daoine.org> References: <20191205150200.GM26683@daoine.org> <20191206122945.GN26683@daoine.org> Message-ID: OK. Trying with a completely different question: My server serves /var/www/html directory-content as static pages to http:// / How do I have to set it up to additionally serve http:///chrony from /var/www/chrony? I've tried with: server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name nc409-muc.bfs.de; root /var/www/chrony; index index.sh index.html; location / { try_files $uri $uri/ $uri/index.sh; } location ~ "index\.sh$" { gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $request_filename; } } But this leads to error 404 - not found. I've tried with: server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name nc409-muc.bfs.de; root /var/www; index index.sh index.html; location /chrony { try_files $uri $uri/ $uri/index.sh; } location ~ "index\.sh$" { gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $request_filename; } } But this also lead to error - 404 - not found. I did not have success with: server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name nc409-muc.bfs.de; root /var/www/chrony; index index.sh index.html; location ~ "index\.sh$" { gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $request_filename; } } lead to 404 - not found. or server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name nc409-muc.bfs.de; root /var/www/chrony; index index.sh index.html; location ~ "index\.sh$" { gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $request_filename; } } lead to 404 - not found. But the file is there: /var/www: insgesamt 16 drwxr-xr-x 4 root root 4096 Dez 2 16:25 . drwxr-xr-x 12 root root 4096 Aug 20 12:58 .. drwxr-xr-x 2 root root 4096 Dez 4 17:17 chrony drwxr-xr-x 2 root root 4096 Aug 20 12:58 html /var/www/chrony: insgesamt 16 drwxr-xr-x 2 root root 4096 Dez 4 17:17 . drwxr-xr-x 4 root root 4096 Dez 2 16:25 .. -rw-r--r-- 1 root root 95 Dez 3 13:42 chrony.css -rwxr-xr-x 1 root root 1712 Dez 3 16:07 index.sh /var/www/html: insgesamt 12 drwxr-xr-x 2 root root 4096 Aug 20 12:58 . drwxr-xr-x 4 root root 4096 Dez 2 16:25 .. -rw-r--r-- 1 root root 612 Aug 20 12:58 index.nginx-debian.html and nginx -T does: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful With configuration: # configuration file /etc/nginx/nginx.conf: user www-data; worker_processes auto; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf; events { worker_connections 768; # multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } load_module modules/ngx_http_auth_pam_module.so; load_module modules/ngx_http_dav_ext_module.so; load_module modules/ngx_http_echo_module.so; load_module modules/ngx_http_geoip_module.so; load_module modules/ngx_http_image_filter_module.so; load_module modules/ngx_http_subs_filter_module.so; load_module modules/ngx_http_upstream_fair_module.so; load_module modules/ngx_http_xslt_filter_module.so; load_module modules/ngx_mail_module.so; load_module modules/ngx_stream_module.so; types { text/html html htm shtml; text/css css; text/xml xml; image/gif gif; image/jpeg jpeg jpg; application/javascript js; application/atom+xml atom; application/rss+xml rss; text/mathml mml; text/plain txt; text/vnd.sun.j2me.app-descriptor jad; text/vnd.wap.wml wml; text/x-component htc; image/png png; image/tiff tif tiff; image/vnd.wap.wbmp wbmp; image/x-icon ico; image/x-jng jng; image/x-ms-bmp bmp; image/svg+xml svg svgz; image/webp webp; application/font-woff woff; application/java-archive jar war ear; application/json json; application/mac-binhex40 hqx; application/msword doc; application/pdf pdf; application/postscript ps eps ai; application/rtf rtf; application/vnd.apple.mpegurl m3u8; application/vnd.ms-excel xls; application/vnd.ms-fontobject eot; application/vnd.ms-powerpoint ppt; application/vnd.wap.wmlc wmlc; application/vnd.google-earth.kml+xml kml; application/vnd.google-earth.kmz kmz; application/x-7z-compressed 7z; application/x-cocoa cco; application/x-java-archive-diff jardiff; application/x-java-jnlp-file jnlp; application/x-makeself run; application/x-perl pl pm; application/x-pilot prc pdb; application/x-rar-compressed rar; application/x-redhat-package-manager rpm; application/x-sea sea; application/x-shockwave-flash swf; application/x-stuffit sit; application/x-tcl tcl tk; application/x-x509-ca-cert der pem crt; application/x-xpinstall xpi; application/xhtml+xml xhtml; application/xspf+xml xspf; application/zip zip; application/octet-stream bin exe dll; application/octet-stream deb; application/octet-stream dmg; application/octet-stream iso img; application/octet-stream msi msp msm; application/vnd.openxmlformats-officedocument.wordprocessingml.document docx; application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx; application/vnd.openxmlformats-officedocument.presentationml.presentation pptx; audio/midi mid midi kar; audio/mpeg mp3; audio/ogg ogg; audio/x-m4a m4a; audio/x-realaudio ra; video/3gpp 3gpp 3gp; video/mp2t ts; video/mp4 mp4; video/mpeg mpeg mpg; video/quicktime mov; video/webm webm; video/x-flv flv; video/x-m4v m4v; video/x-mng mng; video/x-ms-asf asx asf; video/x-ms-wmv wmv; video/x-msvideo avi; } server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 301 https://$host$request_uri; } server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name _; ssl_certificate /etc/ssl/certs/nginx.crt; ssl_certificate_key /etc/ssl/private/nginx.key; root /var/www/html; index index.html index.htm index.nginx-debian.html; location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. try_files $uri $uri/ =404; } location /chrony { root /var/www/chrony; try_files $uri $uri/ $uri/index.sh; } location ~ "index\.sh$" { gzip off; fastcgi_pass unix:/var/run/fcgiwrap.socket; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $request_filename; } } # configuration file /etc/nginx/fastcgi_params: fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param REQUEST_SCHEME $scheme; fastcgi_param HTTPS $https if_not_empty; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; # PHP only, required if PHP was built with --enable-force-cgi-redirect fastcgi_param REDIRECT_STATUS 200; On Fri, Dec 6, 2019 at 1:29 PM Francis Daly wrote: > On Fri, Dec 06, 2019 at 12:39:59PM +0100, Thomas Schweikle wrote: > > Hi there, > > This config fails to run for me. > > So, unless something very strange is happening, this is not the config > that your running nginx is actually using. > > > location ~ "index\.sh"$ { > > $ sbin/nginx -t > nginx: [emerg] unexpected "$" in /usr/local/nginx/conf/nginx.conf:19 > nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed > $ sed -n 19p /usr/local/nginx/conf/nginx.conf > location ~ "index\.sh"$ { > > Changing that line to be > > location ~ "index\.sh$" { > > allows it to run. > > > For https:///: > > nginx default site delivered ok. > > Your provided config says that that should serve something from > /var/www/chrony. You seem to report that it is serving something from > /var/www/html. > > > For https:///chrony: > > 404 - Not found. > > Your provided config says that that should serve something from > /var/www/chrony/chrony, which I think you show does not exist, so 404 > is correct. > > But I suspect that your actual running config is trying to serve something > from /var/www/html/chrony, which also does not exist, so 404 is created. > > > I think that you will need to identify the actual running config, > because that will make it easier to make the changes that you want. > > Cheers, > > f > -- > Francis Daly francis at daoine.org > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -- Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis at daoine.org Fri Dec 6 20:47:43 2019 From: francis at daoine.org (Francis Daly) Date: Fri, 6 Dec 2019 20:47:43 +0000 Subject: Serving a subdirectory In-Reply-To: References: <20191205150200.GM26683@daoine.org> <20191206122945.GN26683@daoine.org> Message-ID: <20191206204743.GO26683@daoine.org> On Fri, Dec 06, 2019 at 04:47:08PM +0100, Thomas Schweikle wrote: Hi there, > OK. Trying with a completely different question: > > My server serves /var/www/html directory-content as static pages to http:// > / > > How do I have to set it up to additionally serve http:///chrony > from /var/www/chrony? location /chrony/ { root /var/www; } Although I would probably really use "location ^~ /chrony/ {". And that is all you need, in the "common" case. Separate from that, since you want to do special handling of "index.sh" within "/chrony/", I would suggest nesting the location, like so: location ^~ /chrony/ { root /var/www; location ~ index\.sh$ { fastcgi_pass unix:/var/run/fcgiwrap.socket; } } You will want index index.sh index.html; somewhere. You probably will not want the try_files line that you have. And you can put the include /etc/nginx/fastcgi_params; and fastcgi_param lines together somewhere -- inside this location{}, or in somewhere that will inherit in to it. The "best" place depends on what else the server config is doing -- do you, for example, want to handle /xxx/index.sh as well as /chrony/index.sh? > I've tried with: > root /var/www/chrony; That will cause the request /chrony to look for /var/www/chrony/chrony. > But this leads to error 404 - not found. > root /var/www; > index index.sh index.html; > > location /chrony { > try_files $uri $uri/ $uri/index.sh; > } > > location ~ "index\.sh$" { > gzip off; > fastcgi_pass unix:/var/run/fcgiwrap.socket; > include /etc/nginx/fastcgi_params; > fastcgi_param DOCUMENT_ROOT $document_root; > fastcgi_param SCRIPT_FILENAME $request_filename; > } That looks to me like it probably should work. At least for the requests /chrony and /chrony/ -- anything like /chrony/x will probably fail. > But this also lead to error - 404 - not found. > root /var/www/chrony; Again, that will cause the request /chrony to look for /var/www/chrony/chrony. > lead to 404 - not found. > root /var/www/chrony; Same. > lead to 404 - not found. > /var/www/chrony: > insgesamt 16 > drwxr-xr-x 2 root root 4096 Dez 4 17:17 . > drwxr-xr-x 4 root root 4096 Dez 2 16:25 .. > -rw-r--r-- 1 root root 95 Dez 3 13:42 chrony.css > -rwxr-xr-x 1 root root 1712 Dez 3 16:07 index.sh Most of the above configs are looking for /var/www/chrony/chrony/index.sh. > root /var/www/html; > index index.html index.htm index.nginx-debian.html; > > location / { > # First attempt to serve request as file, then > # as directory, then fall back to displaying a 404. > try_files $uri $uri/ =404; As it happens, that description (and configuration) is pretty much what happens when try_files is not used. So you can probably just omit that line. > location /chrony { > root /var/www/chrony; root /var/www; > try_files $uri $uri/ $uri/index.sh; The final argument to try_files is a url that must exist; it is not a file to try. So if you request /chrony/x, this will do an internal redirect to /chrony/x/index.sh. You are probably better off including "index.sh" in the "index" directive, and omitting this try_files line too. > location ~ "index\.sh$" { > gzip off; > fastcgi_pass unix:/var/run/fcgiwrap.socket; > include /etc/nginx/fastcgi_params; > fastcgi_param DOCUMENT_ROOT $document_root; > fastcgi_param SCRIPT_FILENAME $request_filename; If the request here is /chrony/index.sh, then $document_root is /var/www/html and $request_filename is /var/www/html/chrony/index.sh. In nginx, one request is handled in one location{}. Only the config in, or inherited into, that location matters. You do not set "root" in this location; therefore the inherited value is /var/www/html. If this location is only intended to handle things below /chrony, set root explicitly; or set root implicitly by nesting it inside the location that does set root appropriately. Good luck with it, f -- Francis Daly francis at daoine.org From rhys.j.ferris at gmail.com Sat Dec 7 08:14:12 2019 From: rhys.j.ferris at gmail.com (Rhys Ferris) Date: Fri, 6 Dec 2019 22:14:12 -1000 Subject: Controlling Access on and off LAN In-Reply-To: <20191204120619.GL26683@daoine.org> References: <20191204120619.GL26683@daoine.org> Message-ID: Hello everyone, Hopefully this is a simple question with a simple answer. First my actual goal: I'm hosting one server: domain.net which at domain.net serves a basic homepage and uses iframes to proxy several other services, which are defined in location blocks: domain.net/service. I want to allow all IPs to access domain.net and the services proxied inside of it. However I want to restrict direct access to domain.net/service from outside my LAN. What I've got so far: I've set up my location blocks for my services to begin with: allow 192.168.x.x/25; deny all; which very effectively blocks access from outside my LAN. However it still blocks the services when proxied from within domain.net, I think because I am using "proxy_set_header X-Real-IP $remote_addr;" so the proxied request is arriving at the location block with an external IP. I looked but could not find documentation on the proxy_set_header X-Real-IP statement (I even ventured to page 2 of google :-P) to try to get it to proxy the request as if my server running nginx had made the request. What I would like from y'all: 1. If there is a better way to achieve my goal, please tell me. I don't have my heart set on this, its just all I could figure. 2. How do I use the proxy_set_header X-Real-IP $remote_addr; to fake the internal IP? or is that even the correct header to be using? Thanks very much for your time, Rhys Ferris Sample location block: ??????? location /service/ { ??????????? allow 192.168.136.128/25; ??????????? deny all; ??????????? proxy_pass http://prometheus:1234/service/; ??????????? proxy_set_header Host $host; ??????????? proxy_set_header X-Real-IP $remote_addr; ??????????? proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ??????? } -- Sent from Thunderbird on Ubuntu 19.10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4452 bytes Desc: S/MIME Cryptographic Signature URL: From francis at daoine.org Sun Dec 8 13:50:43 2019 From: francis at daoine.org (Francis Daly) Date: Sun, 8 Dec 2019 13:50:43 +0000 Subject: Controlling Access on and off LAN In-Reply-To: References: <20191204120619.GL26683@daoine.org> Message-ID: <20191208135043.GP26683@daoine.org> On Fri, Dec 06, 2019 at 10:14:12PM -1000, Rhys Ferris wrote: Hi there, > I'm hosting one server: domain.net which at domain.net serves a basic > homepage and uses iframes to proxy several other services, which are > defined in location blocks: domain.net/service. > > I want to allow all IPs to access domain.net and the services proxied > inside of it. However I want to restrict direct access to > domain.net/service from outside my LAN. Reading that, and reading the config, I'm afraid that I'm not sure what you are trying to achieve. Note that "iframe" and "proxy" are unrelated concepts; it is possible that that might change the understanding of the requirement. My first guess is that you want to allow anyone to access domain.net/service; and you want LAN-users to be able to access prometheus:1234/service; and you want off-LAN users to not be able to access prometheus:1234/service directly. Is that it? > 1. If there is a better way to achieve my goal, please tell me. I don't > have my heart set on this, its just all I could figure. As above -- I'm not sure what the goal is, so I can't offer a suggestion. > 2. How do I use the proxy_set_header X-Real-IP $remote_addr; to fake > the internal IP? or is that even the correct header to be using? I suspect that that's also part of the goal; I'm unclear on what the aim there is either. Possibly your whole question is clear to others; in which case they will be able to respond in due time. But in case it's not, it may be helpful for others if you can describe your goal in other words. Thanks, f -- Francis Daly francis at daoine.org From rhys.j.ferris at gmail.com Mon Dec 9 00:29:57 2019 From: rhys.j.ferris at gmail.com (Rhys Ferris) Date: Sun, 8 Dec 2019 14:29:57 -1000 Subject: Controlling Access on and off LAN In-Reply-To: <20191208135043.GP26683@daoine.org> References: <20191204120619.GL26683@daoine.org> <20191208135043.GP26683@daoine.org> Message-ID: <736dea92-bbb5-45cc-b3fd-3f5480eb4020@gmail.com> Thanks for the reply. I'll try to do better: I have domain.net which is a gateway to all my services. It has buttons on the side for them all and then loads them in an iframe under the url domain.net/#Service. The services themselves are proxied by nginx at domain.net/service. This is Organizr if you've heard of it (https://github.com/causefx/Organizr). I want to force IPs outside of my LAN to access everything through domain.net as it has a logon to use any of the services. I only want direct access to domain.net/service available to my LAN. One more way of looking at it. When a user uses the organizr front end and uses a services, they get some menu bars hosted by nginx as well as an iframe containing domain.net/service, but it is served through domain.net/#Service. When I block external IPs from domain.net/service, the iframe inside of domain.net/#Service also gets blocked. As I think through this it occurs to me I don't think the config change needs to be in nginx, but in organizr. I need organizr to request to content from a local IP. Not sure if that is possible, but I'll hit them up. Thanks for helping me work through it. On 12/8/19 3:50 AM, Francis Daly wrote: > On Fri, Dec 06, 2019 at 10:14:12PM -1000, Rhys Ferris wrote: > > Hi there, > >> I'm hosting one server: domain.net which at domain.net serves a basic >> homepage and uses iframes to proxy several other services, which are >> defined in location blocks: domain.net/service. >> >> I want to allow all IPs to access domain.net and the services proxied >> inside of it. However I want to restrict direct access to >> domain.net/service from outside my LAN. > Reading that, and reading the config, I'm afraid that I'm not sure what > you are trying to achieve. > > Note that "iframe" and "proxy" are unrelated concepts; it is possible > that that might change the understanding of the requirement. > > My first guess is that you want to allow anyone to access > domain.net/service; and you want LAN-users to be able to access > prometheus:1234/service; and you want off-LAN users to not be able to > access prometheus:1234/service directly. > > Is that it? > >> 1. If there is a better way to achieve my goal, please tell me. I don't >> have my heart set on this, its just all I could figure. > As above -- I'm not sure what the goal is, so I can't offer a suggestion. > >> 2. How do I use the proxy_set_header X-Real-IP $remote_addr; to fake >> the internal IP? or is that even the correct header to be using? > I suspect that that's also part of the goal; I'm unclear on what the aim > there is either. > > Possibly your whole question is clear to others; in which case they will > be able to respond in due time. > > But in case it's not, it may be helpful for others if you can describe > your goal in other words. > > Thanks, > > f -- Sent from Thunderbird on Ubuntu 19.04 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4452 bytes Desc: S/MIME Cryptographic Signature URL: From hobson42 at gmail.com Mon Dec 9 10:41:24 2019 From: hobson42 at gmail.com (Ian Hobson) Date: Mon, 9 Dec 2019 10:41:24 +0000 Subject: Controlling Access on and off LAN Message-ID: On 07/12/2019 08:14, Rhys Ferris wrote: > > Hello everyone, > > Hopefully this is a simple question with a simple answer. > > > First my actual goal: > > I'm hosting one server: domain.net which at domain.net serves a basic > homepage and uses iframes to proxy several other services, which are > defined in location blocks: domain.net/service. > > I want to allow all IPs to access domain.net and the services proxied > inside of it. However I want to restrict direct access to > domain.net/service from outside my LAN. > Not 100% clear on your requirements, but I would approach it like this. a) Mount the /service server on a new port - say 8080 b) Mount a dummy server on another port that always returns 404; server dummy { listen 9090; location / { return 404; } } c) Firewall off the 8080 port at the LAN firewall, so it cannot be reached from outside, only by proxy_pass from nginx. d) In the Iframe, request /services from port 80 as usual. e) Use map to map valid referer valued to 8080 and invalid ones to the dummy port map $http_referer $port { default 9090 ~*($http_referer) 8080; } f) Proxy_pass to the port location /service/ { # setup other proxied headers if needed proxy_pass https://192.168.0.??:$port; return 404; } Code untested. The other methods I though of used if, which is slow. Note - some browsers may not send refer headers and will get 404s. If this is a problem, set up advice on your 404 page. Faking referer is easy but pointless here. Regards Ian From francis at daoine.org Tue Dec 10 12:31:58 2019 From: francis at daoine.org (Francis Daly) Date: Tue, 10 Dec 2019 12:31:58 +0000 Subject: Controlling Access on and off LAN In-Reply-To: <736dea92-bbb5-45cc-b3fd-3f5480eb4020@gmail.com> References: <20191204120619.GL26683@daoine.org> <20191208135043.GP26683@daoine.org> <736dea92-bbb5-45cc-b3fd-3f5480eb4020@gmail.com> Message-ID: <20191210123158.GQ26683@daoine.org> On Sun, Dec 08, 2019 at 02:29:57PM -1000, Rhys Ferris wrote: Hi there, thanks for the extra description. > I have domain.net which is a gateway to all my services. It has buttons > on the side for them all and then loads them in an iframe under the url > domain.net/#Service. The services themselves are proxied by nginx at > domain.net/service. This is Organizr if you've heard of it > (https://github.com/causefx/Organizr). > > I want to force IPs outside of my LAN to access everything through > domain.net as it has a logon to use any of the services. I only want > direct access to domain.net/service available to my LAN. I think I'm still not understanding the intended data flow. It does sound like the /#Service is purely a cosmetic "overlay" on /service, and it is still the end client that actually access /service either way -- but in that case /#Service would be pointless, and its login controls would be ineffective. So I guess I am missing something. > One more way of looking at it. When a user uses the organizr front end > and uses a services, they get some menu bars hosted by nginx as well as > an iframe containing domain.net/service, but it is served through > domain.net/#Service. "iframe" is irrelevant to nginx. "/#Service" is irrelevant to nginx. If the end client directly accesses /service, that is the request that nginx will see. The only alternative would be if the client accesses Organizr through some url, and Organizr accesses /service on the client's behalf; in that case, nginx will see the request to /service from Organizr, and so nginx could block any other access to /service. (And should do so, if Organizr is doing some form of access control.) > When I block external IPs from domain.net/service, the iframe inside of > domain.net/#Service also gets blocked. I wonder, if you want to investigate this further... without the IP block, when you use the web application normally, do nginx logs show the requests to /service coming from the same client IP address as the original request to /; or are they coming from a separate Organizr address? If you are doing any kind of "real-ip" conversion in that nginx instance, turn it off for this logging. > As I think through this it occurs to me I don't think the config change > needs to be in nginx, but in organizr. I need organizr to request to > content from a local IP. Not sure if that is possible, but I'll hit them > up. Thanks for helping me work through it. Good luck with it, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Tue Dec 10 21:11:30 2019 From: nginx-forum at forum.nginx.org (jriker1) Date: Tue, 10 Dec 2019 16:11:30 -0500 Subject: RD Gateway thru Reverse Proxy Message-ID: <1e88d377548b4915ed956ed913f79e94.NginxMailingListEnglish@forum.nginx.org> I have multiple servers internal that need to use port 443 due to requirements of the applications and vendors. One is a Windows 2016 Essentials server the other a custom web app on Linux that requires a communication to the cloud on 443. I have setup a reverse proxy and it's excellent. Only issue I'm having is with Essentials server I login to the web console and when I click to launch a RD Gateway session it comes up and I can authenticate but when it's going to launch the actual session it fails. Error I get is: 2019/12/10 14:27:48 [error] 27899#27899: *291 upstream prematurely closed connection while reading response header from upstream, client: , server: , request: "RDG_OUT_DATA /remoteDesktopGateway/ HTTP/1.1", uupstream: "https:/:443/remoteDesktopGateway/", host: "" Below is my custom config settings: ######--------------BEGIN of the script server { listen 80; server_name ; # redirect http to https return 301 https://$server_name$request_uri; client_max_body_size 0; proxy_http_version 1.1; proxy_buffering off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; location / { proxy_pass http://; } } server { listen 80; server_name ; # redirect http to https return 301 https://$server_name$request_uri; client_max_body_size 0; proxy_http_version 1.1; proxy_buffering off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; location / { proxy_pass http://; } } server { listen 443 ssl; listen [::]:443 ssl; server_name ; ssl_certificate /config/user-data/ssl_chain_essentials.pem; ssl_certificate_key /config/user-data/ssl_chain_key_essentials.pem; access_log /var/log/nginx/.access.log; error_log /var/log/nginx/.error.log; ssl_session_timeout 1d; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; #dh param ssl_dhparam /config/user-data/dhparam.pem; # Enable HTTP Strict-Transport-Security # If you have a subdomain of your site, # be careful to use the 'includeSubdomains' options add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; # XSS Protection for Nginx web server add_header X-Frame-Options DENY; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options nosniff; ssl_session_cache shared:SSL:10m; add_header X-Robots-Tag none; client_max_body_size 0; proxy_http_version 1.1; proxy_buffering off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; location / { proxy_pass https://; } } server { listen 443 ssl; server_name ; ssl_certificate /config/user-data/ssl_chain_smartweb.pem; ssl_certificate_key /config/user-data/ssl_chain_key_smartweb.pem; access_log /var/log/nginx/.access.log; error_log /var/log/nginx/.error.log; ssl_session_timeout 1d; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; #dh param ssl_dhparam /config/user-data/dhparam.pem; # Enable HTTP Strict-Transport-Security # If you have a subdomain of your site, # be carefull to use the 'includeSubdomains' options add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; # XSS Protection for Nginx web server add_header X-Frame-Options DENY; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options nosniff; add_header X-Robots-Tag none; client_max_body_size 0; proxy_http_version 1.1; proxy_buffering off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; location / { proxy_pass https://:8123; } } #######-----------------end of script---------------------------- Thoughts? Thanks. JR Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286440,286440#msg-286440 From kohenkatz at gmail.com Tue Dec 10 21:19:13 2019 From: kohenkatz at gmail.com (Moshe Katz) Date: Tue, 10 Dec 2019 16:19:13 -0500 Subject: RD Gateway thru Reverse Proxy In-Reply-To: <1e88d377548b4915ed956ed913f79e94.NginxMailingListEnglish@forum.nginx.org> References: <1e88d377548b4915ed956ed913f79e94.NginxMailingListEnglish@forum.nginx.org> Message-ID: RD Gateway isn't a real HTTP(S) connection, so you need to use a `stream` block. This has been discussed on this email list several years ago: https://forum.nginx.org/read.php?11,266872 Moshe On Tue, Dec 10, 2019, 4:11 PM jriker1 wrote: > I have multiple servers internal that need to use port 443 due to > requirements of the applications and vendors. One is a Windows 2016 > Essentials server the other a custom web app on Linux that requires a > communication to the cloud on 443. I have setup a reverse proxy and it's > excellent. Only issue I'm having is with Essentials server I login to the > web console and when I click to launch a RD Gateway session it comes up and > I can authenticate but when it's going to launch the actual session it > fails. > > Error I get is: > > 2019/12/10 14:27:48 [error] 27899#27899: *291 upstream prematurely closed > connection while reading response header from upstream, client: at>, > server: , request: "RDG_OUT_DATA /remoteDesktopGateway/ > HTTP/1.1", uupstream: "https:/:443/remoteDesktopGateway/", > host: "" > > Below is my custom config settings: > > ######--------------BEGIN of the script > > server { > listen 80; > server_name ; > # redirect http to https > return 301 https://$server_name$request_uri; > client_max_body_size 0; > proxy_http_version 1.1; > proxy_buffering off; > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection "Upgrade"; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; > > location / { > proxy_pass http://; > } > } > > server { > listen 80; > server_name ; > # redirect http to https > return 301 https://$server_name$request_uri; > client_max_body_size 0; > proxy_http_version 1.1; > proxy_buffering off; > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection "Upgrade"; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; > > location / { > proxy_pass http://; > } > } > > server { > listen 443 ssl; > listen [::]:443 ssl; > server_name ; > ssl_certificate /config/user-data/ssl_chain_essentials.pem; > ssl_certificate_key /config/user-data/ssl_chain_key_essentials.pem; > access_log /var/log/nginx/.access.log; > error_log /var/log/nginx/.error.log; > ssl_session_timeout 1d; > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > ssl_ciphers > > "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; > > ssl_prefer_server_ciphers on; > ssl_session_cache shared:SSL:10m; > #dh param > ssl_dhparam /config/user-data/dhparam.pem; > # Enable HTTP Strict-Transport-Security > # If you have a subdomain of your site, > # be careful to use the 'includeSubdomains' options > add_header Strict-Transport-Security "max-age=63072000; > includeSubdomains; preload"; > # XSS Protection for Nginx web server > add_header X-Frame-Options DENY; > add_header X-XSS-Protection "1; mode=block"; > add_header X-Content-Type-Options nosniff; > ssl_session_cache shared:SSL:10m; > add_header X-Robots-Tag none; > client_max_body_size 0; > proxy_http_version 1.1; > proxy_buffering off; > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection "Upgrade"; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; > location / { > proxy_pass https://; > } > } > > server { > listen 443 ssl; > server_name ; > ssl_certificate /config/user-data/ssl_chain_smartweb.pem; > ssl_certificate_key /config/user-data/ssl_chain_key_smartweb.pem; > access_log /var/log/nginx/.access.log; > error_log /var/log/nginx/.error.log; > ssl_session_timeout 1d; > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > ssl_ciphers > > "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; > ssl_prefer_server_ciphers on; > ssl_session_cache shared:SSL:10m; > #dh param > ssl_dhparam /config/user-data/dhparam.pem; > # Enable HTTP Strict-Transport-Security > # If you have a subdomain of your site, > # be carefull to use the 'includeSubdomains' options > add_header Strict-Transport-Security "max-age=63072000; > includeSubdomains; preload"; > # XSS Protection for Nginx web server > add_header X-Frame-Options DENY; > add_header X-XSS-Protection "1; mode=block"; > add_header X-Content-Type-Options nosniff; > add_header X-Robots-Tag none; > client_max_body_size 0; > proxy_http_version 1.1; > proxy_buffering off; > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection "Upgrade"; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; > location / { > proxy_pass https://:8123; > } > } > #######-----------------end of script---------------------------- > > > Thoughts? > > Thanks. > > JR > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?2,286440,286440#msg-286440 > > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesread5737 at gmail.com Tue Dec 10 23:50:21 2019 From: jamesread5737 at gmail.com (James Read) Date: Tue, 10 Dec 2019 23:50:21 +0000 Subject: Getting started Message-ID: I edited the config file as follows: http { server { location / { root /www; } } ... } I then reloaded the config file with sudo nginx -s reload. I created a test file at /www/index.html then when I tried to load the page in my browser I still got the default Welcome to nginx! page. What am I doing wrong? I also tried editing the page at /usr/share/nginx/html/index.html None of my edits seem to have any effect. When I tried to load the page in my browser I still got the default Welcome to nginx! page. What's going on? thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Wed Dec 11 12:42:26 2019 From: nginx-forum at forum.nginx.org (pixel24) Date: Wed, 11 Dec 2019 07:42:26 -0500 Subject: NGINX only for forwarding to LAN Message-ID: <0d835e7daa7b86b67dd82c17876c44cb.NginxMailingListEnglish@forum.nginx.org> Hi at all, first of all a "hello" to the round. I am new here :-) I want to set up NGINX on my firewall/router (IPFire). But only as reverse proxy. There are no websites running on the IPFire. The IP-Fire has a fixed IP on the WAN interface and can be reached from the Internet. [IPFire] WAN: 10.20.30.40 LAN: 192.168.xx.254 Behind the firewall, i.e. in the LAN, there are several web servers each running on the same port (80) but on different physical servers: [Server1] LAN: 192.168.xx.5 [Server2] LAN: 192.168.xx.6 Furthermore I have an external, official domain (mydomain.de). On the external root server I have created two subdomains which I redirect to the IPFire's fixed IP: gw.mydomain.com -> http://10.20.30.40 cloud.mydomain.com -> http://10.20.30.40 NGINX on the IPfire should now forward all requests directed to gw.mydomain.de to the server 192.168.xx.5 (and tur?ck) and requests addressed to cloud.mydomain.com to LAN: 192.168.xx.6 As far as I know the header has to be rewritten so that the remote client thinks it is communicating with xxxx.mydomain.de and not with 192.168.xx.y. I tried for hours yesterday to get this with examples from the internet but nothing worked. Does this work at all? Can anyone help me? best regards pixel24 Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286443,286443#msg-286443 From nginx-forum at forum.nginx.org Wed Dec 11 19:32:38 2019 From: nginx-forum at forum.nginx.org (roshansh) Date: Wed, 11 Dec 2019 14:32:38 -0500 Subject: Dumping request metadata to local port Message-ID: <0711749fc54dacd2124c462ecc0d3d83.NginxMailingListEnglish@forum.nginx.org> Hi, I am relatively new to NGINX module development so I apologize if the question may seem trivial. I would like to dump data/metadata about certain requests that my nginx server receives for a certain location/ config. Can I write a module that creates a regular C udp socket as well as a handler that works as one of the content phase handlers and dumps the data I want to the localhost port using the socket. Is this safe to do in the first place? Is there any other quicker or easier way to do what I want? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286448,286448#msg-286448 From francis at daoine.org Wed Dec 11 20:21:08 2019 From: francis at daoine.org (Francis Daly) Date: Wed, 11 Dec 2019 20:21:08 +0000 Subject: NGINX only for forwarding to LAN In-Reply-To: <0d835e7daa7b86b67dd82c17876c44cb.NginxMailingListEnglish@forum.nginx.org> References: <0d835e7daa7b86b67dd82c17876c44cb.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191211202108.GR26683@daoine.org> On Wed, Dec 11, 2019 at 07:42:26AM -0500, pixel24 wrote: Hi there, > NGINX on the IPfire should now forward all requests directed to > gw.mydomain.de to the server 192.168.xx.5 (and tur?ck) > > and requests addressed to cloud.mydomain.com to LAN: 192.168.xx.6 Typed, rather than tested and copy-pasted, but the following looks like it should work for the simple case: server { server_name gw.mydomain.com; location / { proxy_pass http://192.168.xx.5; } } server { server_name cloud.mydomain.com; location / { proxy_pass http://192.168.xx.6; } } Depending on what the "upstream" (LAN) web servers do, you might need some more directives there too. If you can report a specific problem -- such as "when I do 'curl -i http://gw.mydomain.com/dir', I get a 301 to http://192.168.xx.5/dir/ but I want a 301 to http://gw.mydomain.com/dir/", then someone may be able to offer an improvement. Good luck with it, f -- Francis Daly francis at daoine.org From francis at daoine.org Wed Dec 11 20:30:41 2019 From: francis at daoine.org (Francis Daly) Date: Wed, 11 Dec 2019 20:30:41 +0000 Subject: Getting started In-Reply-To: References: Message-ID: <20191211203041.GS26683@daoine.org> On Tue, Dec 10, 2019 at 11:50:21PM +0000, James Read wrote: Hi there, nginx uses a single config file, which may "include" other files. When a request comes in to nginx, it chooses one "server" to handle the request; and then (with some exceptions) it chooses one "location" to handle the request. > I edited the config file as follows: > > http { > server { > location / { > root /www; > } > } > ... > } > > I then reloaded the config file with sudo nginx -s reload. I created a test > file at /www/index.html then when I tried to load the page in my browser I > still got the default Welcome to nginx! page. > > What am I doing wrong? One possibility is that your browser had cached its previous request to nginx, so it never asked nginx for the request this time. If you use "curl" to make a test request of the page, it should avoid that possibility. Another possibility is that the config file that you edited is not the config file that the running nginx is using. Or maybe, the server{} that you edited is not the server{} that nginx chooses to handle the particular request that you made. The nginx access log file should show something if the request got to nginx -- that might rule out the first possibility above. The nginx error log -- especially if it is in "debug" mode -- may show far more than you ever want to know about what nginx is doing with a request. That *might* show something about the other possibilities. > I also tried editing the page at /usr/share/nginx/html/index.html None of > my edits seem to have any effect. When I tried to load the page in my > browser I still got the default Welcome to nginx! page. That one is most likely browser caching, I guess. Cheers, f -- Francis Daly francis at daoine.org From francis at daoine.org Wed Dec 11 20:46:08 2019 From: francis at daoine.org (Francis Daly) Date: Wed, 11 Dec 2019 20:46:08 +0000 Subject: proxy_pass in post_action location does not send any http request In-Reply-To: References: Message-ID: <20191211204608.GT26683@daoine.org> On Tue, Dec 03, 2019 at 04:48:23AM -0500, jacks wrote: Hi there, since no-one else has answered this yet... > What am i doing wrong? Without me trying to be clever about it: you're asking for help about post_action. I think that the post_action directive is only documented in src/http/ngx_http_request.c, and that is intentional. If that C-code is not enough to make it totally clear to you what you can and cannot safely do with post_action, then you should not use post_action. (As it happens, that C code is not enough to make it clear to me what I can and cannot safely do with post_action, and so I do not use post_action.) > I am trying to configure NGINX to send another http request after successful > completion of the original proxied request, in order to count statistics > etc' I don't have a good answer that involves post_action. I would probably post-process the access log file, if I had need to do that sort of thing. Or maybe something involving the "mirror" module (if "after successful completion" was not important here). You're welcome to wait for a better answer; but given the status of post_action, I will be (pleasantly) surprised if one is forthcoming. Cheers, f -- Francis Daly francis at daoine.org From jamesread5737 at gmail.com Wed Dec 11 20:54:24 2019 From: jamesread5737 at gmail.com (James Read) Date: Wed, 11 Dec 2019 20:54:24 +0000 Subject: Getting started In-Reply-To: <20191211203041.GS26683@daoine.org> References: <20191211203041.GS26683@daoine.org> Message-ID: On Wed, Dec 11, 2019 at 8:30 PM Francis Daly wrote: > On Tue, Dec 10, 2019 at 11:50:21PM +0000, James Read wrote: > > Hi there, > > nginx uses a single config file, which may "include" other files. > > When a request comes in to nginx, it chooses one "server" to handle > the request; and then (with some exceptions) it chooses one "location" > to handle the request. > > > I edited the config file as follows: > > > > http { > > server { > > location / { > > root /www; > > } > > } > > ... > > } > > > > I then reloaded the config file with sudo nginx -s reload. I created a > test > > file at /www/index.html then when I tried to load the page in my browser > I > > still got the default Welcome to nginx! page. > > > > What am I doing wrong? > > One possibility is that your browser had cached its previous request > to nginx, so it never asked nginx for the request this time. If you > use "curl" to make a test request of the page, it should avoid that > possibility. > > Another possibility is that the config file that you edited is not the > config file that the running nginx is using. > > Or maybe, the server{} that you edited is not the server{} that nginx > chooses to handle the particular request that you made. > > The nginx access log file should show something if the request got to > nginx -- that might rule out the first possibility above. > > The nginx error log -- especially if it is in "debug" mode -- may show far > more than you ever want to know about what nginx is doing with a request. > > That *might* show something about the other possibilities. > > Access log shows that page hasn't changed http code 304: 127.0.0.1 - - [11/Dec/2019:20:46:42 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79 Safari/537.36" > > I also tried editing the page at /usr/share/nginx/html/index.html None of > > my edits seem to have any effect. When I tried to load the page in my > > browser I still got the default Welcome to nginx! page. > > That one is most likely browser caching, I guess. > > Cheers, > > f > -- > Francis Daly francis at daoine.org > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhys.j.ferris at gmail.com Wed Dec 11 21:52:42 2019 From: rhys.j.ferris at gmail.com (Rhys Ferris) Date: Wed, 11 Dec 2019 11:52:42 -1000 Subject: IPv6 to IPv4 Message-ID: <349F20CA-9ECF-4930-AA59-2A6467FF2EA6@gmail.com> Not sure if this is possible. I am trying to enable dual stack for my server, which also proxies several other internal services. Nginx is receiving requests on IPv6 fine, but some of my services are IPv4 only. Can Nginx receive the request on IPv6, retrieve the content from IPv4 internally, and the. Serve the context over IPv6? Thanks Rhys Ferris ? 808-257-2252 ? 757-848-7278 ? rhys.j.ferris at gmail.com Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4310 bytes Desc: not available URL: From osa at freebsd.org.ru Wed Dec 11 23:34:37 2019 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Thu, 12 Dec 2019 02:34:37 +0300 Subject: IPv6 to IPv4 In-Reply-To: <349F20CA-9ECF-4930-AA59-2A6467FF2EA6@gmail.com> References: <349F20CA-9ECF-4930-AA59-2A6467FF2EA6@gmail.com> Message-ID: <20191211233437.GC30344@FreeBSD.org.ru> Hi Rhys, hope you're doing well. Yes, it's definitely possible. The following code snippet does the show: server { listen [::]:80 default ipv6only=on; location / { proxy_pass http://127.0.0.1:8081; } } server { listen 127.0.0.1:8081; location / { return 200 "OK, 127.0.0.1:8081\n"; } } % curl 127.0.0.1:8081 OK, 127.0.0.1:8081 % curl -g -6 "http://[::1]/" OK, 127.0.0.1:8081 On Wed, Dec 11, 2019 at 11:52:42AM -1000, Rhys Ferris wrote: > Not sure if this is possible. I am trying to enable dual stack for my server, which also proxies several other internal services. Nginx is receiving requests on IPv6 fine, but some of my services are IPv4 only. Can Nginx receive the request on IPv6, retrieve the content from IPv4 internally, and the. Serve the context over IPv6? > > Thanks > > Rhys Ferris > ??? 808-257-2252 > ???? 757-848-7278 > ???? rhys.j.ferris at gmail.com From nginx-forum at forum.nginx.org Thu Dec 12 16:02:26 2019 From: nginx-forum at forum.nginx.org (pixel24) Date: Thu, 12 Dec 2019 11:02:26 -0500 Subject: NGINX only for forwarding to LAN In-Reply-To: <20191211202108.GR26683@daoine.org> References: <20191211202108.GR26683@daoine.org> Message-ID: based on the default file, combined with your section, the file now looks like this: worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { server_name gw.mydomain.com; location / { proxy_pass http://192.168.XX.5; } } server { server_name cloud.mydomain.com; location / { proxy_pass http://192.168.XX.6; } } } (domain name and IP changed). However, NGINX does not start: [root at ipfire nginx]# /etc/init.d/nginx restart Stopping nginx Server... [ OK ] Starting nginx Server... nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 32 Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286443,286454#msg-286454 From nginx-forum at forum.nginx.org Thu Dec 12 16:22:10 2019 From: nginx-forum at forum.nginx.org (pixel24) Date: Thu, 12 Dec 2019 11:22:10 -0500 Subject: NGINX only for forwarding to LAN In-Reply-To: References: <20191211202108.GR26683@daoine.org> Message-ID: <22b32eb1fe8dde534dd70d58b5b52f61.NginxMailingListEnglish@forum.nginx.org> the line: server_names_hash_bucket_size 64; in the http-section fix the start-problem but when I try from outside to brwose to: gw.mydomain.com in the webbrowser firefox show me the status: connect to: http://192.168.XX.5 that can't work, can it? This address is not available in inetrnet Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286443,286456#msg-286456 From francis at daoine.org Thu Dec 12 16:24:35 2019 From: francis at daoine.org (Francis Daly) Date: Thu, 12 Dec 2019 16:24:35 +0000 Subject: Getting started In-Reply-To: References: <20191211203041.GS26683@daoine.org> Message-ID: <20191212162435.GU26683@daoine.org> On Wed, Dec 11, 2019 at 08:54:24PM +0000, James Read wrote: Hi there, > Access log shows that page hasn't changed http code 304: > > 127.0.0.1 - - [11/Dec/2019:20:46:42 +0000] "GET / HTTP/1.1" 304 0 "-" > "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/79.0.3945.79 Safari/537.36" That indicates that this browser sent a request of something like "please send me /, if it is newer than (some time in the past)", and nginx said "/ is not newer than then". It does not say anything about whether the "time in the past" corresponded to /usr/local/nginx/html/index.html, and whether "not newer" corresponds to /www/index.html. Maybe neither apply; maybe both do. If you do curl -i http://127.0.0.1/ what content do you get back? Is it from the file that you want it to be? f -- Francis Daly francis at daoine.org From jamesread5737 at gmail.com Thu Dec 12 16:34:17 2019 From: jamesread5737 at gmail.com (James Read) Date: Thu, 12 Dec 2019 16:34:17 +0000 Subject: Getting started In-Reply-To: <20191212162435.GU26683@daoine.org> References: <20191211203041.GS26683@daoine.org> <20191212162435.GU26683@daoine.org> Message-ID: On Thu, Dec 12, 2019 at 4:24 PM Francis Daly wrote: > On Wed, Dec 11, 2019 at 08:54:24PM +0000, James Read wrote: > > Hi there, > > > Access log shows that page hasn't changed http code 304: > > > > 127.0.0.1 - - [11/Dec/2019:20:46:42 +0000] "GET / HTTP/1.1" 304 0 "-" > > "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > > Chrome/79.0.3945.79 Safari/537.36" > > That indicates that this browser sent a request of something like "please > send me /, if it is newer than (some time in the past)", and nginx said > "/ is not newer than then". > > It does not say anything about whether the "time in the past" corresponded > to /usr/local/nginx/html/index.html, and whether "not newer" corresponds > to /www/index.html. Maybe neither apply; maybe both do. > > > If you do > > curl -i http://127.0.0.1/ > > what content do you get back? Is it from the file that you want it to be? > I still get the Welcome to nginx! page. James > > f > -- > Francis Daly francis at daoine.org > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis at daoine.org Thu Dec 12 16:36:33 2019 From: francis at daoine.org (Francis Daly) Date: Thu, 12 Dec 2019 16:36:33 +0000 Subject: NGINX only for forwarding to LAN In-Reply-To: <22b32eb1fe8dde534dd70d58b5b52f61.NginxMailingListEnglish@forum.nginx.org> References: <20191211202108.GR26683@daoine.org> <22b32eb1fe8dde534dd70d58b5b52f61.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191212163633.GV26683@daoine.org> On Thu, Dec 12, 2019 at 11:22:10AM -0500, pixel24 wrote: Hi there, > in the webbrowser firefox show me the status: > > connect to: http://192.168.XX.5 > > that can't work, can it? This address is not available in inetrnet Quoting my previous message: """ If you can report a specific problem -- such as "when I do 'curl -i http://gw.mydomain.com/dir', I get a 301 to http://192.168.xx.5/dir/ but I want a 301 to http://gw.mydomain.com/dir/", then someone may be able to offer an improvement. """ Can you show the very specific request that you make, response that you get, and response that you want instead? Does your web service on http://192.168.XX.5 "just" serve files from the filesystem, or does it try to do clever things with hostnames? Depending on what else is happening, perhaps something like (again, typed and untested): upstream gw.mydomain.com { server 192.168.XX.5; } upstream cloud.mydomain.com { server 192.168.XX.6; } server { server_name gw.mydomain.com; location / { proxy_pass http://gw.mydomain.com; } } server { server_name cloud.mydomain.com; location / { proxy_pass http://cloud.mydomain.com; } } will get closer to what you want. That is - using the hostname in proxy_pass means that the matching Host: header will be sent to the upstream server; so if that server uses the incoming name in a redirection, perhaps the right url will get back to the client. I think that it should not be necessary, because nginx's proxy_redirect should have already handled it. But apparently it did not, in this case. Cheers, f -- Francis Daly francis at daoine.org From francis at daoine.org Thu Dec 12 16:42:08 2019 From: francis at daoine.org (Francis Daly) Date: Thu, 12 Dec 2019 16:42:08 +0000 Subject: Getting started In-Reply-To: References: <20191211203041.GS26683@daoine.org> <20191212162435.GU26683@daoine.org> Message-ID: <20191212164208.GW26683@daoine.org> On Thu, Dec 12, 2019 at 04:34:17PM +0000, James Read wrote: > On Thu, Dec 12, 2019 at 4:24 PM Francis Daly wrote: Hi there, > > If you do > > > > curl -i http://127.0.0.1/ > > > > what content do you get back? Is it from the file that you want it to be? > > > > I still get the Welcome to nginx! page. Your nginx is using a config file. You made a change to a config file. Have you any evidence that the config file you changed is the config file that your nginx is using? "ps -ef | grep nginx" may show if an explicit config file is being used ("-c" argument). If not, "nginx -V" should show the "configure arguments", which will show any --conf-path or --prefix that will indicate the default config file that nginx will use, if it is not the default-default. Cheers, f -- Francis Daly francis at daoine.org From jamesread5737 at gmail.com Thu Dec 12 16:52:25 2019 From: jamesread5737 at gmail.com (James Read) Date: Thu, 12 Dec 2019 16:52:25 +0000 Subject: Getting started In-Reply-To: <20191212164208.GW26683@daoine.org> References: <20191211203041.GS26683@daoine.org> <20191212162435.GU26683@daoine.org> <20191212164208.GW26683@daoine.org> Message-ID: On Thu, Dec 12, 2019 at 4:42 PM Francis Daly wrote: > On Thu, Dec 12, 2019 at 04:34:17PM +0000, James Read wrote: > > On Thu, Dec 12, 2019 at 4:24 PM Francis Daly wrote: > > Hi there, > > > > If you do > > > > > > curl -i http://127.0.0.1/ > > > > > > what content do you get back? Is it from the file that you want it to > be? > > > > > > > I still get the Welcome to nginx! page. > > Your nginx is using a config file. > > You made a change to a config file. > > Have you any evidence that the config file you changed is the config > file that your nginx is using? > > "ps -ef | grep nginx" may show if an explicit config file is being used > ("-c" argument). > > root 903 1 0 Dec11 ? 00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; www-data 9470 903 0 Dec11 ? 00:00:00 nginx: worker process www-data 9471 903 0 Dec11 ? 00:00:00 nginx: worker process www-data 9472 903 0 Dec11 ? 00:00:00 nginx: worker process www-data 9473 903 0 Dec11 ? 00:00:00 nginx: worker process www-data 9474 903 0 Dec11 ? 00:00:00 nginx: worker process www-data 9475 903 0 Dec11 ? 00:00:00 nginx: worker process www-data 9476 903 0 Dec11 ? 00:00:00 nginx: worker process www-data 9477 903 0 Dec11 ? 00:00:00 nginx: worker process yaakov 24793 8371 0 16:49 pts/0 00:00:00 grep --color=auto nginx > If not, "nginx -V" should show the "configure arguments", which will > show any --conf-path or --prefix that will indicate the default config > file that nginx will use, if it is not the default-default. > nginx version: nginx/1.16.1 (Ubuntu) built with OpenSSL 1.1.1c 28 May 2019 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-cVmHmM/nginx-1.16.1=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-compat --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module This is the config file that I edited /etc/nginx/nginx.conf James > > Cheers, > > f > -- > Francis Daly francis at daoine.org > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis at daoine.org Thu Dec 12 17:03:18 2019 From: francis at daoine.org (Francis Daly) Date: Thu, 12 Dec 2019 17:03:18 +0000 Subject: Getting started In-Reply-To: References: <20191211203041.GS26683@daoine.org> <20191212162435.GU26683@daoine.org> <20191212164208.GW26683@daoine.org> Message-ID: <20191212170318.GX26683@daoine.org> On Thu, Dec 12, 2019 at 04:52:25PM +0000, James Read wrote: > On Thu, Dec 12, 2019 at 4:42 PM Francis Daly wrote: Hi there, > > If not, "nginx -V" should show the "configure arguments", which will > > show any --conf-path or --prefix that will indicate the default config > > file that nginx will use, if it is not the default-default. > > nginx version: nginx/1.16.1 (Ubuntu) > built with OpenSSL 1.1.1c 28 May 2019 > TLS SNI support enabled > configure arguments: --with-cc-opt='-g -O2 > --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log > --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock > This is the config file that I edited /etc/nginx/nginx.conf That looks correct to me, thanks. When you do the "reload", do you get anything new at the end of the error_log file, probably /var/log/nginx/error.log? If, for example, there is a config file error, then "reload" will not actually use the new file, and there should be something saying why. If that shows no problems, then something like nginx -T | grep 'server\|listen' should show the "server" blocks, "listen" directives, and "server_name" configurations that nginx will use. If you consider any of the information there private -- names, or public IP addresses, for example -- feel free to edit them; but please do so consistently, so that any patterns remain visible. That configuration fragment may make it possible to learn which server{} nginx uses to handle your test request. Cheers, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Thu Dec 12 18:12:52 2019 From: nginx-forum at forum.nginx.org (pixel24) Date: Thu, 12 Dec 2019 13:12:52 -0500 Subject: NGINX only for forwarding to LAN In-Reply-To: <20191212163633.GV26683@daoine.org> References: <20191212163633.GV26683@daoine.org> Message-ID: <0acaa6130f5ca51305c76bdd1e1e8336.NginxMailingListEnglish@forum.nginx.org> My mistake! On IPFire (running NGINX) port 80 was closed. Now I'm a little closer. With: worker_processes 1; events { worker_connections 1024; } http { server_names_hash_bucket_size 64; include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { server_name gw.mydomain.com; location / { proxy_pass http://192.168.24.109; } } } I can connect from the outside to the web server :-) What surprises me however is that in the address line of Firefox my external WAN-IP of the firewall is located afterwards. Is this normal an ok? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286443,286463#msg-286463 From jamesread5737 at gmail.com Thu Dec 12 18:17:25 2019 From: jamesread5737 at gmail.com (James Read) Date: Thu, 12 Dec 2019 18:17:25 +0000 Subject: Getting started In-Reply-To: <20191212170318.GX26683@daoine.org> References: <20191211203041.GS26683@daoine.org> <20191212162435.GU26683@daoine.org> <20191212164208.GW26683@daoine.org> <20191212170318.GX26683@daoine.org> Message-ID: On Thu, Dec 12, 2019 at 5:03 PM Francis Daly wrote: > On Thu, Dec 12, 2019 at 04:52:25PM +0000, James Read wrote: > > On Thu, Dec 12, 2019 at 4:42 PM Francis Daly wrote: > > Hi there, > > > > If not, "nginx -V" should show the "configure arguments", which will > > > show any --conf-path or --prefix that will indicate the default config > > > file that nginx will use, if it is not the default-default. > > > > nginx version: nginx/1.16.1 (Ubuntu) > > built with OpenSSL 1.1.1c 28 May 2019 > > TLS SNI support enabled > > configure arguments: --with-cc-opt='-g -O2 > > > --conf-path=/etc/nginx/nginx.conf > --http-log-path=/var/log/nginx/access.log > > --error-log-path=/var/log/nginx/error.log > --lock-path=/var/lock/nginx.lock > > > This is the config file that I edited /etc/nginx/nginx.conf > > That looks correct to me, thanks. > > When you do the "reload", do you get anything new at the end of the > error_log file, probably /var/log/nginx/error.log? > > If, for example, there is a config file error, then "reload" will not > actually use the new file, and there should be something saying why. > > > If that shows no problems, then something like > > nginx -T | grep 'server\|listen' > > should show the "server" blocks, "listen" directives, and "server_name" > configurations that nginx will use. > > If you consider any of the information there private -- names, or > public IP addresses, for example -- feel free to edit them; but please > do so consistently, so that any patterns remain visible. > > That configuration fragment may make it possible to learn which server{} > nginx uses to handle your test request. > I found the file /etc/nginx/sites-available/default which has the line: root /var/www/html; I edited the file there and now my edits work. James > > Cheers, > > f > -- > Francis Daly francis at daoine.org > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Fri Dec 13 07:39:49 2019 From: nginx-forum at forum.nginx.org (pixel24) Date: Fri, 13 Dec 2019 02:39:49 -0500 Subject: NGINX only for forwarding to LAN In-Reply-To: <0acaa6130f5ca51305c76bdd1e1e8336.NginxMailingListEnglish@forum.nginx.org> References: <20191212163633.GV26683@daoine.org> <0acaa6130f5ca51305c76bdd1e1e8336.NginxMailingListEnglish@forum.nginx.org> Message-ID: <4e1e57ef748919993923dc587a334afa.NginxMailingListEnglish@forum.nginx.org> problem. I am not allowed to redirect the subdomain on the webserver: gw.mydomain.com --> WAN-IP from IPFire but must set an A-record in the DNA. gw A [WAN-IP from IPfire] now it works unencrypted. I will now get to the setup of LetsEncrypt. But for this I open a new threat. many thanks! Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286443,286465#msg-286465 From francis at daoine.org Fri Dec 13 13:22:35 2019 From: francis at daoine.org (Francis Daly) Date: Fri, 13 Dec 2019 13:22:35 +0000 Subject: NGINX only for forwarding to LAN In-Reply-To: <0acaa6130f5ca51305c76bdd1e1e8336.NginxMailingListEnglish@forum.nginx.org> References: <20191212163633.GV26683@daoine.org> <0acaa6130f5ca51305c76bdd1e1e8336.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191213132235.GY26683@daoine.org> On Thu, Dec 12, 2019 at 01:12:52PM -0500, pixel24 wrote: Hi there, > server { > server_name gw.mydomain.com; > location / { > proxy_pass http://192.168.24.109; > } > } > I can connect from the outside to the web server :-) What surprises me > however is that in the address line of Firefox my external WAN-IP of the > firewall is located afterwards. Is this normal an ok? That indicates that something it wrong somewhere. It will "work" fine when you are reverse-proxying for just one server name; but things will break when you try to add the "cloud" name as well. So you should find which part of your config (nginx, or the internal "gw" server) is writing that WAN IP address, and make it stop. f -- Francis Daly francis at daoine.org From francis at daoine.org Fri Dec 13 13:24:13 2019 From: francis at daoine.org (Francis Daly) Date: Fri, 13 Dec 2019 13:24:13 +0000 Subject: Getting started In-Reply-To: References: <20191211203041.GS26683@daoine.org> <20191212162435.GU26683@daoine.org> <20191212164208.GW26683@daoine.org> <20191212170318.GX26683@daoine.org> Message-ID: <20191213132413.GZ26683@daoine.org> On Thu, Dec 12, 2019 at 06:17:25PM +0000, James Read wrote: > On Thu, Dec 12, 2019 at 5:03 PM Francis Daly wrote: Hi there, > > If that shows no problems, then something like > > > > nginx -T | grep 'server\|listen' > > > > should show the "server" blocks, "listen" directives, and "server_name" > > configurations that nginx will use. > I found the file /etc/nginx/sites-available/default which has the line: > > root /var/www/html; > > I edited the file there and now my edits work. Good stuff; I'm glad that you found the place to make changes that stick. And thank you for letting the list know too; that will help the next person who has the same initial problem. Cheers, f -- Francis Daly francis at daoine.org From jamesread5737 at gmail.com Sat Dec 14 17:37:49 2019 From: jamesread5737 at gmail.com (James Read) Date: Sat, 14 Dec 2019 17:37:49 +0000 Subject: How to customise 404 page Message-ID: Hi, how do I customise the 404 page? http://wotstory.com/doesnotexist I don't want to advertise to the world what web server is running and what operating system is running, James http://wotstory.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Sun Dec 15 07:20:12 2019 From: nginx-forum at forum.nginx.org (sojuro) Date: Sun, 15 Dec 2019 02:20:12 -0500 Subject: Does stream module have support to negotiate ALPN when terminating TLS? Message-ID: <7c107a479428ce01f207ec6e52ee2510.NginxMailingListEnglish@forum.nginx.org> Is there support for forwarding to backends when clients are sending ALPN? I would like to use the stream module if possible. The following nginx config works successfully with a Go client but not with the Ruby client. This is similar to the problem with AWS ELB https://github.com/grpc/grpc/issues/18710 stream { upstream stream_backend_1 { server mygrpcservice:8080; } server { listen 443 ssl; proxy_pass stream_backend_1; ssl_certificate /etc/ssl/test_cert.pem; ssl_certificate_key /etc/ssl/test_key.pem; ssl_preread on; } } With preread on and nginx-debug I got the following in the logs and so the client is sending ALPN data 2019/12/15 03:21:12 [debug] 12#12: *1 ssl preread: ALPN protocols "grpc-exp" 2019/12/15 03:21:12 [debug] 12#12: *1 ssl preread: ALPN protocols "grpc-exp,h2" but the Handshake fails in the grpc library because Server does not set the negotiated ALPN?? D1214 23:00:44.714269000 123145438679040 security_handshaker.cc:186] Security handshake failed: {"created":"@1576393244.714255000","description":"Cannot check peer: missing selected ALPN property.","file":"src/core/lib/security/security_connector/ssl_utils.cc","file_line":118} Also fails with openssl $ openssl s_client -connect test00.net:443 -alpn h2 | grep alpn verify return:1 No ALPN negotiated -s Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286473,286473#msg-286473 From rhys.j.ferris at gmail.com Mon Dec 16 09:14:24 2019 From: rhys.j.ferris at gmail.com (Rhys Ferris) Date: Sun, 15 Dec 2019 23:14:24 -1000 Subject: IPv6 to IPv4 In-Reply-To: <20191211233437.GC30344@FreeBSD.org.ru> References: <349F20CA-9ECF-4930-AA59-2A6467FF2EA6@gmail.com> <20191211233437.GC30344@FreeBSD.org.ru> Message-ID: <9878363b-df97-046b-e883-40df37b933b5@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4452 bytes Desc: S/MIME Cryptographic Signature URL: From pluknet at nginx.com Mon Dec 16 10:36:49 2019 From: pluknet at nginx.com (Sergey Kandaurov) Date: Mon, 16 Dec 2019 13:36:49 +0300 Subject: IPv6 to IPv4 In-Reply-To: <9878363b-df97-046b-e883-40df37b933b5@gmail.com> References: <349F20CA-9ECF-4930-AA59-2A6467FF2EA6@gmail.com> <20191211233437.GC30344@FreeBSD.org.ru> <9878363b-df97-046b-e883-40df37b933b5@gmail.com> Message-ID: <9A7E563F-1831-4B10-AB41-FB3E04C917E4@nginx.com> > On 16 Dec 2019, at 12:14, Rhys Ferris wrote: > > hi, sorry for the extreme delay... i was lazy. > Here's what happens when I connect to my server on IPv6 (mind you, everything works fine if I remove the AAAA record): > 2019/12/15 22:53:44 [crit] 15662#15662: *2225 bind() failed (97: Address family not supported by protocol) while connecting to upstream, client: , server: domain.net, request: "GET /sonarr/plugins/bower_components/bootstrap-select/bootstrap-select.min.js HTTP/2.0", upstream: > "http://192.168.136.135:8989/sonarr/plugins/bower_components/boots > trap-select/bootstrap-select.min.js" > , host: "domain.net", referrer: "https://domain.net/sonarr/" > > [...] > > The way I'm reading it is that it is trying to connect from IPv6 source interface to IPv4 destination interface, and well, that obviously doesn't work. Here's my configs > nginx.conf > Your analysis looks correct (see below). > [..] > > excerpt of domain.net.conf > > > ##Orgv2 Let's encrypt vhost - Non SSL > ##vhost_template_v: v1.0.2 > ##author: elmerfdz > > ## > http://domain.net redirects to https://domain.net > > # include config/domain.net/http_server.conf; > upstream sonarr-upstream { server 192.168.136.135:8989; } > upstream radarr-upstream { server 192.168.136.135:7878; } > upstream tautulli-upstream { server 192.168.136.141:8181; } > upstream webmin-upstream { server 192.168.136.130:10000; } > > ## Serves > https://www.domain.net > > server { > listen 443 ssl http2; listen [::]:443 ssl http2; > server_name domain.net; > include /etc/nginx/config/domain.net/ssl.conf; #edit path to your certs > root /var/www/domain.net/html; > index index.php index.html index.htm index.nginx-debian.html; > location ~ /auth-(.*) { rewrite ^/auth-(.*) /api/?v1/auth&group=$1; } #Org Auth > error_page 400 401 403 404 405 408 500 502 503 504 /?error=$status; #error page > location / {try_files $uri $uri/ =404;} > include config/domain.net/phpblock.conf; #PHP Block > location /sonarr/ { > proxy_pass > http://sonarr-upstream > ; > include config/domain.net/proxy.conf; > error_page 400 401 403 404 405 408 500 502 503 504 /?error=$status; #error page > } > ssl_certificate /etc/letsencrypt/live/domain.net/fullchain.pem; # managed by Certbot > ssl_certificate_key /etc/letsencrypt/live/domain.net/privkey.pem; # managed by Certbot > > > And on the off chance you need it, heres proxy.conf > > client_max_body_size 10m; > client_body_buffer_size 128k; > proxy_bind $server_addr; Try removing this directive, that's likely the culprit. Your backend addresses are IPv4, while you're trying binding IPv6 ($server_addr), hence address family mismatch. That's not going to work. -- Sergey Kandaurov From sca at andreasschulze.de Mon Dec 16 12:10:56 2019 From: sca at andreasschulze.de (A. Schulze) Date: Mon, 16 Dec 2019 13:10:56 +0100 Subject: How to customise 404 page In-Reply-To: Message-ID: <20191216131056.Horde.9v5remL8Ivs37LvIvCQDnGR@andreasschulze.de> James Read: > Hi, > > how do I customise the 404 page? http://wotstory.com/doesnotexist I don't > want to advertise to the world what web server is running and what > operating system is running, see https://nginx.org/r/error_page From rhys.j.ferris at gmail.com Mon Dec 16 17:44:47 2019 From: rhys.j.ferris at gmail.com (Rhys Ferris) Date: Mon, 16 Dec 2019 07:44:47 -1000 Subject: IPv6 to IPv4 In-Reply-To: <9A7E563F-1831-4B10-AB41-FB3E04C917E4@nginx.com> References: <349F20CA-9ECF-4930-AA59-2A6467FF2EA6@gmail.com> <20191211233437.GC30344@FreeBSD.org.ru> <9878363b-df97-046b-e883-40df37b933b5@gmail.com> <9A7E563F-1831-4B10-AB41-FB3E04C917E4@nginx.com> Message-ID: THANKS SO MUCH! One of those things where I started with something someone else built without fully understanding it. Learning as I go. Thanks again! Rhys On 12/16/19 12:36 AM, Sergey Kandaurov wrote: >> On 16 Dec 2019, at 12:14, Rhys Ferris wrote: >> >> hi, sorry for the extreme delay... i was lazy. >> Here's what happens when I connect to my server on IPv6 (mind you, everything works fine if I remove the AAAA record): >> 2019/12/15 22:53:44 [crit] 15662#15662: *2225 bind() failed (97: Address family not supported by protocol) while connecting to upstream, client: , server: domain.net, request: "GET /sonarr/plugins/bower_components/bootstrap-select/bootstrap-select.min.js HTTP/2.0", upstream: >> "http://192.168.136.135:8989/sonarr/plugins/bower_components/boots >> trap-select/bootstrap-select.min.js" >> , host: "domain.net", referrer: "https://domain.net/sonarr/" >> >> [...] >> >> The way I'm reading it is that it is trying to connect from IPv6 source interface to IPv4 destination interface, and well, that obviously doesn't work. Here's my configs >> nginx.conf >> > Your analysis looks correct (see below). > >> [..] >> >> excerpt of domain.net.conf >> >> >> ##Orgv2 Let's encrypt vhost - Non SSL >> ##vhost_template_v: v1.0.2 >> ##author: elmerfdz >> >> ## >> http://domain.net redirects to https://domain.net >> >> # include config/domain.net/http_server.conf; >> upstream sonarr-upstream { server 192.168.136.135:8989; } >> upstream radarr-upstream { server 192.168.136.135:7878; } >> upstream tautulli-upstream { server 192.168.136.141:8181; } >> upstream webmin-upstream { server 192.168.136.130:10000; } >> >> ## Serves >> https://www.domain.net >> >> server { >> listen 443 ssl http2; listen [::]:443 ssl http2; >> server_name domain.net; >> include /etc/nginx/config/domain.net/ssl.conf; #edit path to your certs >> root /var/www/domain.net/html; >> index index.php index.html index.htm index.nginx-debian.html; >> location ~ /auth-(.*) { rewrite ^/auth-(.*) /api/?v1/auth&group=$1; } #Org Auth >> error_page 400 401 403 404 405 408 500 502 503 504 /?error=$status; #error page >> location / {try_files $uri $uri/ =404;} >> include config/domain.net/phpblock.conf; #PHP Block >> location /sonarr/ { >> proxy_pass >> http://sonarr-upstream >> ; >> include config/domain.net/proxy.conf; >> error_page 400 401 403 404 405 408 500 502 503 504 /?error=$status; #error page >> } >> ssl_certificate /etc/letsencrypt/live/domain.net/fullchain.pem; # managed by Certbot >> ssl_certificate_key /etc/letsencrypt/live/domain.net/privkey.pem; # managed by Certbot >> >> >> And on the off chance you need it, heres proxy.conf >> >> client_max_body_size 10m; >> client_body_buffer_size 128k; >> proxy_bind $server_addr; > Try removing this directive, that's likely the culprit. > Your backend addresses are IPv4, while you're trying binding IPv6 ($server_addr), > hence address family mismatch. That's not going to work. > -- Sent from Thunderbird on Ubuntu 19.04 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4452 bytes Desc: S/MIME Cryptographic Signature URL: From jasper at arcolaenergy.com Mon Dec 16 17:45:55 2019 From: jasper at arcolaenergy.com (Jasper Wallace) Date: Mon, 16 Dec 2019 17:45:55 +0000 Subject: flood detected with file uploads over http2 Message-ID: We are having intermittent problems uploading files via nginx to a flask backend over http2: 2019/12/16 16:07:08 [debug] 27658#27658: *1 event timer: 3, old: 1576512608187, new: 1576512608301 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 idle handler 2019/12/16 16:07:08 [info] 27658#27658: *1 http2 flood detected while processing HTTP/2 connection, client: x.x.x.x, server: 0.0.0.0:443 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 send GOAWAY frame, status:0 2019/12/16 16:07:08 [debug] 27658#27658: *1 posix_memalign: 0000563642B8EE20:512 @16 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 frame out: 0000563642B8EE40 sid:0 bl:0 len:8 2019/12/16 16:07:08 [debug] 27658#27658: *1 malloc: 0000563642D0A870:16384 2019/12/16 16:07:08 [debug] 27658#27658: *1 SSL buf copy: 17 2019/12/16 16:07:08 [debug] 27658#27658: *1 SSL to write: 17 Is there anyway of getting information on what might be triggering this? We've changed some defaults: client_max_body_size 10m; http2_body_preread_size 256k; http2_recv_buffer_size 1m; proxy_headers_hash_max_size 512; proxy_headers_hash_bucket_size 128; Client is Chrome: Version 78.0.3904.97 (Developer Build) built on Debian 10.1, running on Debian 10.2 (64-bit) openssl: OpenSSL 1.1.0l 10 Sep 2019 nginx: nginx version: nginx/1.10.3 built with OpenSSL 1.1.0k 28 May 2019 (running with OpenSSL 1.1.0l 10 Sep 2019) TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-DhOtPd/nginx-1.10.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_secure_link_module --with-http_sub_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/headers-more-nginx-module --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-auth-pam --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-cache-purge --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-dav-ext-module --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-development-kit --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-echo --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/ngx-fancyindex --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nchan --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-lua --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-upload-progress --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-upstream-fair --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/ngx_http_substitutions_filter_module -- Your hydrogen & fuel cell partner Arcola Energy Ltd, 24 Ashwin Street, London E8 3DL. www.arcolaenergy.com / +44 20 7503 1386 Registered in England and Wales, Company Number 7257863, VAT Number 110085273. Copyright 2019. Confidential and Proprietary. Not to be disseminated or copied in full or in part. From ru at nginx.com Tue Dec 17 09:13:34 2019 From: ru at nginx.com (Ruslan Ermilov) Date: Tue, 17 Dec 2019 12:13:34 +0300 Subject: flood detected with file uploads over http2 In-Reply-To: References: Message-ID: <20191217091334.GA53060@lo0.su> On Mon, Dec 16, 2019 at 05:45:55PM +0000, Jasper Wallace wrote: > We are having intermittent problems uploading files via nginx to a > flask backend over http2: > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 event timer: 3, old: > 1576512608187, new: 1576512608301 > 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 idle handler > 2019/12/16 16:07:08 [info] 27658#27658: *1 http2 flood detected while > processing HTTP/2 connection, client: x.x.x.x, server: 0.0.0.0:443 > 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 send GOAWAY frame, status:0 > 2019/12/16 16:07:08 [debug] 27658#27658: *1 posix_memalign: > 0000563642B8EE20:512 @16 > 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 frame out: > 0000563642B8EE40 sid:0 bl:0 len:8 > 2019/12/16 16:07:08 [debug] 27658#27658: *1 malloc: 0000563642D0A870:16384 > 2019/12/16 16:07:08 [debug] 27658#27658: *1 SSL buf copy: 17 > 2019/12/16 16:07:08 [debug] 27658#27658: *1 SSL to write: 17 > > Is there anyway of getting information on what might be triggering this? > > We've changed some defaults: > > client_max_body_size 10m; > http2_body_preread_size 256k; > http2_recv_buffer_size 1m; > proxy_headers_hash_max_size 512; > proxy_headers_hash_bucket_size 128; > > Client is Chrome: > > Version 78.0.3904.97 (Developer Build) built on Debian 10.1, running > on Debian 10.2 (64-bit) > > openssl: > > OpenSSL 1.1.0l 10 Sep 2019 > > nginx: > > nginx version: nginx/1.10.3 > built with OpenSSL 1.1.0k 28 May 2019 (running with OpenSSL 1.1.0l > 10 Sep 2019) > TLS SNI support enabled > configure arguments: --with-cc-opt='-g -O2 > -fdebug-prefix-map=/build/nginx-DhOtPd/nginx-1.10.3=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' > --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf > --http-log-path=/var/log/nginx/access.log > --error-log-path=/var/log/nginx/error.log > --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid > --modules-path=/usr/lib/nginx/modules > --http-client-body-temp-path=/var/lib/nginx/body > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > --http-proxy-temp-path=/var/lib/nginx/proxy > --http-scgi-temp-path=/var/lib/nginx/scgi > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug > --with-pcre-jit --with-ipv6 --with-http_ssl_module > --with-http_stub_status_module --with-http_realip_module > --with-http_auth_request_module --with-http_v2_module > --with-http_dav_module --with-http_slice_module --with-threads > --with-http_addition_module --with-http_flv_module > --with-http_geoip_module=dynamic --with-http_gunzip_module > --with-http_gzip_static_module --with-http_image_filter_module=dynamic > --with-http_mp4_module --with-http_perl_module=dynamic > --with-http_random_index_module --with-http_secure_link_module > --with-http_sub_module --with-http_xslt_module=dynamic > --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic > --with-stream_ssl_module > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/headers-more-nginx-module > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-auth-pam > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-cache-purge > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-dav-ext-module > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-development-kit > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-echo > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/ngx-fancyindex > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nchan > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-lua > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-upload-progress > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-upstream-fair > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/ngx_http_substitutions_filter_module nginx/1.10.3 doesn't have HTTP/2 flood detection. It appeared in later versions. From sylvain.amrani at gmail.com Tue Dec 17 10:06:19 2019 From: sylvain.amrani at gmail.com (Sylvain Amrani) Date: Tue, 17 Dec 2019 11:06:19 +0100 Subject: Authorization identity for IMAP proxy Message-ID: Hi list, IMAP servers (dovecot, cyrus...) rely on SASL authentication. The SASL specs let the client requests a different identity than the one used for authentication. RFC 3501 says : The authorization identity passed from the client to the server during the authentication exchange is interpreted by the server as the user name whose privileges the client is requesting. Dovecot proxy and Cyrus frontends in murder architecture use this to authenticate with an admin account and request a user identity. It's very useful to authenticate via proxies without to know the user's password. Is there a way to let NGINX use different identification and authentication ids to authenticate to the remote imap server ? I can't figure out what to put in the AUTH-* headers to do that. Regards, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasper at arcolaenergy.com Tue Dec 17 13:37:54 2019 From: jasper at arcolaenergy.com (Jasper Wallace) Date: Tue, 17 Dec 2019 13:37:54 +0000 Subject: flood detected with file uploads over http2 In-Reply-To: <20191217091334.GA53060@lo0.su> References: <20191217091334.GA53060@lo0.su> Message-ID: Hmmm, maybe it got packported by Debian... I think we'll just disable http2 for the time being. On Tue, 17 Dec 2019 at 09:13, Ruslan Ermilov wrote: > > On Mon, Dec 16, 2019 at 05:45:55PM +0000, Jasper Wallace wrote: > > We are having intermittent problems uploading files via nginx to a > > flask backend over http2: > > > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 event timer: 3, old: > > 1576512608187, new: 1576512608301 > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 idle handler > > 2019/12/16 16:07:08 [info] 27658#27658: *1 http2 flood detected while > > processing HTTP/2 connection, client: x.x.x.x, server: 0.0.0.0:443 > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 send GOAWAY frame, status:0 > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 posix_memalign: > > 0000563642B8EE20:512 @16 > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 frame out: > > 0000563642B8EE40 sid:0 bl:0 len:8 > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 malloc: 0000563642D0A870:16384 > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 SSL buf copy: 17 > > 2019/12/16 16:07:08 [debug] 27658#27658: *1 SSL to write: 17 > > > > Is there anyway of getting information on what might be triggering this? > > > > We've changed some defaults: > > > > client_max_body_size 10m; > > http2_body_preread_size 256k; > > http2_recv_buffer_size 1m; > > proxy_headers_hash_max_size 512; > > proxy_headers_hash_bucket_size 128; > > > > Client is Chrome: > > > > Version 78.0.3904.97 (Developer Build) built on Debian 10.1, running > > on Debian 10.2 (64-bit) > > > > openssl: > > > > OpenSSL 1.1.0l 10 Sep 2019 > > > > nginx: > > > > nginx version: nginx/1.10.3 > > built with OpenSSL 1.1.0k 28 May 2019 (running with OpenSSL 1.1.0l > > 10 Sep 2019) > > TLS SNI support enabled > > configure arguments: --with-cc-opt='-g -O2 > > -fdebug-prefix-map=/build/nginx-DhOtPd/nginx-1.10.3=. > > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > > -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' > > --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf > > --http-log-path=/var/log/nginx/access.log > > --error-log-path=/var/log/nginx/error.log > > --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid > > --modules-path=/usr/lib/nginx/modules > > --http-client-body-temp-path=/var/lib/nginx/body > > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > > --http-proxy-temp-path=/var/lib/nginx/proxy > > --http-scgi-temp-path=/var/lib/nginx/scgi > > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug > > --with-pcre-jit --with-ipv6 --with-http_ssl_module > > --with-http_stub_status_module --with-http_realip_module > > --with-http_auth_request_module --with-http_v2_module > > --with-http_dav_module --with-http_slice_module --with-threads > > --with-http_addition_module --with-http_flv_module > > --with-http_geoip_module=dynamic --with-http_gunzip_module > > --with-http_gzip_static_module --with-http_image_filter_module=dynamic > > --with-http_mp4_module --with-http_perl_module=dynamic > > --with-http_random_index_module --with-http_secure_link_module > > --with-http_sub_module --with-http_xslt_module=dynamic > > --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic > > --with-stream_ssl_module > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/headers-more-nginx-module > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-auth-pam > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-cache-purge > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-dav-ext-module > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-development-kit > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-echo > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/ngx-fancyindex > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nchan > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-lua > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-upload-progress > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/nginx-upstream-fair > > --add-dynamic-module=/build/nginx-DhOtPd/nginx-1.10.3/debian/modules/ngx_http_substitutions_filter_module > > nginx/1.10.3 doesn't have HTTP/2 flood detection. It appeared > in later versions. > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx -- Your hydrogen & fuel cell partner Arcola Energy Ltd, 24 Ashwin Street, London E8 3DL. www.arcolaenergy.com / +44 20 7503 1386 Registered in England and Wales, Company Number 7257863, VAT Number 110085273. Copyright 2019. Confidential and Proprietary. Not to be disseminated or copied in full or in part. From gfrankliu at gmail.com Wed Dec 18 02:37:58 2019 From: gfrankliu at gmail.com (Frank Liu) Date: Tue, 17 Dec 2019 18:37:58 -0800 Subject: proxy module handling early responses Message-ID: Hi, When using nginx as a reverse proxy, in case of a large POST payload, what does nginx do when upstream server sends response before nginx finishes posting the full payload? One use case is upstream enforces some payload limit and sends a HTTP/413 response when the payload read reaches certain limit. Will nginx catch this error, stop sending further, and return the 413 to client? I see a stackoverflow discussion for a different use case, not sure how nginx behaves. Regards, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Wed Dec 18 09:48:33 2019 From: nginx-forum at forum.nginx.org (deeztek) Date: Wed, 18 Dec 2019 04:48:33 -0500 Subject: nginx reverse proxy proxy_pass weirdness Message-ID: I have a nginx reverse proxy to forward requests to various Apache websites behind it. This all seems to work fine unless I remove one of the proxy_pass configurations from nginx. Even though I remove it, nginx still fowards the requests back to Apache to a seemingly random website this time. I can't seem to get it to stop doing that. Any idea what's going on? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286492,286492#msg-286492 From francis at daoine.org Wed Dec 18 10:37:54 2019 From: francis at daoine.org (Francis Daly) Date: Wed, 18 Dec 2019 10:37:54 +0000 Subject: nginx reverse proxy proxy_pass weirdness In-Reply-To: References: Message-ID: <20191218103754.GD26683@daoine.org> On Wed, Dec 18, 2019 at 04:48:33AM -0500, deeztek wrote: Hi there, > I have a nginx reverse proxy to forward requests to various Apache websites > behind it. This all seems to work fine unless I remove one of the proxy_pass > configurations from nginx. Even though I remove it, nginx still fowards the > requests back to Apache to a seemingly random website this time. > > I can't seem to get it to stop doing that. Any idea what's going on? The server{} and location{} that you have configured nginx to use for this request may not be the server{} and location{} that you want nginx to use for this request. If you can show the configuration and the request, and say how you want nginx to handle the request, maybe it will be clear what changes to the configuration are needed. Cheers, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Wed Dec 18 12:18:32 2019 From: nginx-forum at forum.nginx.org (deeztek) Date: Wed, 18 Dec 2019 07:18:32 -0500 Subject: nginx reverse proxy proxy_pass weirdness In-Reply-To: <20191218103754.GD26683@daoine.org> References: <20191218103754.GD26683@daoine.org> Message-ID: Here's an example config that I use: server { server_name domain.tld www.domain.tld; add_header Strict-Transport-Security "max-age=31536000; preload"; keepalive_timeout 70; #LOGS CONFIG access_log /usr/local/nginx/logs/domain.tld/domain.tld_access.log; error_log /usr/local/nginx/logs/domain.tld/domain.tld_error.log warn; #SSL CONFIG ssl_certificate /etc/nginx/ssl/domain.tld.pem; ssl_certificate_key /etc/nginx/ssl/domain.tld.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; ssl_dhparam /usr/local/nginx/ssl/dhparam.pem; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; proxy_max_temp_file_size 5120m; client_max_body_size 5120m; #set_real_ip_from 192.168.xx.xx/24; #real_ip_header X-Forwarded-For; #real_ip_recursive on; #LISTEN CONFIG include /usr/local/nginx/conf/listen/domain.tld/*.conf; #MODSECURITY CONFIG modsecurity on; modsecurity_rules_file /usr/local/nginx/conf/domain.tld_modsecurity.conf; location / { #Set Real IP Headers proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Host $host; #proxy_set_header X-Real-IP $remote_addr; #proxy_set_header Host $host; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass https://webserver02.domain.tld:443; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286492,286494#msg-286494 From francis at daoine.org Wed Dec 18 12:53:13 2019 From: francis at daoine.org (Francis Daly) Date: Wed, 18 Dec 2019 12:53:13 +0000 Subject: nginx reverse proxy proxy_pass weirdness In-Reply-To: References: <20191218103754.GD26683@daoine.org> Message-ID: <20191218125313.GE26683@daoine.org> On Wed, Dec 18, 2019 at 07:18:32AM -0500, deeztek wrote: Hi there, > Here's an example config that I use: Thanks. Note that it is possible that the "include" files contain some relevant config; but we can worry about that if it looks like it is the case. What request do you make? What response do you get? What response do you want to get instead? f -- Francis Daly francis at daoine.org From mdounin at mdounin.ru Wed Dec 18 15:21:50 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 18 Dec 2019 18:21:50 +0300 Subject: proxy module handling early responses In-Reply-To: References: Message-ID: <20191218152150.GW12894@mdounin.ru> Hello! On Tue, Dec 17, 2019 at 06:37:58PM -0800, Frank Liu wrote: > When using nginx as a reverse proxy, in case of a large POST payload, what > does nginx do when upstream server sends response before nginx finishes > posting the full payload? > > One use case is upstream enforces some payload limit and sends a HTTP/413 > response when the payload read reaches certain limit. Will nginx catch this > error, stop sending further, and return the 413 to client? Exactly. -- Maxim Dounin http://mdounin.ru/ From nginx-forum at forum.nginx.org Wed Dec 18 15:33:44 2019 From: nginx-forum at forum.nginx.org (deeztek) Date: Wed, 18 Dec 2019 10:33:44 -0500 Subject: nginx reverse proxy proxy_pass weirdness In-Reply-To: <20191218125313.GE26683@daoine.org> References: <20191218125313.GE26683@daoine.org> Message-ID: <783b9957071e633063a8275cbea6c139.NginxMailingListEnglish@forum.nginx.org> Sorry maybe I am confusing you. The config file that I posted, works fine. What I request actually responds. So, if I were to request www.domain.tld, the Apache server behind Nginx responds with the correct website for www.domain.tld. However, if I were to delete the config file for domain.tld from nginx and I tried to browse to that domain again, nginx would forward the request to another (seemingly random?) website on Apache behind it. I would think, deleting a config from Nginx, it would simply stop forwarding requests for that cofig. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286492,286499#msg-286499 From francis at daoine.org Wed Dec 18 16:28:16 2019 From: francis at daoine.org (Francis Daly) Date: Wed, 18 Dec 2019 16:28:16 +0000 Subject: nginx reverse proxy proxy_pass weirdness In-Reply-To: <783b9957071e633063a8275cbea6c139.NginxMailingListEnglish@forum.nginx.org> References: <20191218125313.GE26683@daoine.org> <783b9957071e633063a8275cbea6c139.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191218162816.GF26683@daoine.org> On Wed, Dec 18, 2019 at 10:33:44AM -0500, deeztek wrote: Hi there, > Sorry maybe I am confusing you. The config file that I posted, works fine. > What I request actually responds. So, if I were to request www.domain.tld, > the Apache server behind Nginx responds with the correct website for > www.domain.tld. However, if I were to delete the config file for domain.tld > from nginx and I tried to browse to that domain again, nginx would forward > the request to another (seemingly random?) website on Apache behind it. Ok, that makes sense to me now, thanks. You are deleting a full server{} block; not just a single directive within a server{} block. http://nginx.org/en/docs/http/request_processing.html has the details on what nginx is doing. In short - a request comes in on an ip:port, with a Host header. If nginx has a listener on that ip:port that handles that Host header, the matching server{} is used to handle the request. If not, then the default server for that ip:port handles the request. You can configure which server is the default_server for this ip:port on the "listen" line (http://nginx.org/r/listen). > I would think, deleting a config from Nginx, it would simply stop forwarding > requests for that cofig. Historical reasons / backwards compatibility / overall convenience means that that isn't what happens by default. You can configure it to happen on your system, if you want it to, by configuring your default server for this ip:port explicitly, and having that server drop the connection, or return 404 or 410, or return useful content advertising your hosting service. That is part of the answer to "what response do you want to get instead?". Cheers, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Wed Dec 18 17:35:22 2019 From: nginx-forum at forum.nginx.org (deeztek) Date: Wed, 18 Dec 2019 12:35:22 -0500 Subject: nginx reverse proxy proxy_pass weirdness In-Reply-To: <20191218162816.GF26683@daoine.org> References: <20191218162816.GF26683@daoine.org> Message-ID: okay that explains it. I appreciate that. So, a default config with the following: server { listen 80 default_server; return 444; } Should take care of it? How would I got about doing a default SSL config since it would complain about the certificate? Thanks Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286492,286503#msg-286503 From gfrankliu at gmail.com Wed Dec 18 18:09:56 2019 From: gfrankliu at gmail.com (Frank Liu) Date: Wed, 18 Dec 2019 10:09:56 -0800 Subject: proxy module handling early responses In-Reply-To: <20191218152150.GW12894@mdounin.ru> References: <20191218152150.GW12894@mdounin.ru> Message-ID: Our upstream returns HTTP/413 along with "Connection: close" in the header, then closes the socket. It seems nginx catches the socket close in the middle of sending the large payload. This triggers additional 502 and client gets both 413 and 502 from nginx. On Wed, Dec 18, 2019 at 7:22 AM Maxim Dounin wrote: > Hello! > > On Tue, Dec 17, 2019 at 06:37:58PM -0800, Frank Liu wrote: > > > When using nginx as a reverse proxy, in case of a large POST payload, > what > > does nginx do when upstream server sends response before nginx finishes > > posting the full payload? > > > > One use case is upstream enforces some payload limit and sends a HTTP/413 > > response when the payload read reaches certain limit. Will nginx catch > this > > error, stop sending further, and return the 413 to client? > > Exactly. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Dec 18 19:37:29 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 18 Dec 2019 22:37:29 +0300 Subject: proxy module handling early responses In-Reply-To: References: <20191218152150.GW12894@mdounin.ru> Message-ID: <20191218193729.GY12894@mdounin.ru> Hello! On Wed, Dec 18, 2019 at 10:09:56AM -0800, Frank Liu wrote: > Our upstream returns HTTP/413 along with "Connection: close" in the header, > then closes the socket. It seems nginx catches the socket close in the > middle of sending the large payload. This triggers additional 502 and > client gets both 413 and 502 from nginx. Your upstream server's behaviour is incorrect: it have to continue reading data in the socket buffers and in transit (usually this is called "lingering close", see http://nginx.org/r/lingering_close), or nginx simply won't get the response. The client will get simple and quite reasonable 502 in such a situation (not "413 and 502"). This problem is explicitly documented in RFC 7230, "6.6. Tear-down" (https://tools.ietf.org/html/rfc7230#section-6.6): If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able to read the last HTTP response. If the server receives additional data from the client on a fully closed connection, such as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they can be read and interpreted by the client's HTTP parser. To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by closing only the write side of the read/write connection. The server then continues to read from the connection until it receives a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection. If the upstream server fails to do connection teardown properly, the only option is to fix the upstream server: it should either implemenent proper connection teardown, or avoid returning responses without reading the request body first. -- Maxim Dounin http://mdounin.ru/ From shahzaib.cb at gmail.com Wed Dec 18 20:08:00 2019 From: shahzaib.cb at gmail.com (shahzaib mushtaq) Date: Thu, 19 Dec 2019 01:08:00 +0500 Subject: NGINX SMTP! Message-ID: Hi, We want to achieve following with nginx smtp, please let me know if that's possible and can you help me with that ? 1) Our software will connect to NGinx on port 25 and will authenticate with the NGinx in the same manner as it would to SMTP Server. 3) NGinx should then authenticate against an internal UserID and Password and not our Internal SMTP Server. 4) If authenticated it should either accept the email from the software, or it should pass through the connection to the internal mail server with authentication that is on our internal mail server so the emails will be captured in the mailbox created for the software to allow for email tracking. =========================== I am more concerned about 3rd step, is there some authentication that i can use to verify request within nginx before it can forward it to internal mail server? Thanks in advance. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis at daoine.org Thu Dec 19 12:07:49 2019 From: francis at daoine.org (Francis Daly) Date: Thu, 19 Dec 2019 12:07:49 +0000 Subject: nginx reverse proxy proxy_pass weirdness In-Reply-To: References: <20191218162816.GF26683@daoine.org> Message-ID: <20191219120749.GG26683@daoine.org> On Wed, Dec 18, 2019 at 12:35:22PM -0500, deeztek wrote: Hi there, > server { > listen 80 default_server; > return 444; > } > > Should take care of it? Yes. (So long as every explicit-or-implicit "listen" directive is equivalent to "listen 80", which it probably is.) > How would I got about doing a default SSL config since it would complain > about the certificate? Same thing, essentially. What response do you want, for the request? http://nginx.org/en/docs/http/configuring_https_servers.html A connection comes to an ip:port. The TLS handshake from the client includes a SNI name that you have configured a listener to handle, so your nginx sends the appropriate certificate; or the handshake does not (because it sends no SNI name, or it sends a SNI name that you have not configured a listener to handle), so your nginx sends the certificate associated with the default_server for that ip:port. If the client agrees the handshake and sends the request, your nginx responds the way you configured it to; if the client does not agree the handshake, they go away without sending the request. f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Thu Dec 19 21:23:54 2019 From: nginx-forum at forum.nginx.org (ctaylor) Date: Thu, 19 Dec 2019 16:23:54 -0500 Subject: DNS Over HTTPS Module Message-ID: <0c65ef87440297eccf82c549256f0ef1.NginxMailingListEnglish@forum.nginx.org> Hello all, I don't know if this is the right place to post this, but I've written a simple DNS over HTTPS module that's been working for me so I thought I would post a link here in case anyone else was interested in that sort of thing. https://github.com/themagister/Nginx-DOH-Module Regards, C. Taylor Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286520,286520#msg-286520 From shahzaib.cb at gmail.com Fri Dec 20 11:29:38 2019 From: shahzaib.cb at gmail.com (shahzaib mushtaq) Date: Fri, 20 Dec 2019 16:29:38 +0500 Subject: Nginx SMTP relay access denied! Message-ID: Hi, We've setup NGINX SMTP proxy in front of postfix. When i try to telnet to nginx smtp on port 25 it shows the "relay access denied" message.: https://pastebin.com/JF4TVqBw Here is the config of nginx: mail { server_name mail.domain.com; auth_http localhost:80/auth.php; proxy_pass_error_message on; server { listen 25; protocol smtp; timeout 300s; proxy on; xclient off; smtp_auth none plain; # auth_http_header HTTP_AUTH_USER Auth-User; # auth_http_header HTTP_AUTH_PASS Auth-Pass; smtp_capabilities "AUTH PLAIN"; } Following is the content of auth.php that we're using : https://pastebin.com/q49EC67N What we want is that, any user tries to connect to Nginx SMTP proxy to send email should be authenticated to backend. Is that possible? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Fri Dec 20 11:32:58 2019 From: nginx-forum at forum.nginx.org (vikask) Date: Fri, 20 Dec 2019 06:32:58 -0500 Subject: Wordpress not able to display theme properly - FastCGI sent in stderr: "Primary script unknown" Message-ID: <8c320093d947ddf86e7c6952ff7c1186.NginxMailingListEnglish@forum.nginx.org> I have installed Wordpress in a subdirectory - /var/www/html/stage I am getting the following error in the error log. I think the filename being passed has the subdirectory name prepended, which should not happen. ----- 2019/12/20 15:34:00 [error] 22393#22393: *10 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 110.227.251.142, server: mywebsite.com, request: "GET /stage/%20https://mywebsite.com/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x797.jpg HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "fp-academy.in", referrer: "https://fp-academy.in/stage/" 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 01 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 06 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 00 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 01 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 00 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 51 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 07 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record byte: 00 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi record length: 81 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi parser: 0 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi header: "Status: 404 Not Found" 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi parser: 0 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi header: "Content-type: text/html; charset=UTF-8" 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi parser: 1 2019/12/20 15:34:00 [debug] 22393#22393: *10 http fastcgi header done 2019/12/20 15:34:00 [debug] 22393#22393: *10 HTTP/1.1 404 Not Found ---/etc/nginx/sites-enabled/default looks like this server { # We're deliberately leaving this as-is to avoid conflict at the moment root /var/www/html; server_name mywebsite.com www.mywebsite.com; # rewrite ^/moodle/(.*\.php)(/)(.*)$ /moodle/$1?file=/$3 last; # rewrite ^(..php)(/)(.)$ $1?file=/$3 last; index index.php index.html index.htm login.php; # if you get errors enable the line below and find out errors in the log file. # error_log /var/log/nginx/error.log notice; location / { index index.php index.html index.htm login.php; try_files $uri /index.php?$args; } location ~ \.php$ { try_files $uri /index.php?$args; try_files $uri $script_name =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php7.0-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; } location /fpelms { root /var/www/html; index index.php index.html index.htm login.php; } location /stage { root /var/www/html; index index.php; if (!-e $request_filename) { rewrite ^(.*)$ /stage/index.php?q=$1 last; } } location /doc/ { alias /usr/share/doc/; autoindex on; allow 127.0.0.1; deny all; } location ~/\.ht { deny all; } location /remotech.html { proxy_pass https://outsidedomain.com/; } location /static { proxy_pass https://outsidedomain.com/static/; } location /api/ { proxy_pass https://outsidedomain.com/api/; } location /firebase-messaging-sw.js{ proxy_pass https://outsidedomain.com/firebase-messaging-sw.js; } location /manifest.json{ proxy_pass https://outsidedomain.com/manifest.json; } location /plugins { proxy_pass https://outsidedomain.com/plugins/; } location /scripts { proxy_pass https://outsidedomain.com/scripts/; } location /styles { proxy_pass https://outsidedomain.com/styles/; } location /assets { proxy_pass https://outsidedomain.com/assets/; } location /fonts { proxy_pass https://outsidedomain.com/fonts/; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { if ($host = www.mywebsite.com) { return 301 https://$host$request_uri; } # managed by Certbot if ($host = mywebsite.com) { return 301 https://$host$request_uri; } # managed by Certbot listen 80; server_name mywebsite.com www.mywebsite.com; return 404; # managed by Certbot } ---------- Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286524,286524#msg-286524 From luciano at vespaperitivo.it Fri Dec 20 15:23:26 2019 From: luciano at vespaperitivo.it (Luciano Mannucci) Date: Fri, 20 Dec 2019 16:23:26 +0100 Subject: Nginx 1.17.6 ignores kill -HUP Message-ID: <47fXYW1pghz1ftWW@baobab.bilink.it> I have an istallation of nginx in a FreeBSD PPC64 server (running 11.3 RELEASE) which seems to ignore kill -HUP: it doesn't reload configuration and doesn't log the fact that kill has reached it, even if I set the debug level in error_log to "debug". nginx -V says: nginx version: nginx/1.17.6 built by gcc 9.2.0 (FreeBSD Ports Collection) built with OpenSSL 1.0.2t 10 Sep 2019 TLS SNI support enabled configure arguments: --prefix=/usr/local --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx_pool/nginx.pid --user=httpd --group=nagcmd --with-cc=/usr/local/bin/gcc9 --with-cpp=/usr/local/bin/cpp9 --with-cpu-opt=ppc64 --with-http_dav_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_auth_request_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-http_v2_module --with-google_perftools_module --with-mail --with-mail_ssl_module Have I missed something? where should I look to see what happens? Thanks in advance, Luciano. -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster at sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ From luciano at vespaperitivo.it Fri Dec 20 17:21:42 2019 From: luciano at vespaperitivo.it (Luciano Mannucci) Date: Fri, 20 Dec 2019 18:21:42 +0100 Subject: Nginx 1.17.6 ignores kill -HUP In-Reply-To: <47fXYW1pghz1ftWW@baobab.bilink.it> References: <47fXYW1pghz1ftWW@baobab.bilink.it> Message-ID: <47fb9z1Flwz1ftWW@baobab.bilink.it> On Fri, 20 Dec 2019 16:23:26 +0100 Luciano Mannucci wrote: > I have an istallation of nginx in a FreeBSD PPC64 server (running > 11.3 RELEASE) which seems to ignore kill -HUP: it doesn't reload > configuration and doesn't log the fact that kill has reached it, even > if I set the debug level in error_log to "debug". Further investigation: it does re-read the config. It just doesn't log that it did it. This may be a problem because *sometime* it doesn't reload the ssl certificates not noticing that they have changed. Do I need to put something special in the conf file to achieve that? Thanks again, Luciano. -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster at sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ From osa at freebsd.org.ru Fri Dec 20 17:31:43 2019 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Fri, 20 Dec 2019 20:31:43 +0300 Subject: Nginx 1.17.6 ignores kill -HUP In-Reply-To: <47fb9z1Flwz1ftWW@baobab.bilink.it> References: <47fXYW1pghz1ftWW@baobab.bilink.it> <47fb9z1Flwz1ftWW@baobab.bilink.it> Message-ID: <20191220173143.GD30344@FreeBSD.org.ru> Hi Luciano, hope you're doing well. As far as I understood you're running nginx on FreeBSD 11.3 ppc64. It looks like it's nginx from mainline 1.17 branch. I would recommend to build nginx from FreeBSD ports collection, please see www/nginx-devel for details. In this case nginx builds with the following option: [ ] DEBUGLOG Enable debug log (--with-debug) it's possible to enable debug log in nginx.conf configuration file. Thanks. -- Sergey Osokin On Fri, Dec 20, 2019 at 06:21:42PM +0100, Luciano Mannucci wrote: > On Fri, 20 Dec 2019 16:23:26 +0100 > Luciano Mannucci wrote: > > > I have an istallation of nginx in a FreeBSD PPC64 server (running > > 11.3 RELEASE) which seems to ignore kill -HUP: it doesn't reload > > configuration and doesn't log the fact that kill has reached it, even > > if I set the debug level in error_log to "debug". > Further investigation: it does re-read the config. > It just doesn't log that it did it. > > This may be a problem because *sometime* it doesn't reload the ssl > certificates not noticing that they have changed. > > Do I need to put something special in the conf file to achieve that? > > Thanks again, > > Luciano. > -- > /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) > \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 > X AGAINST HTML MAIL / E-MAIL: posthamster at sublink.sublink.ORG > / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx From roger at netskrt.io Sat Dec 21 01:25:05 2019 From: roger at netskrt.io (Roger Fischer) Date: Fri, 20 Dec 2019 17:25:05 -0800 Subject: Multiple server_name directives in same server block? Message-ID: <84270F84-3FC6-4714-9966-C6CF0E791369@netskrt.io> Hello, is it possible to have multiple server_name directives in the same server block? I.e. is the following possible? server { listen 1.2.3.4:443 ssl; server_name *.site1.org *.site2.org; server_name ~^app1.*\.site3\.org$; ?. Or do I need to create a second server block? Thanks? Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis at daoine.org Sat Dec 21 10:25:50 2019 From: francis at daoine.org (Francis Daly) Date: Sat, 21 Dec 2019 10:25:50 +0000 Subject: Multiple server_name directives in same server block? In-Reply-To: <84270F84-3FC6-4714-9966-C6CF0E791369@netskrt.io> References: <84270F84-3FC6-4714-9966-C6CF0E791369@netskrt.io> Message-ID: <20191221102550.GI26683@daoine.org> On Fri, Dec 20, 2019 at 05:25:05PM -0800, Roger Fischer wrote: Hi there, > is it possible to have multiple server_name directives in the same server block? A quick test shows that "nginx -t" does not object; and that the server_name values are matched with the Host: header as expected. So: yes. f -- Francis Daly francis at daoine.org From francis at daoine.org Sat Dec 21 10:33:56 2019 From: francis at daoine.org (Francis Daly) Date: Sat, 21 Dec 2019 10:33:56 +0000 Subject: Wordpress not able to display theme properly - FastCGI sent in stderr: "Primary script unknown" In-Reply-To: <8c320093d947ddf86e7c6952ff7c1186.NginxMailingListEnglish@forum.nginx.org> References: <8c320093d947ddf86e7c6952ff7c1186.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191221103356.GJ26683@daoine.org> On Fri, Dec 20, 2019 at 06:32:58AM -0500, vikask wrote: Hi there, > I am getting the following error in the error log. I think the filename > being passed has the subdirectory name prepended, which should not happen. The http request that is logged looks strange to me. Is the "referrer" value reliable? If so, check the html returned there to see what the "img src" looks like there. > client: 110.227.251.142, server: mywebsite.com, request: "GET > /stage/%20https://mywebsite.com/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x797.jpg > HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: > "fp-academy.in", referrer: "https://fp-academy.in/stage/" (This does not address any of the nginx config; but it's simplest to fix one thing at a time. Maybe there is only one thing that needs fixing!) Cheers, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Sat Dec 21 12:49:06 2019 From: nginx-forum at forum.nginx.org (sachin.shetty@gmail.com) Date: Sat, 21 Dec 2019 07:49:06 -0500 Subject: Nginx converts 409 from upstream to 502 Message-ID: Hi, Our request flow looks like this: client --> nginx --> haproxy --> tomcat Put requests with large bodies are used to upload files. Sometimes due to some application logic, tomcat may reject an upload early and return 409, tomcat does not drain the input stream, we do not want to read the input stream and rather reject early. When tomcat rejects a PUT request early with 409, tomcat access logs show 409. The haproxy fronting tomcats also log a 409 in access logs, but nginx logs a 502 and sends a 502 to the clients. It looks like nginx does not like that request is rejected and a 409 is sent without reading the full request by the upstream. What can we do to make sure client receives the correct response code i.e. 409 Thanks Sachin Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286531,286531#msg-286531 From nginx-forum at forum.nginx.org Sat Dec 21 12:58:50 2019 From: nginx-forum at forum.nginx.org (vikask) Date: Sat, 21 Dec 2019 07:58:50 -0500 Subject: Wordpress not able to display theme properly - FastCGI sent in stderr: "Primary script unknown" In-Reply-To: <20191221103356.GJ26683@daoine.org> References: <20191221103356.GJ26683@daoine.org> Message-ID: <9902b592550aeac56a2a5396730b4463.NginxMailingListEnglish@forum.nginx.org> Hi Francis... Here is the error log 2019/12/21 18:16:01 [error] 23708#23708: *1821 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 73.218.245.139, server: fp-academy.in, request: "GET /stage/%20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg.jpg HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "fp-academy.in", referrer: "https://fp-academy.in/stage/" 2019/12/21 18:16:02 [error] 23708#23708: *1826 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 73.218.245.139, server: fp-academy.in, request: "GET /stage/%20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg.jpg HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "fp-academy.in", referrer: "https://fp-academy.in/stage/" 2019/12/21 18:16:03 [error] 23708#23708: *1821 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 73.218.245.139, server: fp-academy.in, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "fp-academy.in", referrer: "https://fp-academy.in/stage/" 2019/12/21 18:16:09 [error] 23708#23708: *1838 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 116.73.20.16, server: fp-academy.in, request: "GET /stage/%20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x797.jpg HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "fp-academy.in", referrer: "https://fp-academy.in/stage/" 2019/12/21 18:16:10 [error] 23708#23708: *1838 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 116.73.20.16, server: fp-academy.in, request: "GET /stage/%20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x797.jpg HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "fp-academy.in", referrer: "https://fp-academy.in/stage/" 2019/12/21 18:16:11 [error] 23708#23708: *1837 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 116.73.20.16, server: fp-academy.in, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "fp-academy.in" ----------------------------------- Here is the listing of the directory #ls -lsa /var/www/html/stage/wp-content/uploads/2019/11/hp* 364 -rwxrwxrwx 1 www-data www-data 368698 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-1030x547.jpg 312 -rwxrwxrwx 1 www-data www-data 317903 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-1210x423.jpg 356 -rwxrwxrwx 1 www-data www-data 361355 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x430.jpg 520 -rwxrwxrwx 1 www-data www-data 531659 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x630.jpg 652 -rwxrwxrwx 1 www-data www-data 667035 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x797.jpg 32 -rwxrwxrwx 1 www-data www-data 29744 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-180x180.jpg 44 -rwxrwxrwx 1 www-data www-data 42398 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-260x185.jpg 44 -rwxrwxrwx 1 www-data www-data 42039 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-300x159.jpg 4 -rwxrwxrwx 1 www-data www-data 2710 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-36x36.jpg 140 -rwxrwxrwx 1 www-data www-data 140912 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-495x400.jpg 192 -rwxrwxrwx 1 www-data www-data 193974 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-705x375.jpg 192 -rwxrwxrwx 1 www-data www-data 194602 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-710x375.jpg 220 -rwxrwxrwx 1 www-data www-data 221598 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-768x408.jpg 8 -rwxrwxrwx 1 www-data www-data 7239 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-80x80.jpg 188 -rwxrwxrwx 1 www-data www-data 192062 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-845x321.jpg 336 -rwxrwxrwx 1 www-data www-data 343025 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg-845x684.jpg 220 -rwxrwxrwx 1 www-data www-data 224100 Nov 26 11:29 /var/www/html/stage/wp-content/uploads/2019/11/hp_slider_bg.jpg ------------------------------------- And Here is the source of the page.

WELCOME

To Henkel Flexible Packaging Academy

Educate

Innovate

Collaborate

Peerless Course

Training modules include practical hands-on experience on industrial lamination machines, with classroom sessions for theory

I am sorry the message is appearing a little clumsy.. the option of attaching a file.would have been great.. Regards Vikas Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286530,286532#msg-286532 From joneum at FreeBSD.org Sat Dec 21 18:06:24 2019 From: joneum at FreeBSD.org (Jochen Neumeister) Date: Sat, 21 Dec 2019 19:06:24 +0100 Subject: Nginx 1.17.6 ignores kill -HUP In-Reply-To: <20191220173143.GD30344@FreeBSD.org.ru> References: <47fXYW1pghz1ftWW@baobab.bilink.it> <47fb9z1Flwz1ftWW@baobab.bilink.it> <20191220173143.GD30344@FreeBSD.org.ru> Message-ID: <4dd0a66a-65f9-0cc8-4ab1-a0f35e04a878@FreeBSD.org> Hi, you're not allone with this Problem. Other nginx user have the same Problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242626 Unfortunately I have no solution for the problem at the moment Cheers Jochen Am 20.12.19 um 18:31 schrieb Sergey A. Osokin: > Hi Luciano, > > hope you're doing well. > > As far as I understood you're running nginx on FreeBSD 11.3 ppc64. > It looks like it's nginx from mainline 1.17 branch. > > I would recommend to build nginx from FreeBSD ports collection, > please see www/nginx-devel for details. > > In this case nginx builds with the following option: > > [ ] DEBUGLOG Enable debug log (--with-debug) > > it's possible to enable debug log in nginx.conf configuration > file. > > Thanks. > > -- > Sergey Osokin > > On Fri, Dec 20, 2019 at 06:21:42PM +0100, Luciano Mannucci wrote: >> On Fri, 20 Dec 2019 16:23:26 +0100 >> Luciano Mannucci wrote: >> >>> I have an istallation of nginx in a FreeBSD PPC64 server (running >>> 11.3 RELEASE) which seems to ignore kill -HUP: it doesn't reload >>> configuration and doesn't log the fact that kill has reached it, even >>> if I set the debug level in error_log to "debug". >> Further investigation: it does re-read the config. >> It just doesn't log that it did it. >> >> This may be a problem because *sometime* it doesn't reload the ssl >> certificates not noticing that they have changed. >> >> Do I need to put something special in the conf file to achieve that? >> >> Thanks again, >> >> Luciano. >> -- >> /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) >> \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 >> X AGAINST HTML MAIL / E-MAIL: posthamster at sublink.sublink.ORG >> / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ >> _______________________________________________ >> nginx mailing list >> nginx at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx From francis at daoine.org Sat Dec 21 20:37:03 2019 From: francis at daoine.org (Francis Daly) Date: Sat, 21 Dec 2019 20:37:03 +0000 Subject: Wordpress not able to display theme properly - FastCGI sent in stderr: "Primary script unknown" In-Reply-To: <9902b592550aeac56a2a5396730b4463.NginxMailingListEnglish@forum.nginx.org> References: <20191221103356.GJ26683@daoine.org> <9902b592550aeac56a2a5396730b4463.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191221203703.GK26683@daoine.org> On Sat, Dec 21, 2019 at 07:58:50AM -0500, vikask wrote: Hi there, The request getting to nginx is: > /stage/%20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg.jpg That is almost certainly wrong. The request probably should be just /stage/wp-content/uploads/2019/11/hp_slider_bg.jpg Do things work if you just request that url? > height="850" > src="https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg.jpg" > class="ls-bg" alt="" > srcset="%20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg.jpg Edit that (and the rest of this "srcset" collection) and replace the %20 before each https:// with just a space. (And if this content is generated -- edit whatever the source is so that when this content is generated, there is no %20 at the start of a url.) > 1600w, > %20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg-300x159.jpg > 300w, > %20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg-768x408.jpg > 768w, > %20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg-1030x547.jpg > 1030w, > %20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg-1500x797.jpg > 1500w, > %20https://fp-academy.in/stage/wp-content/uploads/2019/11/hp_slider_bg-705x375.jpg > 705w" sizes="(max-width: 1600px) 100vw, 1600px" /> It may be that your nginx config works as it should, already. Cheers, f -- Francis Daly francis at daoine.org From nginx-forum at forum.nginx.org Sun Dec 22 14:43:47 2019 From: nginx-forum at forum.nginx.org (vikask) Date: Sun, 22 Dec 2019 09:43:47 -0500 Subject: Wordpress not able to display theme properly - FastCGI sent in stderr: "Primary script unknown" In-Reply-To: <20191221203703.GK26683@daoine.org> References: <20191221203703.GK26683@daoine.org> Message-ID: <7de51ad855c4577c31d4c8c16f088b86.NginxMailingListEnglish@forum.nginx.org> Hi there, Thanks for showing me the direction. I removed the block i had created for the subdirectory /stage in the default nginx file. the default Home URL had a space [typing mistake] and so the 20% was being sent in the URL. Wonder what i would have done without your debugging skills. Thank you for your super diagnosis! Appreciate it! Regards Vikas Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286530,286535#msg-286535 From mdounin at mdounin.ru Sun Dec 22 18:15:24 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 22 Dec 2019 21:15:24 +0300 Subject: Nginx converts 409 from upstream to 502 In-Reply-To: References: Message-ID: <20191222181524.GC12894@mdounin.ru> Hello! On Sat, Dec 21, 2019 at 07:49:06AM -0500, sachin.shetty at gmail.com wrote: > Our request flow looks like this: > > client --> nginx --> haproxy --> tomcat > > Put requests with large bodies are used to upload files. Sometimes due to > some application logic, tomcat may reject an upload early and return 409, > tomcat does not drain the input stream, we do not want to read the input > stream and rather reject early. > > When tomcat rejects a PUT request early with 409, tomcat access logs show > 409. The haproxy fronting tomcats also log a 409 in access logs, but nginx > logs a 502 and sends a 502 to the clients. It looks like nginx does not like > that request is rejected and a 409 is sent without reading the full request > by the upstream. > > What can we do to make sure client receives the correct response code i.e. > 409 The 502 error suggests that nginx do not receive HTTP response from the upstream server. Most likely reason is that haproxy closes connection with nginx without trying to read data which is in socket buffers and/or in transit, resulting in connection reset. See http://mailman.nginx.org/pipermail/nginx/2019-December/058812.html for details. -- Maxim Dounin http://mdounin.ru/ From osa at freebsd.org.ru Sun Dec 22 20:37:22 2019 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Sun, 22 Dec 2019 23:37:22 +0300 Subject: Nginx 1.17.6 ignores kill -HUP In-Reply-To: <4dd0a66a-65f9-0cc8-4ab1-a0f35e04a878@FreeBSD.org> References: <47fXYW1pghz1ftWW@baobab.bilink.it> <47fb9z1Flwz1ftWW@baobab.bilink.it> <20191220173143.GD30344@FreeBSD.org.ru> <4dd0a66a-65f9-0cc8-4ab1-a0f35e04a878@FreeBSD.org> Message-ID: <20191222203722.GA70594@FreeBSD.org.ru> Hi Jochen, thanks for the reply. On Sat, Dec 21, 2019 at 07:06:24PM +0100, Jochen Neumeister wrote: > Hi, > > you're not allone with this Problem. > Other nginx user have the same Problem: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242626 > > Unfortunately I have no solution for the problem at the moment I'm not on position to think these two issues are similar. Here, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242626#c20 the originator has clear replied he has the issue on 12.1 amd64 and on 11.1 everything looks fine. In this case we have FreeBSD 11.3 on ppc64, nginx has been built with gcc9, not from ports. So, my recommendation is still the same as before: build nginx from ports tree with debug log enabled. Once compiled, it's possible to use the following directive on the main level to enable debug logging: error_log /var/log/nginx/error.log debug; -- Sergey > Am 20.12.19 um 18:31 schrieb Sergey A. Osokin: > > Hi Luciano, > > > > hope you're doing well. > > > > As far as I understood you're running nginx on FreeBSD 11.3 ppc64. > > It looks like it's nginx from mainline 1.17 branch. > > > > I would recommend to build nginx from FreeBSD ports collection, > > please see www/nginx-devel for details. > > > > In this case nginx builds with the following option: > > > > [ ] DEBUGLOG Enable debug log (--with-debug) > > > > it's possible to enable debug log in nginx.conf configuration > > file. > > > > Thanks. > > > > -- > > Sergey Osokin > > > > On Fri, Dec 20, 2019 at 06:21:42PM +0100, Luciano Mannucci wrote: > >> On Fri, 20 Dec 2019 16:23:26 +0100 > >> Luciano Mannucci wrote: > >> > >>> I have an istallation of nginx in a FreeBSD PPC64 server (running > >>> 11.3 RELEASE) which seems to ignore kill -HUP: it doesn't reload > >>> configuration and doesn't log the fact that kill has reached it, even > >>> if I set the debug level in error_log to "debug". > >> Further investigation: it does re-read the config. > >> It just doesn't log that it did it. > >> > >> This may be a problem because *sometime* it doesn't reload the ssl > >> certificates not noticing that they have changed. > >> > >> Do I need to put something special in the conf file to achieve that? > >> > >> Thanks again, > >> > >> Luciano. > >> -- > >> /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) > >> \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 > >> X AGAINST HTML MAIL / E-MAIL: posthamster at sublink.sublink.ORG > >> / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ > >> _______________________________________________ > >> nginx mailing list > >> nginx at nginx.org > >> http://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > > nginx mailing list > > nginx at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx From nsclick at gmx.de Mon Dec 23 11:47:11 2019 From: nsclick at gmx.de (nsclick at gmx.de) Date: Mon, 23 Dec 2019 12:47:11 +0100 Subject: auth_http - Password always different Message-ID: Hello, I'm trying to use "auth_http" to handle the authentication for SMTP. The auth script itself is a PHP script. At the beginning of the script I'm doing the following (just for testing!!! The passwords will not be logged later): if( !isset($_SERVER["HTTP_AUTH_USER"]) || !isset($_SERVER["HTTP_AUTH_PASS"]) ) { // User or Password are NOT set. fail("Invalid user or password"); } $username = $_SERVER["HTTP_AUTH_USER"]; $userpass = $_SERVER["HTTP_AUTH_PASS"]; $protocol = $_SERVER["HTTP_AUTH_PROTOCOL"]; $fd=fopen('php_mail.log', 'a'); fputs($fd, "User: [".$username."] Protocol: [".$protocol."] Pass: [".$userpass."]\n"); fclose($fd); However, the passwords I see in the log are different all the time for the same user. Often they consist of 32 hexadecimal digits (but never the same combination) or sometimes they are simply the username with brackets around. For my understanding the received password should be the same all the time, because otherwise I cannot check the user credentials. Is there a problem with my understanding or do I miss something? Thanks, Thomas From mdounin at mdounin.ru Mon Dec 23 12:40:12 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 23 Dec 2019 15:40:12 +0300 Subject: auth_http - Password always different In-Reply-To: References: Message-ID: <20191223124012.GG12894@mdounin.ru> Hello! On Mon, Dec 23, 2019 at 12:47:11PM +0100, nsclick at gmx.de wrote: > Hello, > > I'm trying to use "auth_http" to handle the authentication for SMTP. > The auth script itself is a PHP script. At the beginning of the script I'm doing the following (just for testing!!! The passwords will not be logged later): > > if( !isset($_SERVER["HTTP_AUTH_USER"]) || !isset($_SERVER["HTTP_AUTH_PASS"]) ) > { > // User or Password are NOT set. > fail("Invalid user or password"); > } > > $username = $_SERVER["HTTP_AUTH_USER"]; > $userpass = $_SERVER["HTTP_AUTH_PASS"]; > $protocol = $_SERVER["HTTP_AUTH_PROTOCOL"]; > > $fd=fopen('php_mail.log', 'a'); > fputs($fd, "User: [".$username."] Protocol: [".$protocol."] Pass: [".$userpass."]\n"); > fclose($fd); > > > However, the passwords I see in the log are different all the time for the same user. > Often they consist of 32 hexadecimal digits (but never the same combination) or sometimes they are simply the username with brackets around. > > For my understanding the received password should be the same all the time, because otherwise I cannot check the user credentials. > > Is there a problem with my understanding or do I miss something? Check the Auth-Method header, most likely the auth method used is not plain, but apop or cram-md5. See docs here: http://nginx.org/en/docs/mail/ngx_mail_auth_http_module.html#protocol for details. More information about APOP and CRAM-MD5 can be found in relevant RFCs. -- Maxim Dounin http://mdounin.ru/ From nginx-forum at forum.nginx.org Mon Dec 23 14:51:21 2019 From: nginx-forum at forum.nginx.org (dviswanath) Date: Mon, 23 Dec 2019 09:51:21 -0500 Subject: NGINX is shutting down immediately in windows Message-ID: Hi Team, When I am running NGINX on windows directly(not from service), the process is shutting down immediately. The log says "[alert] 82540#89652: the event "ngx_master_82540" was not signaled for 5s". When we run with master_process off; NGINX is running properly but the problem is making master_process off; is not preferable as per documentation and one more problem is configuration cannot be reloaded. Can you please suggest me the way to proceed further as I am stuck and not able to use NGINX in windows at all. Thanks In Advance Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286541,286541#msg-286541 From mdounin at mdounin.ru Mon Dec 23 16:09:34 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 23 Dec 2019 19:09:34 +0300 Subject: NGINX is shutting down immediately in windows In-Reply-To: References: Message-ID: <20191223160934.GM12894@mdounin.ru> Hello! On Mon, Dec 23, 2019 at 09:51:21AM -0500, dviswanath wrote: > Hi Team, > > When I am running NGINX on windows directly(not from service), the process > is shutting down immediately. The log says "[alert] 82540#89652: the event > "ngx_master_82540" was not signaled for 5s". > > When we run with master_process off; NGINX is running properly but the > problem is making master_process off; is not preferable as per documentation > and one more problem is configuration cannot be reloaded. > > Can you please suggest me the way to proceed further as I am stuck and not > able to use NGINX in windows at all. The message in question suggests that nginx worker processes fails to start in 5 seconds (or fails to signal it was able to start for some reason). To find out why exactly this happens you may want to configure debug logging, see here: http://nginx.org/en/docs/debugging_log.html One possible reason which might cause this is an attempt to use password-protected SSL private keys on Windows without ssl_password_file configured. -- Maxim Dounin http://mdounin.ru/ From mdounin at mdounin.ru Tue Dec 24 15:14:10 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 24 Dec 2019 18:14:10 +0300 Subject: nginx-1.17.7 Message-ID: <20191224151410.GV12894@mdounin.ru> Changes with nginx 1.17.7 24 Dec 2019 *) Bugfix: a segmentation fault might occur on start or during reconfiguration if the "rewrite" directive with an empty replacement string was used in the configuration. *) Bugfix: a segmentation fault might occur in a worker process if the "break" directive was used with the "alias" directive or with the "proxy_pass" directive with a URI. *) Bugfix: the "Location" response header line might contain garbage if the request URI was rewritten to the one containing a null character. *) Bugfix: requests with bodies were handled incorrectly when returning redirections with the "error_page" directive; the bug had appeared in 0.7.12. *) Bugfix: socket leak when using HTTP/2. *) Bugfix: a timeout might occur while handling pipelined requests in an SSL connection; the bug had appeared in 1.17.5. *) Bugfix: in the ngx_http_dav_module. -- Maxim Dounin http://nginx.org/ From nginx-forum at forum.nginx.org Thu Dec 26 17:57:49 2019 From: nginx-forum at forum.nginx.org (ayman) Date: Thu, 26 Dec 2019 12:57:49 -0500 Subject: 301/302 XSS vulnerability Message-ID: <4f0e40d2bc744504174552a746244231.NginxMailingListEnglish@forum.nginx.org> Hello, We detected XSS vulnerability when we use 301 or 302 redirections. How to reproduce? curl -I -k "http://example.com/test'""'>>" > ayman.html open ayman.html and you will get the popup! I tried the below redirections and it's valid on all cases: - return 301 https://www.exampl.com$request_uri; - rewrite ^/(.*) https://www.example.com/$1 permanent; Nginx version: 1.14.2 Is there a fix/workaround for this? Thanks Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286600,286600#msg-286600 From mdounin at mdounin.ru Fri Dec 27 12:42:47 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 27 Dec 2019 15:42:47 +0300 Subject: 301/302 XSS vulnerability In-Reply-To: <4f0e40d2bc744504174552a746244231.NginxMailingListEnglish@forum.nginx.org> References: <4f0e40d2bc744504174552a746244231.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191227124247.GN12894@mdounin.ru> Hello! On Thu, Dec 26, 2019 at 12:57:49PM -0500, ayman wrote: > We detected XSS vulnerability when we use 301 or 302 redirections. > > How to reproduce? > > curl -I -k "http://example.com/test'""'>>" > > ayman.html > > open ayman.html and you will get the popup! You are saving response headers, not the response itself. -- Maxim Dounin http://mdounin.ru/ From vbart at nginx.com Fri Dec 27 13:39:55 2019 From: vbart at nginx.com (Valentin V. Bartenev) Date: Fri, 27 Dec 2019 16:39:55 +0300 Subject: Unit 1.14.0 release Message-ID: <1962988.6ptJYqHVjx@vbart-workstation> Hi, I'm glad to announce a new release of NGINX Unit. Besides improving the request routing abilities, this release simplifies operations concerning the Go module. Now it can also be installed with the "go get" command: go get unit.nginx.org/go Mind, however, that it requires the "unit-dev" package. Great effort went into improving the efficiency and avoiding memory bloat in cases where an application generates gigabytes of response body. Now Unit can deal with that without much hassle. We will continue improving the performance and increasing efficiency, as this is one of our primary priorities. Changes with Unit 1.14.0 26 Dec 2019 *) Change: the Go package import name changed to "unit.nginx.org/go". *) Change: Go package now links to libunit instead of including library sources. *) Feature: ability to change user and group for isolated applications when Unit daemon runs as an unprivileged user. *) Feature: request routing by source and destination addresses and ports. *) Bugfix: memory bloat on large responses. We also updated our Docker images and switched them from Debian 9 to 10 as the base, so the language module versions have been updated respectively. - https://unit.nginx.org/installation/#docker-images Python 3.6 module packages were added to CentOS and RHEL 7 repositories, and Python 3.7 package was added to Amazon Linux 2 LTS. Please note that the name of Python 2.7 package in these repositories was changed from "unit-python" to "unit-python27". The Go package now has the same name "unit-go" across all our repositories and depends on "unit-dev". This is the last release of 2019, so I'll use this opportunity to wish a Happy New Year to our strong community. Thank you for your requests, bug reports, ideas, and suggestions. Everything that we do, we primarily do for you, our users. This year, we made 8 releases, with 427 commits to the repository, where 65242 lines were added and 8219 removed. The biggest features of the year are: - Support for Java Servlet Containers, which means that now Unit supports 7 languages - Advanced internal request routing that allows to filter requests by various parameters, including: URI, header fields, arguments, cookies, addresses, and ports - Built-in WebSocket server offloading for Node.js and Java - Isolation of application processes - Serving of static files - Reverse proxying These features establish a firm basis for further development of Unit as a general-purpose web server that is able to perform absolutely any task related to handling and processing web protocols in the most efficient way. This is our ultimate goal, and we are eager to achieve it over the coming years. I'd like to thank everyone who worked hard with me on Unit through the year: - Andrei Belov - system engineer, who maintained repositories and prepared packages - Andrei Zeliankou - QA engineer, who wrote functional tests and ran fuzzing - Artem Konev - technical writer, who wrote documentation and blog posts, improved the website, and sometimes helped us to arrange words in sentences the right way - Axel Duch - junior developer, who improved request routing - Igor Sysoev - senior developer and architect, who worked on request routing, proxying, and many internal aspects - Konstantin Pavlov - system engineer, who prepared Docker images and packages - Maxim Romanov - senior developer, who worked on Java, WebSockets, and internal IPC - Tiago Natel de Moura - senior developer, who worked on isolation features Thank you guys, I'm happy to work with you. wbr, Valentin V. Bartenev From ragnar.rova at gmail.com Sat Dec 28 09:58:06 2019 From: ragnar.rova at gmail.com (Ragnar Rova) Date: Sat, 28 Dec 2019 10:58:06 +0100 Subject: Redis storage for cache Message-ID: I want to use redis as the storage for the cache instead of the filesystem. I found a third-party module which seems to offer this: https://github.com/openresty/srcache-nginx-module#caching-with-redis, is this the recommended solution? Hot requests should be served from memory, with redis as a fallback and use to populate the cache on startup. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Sat Dec 28 11:42:30 2019 From: nginx-forum at forum.nginx.org (antikurjers) Date: Sat, 28 Dec 2019 06:42:30 -0500 Subject: if ($remote_addr ~ and set $white_list for subnets? Message-ID: <67c9bed243e49e7ba25a2a8046ef6abb.NginxMailingListEnglish@forum.nginx.org> Hi! I want to mark same subnets to as $white_list. I currently use: # urdas web location / { if ($remote_addr ~ "(10.10.1.128)|(10.20.1.53)|(10.30.14.56)") { set $white_list a712ba9579080e61cd89955a2cb837bf; } proxy_pass http://10.10.1.53:30081; proxy_set_header WhiteList $white_list; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } It work well. But works only by one IP address. How to mark as subnets? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286617,286617#msg-286617 From nginx-forum at forum.nginx.org Sat Dec 28 12:25:14 2019 From: nginx-forum at forum.nginx.org (antikurjers) Date: Sat, 28 Dec 2019 07:25:14 -0500 Subject: if ($remote_addr ~ and set $white_list for subnets? In-Reply-To: <67c9bed243e49e7ba25a2a8046ef6abb.NginxMailingListEnglish@forum.nginx.org> References: <67c9bed243e49e7ba25a2a8046ef6abb.NginxMailingListEnglish@forum.nginx.org> Message-ID: <59644d1b50c4b4b4c2f9d2ed11f7374b.NginxMailingListEnglish@forum.nginx.org> I resoved it! out of blocks I add: geo $mark_nocapcha { default 0; 10.10.1.0/24 1; 10.20.1.0/24 1; 10.30.33.0/24 1; 10.30.14.0/24 1; } ANd add/substitute in server block if ($remote_addr ~ "(10.10.1.128)|(10.20.1.53)|(10.30.14.56)") { to if ($mark_nocapcha) { Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286617,286618#msg-286618 From bernard+nginx at rosset.net Sat Dec 28 20:11:09 2019 From: bernard+nginx at rosset.net (Bernard Rosset) Date: Sat, 28 Dec 2019 21:11:09 +0100 Subject: nginx.org docs search Message-ID: Hello, First of all, since it is that time of the year, I hope you had a merry Christmas, and I wish you all the best for the new year to come! I am a regular user of the https://nginx.org/r/ prefix to search documentation. I might have asked that in the past, and/or someone else might have too, but I can put my hands on such an answer: How does one search a specific directive when multiple one share the same name, inter-modules? Example case: How to search for https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#server, and not https://nginx.org/en/docs/http/ngx_http_core_module.html#server ? Have a nice evening, Bernard Rosset https://rosset.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4046 bytes Desc: S/MIME Cryptographic Signature URL: From osa at freebsd.org.ru Sun Dec 29 08:58:32 2019 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Sun, 29 Dec 2019 11:58:32 +0300 Subject: Redis storage for cache In-Reply-To: References: Message-ID: <20191229085832.GB70594@FreeBSD.org.ru> Hi Ragnar, hope you're doing well. On Sat, Dec 28, 2019 at 10:58:06AM +0100, Ragnar Rova wrote: > I want to use redis as the storage for the cache instead of the filesystem. > > I found a third-party module which seems to offer this: > https://github.com/openresty/srcache-nginx-module#caching-with-redis, is > this the recommended solution? Hot requests should be served from memory, > with redis as a fallback and use to populate the cache on startup. The solution you've mentioned uses ngx_http_redis module to get data from a redis database. Usually, it's possible to increase a stability and per- formance of a web service by pushing a static content (html, graphics, binary files) to a redis database and reroute requests from an application server to the redis. Please visit https://github.com/osokin/ngx_http_redis, Example 1 for details. -- Sergey Osokin From nginx-forum at forum.nginx.org Sun Dec 29 09:41:58 2019 From: nginx-forum at forum.nginx.org (Olaf van der Spek) Date: Sun, 29 Dec 2019 04:41:58 -0500 Subject: Rewriting query string Message-ID: <82723040685a986545ce73ad48f4aa1e.NginxMailingListEnglish@forum.nginx.org> > rewrite ^(.*)$ $1?ra=$remote_addr break; The ra argument is inserted before the original query string. Is it possible to append it to the original query string? Is this behavior documented somewhere? Couldn't find it. Can one also remove certain arguments from the query string this way? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286625,286625#msg-286625 From osa at freebsd.org.ru Sun Dec 29 11:58:46 2019 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Sun, 29 Dec 2019 14:58:46 +0300 Subject: Rewriting query string In-Reply-To: <82723040685a986545ce73ad48f4aa1e.NginxMailingListEnglish@forum.nginx.org> References: <82723040685a986545ce73ad48f4aa1e.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191229115846.GC70594@FreeBSD.org.ru> Hi Olaf, hope you're doing well. On Sun, Dec 29, 2019 at 04:41:58AM -0500, Olaf van der Spek wrote: > > rewrite ^(.*)$ $1?ra=$remote_addr break; > > The ra argument is inserted before the original query string. Is it possible > to append it to the original query string? > Is this behavior documented somewhere? Couldn't find it. > Can one also remove certain arguments from the query string this way? The following code snippet shows another arguments has been added after the original query: server { listen 8080; location / { return 200 "OK:$request_uri\n"; } } server { listen 80; location / { rewrite ^(.*)$ $1?ra=$remote_addr break; proxy_pass http://127.0.0.1:8080; } } -------- % curl -i http://127.0.0.1/foo HTTP/1.1 200 OK Server: nginx/1.17.7 Date: Sun, 29 Dec 2019 11:51:32 GMT Content-Type: application/octet-stream Content-Length: 21 Connection: keep-alive OK:/foo?ra=127.0.0.1 -------- There are several ways to manage a list of arguments of a query string and the embedded perl module definitely can help in that case. Another approach is to use the following third-party module, https://github.com/wandenberg/nginx-sorted-querystring-module -- Sergey Osokin From rr at mima.x.se Sun Dec 29 16:21:28 2019 From: rr at mima.x.se (Ragnar Rova) Date: Sun, 29 Dec 2019 17:21:28 +0100 Subject: Redis storage for cache In-Reply-To: <20191229085832.GB70594@FreeBSD.org.ru> References: <20191229085832.GB70594@FreeBSD.org.ru> Message-ID: Hello Sergey, the same wishes for you. Thanks for the link to the redis module. My use case is that I want to cache dynamic responses from a origin server just in case the origin is unhealthy. The origin server already uses redis as a cache, I just wanted to put nginx in front in case of a total failure of that component. Your suggestion gave me some ideas; since the app server already writes query responses to redis and caches internally, I can use your module to just try to read all responses from redis on the same keys from nginx. So, how do I configure nginx to do the following: For each request: 1. Try to proxy each request directly to origin using proxy_pass 2. If origin server responds with http 5xx, or timeout/connection refused occurs, use the data from redis (which the origin server has written itself to redis previously) Also, I need to calculate the same redis key in nginx as the origin server does. Currently the redis key is a stringified JSON object... I might need some additional modules to construct this key. I will test the following based on your docs at https://github.com/osokin/ngx_http_redis. http { ... server { location / { proxy_pass backed; error_page 500 503 502 504 = @fallback; // does this cover timeout and connect refused as well? } location @fallback { set $redis_key "$uri?$args"; // this key needs to be calculated differently, some query params form a JSON key in case of GET requests, for POST requests it is taken from the POST body. redis_pass 127.0.0.1:6379; } } } On Sun, Dec 29, 2019 at 9:58 AM Sergey A. Osokin wrote: > > Hi Ragnar, > > hope you're doing well. > > On Sat, Dec 28, 2019 at 10:58:06AM +0100, Ragnar Rova wrote: > > I want to use redis as the storage for the cache instead of the filesystem. > > > > I found a third-party module which seems to offer this: > > https://github.com/openresty/srcache-nginx-module#caching-with-redis, is > > this the recommended solution? Hot requests should be served from memory, > > with redis as a fallback and use to populate the cache on startup. > > The solution you've mentioned uses ngx_http_redis module to get data from > a redis database. Usually, it's possible to increase a stability and per- > formance of a web service by pushing a static content (html, graphics, binary > files) to a redis database and reroute requests from an application server > to the redis. > > Please visit https://github.com/osokin/ngx_http_redis, Example 1 for details. > > -- > Sergey Osokin > _______________________________________________ > nginx mailing list > nginx at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at forum.nginx.org Mon Dec 30 08:29:26 2019 From: nginx-forum at forum.nginx.org (hmahajan21) Date: Mon, 30 Dec 2019 03:29:26 -0500 Subject: Multiple host in request Message-ID: <452a813e7e88c667db5279b177f8f574.NginxMailingListEnglish@forum.nginx.org> Hi, I am using zuul filters for reverse proxy in aks cluster but when the request recieved at service it has multiple host name like host host.com,host.com Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286632,286632#msg-286632 From francis at daoine.org Mon Dec 30 12:03:40 2019 From: francis at daoine.org (Francis Daly) Date: Mon, 30 Dec 2019 12:03:40 +0000 Subject: Rewriting query string In-Reply-To: <82723040685a986545ce73ad48f4aa1e.NginxMailingListEnglish@forum.nginx.org> References: <82723040685a986545ce73ad48f4aa1e.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191230120340.GO26683@daoine.org> On Sun, Dec 29, 2019 at 04:41:58AM -0500, Olaf van der Spek wrote: Hi there, > > rewrite ^(.*)$ $1?ra=$remote_addr break; > > The ra argument is inserted before the original query string. Is it possible > to append it to the original query string? Something like rewrite ^(.*)$ $1?$args&ra=$remote_addr? break; should work. Note that it might look odd if there was no original query string. Also note - common practice on the web seems to be that the order of key=value pairs in the query string is unpredictable; you may be happier if you change your back-end to not care about the order (if you want random web browsers to work with your application). > Is this behavior documented somewhere? Couldn't find it. http://nginx.org/r/rewrite """ If a replacement string includes the new request arguments, the previous request arguments are appended after them. """ > Can one also remove certain arguments from the query string this way? Not easily, this way. For that, you probably want either to use one of the embedded languages to manipulate things; or to use the module referenced in the other reply. f -- Francis Daly francis at daoine.org From francis at daoine.org Mon Dec 30 12:56:56 2019 From: francis at daoine.org (Francis Daly) Date: Mon, 30 Dec 2019 12:56:56 +0000 Subject: Wordpress not able to display theme properly - FastCGI sent in stderr: "Primary script unknown" In-Reply-To: <7de51ad855c4577c31d4c8c16f088b86.NginxMailingListEnglish@forum.nginx.org> References: <20191221203703.GK26683@daoine.org> <7de51ad855c4577c31d4c8c16f088b86.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191230125656.GP26683@daoine.org> On Sun, Dec 22, 2019 at 09:43:47AM -0500, vikask wrote: Hi there, great that you now have a config+system that works for you. > I removed the block i had created for the subdirectory /stage in the default > nginx file. > the default Home URL had a space [typing mistake] and so the 20% was being > sent in the URL. And thanks for sharing the eventual fix -- that will probably help the next person with the same issue. Cheers, f -- Francis Daly francis at daoine.org From francis at daoine.org Mon Dec 30 13:07:11 2019 From: francis at daoine.org (Francis Daly) Date: Mon, 30 Dec 2019 13:07:11 +0000 Subject: Multiple host in request In-Reply-To: <452a813e7e88c667db5279b177f8f574.NginxMailingListEnglish@forum.nginx.org> References: <452a813e7e88c667db5279b177f8f574.NginxMailingListEnglish@forum.nginx.org> Message-ID: <20191230130711.GQ26683@daoine.org> On Mon, Dec 30, 2019 at 03:29:26AM -0500, hmahajan21 wrote: Hi there, > I am using zuul filters for reverse proxy in aks cluster > but when the request recieved at service it has multiple host name > like > host host.com,host.com I'm not sure if your question is "why does nginx generate this outgoing Host: header?", or "why does nginx not handle this incoming Host: header the way I want it to?", or something else entirely. Cheers, f -- Francis Daly francis at daoine.org From kworthington at gmail.com Mon Dec 30 13:59:54 2019 From: kworthington at gmail.com (Kevin Worthington) Date: Mon, 30 Dec 2019 08:59:54 -0500 Subject: [nginx-announce] nginx-1.17.7 In-Reply-To: <20191224151417.GW12894@mdounin.ru> References: <20191224151417.GW12894@mdounin.ru> Message-ID: Hello Nginx users, Now available: Nginx 1.17.7 for Windows https:// kevinworthington.com/nginxwin1177 (32-bit and 64-bit versions) These versions are to support legacy users who are already using Cygwin based builds of Nginx. Officially supported native Windows binaries are at nginx.org. Announcements are also available here: Twitter http://twitter.com/kworthington Thank you, Kevin -- Kevin Worthington kworthington *@* (gmail] [dot} {com) https://kevinworthington.com/ https://twitter.com/kworthington On Tue, Dec 24, 2019 at 10:14 AM Maxim Dounin wrote: > Changes with nginx 1.17.7 24 Dec > 2019 > > *) Bugfix: a segmentation fault might occur on start or during > reconfiguration if the "rewrite" directive with an empty replacement > string was used in the configuration. > > *) Bugfix: a segmentation fault might occur in a worker process if the > "break" directive was used with the "alias" directive or with the > "proxy_pass" directive with a URI. > > *) Bugfix: the "Location" response header line might contain garbage if > the request URI was rewritten to the one containing a null > character. > > *) Bugfix: requests with bodies were handled incorrectly when returning > redirections with the "error_page" directive; the bug had appeared > in > 0.7.12. > > *) Bugfix: socket leak when using HTTP/2. > > *) Bugfix: a timeout might occur while handling pipelined requests in > an > SSL connection; the bug had appeared in 1.17.5. > > *) Bugfix: in the ngx_http_dav_module. > > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-announce mailing list > nginx-announce at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-announce > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Dec 31 10:35:02 2019 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 31 Dec 2019 13:35:02 +0300 Subject: nginx.org docs search In-Reply-To: References: Message-ID: <20191231103502.GQ12894@mdounin.ru> Hello! On Sat, Dec 28, 2019 at 09:11:09PM +0100, Bernard Rosset wrote: > First of all, since it is that time of the year, I hope you had a merry > Christmas, and I wish you all the best for the new year to come! > > I am a regular user of the https://nginx.org/r/ prefix to search > documentation. > > I might have asked that in the past, and/or someone else might have too, > but I can put my hands on such an answer: > How does one search a specific directive when multiple one share the > same name, inter-modules? > Example case: How to search for > https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#server, > and not https://nginx.org/en/docs/http/ngx_http_core_module.html#server ? There is no way to reference a particular directive among multiple ones with the same name by using the nginx.org/r/ redirector. Mostly because additional module name would make the link almost as long as the full one, and this hardly makes sense. If you want to send a link, consider using a full link instead. If you are looking for a list of directives (or variables) with a particular name, consider using the index pages: http://nginx.org/en/docs/dirindex.html http://nginx.org/en/docs/varindex.html -- Maxim Dounin http://mdounin.ru/ From nginx-forum at forum.nginx.org Tue Dec 31 11:24:18 2019 From: nginx-forum at forum.nginx.org (hmahajan21) Date: Tue, 31 Dec 2019 06:24:18 -0500 Subject: Multiple host in request In-Reply-To: <20191230130711.GQ26683@daoine.org> References: <20191230130711.GQ26683@daoine.org> Message-ID: <6623e7db382f61f304e98e10029b136c.NginxMailingListEnglish@forum.nginx.org> Yes my question is why ngnix override the header and append double host in host header Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286632,286644#msg-286644