Quantcast
Channel: Nginx Forum
Viewing all 53287 articles
Browse latest View live

Re: net::ERR_CONNECTION_REFUSED . How to correctly configure Nginx with Socket.io?

$
0
0
Hi Francis,

I remember you have deep expertise with nginx configuration.
I posted in the mailing list a question about how to configure nginx in order to use also golang webserver.
Would you be so kind in having a look at it? https://forum.nginx.org/read.php?2,287914

Thank you very much.
Looking forward to your kind help.
Marco

Re: POST result: 404

$
0
0
On 4/30/20 2:09 PM, MarcoI wrote:
> This is the nginx configuration in Ubuntu 18.04 :
>
> server {
> listen 443 ssl http2 default_server;
> server_name ggc.world;
>
> ...
>
> location / {
> proxy_pass http://127.0.0.1:8080;

If I'm reading your config directly, this is passing port 443 to the
backend here at port 8080 on the system locally.  Therefore, the 404
request could be coming from this backend.  Have you verified that this
path actually works in your app when accessed directly on the system? 
If it does not, then the backend app is at fault here.

> ...
>
> And running the go-webserver:
>
> goServer$ go run server-gorillamux.go
>
>
> I get this error: POST https://ggc.world/puser/add 404

.... which is indicative of the issue because of the above mentioned
proxy_pass block being on the app you've built/compiled.  If that
backend doesn't have the capacity to handle the requested path it could
return the 404 which would trickle back and show a 404 via the nginx server.

> Posted at Nginx Forum: https://forum.nginx.org/read.php?2,287914,287914#msg-287914
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx


Thomas

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: POST result: 404

$
0
0
Hi Thomas,
thank you for your kind help.

I'm not sure, due to my lack of knowledge, how I can check if the path from port 443 to port 8080 works in my app when accessed directly on my system.

(base) marco@pc01:~$ sudo netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 19569/nginx: master
tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN 19569/nginx: master
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 754/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1230/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1035/cupsd
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 19569/nginx: master
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 1321/postgres
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 19569/nginx: master
tcp 0 0 127.0.0.1:33917 0.0.0.0:* LISTEN 1227/containerd
tcp6 0 0 :::80 :::* LISTEN 19569/nginx: master
tcp6 0 0 :::22 :::* LISTEN 1230/sshd
tcp6 0 0 ::1:631 :::* LISTEN 1035/cupsd

ports 80 and 443 seem both listening and owned by nginx.

How can I check if the backend has the capacity to handle the requested path?

Re: POST result: 404

$
0
0
On 4/30/20 3:20 PM, MarcoI wrote:
> Hi Thomas,
> thank you for your kind help.
>
> ...
>
> How can I check if the backend has the capacity to handle the requested
> path?

This is where you need to expand the knowledge into other tools such as
`curl`.  On the system where nginx and your webapp run execute this:

    curl -X POST http://127.0.0.1:8080/puser/add

.... if this 404s then you know that the issue is that your backend
application written in Go doesn't accept this as a POST-able path.

> Posted at Nginx Forum: https://forum.nginx.org/read.php?2,287914,287917#msg-287917
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx


Thomas

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: POST result: 404

$
0
0
It doesn't produce a "404" but it is saying "Cannot POST" ...:

curl -X POST http://127.0.0.1:8080/puser/add
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot POST /puser/add</pre>
</body>
</html>


These are the corresponding lines in /var/log/nginx :

128.14.134.170 - - [01/May/2020:10:04:03 +0200] "GET / HTTP/1.1" 502 584 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
37.116.208.25 - - [01/May/2020:10:09:53 +0200] "GET / HTTP/2.0" 200 694 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
37.116.208.25 - - [01/May/2020:10:09:53 +0200] "GET /js/app.js HTTP/2.0" 200 147353 "https://ggc.world/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safar$
37.116.208.25 - - [01/May/2020:10:09:54 +0200] "GET /js/chunk-vendors.js HTTP/2.0" 200 4241853 "https://ggc.world/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.404$
37.116.208.25 - - [01/May/2020:10:09:54 +0200] "GET /sockjs-node/info?t=1588320594594 HTTP/2.0" 200 79 "https://ggc.world/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/$
37.116.208.25 - - [01/May/2020:10:10:15 +0200] "POST /puser/add HTTP/2.0" 404 137 "https://ggc.world/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/$

And this is the nginx configuration file:

server {
listen 443 ssl http2 default_server;
server_name ggc.world;

ssl_certificate /etc/letsencrypt/live/ggc.world/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/ggc.world/privkey.pem; # managed by Certbot

ssl_trusted_certificate /etc/letsencrypt/live/ggc.world/chain.pem;

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

ssl_session_timeout 5m;
#ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
#ssl_stapling on;
#ssl_stapling_verify on;

access_log /var/log/nginx/ggcworld-access.log combined;

add_header Strict-Transport-Security "max-age=31536000";
location = /favicon.ico { access_log off; log_not_found off; }

location / {
proxy_pass http://127.0.0.1:8080;
#proxy_pass http://127.0.0.1:2000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
#proxy_set_header Host $host;
}
}

server {
listen 80 default_server;
listen [::]:80 default_server;
error_page 497 https://$host:$server_port$request_uri;
server_name ggc.world;
return 301 https://$server_name$request_uri;

access_log /var/log/nginx/ggcworld-access.log combined;

add_header Strict-Transport-Security "max-age=31536000";
location = /favicon.ico { access_log off; log_not_found off; }

location / {
proxy_pass http://127.0.0.1:8080;
#proxy_pass http://127.0.0.1:2000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
#proxy_set_header Host $host;
}
}

# https://www.nginx.com/blog/nginx-nodejs-websockets-socketio/
# https://gist.github.com/uorat/10b15a32f3ffa3f240662b9b0fefe706
# http://nginx.org/en/docs/stream/ngx_stream_core_module.html

upstream websocket {
ip_hash;
server localhost:3000;
}

server {
listen 81;
server_name ggc.world;

#location / {
location ~ ^/(websocket|websocket\/socket-io) {
proxy_pass http://127.0.0.1:4201;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Forwared-For $remote_addr;
proxy_set_header Host $host;

proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
}
}
# https://stackoverflow.com/questions/40516288/webpack-dev-server-with-nginx-proxy-pass

upstream golang-webserver {
ip_hash;
server 127.0.0.1:2000;
}

server {
listen 2999;
server_name ggc.world;

location / {
#proxy_pass http://127.0.0.1:8080;
proxy_pass http://golang-webserver;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
#proxy_set_header Host $host;
}
}

Re: POST result: 404

$
0
0
I tried to curl POST the entire form:

(base) marco@pc01:/var/log/nginx$ curl -X POST -F 'first_name=pinco' -F 'last_name=pallo' -F 'company_name=Company' -F 'email=pinco.pallo@company.com' -F 'tel=111111111' http://127.0.0.1:8080/puser/add
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot POST /puser/add</pre>
</body>
</html>

Setting Up a Nginx Server or OpenResty on OS X or UBUNTU with http_auth_request_module

$
0
0
I need to set up an NGINX server on OS X or UBUNTU that has the http_auth_request_module installed and enabled. I am kind of a novice when it comes to NGINX, but familiar with Apache, LINUX, etc. There is an NGINX server packaged with my MAMP Pro server on OS X, but I don't think that comes with the http_auth_request_module:



I actually do (I think) want to try using Nginx as a reverse proxy, but I will have to do some research about that also. First, I need to just get a server up and running with that module enabled. I would prefer using OS X because I do most of my development on a Mac, but installing on an UBUNTU VM would also probably work.

I did try installing OpenResty using the brew package manager on OS X, and if install with "verbose" I get the log for ./configure, which looks like it is compiled with that included. So that might work ? How do I tell if that module is actually enabled ? It does say --with that module (bold).

brew reinstall openresty/brew/openresty --verbose (or just install)
____________________

Brew compile output:


./configure -j8 --prefix=/usr/local/Cellar/openresty/1.15.8.3_1 --pid-path=/usr/local/var/run/openresty.pid --lock-path=/usr/local/var/run/openresty.lock --conf-path=/usr/local/etc/openresty/nginx.conf --http-log-path=/usr/local/var/log/nginx/access.log --error-log-path=/usr/local/var/log/nginx/error.log --with-cc-opt=-I/usr/local/include -I/usr/local/opt/pcre/include -I/usr/local/opt/openresty-openssl/include --with-ld-opt=-L/usr/local/lib -L/usr/local/opt/pcre/lib -L/usr/local/opt/openresty-openssl/lib --with-pcre-jit --without-http_rds_json_module --without-http_rds_csv_module --without-lua_rds_parser --with-ipv6 --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_v2_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_auth_request_module --with-http_secure_link_module --with-http_random_index_module --with-http_geoip_module --with-http_gzip_static_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-threads --with-luajit-xcflags=-DLUAJIT_NUMMODE=2 -DLUAJIT_ENABLE_LUA52COMPAT -fno-stack-check --with-dtrace-probes
platform: macosx (darwin)

.. . . .

To have launchd start openresty/brew/openresty now and restart at login:
brew services start openresty/brew/openresty
Or, if you don't want/need a background service you can just run:
openresty

___________________

The config file for openresty is here: /usr/local/etc/openresty/nginx.conf, set to listen on 81, http, and that works, I get the welcome page.

Welcome to OpenResty!


So I guess my question is how to I know that the http_auth_request_module is actually there, and then how to go about setting up as a reverse proxy.

I know that part is probably dependent on my setup. If someone can help with that it would be greatly appreciated, although it seems like it is installed on OS X.


E-mails: sscotti@sscotti.org, sscotti@icloud.com



_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: nginx-devel Digest, Vol 127, Issue 1

$
0
0
Seems that I can just execute:

openresty -V 2>&1 | grep -- 'http_auth_request_module'

From the terminal, which gives this, so it must be installed ?

configure arguments: --prefix=/usr/local/Cellar/openresty/1.15.8.3_1/nginx --with-cc-opt='-O2 -I/usr/local/include -I/usr/local/opt/pcre/include -I/usr/local/opt/openresty-openssl/include' --add-module=../ngx_devel_kit-0.3.1rc1 --add-module=../echo-nginx-module-0.61 --add-module=../xss-nginx-module-0.06 --add-module=../ngx_coolkit-0.2 --add-module=../set-misc-nginx-module-0.32 --add-module=../form-input-nginx-module-0.12 --add-module=../encrypted-session-nginx-module-0.08 --add-module=../srcache-nginx-module-0.31 --add-module=../ngx_lua-0.10.15 --add-module=../ngx_lua_upstream-0.07 --add-module=../headers-more-nginx-module-0.33 --add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.19 --add-module=../redis2-nginx-module-0.15 --add-module=../redis-nginx-module-0.3.7 --add-module=../ngx_stream_lua-0.0.7 --with-ld-opt='-Wl,-rpath,/usr/local/Cellar/openresty/1.15.8.3_1/luajit/lib -L/usr/local/lib -L/usr/local/opt/pcre/lib -L/usr/local/opt/openresty-openssl/lib' --pid-path=/usr/local/var/run/openresty.pid --lock-path=/usr/local/var/run/openresty.lock --conf-path=/usr/local/etc/openresty/nginx.conf --http-log-path=/usr/local/var/log/nginx/access.log --error-log-path=/usr/local/var/log/nginx/error.log --with-pcre-jit --with-ipv6 --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_v2_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_auth_request_module --with-http_secure_link_module --with-http_random_index_module --with-http_geoip_module --with-http_gzip_static_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-threads --with-dtrace-probes --with-stream --with-stream_ssl_preread_module --with-http_ssl_module

___________________
The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

>
> Today's Topics:
>
> 1. Setting Up a Nginx Server or OpenResty on OS X or UBUNTU with
> http_auth_request_module (sscotti@sscotti.org <mailto:sscotti@sscotti.org>)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 1 May 2020 16:31:27 -0500
> From: "sscotti@sscotti.org <mailto:sscotti@sscotti.org>" <sscotti@sscotti.org <mailto:sscotti@sscotti.org>>
> To: nginx-devel@nginx.org <mailto:nginx-devel@nginx.org>
> Subject: Setting Up a Nginx Server or OpenResty on OS X or UBUNTU with
> http_auth_request_module
> Message-ID: <7489FE86-0F4D-4866-A96E-8A459E1AC742@sscotti.org <mailto:7489FE86-0F4D-4866-A96E-8A459E1AC742@sscotti.org>>
> Content-Type: text/plain; charset="us-ascii"
>
> I need to set up an NGINX server on OS X or UBUNTU that has the http_auth_request_module installed and enabled. I am kind of a novice when it comes to NGINX, but familiar with Apache, LINUX, etc. There is an NGINX server packaged with my MAMP Pro server on OS X, but I don't think that comes with the http_auth_request_module:
>
>
>
> I actually do (I think) want to try using Nginx as a reverse proxy, but I will have to do some research about that also. First, I need to just get a server up and running with that module enabled. I would prefer using OS X because I do most of my development on a Mac, but installing on an UBUNTU VM would also probably work.
>
> I did try installing OpenResty using the brew package manager on OS X, and if install with "verbose" I get the log for ./configure, which looks like it is compiled with that included. So that might work ? How do I tell if that module is actually enabled ? It does say --with that module (bold).
>
> brew reinstall openresty/brew/openresty --verbose (or just install)
> ____________________
>
> Brew compile output:
>
>
> ./configure -j8 --prefix=/usr/local/Cellar/openresty/1.15.8.3_1 --pid-path=/usr/local/var/run/openresty.pid --lock-path=/usr/local/var/run/openresty.lock --conf-path=/usr/local/etc/openresty/nginx.conf --http-log-path=/usr/local/var/log/nginx/access.log --error-log-path=/usr/local/var/log/nginx/error.log --with-cc-opt=-I/usr/local/include -I/usr/local/opt/pcre/include -I/usr/local/opt/openresty-openssl/include --with-ld-opt=-L/usr/local/lib -L/usr/local/opt/pcre/lib -L/usr/local/opt/openresty-openssl/lib --with-pcre-jit --without-http_rds_json_module --without-http_rds_csv_module --without-lua_rds_parser --with-ipv6 --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_v2_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_auth_request_module --with-http_secure_link_module --with-http_random_index_module --with-http_geoip_
> module --with-http_gzip_static_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-threads --with-luajit-xcflags=-DLUAJIT_NUMMODE=2 -DLUAJIT_ENABLE_LUA52COMPAT -fno-stack-check --with-dtrace-probes
> platform: macosx (darwin)
>
> . . . .
>
> To have launchd start openresty/brew/openresty now and restart at login:
> brew services start openresty/brew/openresty
> Or, if you don't want/need a background service you can just run:
> openresty
>
> ___________________
>
> The config file for openresty is here: /usr/local/etc/openresty/nginx.conf, set to listen on 81, http, and that works, I get the welcome page.
>
> Welcome to OpenResty!
>
>
> So I guess my question is how to I know that the http_auth_request_module is actually there, and then how to go about setting up as a reverse proxy.
>
> I know that part is probably dependent on my setup. If someone can help with that it would be greatly appreciated, although it seems like it is installed on OS X.
>
>
> E-mails: sscotti@sscotti.org <mailto:sscotti@sscotti.org>, sscotti@icloud.com <mailto:sscotti@icloud.com>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200501/ebac9f4a/attachment.htm http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200501/ebac9f4a/attachment.htm>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PastedGraphic-1.png
> Type: image/png
> Size: 64093 bytes
> Desc: not available
> URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200501/ebac9f4a/attachment.png http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200501/ebac9f4a/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 3873 bytes
> Desc: not available
> URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200501/ebac9f4a/attachment.bin http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200501/ebac9f4a/attachment.bin>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org <mailto:nginx-devel@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-devel http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
> ------------------------------
>
> End of nginx-devel Digest, Vol 127, Issue 1
> *******************************************

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Follow RFC-7232 while evaluating the precedence of conditional headers

$
0
0
Nginx evaluates the conditional headers in the following order
if_unmodified_since
if_match
if_modified_since
if_none_match

which ignores some of the subtleties mentioned in RFC-7232, which
gives more precedence to etag based validation over time.

https://tools.ietf.org/html/rfc7232#section-3.4
A recipient MUST ignore If-Unmodified-Since if the request contains
an If-Match header field; the condition in If-Match is considered to
be a more accurate replacement for the condition in
If-Unmodified-Since, and the two are only combined for the sake of
interoperating with older intermediaries that might not implement
If-Match.

https://tools.ietf.org/html/rfc7232#section-3.3 and
A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is
considered to be a more accurate replacement for the condition in
If-Modified-Since, and the two are only combined for the sake of
interoperating with older intermediaries that might not implement
If-None-Match.

Along with those I have followed the precedence guidance provided in
https://tools.ietf.org/html/rfc7232#section-6 to change the order of
conditional headers being evaluated in nginx.

Please let me know if the changes in the patch file looks good. Happy to
address any concerns you may have.

- Karthik Uthaman
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

NGINX proxy to Ingress Controller with Client Certificate Authentication

$
0
0
On my production env, I have a configuration with two Nginx and the communication between the two servers is secured with this config like this: https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/

INTERNET ---> NGINX reverse proxy ---TLS authentication---> NGINX upstream ---> Application

The conf work as expected, the upstream accept requests only by the trusted certificated.

But I need to migrate the upstream server from a bare metal server to a Kubernetes cluster on Azure Kubernetes Service. So, the conf on the server acting as a reverse proxy is unchanged and I migrate the config of the upstream to NGINX Ingress Controller.

I've deployed this image of the Ingress Controller: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0

And configured the resource as follow:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-backend
namespace: dev
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "dev/my-cert"
nginx.ingress.kubernetes.io/auth-tls-error-page: "https://google.com"
spec:
tls:
- hosts:
- my-backend.my-domain
secretName: my-cert
rules:
- host: my-backend.my-domain
http:
paths:
- path: /
backend:
serviceName: my-backend-service
servicePort: http

And the secret called "my-cert" includes: ca.crt tls.crt tls.key imported from the NGINX upstream. https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#client-certificate-authentication

Config in the NGINX reverse proxy unchanged:

location / {
set $upstream my-upstream;
proxy_pass https://$upstream$request_uri;
proxy_set_header Host my-backend.my-domain;
proxy_set_header X-Request-ID $request_id;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_ssl_certificate /etc/nginx/ssl/client.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/client.key;
proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/nginx/CA/CA.pem;
proxy_ssl_session_reuse on;
}

The first attempt to try the config was a curl request from the reverse proxy to the Ingress Controller passing the client certificate:

curl --cacert /etc/nginx/CA/CA.pem --key /etc/nginx/ssl/client.key --cert /etc/nginx/ssl/client.pem https://my-backend.my-domain/health
{"status":"UP"}

It works!

But trying to send a request through the NGINX reverse proxy I'm redirected to google.com page, as configured in the Ingress Controller. This is note the expected behaviour because, so the NGINX reverse proxy is not able to authenticate to the Nginx ingress controller.

Someone can help me to fix the config and make the auth working?

Re: NGINX proxy to Ingress Controller with Client Certificate Authentication

$
0
0
Attacched the ingress controller logs

Re: NGINX proxy to Ingress Controller with Client Certificate Authentication

$
0
0
I need to enable SNI support on the NGINX client:
proxy_ssl_server_name on;
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_server_name

Logging to AWS Cloudwatch from Nginx Container

$
0
0
According to documentation for Nginx container "By default, the NGINX image is configured to send NGINX access log and error log to the Docker log collector". When we configure the logs to show up in AWS Cloudwatch it looks like both the error log and Access logs are combined in the same log group. Has any one found a way to separate each go to a different log group?

Re: [PATCH] Support loading server certificate from HW token

$
0
0
I support the base idea to load certificates from engines but CMD_LOAD_CERT_CTRL ('LOAD_CERT_CTRL') seems not defined in openssl, it is an engine specific functionality. Is that the only way?

And secondly, i can not imagine that you can not get a certificate from your hardware prior nginx run, because the certificate information is always open. So this new functionality is not a must, but a useful one.
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

как работает gzip_static?

$
0
0
Есть два файла: test.html и test.html.gz

Если gzip_static не указана, то отдаётся test.html
(нет content-encoding=gzip в ff webdeveloper)

Если написать gzip_static on, то отдаётся test.html.gz
(content-encoding=gzip в ff webdeveloper)


1. Если после этого удалить test.html то nginx отвечает 404, хотя ни
https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html ни
https://docs.nginx.com/nginx/admin-guide/web-server/compression/ не
говорят ни слова, о том, что для этого должны присутствовать ОБА файла.

По-моему документацию стоит исправить.


2. Так же ngx_http_gzip_static_module.html говорит:

With the “always” value .. It is useful if there are no uncompressed
files on the disk anyway

Но переключние gzip_static с on на anyway при отсутствующем test.html
ничего не меняет: nginx продолжает отвечать 404.

--
sergio.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Hello Nginx World :3 :3

$
0
0
Hello Nginx World :3 :3
Nice to be

Re: Hello from Croatia

$
0
0
Hi there! It's my dream to visit Croatia one day. But I live kind of far in my Thai condo https://tranio.com/thailand/apartments/condo/ and tickets to come to Europe are kind of expensive. Welcome to this forum, nice to meet you!

CHACHA20-POLY1305 Server Preference NOK with tlsv1.3

$
0
0
Hello,

Trying to get CHACHA20-POLY1305 Server Preference ... Working with tlsv1.2
but NOK with tlsv1.3

** Tried with a Custom OpenSSL.conf ServerPreference,PrioritizeChaCha

OPENSSL_CONF=$HOME/conf/openssl.conf $HOME/bin/nginx.exe

[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
Ciphersuites =
TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
Options = ServerPreference,PrioritizeChaCha

** Tried by patching src/event/ngx_event_openssl.c

- SSL_CTX_set_options(ssl->ctx, SSL_OP_CIPHER_SERVER_PREFERENCE);
+ SSL_CTX_set_options(ssl->ctx, SSL_OP_CIPHER_SERVER_PREFERENCE |
SSL_OP_PRIORITIZE_CHACHA);

** Tried by patching src/event/ngx_event_openssl.c

nginx -s reload
nginx: [emerg]
SSL_CTX_set_cipher_list("TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256")
failed (SSL: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher
match)

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.3;
ssl_ciphers
TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256;

my config is working like a charm with tlsv1.2 but i cannot get CHACHA20
prioritized with tlsv1.3 ... hence my question ...how to do with nginx
version: nginx/1.18.0 ?

tx, V.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?

$
0
0
Hello!

On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:

> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно пометить клиента стандартным способом
> > через
> > > cookie.
> >
> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как
> > на сервер, так и на канал. И статистика как бы говорит нам, что в
> > среднем эти накладные расходы - больше, чем польза.
>
> Я таковой статистикой не располагаю.

Ссылку на статистику я привёл. Если вы не располагаете другой -
вероятно, другой и нет.

> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> дополнительный запрос к ресурсу.

По ресурсам "получить push" и "сделать дополнительный запрос и
получить на него ответ" - строго одно и то же. Разница - только во
времени, полученный push будет доступен чуть раньше, что в хорошем
случае немного сократит время до показа страницы. А в плохом -
потребует передачи по сети дополнительных данных (начала push'а и
его отмены) и приведёт к увеличению времени до показа страницы.
Именно на баланс "хороших" и "плохих" случаев и стоит смотреть.

> > Что будет конкретно в вашем случае - зависит, безусловно, от
> > конкретной нагрузки и от того, насколько "в крайнем случае
> > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в
> > среднем - будет хуже, потому что "в крайнем случае" никто не
> > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы
> > тестировать, что получится. Подозреваю, что от банального
> > перекладывания существующих <link rel="preload"> в push'ы -
> > станет только хуже.
>
> Да, я понял Вашу точку зрения.
> Да, узкого эксперимента я не проводил.
>
> >
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> > >
> > > Не совсем понимаю какие выводы делают авторы.
> > >
> > > Предлагают работать над приоритезацией (которая и так корректная, и
> > > регулируется preload'ом), использовать экспериментальный QUIC,
> > поддержики
> > > которого толком нет.
> >
> > Авторы ясно и однозначно показывают, что server push - в среднем
> > вредит, и в большинстве случаев лишь способ выстрелить себе в
> > ногу. И предлагают работать над другими технологиями,
> > потенциально более полезными.
> >
> > Тут важно понимать, что речь идёт про взгляд разработчиков
> > браузера, и рассказывалось это всё на HTTP working group, то есть
> > в рамках встречи людей, занимающихся разработкой протокола.
>
> Из Ваших соображений и трактовке вышеприведённого исследования складывается
> впечатление, что даже разработчики протокола не донца понимают зачем push
> нужен.
> При том, что не только они описали его в протоколе, но и сторонние
> разработчики реализовали поддержку push'а клиентах и нескольких серверах.

Зачем нужен push - все понимают. Насколько он при этом полезен
для интернета в среднем - можно выяснить только практически. Вот
есть исследование от команды одного из браузеров, которое говорит,
что в среднем - вреден.

Что до "реализовали поддержку push'а", то вот мы - всегда считали,
что полезность push'а, мягко говоря, преувеличена. Но, тем не
менее, вынуждены были реализовать, просто мотому, что пользователи
читают маркетинговые материалы, рассказывающие о новом красивом
протоколе HTTP/2 и его замечательных возможностях. А понимать,
какие недостатки есть у этих замечательных возможностей - не
пытаются.

> > (Ну и да, про приоритезацию - смешно. Нет, это не про preload,
> > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с
> > бассейном и джакузи запроектирован в рамках стандарта, корректности
> > ждать не приходится.)
>
> Я о текущей примитивной приоретизации.
> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
> браузеры всё равно будут вынуждены использовать указания как рекомендацию.

Приоритизация в рамках стандарта HTTP/2 - это вполне конкретная
вещь, и именно она и упоминается в соответствующем докладе. И с
ней проблемы, именно потому она там и упоминается.

> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> > практике
> > > проталкивание критических ресурсов, которые в любом случае
> > приоритетны и
> > > будут загружены для отрисовки.
> >
> > Именно с этого я и начал: попробуйте на практике на отдельных
> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот
> > этого всего. Получите статистику, сравните.
> >
> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо,
> > потому что оно точно будет лучше, но тестировать вы ничего не
> > тестировали и не хотите.
>
> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
> Я задал вопрос о планах.

И получили на него ответ. А равно рекоменацию о том, с чего
начать, если вы вдруг считаете, что вам, тем не менее, надо.

Но почему-то пытаетесь спорить, убеждая меня в том, что статистика
не нужна, а надо слепо верить в теоретические рассуждения в
интернете.

> А учитывая, что использовать саму директиву http2_push затруднительно — один
> ресурс за раз, невозможность использования в if — и предвидя рекомендацию
> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и
> что уже попробовал сделать своими силами, и о том, какие возможности могли
> бы помочь в решении задачи.

Директив http2_push может быть сколько угодно. Если после
интерполяции переменных парамером оказалась пустая строка -
директива не делает ничего. То есь если хочется push'ить ресурсы
условно, то это можно сделать элементарно:

set $push "";
if ($want_push_css) {
set $push "/css/main.css";
}

http2_push $css;

Аналогично можно push'ить произвольное количество ресурсов, если
это нужно. Достаточно написать соответствующий конфиг.

> > Так это не работает. Придёте со
> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как
> > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике
> > есть вот только ссылка выше, из которой явно следует, что делать
> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.
>
> То, о чём я рассказываю и есть эксперимент.
> Проще внедрить это на dev- или даже production-версии сайта, чем готовить
> узкие эксперименты из двух страниц.
> В случае pdocution'а можно прогнозировать значимое изменение в статистике
> загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google
> Console или PageSpeed Insights.
>
> Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и
> несколько доступных браузеров и инструментов.

Ну вот для эксперимента - у вас есть все ресурсы, начиная от
собственно отдачи страниц с бекенда напрямую, без кеширования
SSI-кусков, с явно проставленными заголовками Link, и заканчивая
явной выдачей необходимых push'ей с помощью директивы http2_push.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: как работает gzip_static?

$
0
0
Hello!

On Sun, May 03, 2020 at 05:22:33AM +0300, sergio wrote:

> Есть два файла: test.html и test.html.gz
>
> Если gzip_static не указана, то отдаётся test.html
> (нет content-encoding=gzip в ff webdeveloper)
>
> Если написать gzip_static on, то отдаётся test.html.gz
> (content-encoding=gzip в ff webdeveloper)
>
>
> 1. Если после этого удалить test.html то nginx отвечает 404, хотя ни
> https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html ни
> https://docs.nginx.com/nginx/admin-guide/web-server/compression/ не
> говорят ни слова, о том, что для этого должны присутствовать ОБА файла.
>
> По-моему документацию стоит исправить.

Ответ 404 будет тогда и только тогда, когда файл test.html для
чего-то используется и отсутствует на диске. В случае, если
запрос идёт непосредственно к файлу, клиент поддерживает gzip, и
включён gzip_static - клиенту будет отправлен ответ из
test.html.gz.

> 2. Так же ngx_http_gzip_static_module.html говорит:
>
> With the “always” value .. It is useful if there are no uncompressed
> files on the disk anyway
>
> Но переключние gzip_static с on на anyway при отсутствующем test.html
> ничего не меняет: nginx продолжает отвечать 404.

В случае с "gzip_static always;" меняется ровно одно: становится
не важно, поддерживает ли клиент gzip, или нет - всегда будет
отправлен сжатый ответ. Если вы и в этом случае видите ответ 404,
то это означает, что до gzip_static дело не доходит, и ответ 404
отправляется раньше.

Например, так может быть, если у вас в конфиге стоит что-нибудь
вроде "try_files $uri =404;", то есть существование конкретного
файла проверяется явно.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Viewing all 53287 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>