Nginx on Debian: dynamic network interfaces

Server NGINX
1

Hello,

Facing issues on Debian with official nginx packages, I filled a bug up
on
the Debian tracker which ended up as being closed since Debian refers to
the faulty service(s), nginx being one.

​Bug #785253 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785253​

​I could not fill a bug on nginx since OAuth 2.0
authentication through Google went away (already adressed in a separated
thread).

Could someone here confirms nginx (and not the OS) is to be adressed?
Thanks,

B. R.

2

Hello!

On Tue, May 26, 2015 at 05:53:00PM +0200, B.R. wrote:

thread).

Could someone here confirms nginx (and not the OS) is to be adressed?

Looking though the bug in question I don’t see anything to fix in
nginx. As far as I understand the problem, it is as follows:

  1. you are trying to start nginx without access to DNS;
  2. your nginx configuration contains DNS names and therefore
    requires access to DNS for nginx to start, as nginx resolves
    DNS names on startup;

You should either configure your OS to ensure that you start nginx
after DNS is available or change your nginx configuration to avoid
DNS names.

–
Maxim D.
http://nginx.org/

3

The keyword here is ‘dynamic’.

I even modified the service configuration to depend on ‘named’, but the
thing is that being dynamic, the network and name resolution dependency
might be fulfilled while the actual service is not ready yet. Those
dependencies might (dis)appear following this ‘hot-plug’ behavior and
services should adapt to this.
‘auto’ (synchronous) differs from ‘hot-plug’ (asynchronous).

Is there really nothing you can do on your side about it?
It is a little tiresome to see both parts throwing the ball back.

​Thanks,​

B. R.

4

On Wed, May 27, 2015 at 09:51:40AM +0200, B.R. wrote:

Hi there,

Is there really nothing you can do on your side about it?
It is a little tiresome to see both parts throwing the ball back.

If nginx sees host names in particular places in the config file, it
currently chooses to resolve them at start time.

I suspect it will be slow for you to get a patch that changes that
behaviour accepted into nginx.

You can configure your system resolver to avoid needing DNS, by putting
the host names into /etc/hosts.

You can configure your nginx to avoid resolving the host names, by one
of:

  • not using host names, instead using IP addresses
  • using host names, and including an upstream{} which includes the IP
    address
  • including a variable in the directive that includes the host name,
    so nginx will not try to resolve it at start time

(which is pretty much the previous answer you got, but with a few
specific
ways that you can implement it).

Good luck with it,

f

Francis D. [email protected]

5

On 27/05/2015 10:51, B.R. wrote:

It is a little tiresome to see both parts throwing the ball back.
JFYI, systemd works around that issue by introducing a pseudo-service
that essentially sleeps for some amount of time until network is
(hopefully) up, see
NetworkTarget .

–
Konstantin P.

6

B.R. Wrote:

The keyword here is ‘dynamic’.

I even modified the service configuration to depend on ‘named’, but
the
thing is that being dynamic, the network and name resolution
dependency

Why not simplify things, set nginx start to manual, create a service
that
runs a script, inside that script attempt to resolve some dns name, when
it
fails wait a while and loop back, when it succeeds start nginx and exit
script.

Posted at Nginx Forum:

7

Thanks to all for your input.

@Konstantin
‘workaround’ has a very specific meaning there is a bug and a way to
avoid
it.
I want to address the bug where it lies, the latter being unclear still.
systemd has probably benefits and some drawbacks which are important to
me:
I am sticking to sysvinit.

@Francis
Thanks for your input.
I know that not using names meanings name resolution won’t be needed.
However cutting in features works around bugs, meaning there is one.
DNS has been invented because of many difficulties involved when you use
IP
addresses: using names in a configuration, especially for an external
resolver over which I do not have control is the way to go.
I do not want to make breakable configurations simply because my OS and
one
service does not understand each other.
I made all that fuss and I am spending my time to identify a bug and
address it.
FYI, using the old ‘auto’ (synchronous) mode on the network service is
also
a workaround, which seems more reliable to me. I do not want to stick
with
this since the OS default is to use ‘hotplug’. That is a workaround… I
want the chase the bug. (Am I repeating myself? ;o) )

@Maxim
I understand from your words that using hotplug interfaces is currently
not
supported by nginx (as I observed).
Now there are (at least) 2 ways of seing it:
1°) Considering the asynchronous nature of the new default network
configuration of Debian, the services should adapt to handle cases where
the network is ‘not really up’ or some features are missing (no IP
address
bound, name resolution not working) --> Debian’s stance, making nginx
service faulty
2°) The network should be up when (and only when) it is advertised so,
making the services dependencies on system facilities reliable and safe
–>
Debian OS is faulty
Removing features because ‘it does not work’ is in no way a solution to
my
eyes.

There might have huge divergence on how to embrace things, but if
Debian’s
claims on the fact service should have proper support are right and {if
you
disagree with the way Debian has taken or you do not want to change your
way}, you shall then declare yourself not supporting the Debian distro.

@itpp2012
I love your way of ‘simplifying’ things.
I probably differ on the definition, since to me ‘simpler’ converges
towards ‘standard’ and/or ‘default’.
Making scripts is one of the multiple workarounds, but that is
definitely
not the solution. Will you make everyone using nginx on Debian using
that
trick, as soon as they need DNS on a default ‘hotplug’ interface with
sysvinit?

B. R.

8

B.R. Wrote:

Will you make everyone using nginx on Debian using
that
trick, as soon as they need DNS on a default ‘hotplug’ interface with
sysvinit?

No I’d make everyone use IP addresses with the EBLB I’ve introduced a
while
ago with sources. For a fast acting webservice DNS is outdated,
outperformed
and is only useful for clients. If it was up to me I’d rip dns out
completely from nginx.

Posted at Nginx Forum:

9

Hello!

On Wed, May 27, 2015 at 09:51:40AM +0200, B.R. wrote:

It is a little tiresome to see both parts throwing the ball back.
As I already tried to explain, that’s not about “both parts”, but
rather about configuration you wrote for both parts. It’s up to
you to change configuration to something consistent. You have to
either change your OS configuration (to ensure that appropriate
names are resolvable on nginx start), or change your nginx
configuration (to ensure it won’t try to resolve names).

–
Maxim D.
http://nginx.org/

10

On Wed, May 27, 2015 at 6:40 PM, itpp2012 [email protected] wrote:

​Then I am one of the many glad that this is not up to you.

@nginx
Will you do anything to adapt to the new way on handling services
asynchronously​

​on Debian or not?​

(As a side note, and as reported here multiple times by different
people,
OpenID through Google does not work, so I was unable to fill up a bug
there.
Would you provide a way of creating accounts on your PKI?)

Thanks,

B. R.