Make mail module available dynamically

[mogul]

The NGINX mail module is a core NGINX module, useful for constructing proxies (my use-case). There are built-in configure flags for it; see docs here.

This PR builds the module dynamically so it will not change the buildpack's behavior for anyone who doesn't deliberately enable it. Including this module in the available dynamic modules removes the need for people (eg me) to separately maintain builds that are compatible with each new version of nginx supported by the buildpack!

[mogul]

Note I'm working from this precedent, noting that ngx_stream_module is explicitly documented as dynamically available.

The wording there...

To load a built-in module like ngx_stream_module,

...makes me think that the other core modules that can be compiled dynamically...

--with-http_xslt_module=dynamic
--with-http_image_filter_module=dynamic
--with-http_geoip_module=dynamic
--with-http_perl_module=dynamic
--with-stream_geoip_module=dynamic

...are candidates for the same treatment. I'll leave it for someone else to decide if that is a good idea!

[robdimsdale]

cc @cloudfoundry/wg-app-runtime-interfaces-buildpacks-web-servers-approvers - can't request for approval as that team isn't in CODEOWNERS

[robdimsdale]

This makes sense to me in principle, though I haven't dug into it particularly deeply. My understanding is that the --with-mail=dynamic instructions nginx to compile the plugin but not enable it until the user configures nginx to do so. I'm assuming that --with-mail_ssl_module compiles the module with ssl functionality.

[mogul]

Thanks so much for the merge! Any idea when the next release of the buildpack might happen?

[robdimsdale]

We aim to ship monthly, so probably in the order of days or maybe weeks.

[mogul]

Noting here from Slack:

I see there's logic somewhere that's handling ngx_stream_module.so specially... Where do I find that? Because the same thing has to happen with this module.
https://buildpacks.ci.cf-app.com/teams/main/pipelines/dependency-builds/jobs/build-nginx-1.23.x/builds/10#L63dfd23b:1549

[robdimsdale]

I think that output is coming from running make against the nginx configuration. We pass the flags to ./configure in the nginx source, followed by make. I don't think we're doing anything special with nginx's makefiles here.

[mogul]

I meant making sure that the .so binary files that're produced by the Makefile in modules/ are included in the /modules directory in the buildpack. If it just grabs all the files in that directory, that's probably fine.

[robdimsdale]

Gotcha. I'm not 100% sure, but I don't see any reference to handling ngx_stream_module specifically, so I'd assume it grabs all modules.

[mogul]

For the record... 😳

[robdimsdale]

Ah, that's frustrating. Glad you were able to find a solution with the buildpack though, even if it was a different module.

[mogul]

Since I'm the person who asked for this and supplied the PR, I'd understand if you wanted to roll it back out.

[robdimsdale]

I think this is really a question for @cloudfoundry/wg-app-runtime-interfaces-buildpacks-web-servers-approvers but personally I'd be happy to leave it in. The CF/V2 buildpacks tend to err on the side of compatibility rather than minimal surface area or footprint.

[mogul]

The CF/V2 buildpacks tend to err on the side of compatibility rather than minimal surface area or footprint.

OK, in that case I'll draw attention to this again!

The wording there...

To load a built-in module like ngx_stream_module,

...makes me think that the other core modules that can be compiled dynamically...

--with-http_xslt_module=dynamic
--with-http_image_filter_module=dynamic
--with-http_geoip_module=dynamic
--with-http_perl_module=dynamic
--with-stream_geoip_module=dynamic

...are candidates for the same treatment. I'll leave it for someone else to decide if that is a good idea!