Dynamic Module Portability

[Joseph Spencer]

Got it.  Thank you so much!  I'll probably do a mix of both by having an
install script that parses the output of -V and provide guidance
accordingly for the stray cows :D

On Jun 29, 2017 7:07 AM, "Maxim Dounin" <mdounin at mdounin.ru> wrote:

Hello!

On Thu, Jun 29, 2017 at 12:27:50AM -0700, Joseph Spencer wrote:

> I'm looking to create a portable binary, and from everything I can read,
it
> is almost impossible.  The recommended approach seems to be to expose
> source code and require users to compile.  This is painful because it
> requires the source code and gcc to be available: a hard sell for the lazy
> sysadmin.
>
> My goal is to create a proprietary module that is used in conjunction with
> a paid service.  Users simply install the module and provide access token
> credentials.
>
> As you can imagine it's been really difficult, mainly because practically
> *every* configure option is compared at run time.

There are two basic approaches you can follow:

1. Distribute a module built with the same configure options and
on the same platform as a target nginx binary.  This is usually
possible as long as you are targeting a particular OS and a
package repository.  The "nginx -V" output should contain enough
information to reproduce the build.

2. Distribute a module built with the `--with-compat` configure
option (available since nginx 1.11.5).  Such a module will be
compatible with any nginx binary built with the `--with-compat`
option as well.

Since all supported branches (1.13.x mainline, 1.12.x stable)
already contain the `--with-compat` option, I would recommend
following (2) unless there are specific reasons to support older
versions.

> I added some logging, and found that the module signature is indeed
> embedded in the resulting .so file.  I was able to successfully use sed to
> get my module to work, but I'm thinking this is an obvious hack not even
> worth considering for a production binary:
>
> sed -i''
> 's|8,4,8,0011111111010111001111111111111111|8,4,8,
0000111111010111001110101111000110|'
> ngx_my_custom_module-nginx-1.11.5.so
>
> Having nginx -V is nice, but it could be beneficial to
> expose NGX_MODULE_SIGNATURE somehow.  That way I could have an installer
> script that checkes to ensure that essential modules are available and
> modify the binary after it's been downloaded.  I realize this is
dangerous,
> but I'm not willing to expose source code and require gcc yet.

It is not expected to work that way.  The signature is to prevent
accidental loading of incompatible modules.  It is neither
expected to be exposed to users, nor modified.  Instead, you
should built a compatible module based on the "nginx -V"
information, notably configure options - either by using the same
options, or using `--with-compat`, as suggested above.  If the
resulting signature do not match, it merely indicates that you've
done something wrong while building the module.

--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-devel mailing list
nginx-devel at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170629/386ff475/attachment.html>