[PATCH] Support FreeBSD jails for testing

Steven Hartland steven.hartland at multiplay.co.uk
Fri Oct 16 17:24:11 UTC 2015



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 <steven.hartland at multiplay.co.uk>
>> # 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?

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.

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?

     Regards
     Steve



More information about the nginx-devel mailing list