Re: Persistent connections timeout (keepalive on upstream)
--On Wednesday, August 26, 2015 3:11 PM -0400 ionut_rusu
nginx-fo...@nginx.us wrote:
The short question is how can be set the timeout for an upstream for
persistent connections (using keepalive) - looks like they never timeout.
Details:
I have a configuration where i need to setup a reverse proxy for SSL
connections, and reuse the backend SSL connections. For doing this i'm
using the keepalive directive on the upstream, something like this:
...
upstream backend {
server backend-host.com:443;
keepalive 10;
}
Have you tried the nginx keepalive module?
https://github.com/nviennot/nginx-tcp-keepalive
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: SASL support for mail proxy in NGINX
--On Friday, August 22, 2014 5:50 PM -0500 Kunal Pariani kpari...@zimbra.com wrote: Hello, Wanted to know if there's a plan to add SASL support to Nginx anytime soon ? Zimbra has patches that add SASL support for POP3 IMAP. Would you be interested in that as a contribution from us ? We plan on adding SASL support to SMTP as well unless you guys have plan to do that already ? Any nginx developers have any thoughts on this? Thanks, Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: SASL support for mail proxy in NGINX
--On Tuesday, September 09, 2014 12:49 AM +0400 Maxim Dounin mdou...@mdounin.ru wrote: We plan on adding SASL support to SMTP as well unless you guys have plan to do that already ? Any nginx developers have any thoughts on this? When talking to mail backends, nginx doesn't use SASL for authentication as it's believed to be superfluous to use it instead of native protocol commands in the non-hostile backend environment. I'm not sure what you mean by this, can you expand please? There is SASL support in nginx mail module though, and it happily authenticates users with PLAIN, LOGIN and CRAM-MD5 SASL mechanisms (as long as http_auth script used is able to handle this). These are particularly limited SASL mechanisms. Ours adds support for linking to cyrus-sasl, for extended SASL mechanisms such as GSSAPI, SPNEGO, etc. If that's not of interest, that's fine, but it's generally much more useful security wise. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] The directives such as user, rlimit_core should also be effective on master process
--On Tuesday, August 05, 2014 12:58 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Tue, Aug 05, 2014 at 02:26:59AM -0500, Kunal Pariani wrote: # HG changeset patch # User Kunal Pariani kpari...@zimbra.com # Date 1407194790 25200 # Mon Aug 04 16:26:30 2014 -0700 # Node ID f25ab24517bb5e45b1b7fa1a1502b907f2cff213 # Parent f8764e20fcd7f87d98fe97f82b2a8d0a77ed9097 The directives such as user, rlimit_core should also be effective on master process No, thanks. The master process should remain root to be able to read priveleged configuration files during configuration reload, open listening sockets on priveleged ports and so on. The drop to the user happens *after* the files ports have been opened already. This is how many *nix server processes work, as an additional security measure. We've been using nginx with this patch since nginx 0.5.37, so it's quite heavily tested. See also: http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/minimize-privileges.html and http://www.ibm.com/developerworks/linux/library/l-sppriv/index.html -Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[PATCH 1 of 2] HTTP: Add client source port to any error that is logged
# HG changeset patch
# User Quanah Gibson-Mount qua...@zimbra.com
# Date 1398357557 18000
# Node ID 4b7d2e503c06758330aabcc21ffbbab77f09568e
# Parent 1b0c55d38d0b7ba69dcad79760a3fadc30696a9d
HTTP: Add client source port to any error that is logged
For TRAC ticket 531
diff -r 1b0c55d38d0b -r 4b7d2e503c06 src/http/ngx_http_request.c
--- a/src/http/ngx_http_request.c Thu Apr 24 16:54:23 2014 +0400
+++ b/src/http/ngx_http_request.c Thu Apr 24 11:39:17 2014 -0500
@@ -3548,6 +3548,11 @@
u_char *p;
ngx_http_request_t *r;
ngx_http_log_ctx_t *ctx;
+ngx_uint_t remote_port=0;
+struct sockaddr_in *sin;
+#if (NGX_HAVE_INET6)
+struct sockaddr_in6*sin6;
+#endif
if (log-action) {
p = ngx_snprintf(buf, len, while %s, log-action);
@@ -3557,15 +3562,32 @@
ctx = log-data;
-p = ngx_snprintf(buf, len, , client: %V, ctx-connection-addr_text);
-len -= p - buf;
-
r = ctx-request;
-
if (r) {
+switch (r-connection-sockaddr-sa_family) {
+#if (NGX_HAVE_INET6)
+case AF_INET6:
+sin6 = (struct sockaddr_in6 *) r-connection-sockaddr;
+remote_port = ntohs(sin6-sin6_port);
+break;
+#endif
+
+default: /* AF_INET */
+sin = (struct sockaddr_in *) r-connection-sockaddr;
+remote_port = ntohs(sin-sin_port);
+break;
+}
+
+if (remote_port remote_port 65536) {
+ p = ngx_snprintf(buf, len, , client: %V:%ui,
ctx-connection-addr_text,remote_port);
+} else {
+ p = ngx_snprintf(buf, len, , client: %V,
ctx-connection-addr_text);
+}
+len -= p - buf;
+
return r-log_handler(r, ctx-current_request, p, len);
-
} else {
+p = ngx_snprintf(buf, len, , client: %V,
ctx-connection-addr_text);
p = ngx_snprintf(p, len, , server: %V,
ctx-connection-listening-addr_text);
}
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
[PATCH 0 of 2] TRAC 531 - Add source port logging for HTTP(S) error logging and all proxied email client connections
The following patches ensure that the source port is logged for all client connections. This is to resolve TRAC issue 531. Belgium is mandating that the source port be logged for all client connections for Carrier Grade NAT. This may soon extend to the entire European Union. ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH 1 of 2] HTTP: Add client source port to any error that is logged
--On April 24, 2014 at 9:37:54 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: I tend to say No, thanks. If needed due to local regulations, $remote_port can be added to log_format. $remote_port in the log format section only covers errors logged to the access log, it does not cover errors in the error log. The submitted patch handles the error log. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH 1 of 2] HTTP: Add client source port to any error that is logged
--On April 24, 2014 at 10:41:43 AM -0700 Quanah Gibson-Mount qua...@zimbra.com wrote: --On April 24, 2014 at 9:37:54 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: I tend to say No, thanks. If needed due to local regulations, $remote_port can be added to log_format. $remote_port in the log format section only covers errors logged to the access log, accesses even.. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH 1 of 2] HTTP: Add client source port to any error that is logged
--On April 24, 2014 at 9:56:48 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: $remote_port in the log format section only covers errors logged to the access log, it does not cover errors in the error log. The submitted patch handles the error log. I understand the difference, thank you. The ticket in question only talked about error_log in context of mail module, where is no separate access logging to meet the alleged regulations. Yes, that is true, but why only implement a partial solution? With CGN, only logging the IP is fairly useless in all cases. To truly get useful information going forward, the IP + PORT of the client should logged in all cases. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH 1 of 2] HTTP: Add client source port to any error that is logged
--On April 24, 2014 at 10:26:07 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: Yes, that is true, but why only implement a partial solution? With CGN, only logging the IP is fairly useless in all cases. To truly get useful information going forward, the IP + PORT of the client should logged in all cases. Access log certainly can be configured to provide enough enformation to match any given error log message to a port if needed. There is no need to implement anything, solution is already here. The error log currently only provides the IP. While I'm guessing you could do things like correlate timestamps, it's still going to be a pain. Having the port readily available everywhere makes tracking a specific user much easier to do. And, by asking about why implement a partical solution you are overlooking the fact that proposed solution is partial as well - it doesn't change c-addr_text to ensure proper logging in all places (this would be a bad idea for other reasons, but it's another question), but rather tries to hack on the http error logging code to introduce remote port logging. This is far from being a complete solution. I'm certainly willing to address any deficiencies, but I'd want to make sure it would follow whatever you want in the product before investing more time on it. ;) For now it meets the needs of our customer in Belgium who has to start dealing with the legal requirements of client port logging sooner than later. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH 2 of 2] MAIL: Always log the source port of the client
--On April 24, 2014 at 9:47:39 PM +0400 Maxim Dounin mdou...@mdounin.ru wrote: Hello! Much like http-related counterpart, this looks like a hack for me. We may consider adding port to the client connected messages (not sure), but I don't think we have to do anything beyond that. For our end clients, who have to actually examine particular error messages, it is useful to have the port logged in any of the connection data. If the current solution is hackish, I'm happy to work out something more acceptable if you want to note what that would be. ;) --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
