On 19/10/2015 18:57, Maxim Dounin wrote:
Hello!

On Fri, Oct 16, 2015 at 06:24:11PM +0100, Steven Hartland wrote:

On 16/10/2015 13:05, Maxim Dounin wrote:
Hello!

On Fri, Oct 16, 2015 at 12:09:49AM +0000, Steven Hartland wrote:

# HG changeset patch
# User Steven Hartland <[email protected]>
# Date 1444954080 0
#      Fri Oct 16 00:08:00 2015 +0000
# Node ID c22d8299e7040e0de6f85b4e96d0dd953f7af644
# Parent  78b4e12e6efe642aff591234db0f0b040cae9b5e
Support FreeBSD jails for testing

Ensure the test directory is read and writable to the test user.

If you request 127.0.0.1 in a FreeBSD jail without specific access
to 127.0.0.1 then the socket binds to the interface address to
maintain compatibility. This results in the log entries being
>from the bound interface address. To prevent failure compare
with the bound IP when requesting 127.0.0.1 in combined test.
This jails behaviour is known to cause many problems, in
particular, it makes impossible nginx binary upgrades unless all
listen sockets are explicitly bound to jail's IP address.

Fortunately, this was resolved several years ago by introduction
of multi-IP jails.  You may try to use them for tests instead.

Adding quirks everywhere to support this brain-damaged "no
127.0.0.1" case looks like a wrong way to go for me.  Especially
given the fact that simple solution exists for years.

[...]
That doesn't fix the directory permission issue which causes pretty much
every test to fail, so is this still an option for inclusion?
Directory premissions may vary depending on umask used.  If your
umask breaks tests for you - you may try changing it while running
tests.  It also shouldn't be important when running tests under
non-privileged user.
Confirmed it doesn't effect a non-privileged user.

The default umask is 022 hence the issue if its run as privileged user with the default user as nobody which will have no access to the created directory.
I don't think this change should be added at all, and don't
see how it's related to FreeBSD jails your patch says it's about.
Fair comment with regards relevance, it clearly would prevent the tests being run as a privileged user on any Unix platform which has a 022 umask not just a FreeBSD jail.

Something to mention in the README, if you don't like the chmod?

With regards to binding 127.0.0.1, yes its possible to bind it using multi
IP, but doing so breaks security if you share it with the host, so its only
possible in some situations and usually only for a proper loop back address
which wouldn't be 127.0.0.1 just in that /24.
AFAIR, multi-IP jails used to provide per-jail loopback
addresses.  But may be I'm wrong here and mistaken with wildcard
addresses.
Not aware of that, you can assign any address you like but it still needs to consciously done and any sharing with the host has the potential to cause issues.

Maybe you're thinking of vnet support which provides a jail with their own virtual network stack, however that requires a kernel compiled with the VIMAGE option.

I do agree quirks aren't ideal, but as its only the one test I thought it
would be nice to have given there's a simple and reliable way to correct
said test.

With this in mind would you be up for making an exception in this case?
As long as it's the only test affected we may consider it.
Sergey, could you please take a look?


_______________________________________________
nginx-devel mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Reply via email to