Re: Nginx as a Proxy for WSUS static caching not working

[nnvc]

Dear good afternoon

I'm going through the same situation.

Did you solve it?

thank's

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,220614,273712#msg-273712

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

Re: Welcome to nginx on Debian!

[shiz]

/var/www/html/index.nginx-debian.html

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,273701,273710#msg-273710

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

nginx-extras

[Jeff Dyke]

I realize this may not be the best place to ask, but thought someone may
know.

I am using nginx-extras which runs 1.10, for some very helpful lua
functionality, and nginx stable just hit the apt repositories on 1.12, does
anyone know how quickly nginx-extras may be updated to 1.12?

I would like to avoid self compilation as all machines are managed via
saltstack. and i would like to take advantage of the latest stable.

Thanks for any info, even if only historical knowledge.  I'll also put this
on the ubuntu lists, but feel it will just get lost in the volume.

Best,
Jeff
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: upstream - behavior on pool exhaustion

[B.R. via nginx]

'down' should not translate into any kind of attempt, so nothing should
really appear for the servers in that static state.
For 'unavailable' servers, for the most part the content of the variables
should be the same.

Starting from the example I provided, here is what I expected to see:
- $upstream_addr: :, :, :, :, :, :
- $upstream_response_time: 0.000, 0.000, 0.000, 0.000, 0.001, 0.000

That, associated with the 502 response from the HTTP language, is
sufficient to interpret the log entry as: the request failed to find a
proper backend after having attempted communication with the 6 specified
active backends. It is pretty straightforward.
If you want to add something to explicitely states the whole upstream group
is down, this should go to the error log.
At the very least, if the current way of working is kept, the grammar of
the content of the $upstream_* variables should be specified.

​Does not that seem reasonable?
---
*B. R.*

On Mon, Apr 17, 2017 at 6:09 PM, Ruslan Ermilov  wrote:

> On Sat, Apr 15, 2017 at 03:55:20AM +0200, B.R. via nginx wrote:
> > Let me be clear here:
> > I got 6 active servers (not marked down), and the logs show 1 attempt on
> > each. They all failed for a known reason, and there is no problem there.
> > Subsequently, the whole pool was 'down' and the response was 502.
> > Everything perfectly normal so far.
> >
> > ​What is unclear is the feature (as you classified it) of having a fake
> > node named after the pool appearing in the list of tried upstream
> servers.​
> > It brings confusion more than anything else: having a 502 response + the
> > list of all tried (and failed) nodes corresponding with the list of
> active
> > nodes is more than enough to describe what happened.
> > The name of the upstream group does not corresponding to any real asset,
> it
> > is purely virtual classification. It thus makes no sense at all to me to
> > have it appearing as a 7th 'node' in the list... and how do you interpret
> > its response time (where you got also a 7th item in the list)?
> > Moreover, it is confusing, since proxy_pass handles domain names and one
> > could believe nginx treated the upstream group name as such.
>
> Without the six attempts, if all of the servers are unreachable (either
> "down" or "unavailable" because they have failed previously) at the time
> the request starts, what do you expect to see in $upstream_*?
>
> > On Fri, Apr 14, 2017 at 10:21 AM, Ruslan Ermilov  wrote:
> >
> > > On Fri, Apr 14, 2017 at 09:41:36AM +0200, B.R. via nginx wrote:
> > > > Hello,
> > > >
> > > > Reading from upstream
> > > >  l#upstream>
> > > > docs, on upstream pool exhaustion, every backend should be tried
> once,
> > > and
> > > > then if all fail the response should be crafted based on the one
> from the
> > > > last server attempt.
> > > > So far so good.
> > > >
> > > > I recently faced a server farm which implements a dull nightly
> restart of
> > > > every node, not sequencing it, resulting in the possibility of
> having all
> > > > nodes offline at the same time.
> > > >
> > > > However, I collected log entries which did not match what I was
> expected.
> > > > For 6 backend nodes, I got:
> > > > - log format: $status $body_bytes_sent $request_time $upstream_addr
> > > > $upstream_response_time
> > > > - log entry: 502 568 0.001 :,  2>:,
> > > > :, :, :,
>  > > > address 6>:, php-fpm 0.000, 0.000, 0.000, 0.000, 0.001, 0.000,
> > > 0.000
> > > > I got 7 entries for $upstream_addr & $upstream_response_time,
> instead of
> > > > the expected 6.
> > > >
> > > > ​Here are the interesting parts of the configuration:
> > > > upstream php-fpm {
> > > > server : down;
> > > > server : down;
> > > > [...]
> > > > server :;
> > > > server :;
> > > > server :;
> > > > server :;
> > > > server :;
> > > > server :;
> > > > keepalive 128;
> > > > }
> > > >
> > > > ​server {
> > > > set $fpm_pool "php-fpm$fpm_pool_ID";
> > > > [...]
> > > > location ~ \.php$ {
> > > > [...]
> > > > fastcgi_read_timeout 600;
> > > > fastcgi_keep_conn on;
> > > > fastcgi_index index.php;
> > > >
> > > > include fastcgi_params;
> > > > fastcgi_param SCRIPT_FILENAME
> > > > $document_root$fastcgi_script_name;
> > > > [...]
> > > > fastcgi_pass $fpm_pool;
> > > > }
> > > > }
> > > >
> > > > ​The question is:
> > > > php-fpm being an upstream group name, how come has it been tried as a
> > > > domain name in the end?
> > > > Stated otherwise, is this because the upstream group is considered
> > > 'down',
> > > > thus somehow removed from the possibilities, and nginx trying one
> last
> > > time
> > > > the name as a domain name to see if something answers?
> > > > This 7th request is definitely strange to my point of view. Is it a
> bug
> > > or
> > > > a feature?
> > >
> > > A feature.
> >

Welcome to nginx on Debian!

[xstation]

Welcome to nginx on Debian! is the default  holding page

where is this stored on debian 8 jessie?

thankyou
xstation

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,273701,273701#msg-273701

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