OpenResty 1.15.8.1 RC1 is now available for testing

yichun · 2019-03-03T06:03:31+00:00

Hello!The If-Unmodified-Since and If-Match header will lead the Nginx "filter finalize",and this process will clear all modules' context, inclu...

OpenResty 1.15.8.1 RC1 is now available for testing

yichun

Hi folks,

I've just kicked out a new release candidate, OpenResty 1.15.8.1 RC1,
for the community to test out. You can download the source tarball and
the Windows binary packages from here

https://openresty.org/en/ann-1015008001rc1.html

Complete changelogs can also be found on the web page above. We have
so many new features and important bug fixes that we had to postpone
this version over and over again. But finally it is here.

Feedback welcome!

The formal version 1.15.8.1 will be out if we do not get showstoppers
reported by the community in the next week or so.

Thanks!

Best regards,
Yichun

rpaprocki

Wonderful! So exciting to see all the hard work materialize :D

It would be great to see some formal documentation for things like 'table.new' and 'table.clear' alongside https://github.com/openresty/luajit2#new-api - docs for these primatives is essentially insider knowledge (try google searching "luajit table.clear" :D).

On Sat, Mar 2, 2019 at 2:03 PM Yichun Zhang <yi...@openresty.com> wrote:

Hi folks,

I've just kicked out a new release candidate, OpenResty 1.15.8.1 RC1,
for the community to test out. You can download the source tarball and
the Windows binary packages from here

https://openresty.org/en/ann-1015008001rc1.html

Complete changelogs can also be found on the web page above. We have
so many new features and important bug fixes that we had to postpone
this version over and over again. But finally it is here.

Feedback welcome!

The formal version 1.15.8.1 will be out if we do not get showstoppers
reported by the community in the next week or so.

Thanks!

Best regards,
Yichu.

yichun

Hi Robert,

On Sat, Mar 2, 2019 at 2:59 PM Robert Paprocki wrote:
> It would be great to see some formal documentation for things like 'table.new' and 'table.clear' alongside https://github.com/openresty/luajit2#new-api - docs for these primatives is essentially insider knowledge (try google searching "luajit table.clear" :D).
>

They are documented by LuaJIT official here:

    https://github.com/openresty/luajit2/blob/v2.1-agentzh/doc/extensions.html

One quick way to access such docs is on the command line like this:

    restydoc -s table.new

and also

    restydoc -s table.clear

These docs in restydoc's indexes were extracted from the
extensions.html given above.

The latest table.* API docs were not included in the RC1 version BTW
but will be included in the next version (already committed to git
master).

Best,
Yichun

hroostik

Wow such a great work!

phanuc2016

Dear Yichun,

I can compile OpenResty 1.15.8.1 RC1 from source in my macOS 10.14.2 (Mojave).

My system use OpenSSL 1.0.2q.

I still looking for how to compile with OpenSSL 1.1.1 to use TLS 1.3.

I have tried but fail.

Best regards,

Phanu C.

agentzh

Hello!

On Tue, Mar 5, 2019 at 2:33 AM <phan...@gmail.com> wrote:
> I can compile OpenResty 1.15.8.1 RC1 from source in my macOS 10.14.2 (Mojave).
>
> My system use OpenSSL 1.0.2q.
> I still looking for how to compile with OpenSSL 1.1.1 to use TLS 1.3.
>

You could specify your own openssl via `./configure --with-openssl=DIR`. See

$ ./configure --help|grep openssl
  --with-openssl=DIR                 set path to OpenSSL library sources
  --with-openssl-opt=OPTIONS         set additional build options for OpenSSL

But ssl_*_by_lua* directives might not work properly. For normal
users, it's recommended to use our brew instead:

https://openresty.org/en/download.html#macosmac-os-x

If you have problems, please provide as much details as possible,
especially the raw failure output. Simply saying "failed" won't be
helpful for the community to help you out. Thanks for your
understanding.

Yichun

thibaultcha

Hi,

What exactly is failing? I just linked OpenResty against OpenSSL 1.1.1b
and did not see any noticeable failures in the ngx_lua test suite
(except a couple of expected ones due to ssl_session_fetch and ssl_store).

As long as you do not need to use ssl_session_fetch_by_lua* and
ssl_session_store_by_lua*, you should be able to link OpenResty with
OpenSSL 1.1.1 like so:

Configure OpenSSL as such (feel free to tweak the options, but preserve
the 'shared' one):

    ./config --prefix=/usr/local/opt/ \
        --openssldir=/usr/local/opt/ \
        shared \
        enable-ssl3
    make
    make install_sw

And compile OpenResty as such:

    ./configure --prefix=/usr/local/opt/openresty \
        --with-cc-opt="-I/usr/local/opt/include" \
        --with-ld-opt="-L/usr/local/opt/lib -Wl,-rpath,/usr/local/opt/lib" \
        --with-http_ssl_module
    make
    make install

Again, feel free to tweak options at your convenience.

In the OpenResty packages, we need to upgrade our custom patches for
OpenSSL 1.1.1 before bumping the officially supported version (again,
due to the two aforementioned ngx_lua callbacks that require these patches).

Best,
Thibault

On 3/5/19 2:33 AM, phan...@gmail.com wrote:
> Dear Yichun,
> 
> I can compile OpenResty 1.15.8.1 RC1 from source in my macOS 10.14.2
> (Mojave).
> 
> My system use OpenSSL 1.0.2q.
> I still looking for how to compile with OpenSSL 1.1.1 to use TLS 1.3.
> I have tried but fail.
> 
> Best regards, 
> Phanu C. .

phanuc2016

Dear

I have tried to compile it again with following command:

./configure --with-cc-opt="-I/usr/local/Cellar/openssl\@1.1/1.1.1b/include" --with-ld-opt="-L/usr/local/Cellar/openssl\@1.1/1.1.1b/lib"

gmake

gmake install

otool -L /usr/local/openresty/bin/openresty

/usr/local/openresty/bin/openresty:

/usr/local/openresty/luajit/lib/libluajit-5.1.2.dylib (compatibility version 2.1.0, current version 2.1.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)

/opt/local/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.10.0)

/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)

/usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)

/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)

Now it work and link to openssl-1.1.1b.

I have to add a backslash in front of @ to fix it:

./configure --with-cc-opt="-I/usr/local/Cellar/openssl\@1.1/1.1.1b/include" --with-ld-opt="-L/usr/local/Cellar/openssl\@1.1/1.1.1b/lib"

Regards,

Phanu C.

On Wednesday, March 6, 2019 at 2:56:05 AM UTC+7, Thibault Charbonnier wrote:

Hi,

What exactly is failing? I just linked OpenResty against OpenSSL 1.1.1b
and did not see any noticeable failures in the ngx_lua test suite
(except a couple of expected ones due to ssl_session_fetch and ssl_store).

As long as you do not need to use ssl_session_fetch_by_lua* and
ssl_session_store_by_lua*, you should be able to link OpenResty with
OpenSSL 1.1.1 like so:

Configure OpenSSL as such (feel free to tweak the options, but preserve
the 'shared' one):

./config --prefix=/usr/local/opt/ \
--openssldir=/usr/local/opt/ \
shared \
enable-ssl3
make
make install_sw

And compile OpenResty as such:

./configure --prefix=/usr/local/opt/openresty \
--with-cc-opt="-I/usr/local/opt/include" \
--with-ld-opt="-L/usr/local/opt/lib -Wl,-rpath,/usr/local/opt/lib" \
--with-http_ssl_module
make
make install

Again, feel free to tweak options at your convenience.

In the OpenResty packages, we need to upgrade our custom patches for
OpenSSL 1.1.1 before bumping the officially supported version (again,
due to the two aforementioned ngx_lua callbacks that require these patches).

Best,
Thibault

On 3/5/19 2:33 AM, phanu...@gmail.com wrote:
> Dear Yichun,
>
> I can compile OpenResty 1.15.8.1 RC1 from source in my macOS 10.14.2
> (Mojave).
>
> My system use OpenSSL 1.0.2q.
> I still looking for how to compile with OpenSSL 1.1.1 to use TLS 1.3.
> I have tried but fail.
>
> Best regards,
> Phanu C. .

joshua.eichorn

Testing the OpenResty rc and i'm seeing write guard warnings in several places.

One was a bug someone forgot a local so i see the value of the warning, but in some places we are caching values in global vars for performance reasons and also need to update them.

My understanding of the Luajit concurrency model is that writes to variables are atomic, so assuming i'm taking appropriate precautions this is safe behavior.

Is the expectation that I update __newindex on the variables where i've determined this is safe, or is there some other pattern I should be using for per worker caches.

agentzh

Hello!
On Thu, Mar 7, 2019 at 1:39 PM Joshua Eichorn wrote:
> One was a bug someone forgot a local so i see the value of the warning, but in some places we are caching values in global vars for performance reasons and also need to update them.
> My understanding of the Luajit concurrency model is that writes to variables are atomic, so assuming i'm taking appropriate precautions this is safe behavior.
>

A single write operation is atomic, of course since it's using a
single thread in the same worker process. The guard protect cases for
concurrent light threads using the same global variable, like this:

Time         light thread A                          light thread B
0:00         [global v = 2]
0:01         [yield]
0:02                                                        [resume]
0:03                                                      [global v = 3]
0:04         [read global v,
                 assuming it's still 2]

> Is the expectation that I update __newindex on the variables where i've determined this is safe, or is there some other pattern I should be using for per worker caches.
>

If you want to share data across all (concurrent) requests served by
the same worker process, then you should use local variables anchored
to your own Lua modules, like this:

    https://github.com/openresty/lua-resty-core/blob/master/lib/resty/core/regex.lua#L64

The  module-level "local" variable can also be a resty.lrucache
instance, like this:

    https://github.com/openresty/lua-resty-core/blob/master/lib/resty/core/regex.lua#L63

    https://github.com/openresty/lua-resty-core/blob/master/lib/resty/core/regex.lua#L436

Regards,
Yichun